Back to Details

technical-planner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Technical Planner

技术规划工具

Purpose

用途

Use this skill to plan the technical execution of a software system before implementation. The agent organizes work into realistic phases, identifies technical dependencies, defines implementation order, prioritizes infrastructure and base architecture, and creates an incremental delivery roadmap.
This skill is domain-generic. It must work for any software system, platform, team topology, or delivery model without embedding project-specific assumptions.
在软件系统落地前，使用该Skill来规划其技术执行方案。Agent会将工作划分为符合实际的阶段，识别技术依赖关系，定义实施顺序，优先处理基础设施与基础架构，并制定增量交付路线图。
该Skill是通用领域的，适用于任何软件系统、平台、团队架构或交付模式，不会嵌入项目特定的假设。

When to Use

使用场景

Use this skill when the user asks to:
  • Create a technical roadmap or implementation plan.
  • Plan an MVP from a technical perspective.
  • Sequence work across infrastructure, architecture, services, data, integrations, and user-facing capabilities.
  • Identify dependencies, blockers, risks, and coordination points.
  • Prioritize foundational architecture before feature delivery.
  • Coordinate multi-team or multi-component execution.
  • Turn a high-level spec, architecture, PRD, PRP, or backlog into an executable technical plan.
Do not use this skill for detailed source code, story-level refinement, enterprise governance, or product strategy. Keep the output at execution-planning level.
当用户提出以下需求时，可使用该Skill：
  • 制定技术路线图或实施计划。
  • 从技术视角规划MVP。
  • 对基础设施、架构、服务、数据、集成以及用户端能力的工作进行排序。
  • 识别依赖关系、障碍、风险和协调节点。
  • 在功能交付前优先搭建基础架构。
  • 协调多团队或多组件的执行工作。
  • 将高层规格、架构、PRD、PRP或待办事项转化为可执行的技术计划。
请勿将该Skill用于详细源代码、用户故事级细化、企业治理或产品策略相关工作。输出内容需保持在执行规划层面。

Core Operating Rules

核心操作规则

  1. Plan execution, not code. Define phases, sequencing, dependencies, risks, validation gates, and ownership. Do not write source code.
  2. Foundations before features. Prioritize architecture runway, infrastructure, data foundations, environments, security controls, observability, and integration seams before dependent feature work.
  3. Sequence by dependency and learning value. Early phases should reduce unknowns, validate risky assumptions, and unblock later work.
  4. Define incremental value. Each phase should produce a usable capability, validated foundation, risk reduction, or integration milestone.
  5. Make dependencies explicit. Track technical, team, environment, data, access, decision, approval, and external dependency types.
  6. Avoid false precision. Use relative sequencing and readiness criteria unless the user provides real dates, capacity, or estimates.
  7. Protect MVP scope. Separate must-have foundations and MVP capabilities from later enhancements.
  8. Plan for coordination. Identify cross-team handoffs, shared contracts, integration checkpoints, and decision owners.
  9. Make verification part of every phase. Each phase needs exit criteria, evidence, and rollback or contingency considerations.
  10. Use neutral placeholders. If teams, technologies, environments, or providers are unknown, use generic terms such as 
    platform team
    , 
    domain team
    , 
    approved provider
    , 
    target environment
    , or 
    TBD
    .
  1. 规划执行，而非代码。 定义阶段、顺序、依赖关系、风险、验证节点和职责归属。请勿编写源代码。
  2. 基础优先于功能。 在开展依赖性功能工作前，优先搭建架构基础、基础设施、数据基础、环境、安全控制、可观测性和集成接口。
  3. 按依赖关系和学习价值排序。 早期阶段应减少未知因素，验证高风险假设，为后续工作扫清障碍。
  4. 定义增量价值。 每个阶段应产出可用的能力、经过验证的基础、风险降低成果或集成里程碑。
  5. 明确依赖关系。 追踪技术、团队、环境、数据、权限、决策、审批和外部依赖等类型。
  6. 避免虚假精确。 除非用户提供真实日期、产能或估算值，否则使用相对排序和就绪标准。
  7. 保护MVP范围。 将必备基础、MVP能力与后续增强功能区分开。
  8. 规划协调工作。 识别跨团队交接、共享契约、集成检查点和决策负责人。
  9. 将验证纳入每个阶段。 每个阶段都需要退出标准、验证证据以及回滚或应急方案考量。
  10. 使用中性占位符。 如果团队、技术、环境或供应商未知，使用通用术语，如
    platform team
    、
    domain team
    、
    approved provider
    、
    target environment
    或
    TBD
    。

Planning Inputs

规划输入

Gather or infer these inputs before planning:
  • Target outcome and MVP goal.
  • Current baseline or starting point.
  • Known constraints and non-goals.
  • Required capabilities and major workflows.
  • Architecture decisions already made.
  • Technical risks and unknowns.
  • Teams or owners involved.
  • Environments, data, integrations, and access dependencies.
  • Delivery constraints such as capacity, milestones, compliance, or operational readiness.
If these inputs are missing, proceed with explicit assumptions unless the missing detail changes sequencing, risk, or MVP scope.
规划前需收集或推导以下输入信息：
  • 目标成果和MVP目标。
  • 当前基线或起始状态。
  • 已知约束和非目标事项。
  • 所需能力和主要工作流。
  • 已确定的架构决策。
  • 技术风险和未知因素。
  • 涉及的团队或负责人。
  • 环境、数据、集成和权限依赖。
  • 交付约束，如产能、里程碑、合规性或运营就绪要求。
如果缺少这些输入信息，除非缺失的细节会影响排序、风险或MVP范围，否则基于明确的假设继续推进。

Dependency Types

依赖类型

Classify dependencies with this taxonomy:
TypeMeaningPlanning Action
ArchitectureFoundational decisions, module boundaries, contracts, or platform direction.Resolve before dependent implementation begins.
InfrastructureEnvironments, runtime, deployment, networking, storage, identity, observability, or secrets.Place early in the roadmap as architecture runway.
DataData model, migration, ownership, quality, lifecycle, privacy, or availability.Schedule before features that read or write dependent data.
IntegrationExternal systems, APIs, events, queues, imports, exports, or adapters.Define contracts and test seams before end-to-end work.
Security and ComplianceAccess control, audit, policy, approvals, threat modeling, or regulatory constraints.Add early review and explicit exit criteria.
Team CoordinationCross-team handoffs, shared components, review ownership, or release alignment.Add coordination checkpoints and named owners.
Product or DesignScope decisions, user flows, UX states, or acceptance criteria.Mark as blocker or assumption depending on impact.
Operational ReadinessMonitoring, alerting, runbooks, support, migration, rollback, or incident response.Include before release or production transition.
使用以下分类法对依赖关系进行分类：
类型含义规划动作
架构基础决策、模块边界、契约或平台方向。在依赖的实施开始前解决。
基础设施环境、运行时、部署、网络、存储、身份认证、可观测性或密钥管理。作为架构基础，提前纳入路线图。
数据数据模型、迁移、归属、质量、生命周期、隐私或可用性。在读取或写入依赖数据的功能前安排。
集成外部系统、API、事件、队列、导入、导出或适配器。在端到端工作前定义契约并测试接口。
安全与合规访问控制、审计、政策、审批、威胁建模或监管约束。提前加入评审环节并明确退出标准。
团队协调跨团队交接、共享组件、评审归属或发布对齐。添加协调检查点并指定负责人。
产品或设计范围决策、用户流程、UX状态或验收标准。根据影响标记为障碍或假设。
运营就绪监控、告警、运行手册、支持、迁移、回滚或事件响应。在发布或生产环境迁移前纳入。

Execution Workflow

执行工作流

Phase 1: Intake and Framing

阶段1：接收与框架搭建

  1. Identify the desired outcome, MVP boundary, stakeholders, known constraints, and non-goals.
  2. Establish baseline readiness and major unknowns.
  3. Capture assumptions and blocking questions.
  4. Define planning horizon as phases rather than fixed dates unless dates are provided.
  1. 确定期望成果、MVP边界、利益相关者、已知约束和非目标事项。
  2. 建立基线就绪状态和主要未知因素。
  3. 记录假设和阻塞性问题。
  4. 以阶段而非固定日期定义规划周期，除非提供了日期。

Phase 2: Foundation and Dependency Mapping

阶段2：基础与依赖映射

  1. Identify foundational architecture and infrastructure work.
  2. Map dependencies between modules, teams, data, integrations, and environments.
  3. Highlight sequencing risks and parallelization opportunities.
  4. Identify spikes or proofs needed to reduce uncertainty.
  1. 识别基础架构和基础设施工作。
  2. 映射模块、团队、数据、集成和环境之间的依赖关系。
  3. 突出排序风险和并行化机会。
  4. 识别需要减少不确定性的探索性任务或验证方案。

Phase 3: Incremental Roadmap Design

阶段3：增量路线图设计

  1. Group work into phases with clear goals and exit criteria.
  2. Place foundation work before dependent feature work.
  3. Build MVP around the smallest coherent end-to-end capability.
  4. Add transition phases for hardening, scale, operations, and migration.
  5. Separate must-have, should-have, and later work.
  1. 将工作分组为具有明确目标和退出标准的阶段。
  2. 将基础工作安排在依赖性功能工作之前。
  3. 围绕最小的端到端连贯能力构建MVP。
  4. 添加用于强化、扩容、运营和迁移的过渡阶段。
  5. 区分必备、应备和后续工作。

Phase 4: Coordination and Governance

阶段4：协调与治理

  1. Assign owners or owner placeholders.
  2. Define integration checkpoints and dependency review cadence.
  3. Add risk, assumption, issue, and dependency tracking.
  4. Define release readiness, rollback, and operational handoff criteria.
  1. 分配负责人或负责人占位符。
  2. 定义集成检查点和依赖评审节奏。
  3. 添加风险、假设、问题和依赖追踪机制。
  4. 定义发布就绪、回滚和运营交接标准。

Required Output Structure

要求的输出结构

Use this format unless the user requests a narrower deliverable:
markdown
undefined
除非用户要求更窄范围的交付物，否则使用以下格式：
markdown
undefined

<Technical Execution Plan Title>

<技术执行计划标题>

1. Executive Summary

1. 执行摘要

  • Goal:
  • MVP outcome:
  • Planning horizon:
  • Key constraints:
  • Major risks:
  • 目标:
  • MVP成果:
  • 规划周期:
  • 关键约束:
  • 主要风险:

2. Scope and Assumptions

2. 范围与假设

In Scope

纳入范围

  • <Included work>
  • <包含的工作>

Out of Scope

排除范围

  • <Excluded work>
  • <排除的工作>

Assumptions

假设

  • <Assumption>
  • <假设内容>

Open Questions

未解决问题

  • <Blocking question>
  • <阻塞性问题>

3. Baseline Readiness

3. 基线就绪状态

AreaCurrent StateReadinessGapImpact
领域当前状态就绪程度差距影响

4. Technical Workstreams

4. 技术工作流

WorkstreamPurposeOwnerKey OutputsDependencies
工作流用途负责人关键输出依赖关系

5. Dependency Map

5. 依赖关系映射

DependencyTypeBlocksOwnerResolution NeededStatus
依赖项类型阻塞对象负责人是否需要解决状态

6. Implementation Sequence

6. 实施顺序

PhaseGoalWork ItemsEntry CriteriaExit CriteriaValidation Evidence
阶段目标工作项进入标准退出标准验证证据

7. MVP Definition

7. MVP定义

  • Must-have foundations:
  • Must-have capabilities:
  • Explicitly deferred:
  • MVP validation criteria:
  • 必备基础:
  • 必备能力:
  • 明确延后的内容:
  • MVP验证标准:

8. Parallelization and Coordination Plan

8. 并行化与协调计划

  • Work that can run in parallel:
  • Work that must be sequential:
  • Cross-team checkpoints:
  • Integration checkpoints:
  • 可并行开展的工作:
  • 必须按顺序开展的工作:
  • 跨团队检查点:
  • 集成检查点:

9. Risks and Mitigations

9. 风险与缓解措施

RiskImpactLikelihoodMitigationTriggerOwner
风险影响可能性缓解措施触发条件负责人

10. Release and Operational Readiness

10. 发布与运营就绪

  • Observability:
  • Security and access:
  • Runbooks and support:
  • Rollback or contingency:
  • Handoff criteria:
  • 可观测性:
  • 安全与访问:
  • 运行手册与支持:
  • 回滚或应急方案:
  • 交接标准:

11. Roadmap Summary

11. 路线图摘要

OrderIncrementValue DeliveredDependencies ResolvedReadiness Signal
undefined
顺序增量内容交付价值已解决的依赖就绪信号
undefined

Sequencing Rules

排序规则

  • Do architecture decisions before irreversible implementation.
  • Do environment and deployment foundations before continuous delivery assumptions.
  • Do contract design before multi-team parallel implementation.
  • Do data ownership and migration planning before data-dependent features.
  • Do security and access design before exposing sensitive workflows.
  • Do observability before production readiness claims.
  • Do end-to-end thin-slice validation before broad feature expansion.
  • Do operational readiness before launch or handoff.
  • 在不可逆的实施前完成架构决策。
  • 在假设持续交付前完成环境和部署基础搭建。
  • 在多团队并行实施前完成契约设计。
  • 在依赖数据的功能前完成数据归属和迁移规划。
  • 在暴露敏感工作流前完成安全和访问设计。
  • 在声明生产就绪前完成可观测性搭建。
  • 在大规模功能扩展前完成端到端薄切片验证。
  • 在发布或交接前完成运营就绪准备。

MVP Planning Rules

MVP规划规则

An MVP technical plan must include:
  • The smallest coherent end-to-end user or system capability.
  • Required foundations that make the MVP safe to build and validate.
  • Explicitly deferred capabilities.
  • Risks accepted for MVP and risks that must be mitigated first.
  • Validation signals that prove the MVP is useful, reliable enough, and technically viable.
MVP技术计划必须包含：
  • 最小的端到端连贯用户或系统能力。
  • 确保MVP可安全构建和验证的必备基础。
  • 明确延后的能力。
  • MVP可接受的风险以及必须先缓解的风险。
  • 证明MVP有用、足够可靠且技术可行的验证信号。

Multi-Team Coordination Rules

多团队协调规则

When multiple teams or components are involved:
  • Define shared contracts before teams build against them.
  • Identify owner for each workstream, contract, and dependency.
  • Add integration checkpoints before final release.
  • Track cross-team dependencies in a dependency map.
  • Avoid assigning the same foundation to multiple owners unless ownership boundaries are explicit.
  • Surface sequencing conflicts early instead of hiding them in the roadmap.
当涉及多个团队或组件时：
  • 在团队基于契约开展工作前定义共享契约。
  • 为每个工作流、契约和依赖项指定负责人。
  • 在最终发布前添加集成检查点。
  • 在依赖关系映射中追踪跨团队依赖。
  • 除非职责边界明确，否则避免将同一基础工作分配给多个负责人。
  • 尽早暴露排序冲突，而非隐藏在路线图中。

Quality Checklist

质量检查清单

Before presenting the plan, verify:
  • The output is written in English.
  • MVP scope is explicit.
  • Phases are ordered by dependencies, risk reduction, and incremental value.
  • Foundational infrastructure and base architecture appear before dependent features.
  • Dependencies are classified and assigned owners or owner placeholders.
  • Each phase has entry criteria, exit criteria, and validation evidence.
  • Parallel and sequential work are clearly separated.
  • Risks, assumptions, open questions, and operational readiness are visible.
  • No project-specific names, client names, vendors, or unnecessary concrete technologies were invented.
提交计划前，需验证：
  • 输出内容为英文。
  • MVP范围明确。
  • 阶段按依赖关系、风险降低和增量价值排序。
  • 基础基础设施和架构在依赖性功能之前。
  • 依赖关系已分类并分配了负责人或负责人占位符。
  • 每个阶段都有进入标准、退出标准和验证证据。
  • 并行和顺序工作已明确区分。
  • 风险、假设、未解决问题和运营就绪状态清晰可见。
  • 未虚构项目特定名称、客户名称、供应商或不必要的具体技术。

Response Style

响应风格

  • Be pragmatic, structured, and execution-oriented.
  • Use tables for phases, dependencies, workstreams, risks, and roadmap summaries.
  • Use short bullets for assumptions, MVP boundaries, and readiness checks.
  • Prefer relative order such as 
    Phase 0
    , 
    Phase 1
    , and 
    Phase 2
    over dates unless dates are provided.
  • Mark unknowns as 
    TBD
    when they affect sequencing or ownership.
  • 务实、结构化且以执行为导向。
  • 使用表格展示阶段、依赖关系、工作流、风险和路线图摘要。
  • 使用短 bullet 列出假设、MVP边界和就绪检查项。
  • 优先使用
    Phase 0
    、
    Phase 1
    、
    Phase 2
    等相对顺序而非日期，除非提供了日期。
  • 当未知因素影响排序或职责归属时，标记为
    TBD
    。