implementation-planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implementation Planning Skill

实现规划Skill

Overview

概述

Transform design documents into TDD-based implementation plans with granular, parallelizable tasks. Ensures complete spec coverage through explicit traceability.
For a complete worked example, see
references/worked-example.md
.
将设计文档转换为基于TDD的细粒度、可并行化任务实现计划。通过明确的可追溯性确保完整的规格覆盖。
完整示例请参考
references/worked-example.md

Triggers

触发条件

Activate this skill when:
  • User runs
    /plan
    command
  • User wants to break down a design into tasks
  • A design document exists and needs implementation steps
  • User says "plan the implementation" or similar
  • Auto-chained from
    /ideate
    after design completion
  • Auto-chained from plan-review with
    --revise
    flag (gaps found)
在以下场景激活此Skill:
  • 用户运行/plan命令
  • 用户希望将设计拆解为任务
  • 已存在设计文档且需要实现步骤
  • 用户说出类似“plan the implementation”的表述
  • 在/ideate完成设计后自动链式触发
  • 在计划评审中发现漏洞时,通过--revise标志自动链式触发

Revision Mode (--revise flag)

修订模式(--revise标志)

When invoked with
--revise
, plan-review found gaps. Read
.planReview.gaps
from state, re-read the design, add tasks to address each gap, update the plan file, then clear gaps via
mcp__exarchos__exarchos_workflow
action: "set"
.
当使用--revise标志调用时,说明计划评审发现了漏洞。从状态中读取
.planReview.gaps
,重新读取设计文档,添加任务以解决每个漏洞,更新计划文件,然后通过
mcp__exarchos__exarchos_workflow
action: "set"
清除漏洞。

Revision Loop Guard

修订循环防护

Max revisions: 3 per plan.
After 3 failed revisions:
  1. Set
    planReview.revisionsExhausted = true
  2. Output: "Plan revision failed after 3 attempts. Design may be incomplete."
  3. Escalate: Suggest
    /ideate --redesign
    to revisit design
MANDATORY: Before accepting any rationalization for skipping tests, planning, or TDD steps, consult
references/rationalization-refutation.md
. Every common excuse is catalogued with a counter-argument and the correct action.
最大修订次数:每个计划最多3次。
经过3次失败修订后:
  1. 设置
    planReview.revisionsExhausted = true
  2. 输出:“经过3次尝试后,计划修订失败。设计可能不完整。”
  3. 升级处理:建议使用/ideate --redesign重新审视设计
强制性要求: 在接受任何跳过测试、规划或TDD步骤的理由之前,请参考
references/rationalization-refutation.md
。每个常见借口都有对应的反驳论据和正确操作说明。

The Iron Law

铁律

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Every implementation task MUST:
  1. Start with writing a failing test
  2. Specify the expected failure reason
  3. Only then implement minimum code to pass
Verify TDD compliance in git history after implementation:
typescript
exarchos_orchestrate({
  action: "check_tdd_compliance",
  featureId: "<featureId>",
  taskId: "<taskId>",
  branch: "feature/<name>"
})
  • passed: true
    — All commits have test files before or alongside implementation
  • passed: false
    — Violations found; commits have implementation without corresponding tests
未先编写失败测试,不得编写生产代码
每个实现任务必须:
  1. 从编写失败测试开始
  2. 指定预期的失败原因
  3. 仅实现通过测试所需的最少代码
实现后在git历史中验证TDD合规性:
typescript
exarchos_orchestrate({
  action: "check_tdd_compliance",
  featureId: "<featureId>",
  taskId: "<taskId>",
  branch: "feature/<name>"
})
  • passed: true
    — 所有提交的测试文件在实现代码之前或同时存在
  • passed: false
    — 发现违规;提交中存在无对应测试的实现代码

Planning Process

规划流程

Step 1: Analyze Design Document

步骤1:分析设计文档

Read the design document thoroughly. For each major section, extract:
  • Problem Statement — Context (no tasks, but informs scope)
  • Chosen Approach — Architectural decisions to implement
  • Technical Design — Core implementation requirements
  • Integration Points — Integration and glue code tasks
  • Testing Strategy — Test coverage requirements
  • Open Questions — Decisions to resolve or explicitly defer
仔细阅读设计文档。针对每个主要部分,提取:
  • 问题陈述 — 背景信息(不生成任务,但用于明确范围)
  • 选定方案 — 要实现的架构决策
  • 技术设计 — 核心实现要求
  • 集成点 — 集成和粘合代码任务
  • 测试策略 — 测试覆盖要求
  • 待解决问题 — 需要解决或明确推迟的决策

Step 1.5: Spec Tracing (Required)

步骤1.5:规格追溯(必填)

Create a traceability matrix mapping design sections to planned tasks. Consult
references/spec-tracing-guide.md
for the methodology and template.
Pre-populate the matrix using the traceability generator script:
typescript
exarchos_orchestrate({
  action: "generate_traceability",
  designFile: "docs/designs/<feature>.md",
  planFile: "docs/plans/<date>-<feature>.md",
  output: "docs/plans/<date>-<feature>-traceability.md"
})
  • passed: true
    — Matrix generated; review and fill in "Key Requirements" column
  • passed: false
    — Parse error; design document may lack expected
    ##
    /
    ###
    headers
创建可追溯性矩阵,将设计部分映射到计划任务。 参考
references/spec-tracing-guide.md
获取方法和模板。
使用追溯生成脚本预填充矩阵:
typescript
exarchos_orchestrate({
  action: "generate_traceability",
  designFile: "docs/designs/<feature>.md",
  planFile: "docs/plans/<date>-<feature>.md",
  output: "docs/plans/<date>-<feature>-traceability.md"
})
  • passed: true
    — 矩阵已生成;评审并填写“关键需求”列
  • passed: false
    — 解析错误;设计文档可能缺少预期的
    ##
    /
    ###
    标题

Step 2: Decompose into Tasks

步骤2:拆解为任务

Each task follows the TDD format in
references/task-template.md
.
Granularity Guidelines:
  • Each task: 2-5 minutes of focused work
  • One test = one behavior
  • Prefer many small tasks over few large ones
Assign a
testingStrategy
to each task using
references/testing-strategy-guide.md
to control which verification techniques agents apply. Auto-determine
propertyTests
and
benchmarks
flags by matching each task's description and file paths against the category tables — do not leave these for the implementer to decide.
Task Ordering:
  1. Foundation first (types, interfaces, data structures)
  2. Core behaviors second
  3. Edge cases and error handling third
  4. Integration and glue code last
每个任务遵循
references/task-template.md
中的TDD格式。
粒度指南:
  • 每个任务:2-5分钟的专注工作
  • 一个测试对应一个行为
  • 优先拆分为多个小任务,而非少数大任务
使用
references/testing-strategy-guide.md
为每个任务分配
testingStrategy
,以控制Agent应用的验证技术。通过将每个任务的描述和文件路径与类别表匹配,自动确定
propertyTests
benchmarks
标志 — 不要将这些留给实现者决定。
任务排序:
  1. 基础任务优先(类型、接口、数据结构)
  2. 核心行为次之
  3. 边缘情况和错误处理第三
  4. 集成和粘合代码最后

Step 3: Identify Parallelization

步骤3:识别可并行化任务

Analyze dependencies to find sequential chains and parallel-safe groups that can run simultaneously in worktrees.
分析依赖关系,找出可在工作树中同时运行的顺序链和可并行分组。

Step 4: Generate Plan Document

步骤4:生成计划文档

Save to:
docs/plans/YYYY-MM-DD-<feature>.md
Use the template from
references/plan-document-template.md
.
保存至:
docs/plans/YYYY-MM-DD-<feature>.md
使用
references/plan-document-template.md
中的模板。

Step 5: Plan Verification

步骤5:计划验证

Run deterministic verification scripts instead of manual checklist review.
5a. Design-to-plan coverage — verify every Technical Design subsection maps to a task:
typescript
exarchos_orchestrate({
  action: "check_plan_coverage",
  featureId: "<id>",
  designPath: "docs/designs/<feature>.md",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — All design sections covered; proceed to 5a-ii
  • passed: false — Gaps found; add tasks for uncovered sections or defer with rationale
  • error — Usage error or empty design; check arguments
5a-ii. Provenance chain verification — verify every DR-N requirement maps to a task via
Implements:
field:
typescript
exarchos_orchestrate({
  action: "check_provenance_chain",
  featureId: "<id>",
  designPath: "docs/designs/<feature>.md",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — All DR-N requirements traced; proceed to 5b
  • passed: falseBlock: gaps or orphan references found. Add
    **Implements:** DR-N
    to tasks for each uncovered requirement before proceeding. Every DR-N requirement MUST trace to at least one task.
  • error — No DR-N identifiers in design (exit 2); if design doesn't use DR-N identifiers, this check is skipped (exempt)
5a-iii. D5: Task decomposition quality (advisory) — verify each task has clear description, file targets, and test expectations; dependency graph is a valid DAG; parallelizable tasks don't modify the same files:
typescript
exarchos_orchestrate({
  action: "check_task_decomposition",
  featureId: "<id>",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — All tasks well-decomposed; proceed to 5b
  • passed: false — Findings recorded as D5 gate events for the ConvergenceView. Present findings to the user for awareness but do not block plan approval.
  • error — Input error (missing file, no task headers); check arguments
Advisory: This gate verifies task structure quality but does not block plan approval. Findings are recorded for convergence tracking.
5b. Spec coverage check — verify planned test files exist and pass:
typescript
exarchos_orchestrate({
  action: "spec_coverage_check",
  planFile: "docs/plans/<date>-<feature>.md",
  repoRoot: ".",
  threshold: 80
})
  • passed: true
    — All planned tests found and passing; plan verification complete
  • passed: false
    — Missing test files or test failures; create missing tests or fix failures
For reference, consult
references/spec-tracing-guide.md
for the underlying methodology.
运行确定性验证脚本,而非手动检查清单。
5a. 设计到计划的覆盖度 — 验证每个技术设计子部分都映射到一个任务:
typescript
exarchos_orchestrate({
  action: "check_plan_coverage",
  featureId: "<id>",
  designPath: "docs/designs/<feature>.md",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — 所有设计部分已覆盖;进入5a-ii
  • passed: false — 发现漏洞;为未覆盖部分添加任务或给出推迟理由
  • error — 使用错误或设计文档为空;检查参数
5a-ii. 来源链验证 — 验证每个DR-N需求都通过
Implements:
字段映射到一个任务:
typescript
exarchos_orchestrate({
  action: "check_provenance_chain",
  featureId: "<id>",
  designPath: "docs/designs/<feature>.md",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — 所有DR-N需求已追溯;进入5b
  • passed: false阻塞: 发现漏洞或孤立引用。为每个未覆盖的需求在任务中添加
    **Implements:** DR-N
    后再继续。每个DR-N需求必须至少追溯到一个任务。
  • error — 设计中无DR-N标识符(退出码2);若设计未使用DR-N标识符,则跳过此检查(豁免)
5a-iii. D5:任务拆解质量(建议性) — 验证每个任务有清晰的描述、文件目标和测试预期;依赖图为有效的DAG;可并行任务不修改相同文件:
typescript
exarchos_orchestrate({
  action: "check_task_decomposition",
  featureId: "<id>",
  planPath: "docs/plans/<date>-<feature>.md"
})
  • passed: true — 所有任务拆解良好;进入5b
  • passed: false — 发现结果记录为ConvergenceView的D5 gate事件。向用户展示发现结果,但不阻止计划批准。
  • error — 输入错误(文件缺失、无任务标题);检查参数
建议: 此关卡验证任务结构质量,但不阻止计划批准。发现结果会被记录用于收敛跟踪。
5b. 规格覆盖度检查 — 验证计划的测试文件存在并通过:
typescript
exarchos_orchestrate({
  action: "spec_coverage_check",
  planFile: "docs/plans/<date>-<feature>.md",
  repoRoot: ".",
  threshold: 80
})
  • passed: true
    — 所有计划的测试已找到并通过;计划验证完成
  • passed: false
    — 测试文件缺失或测试失败;创建缺失的测试或修复失败的测试
参考
references/spec-tracing-guide.md
获取底层方法。

Anti-Patterns

反模式

Don'tDo Instead
Write implementation firstWrite failing test first
Create large tasksBreak into 2-5 min chunks
Skip dependency analysisIdentify parallel opportunities
Vague test descriptionsSpecific: Method_Scenario_Outcome
Assume tests passVerify each test fails first
Add "nice to have" codeOnly what the test requires
请勿正确做法
先编写实现代码先编写失败测试
创建大型任务拆分为2-5分钟的小任务
跳过依赖分析识别可并行的机会
模糊的测试描述具体化:方法_场景_结果
假设测试通过先验证每个测试失败
添加“锦上添花”的代码只编写测试要求的代码

Rationalization Debunking

理由反驳

ExcuseReality
"This is too simple for tests"Simple code breaks too. Test it.
"I'll add tests after"You won't. Or they'll be weak.
"Tests slow me down"Debugging without tests is slower.
"The design is obvious"Obvious to you now. Not in 3 months.
借口事实
"这个太简单,不需要测试"简单代码也会出错。请测试。
"我之后再加测试"你不会的。或者测试会很薄弱。
"测试拖慢我的速度"没有测试的调试更慢。
"设计很明显"现在对你来说明显。3个月后就不是了。

State Management

状态管理

On plan save, transition phase based on
workflowType
: feature →
plan-review
, refactor →
overhaul-plan-review
.
action: "set", featureId: "<id>", phase: "<plan-review-phase>", updates: {
  "artifacts": { "plan": "<plan-file-path>" },
  "tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}
保存计划时,根据
workflowType
转换阶段:功能开发 →
plan-review
,重构 →
overhaul-plan-review
action: "set", featureId: "<id>", phase: "<plan-review-phase>", updates: {
  "artifacts": { "plan": "<plan-file-path>" },
  "tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}

Phase Transitions and Guards

阶段转换与防护

For the full transition table, consult
@skills/workflow-state/references/phase-transitions.md
.
Quick reference: The
plan
plan-review
transition requires guard
plan-artifact-exists
— set
artifacts.plan
in the same
set
call as
phase
.
完整的转换表请参考
@skills/workflow-state/references/phase-transitions.md
快速参考:
plan
plan-review
转换需要
plan-artifact-exists
防护 — 在设置
phase
的同一个
set
调用中设置
artifacts.plan

Schema Discovery

架构发现

Use
exarchos_workflow({ action: "describe", actions: ["set", "init"] })
for parameter schemas and
exarchos_workflow({ action: "describe", playbook: "feature" })
(or
"debug"
,
"refactor"
) for phase transitions, guards, and playbook guidance. Use
exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })
for orchestrate action schemas.
使用
exarchos_workflow({ action: "describe", actions: ["set", "init"] })
获取参数架构,使用
exarchos_workflow({ action: "describe", playbook: "feature" })
(或
"debug"
,
"refactor"
)获取阶段转换、防护和剧本指导。使用
exarchos_orchestrate({ action: "describe", actions: ["check_plan_coverage", "check_provenance_chain"] })
获取编排动作架构。

Completion Criteria

完成标准

  • Design document read and understood
  • Spec traceability table created (
    exarchos_orchestrate({ action: "generate_traceability" })
    )
  • Scope declared (full or partial with rationale)
  • Tasks decomposed to 2-5 min granularity
  • Each task starts with failing test
  • Dependencies mapped
  • Parallel groups identified
  • Plan verification passed —
    exarchos_orchestrate({ action: "check_plan_coverage" })
    returns passed: true
  • Provenance chain checked —
    exarchos_orchestrate({ action: "check_provenance_chain" })
    passed (blocking; gaps must be resolved before proceeding)
  • Task decomposition checked —
    exarchos_orchestrate({ action: "check_task_decomposition" })
    run (advisory; findings presented but non-blocking)
  • Spec coverage check passed —
    exarchos_orchestrate({ action: "spec_coverage_check" })
    passed: true
  • Coverage thresholds met —
    exarchos_orchestrate({ action: "check_coverage_thresholds" })
    passed: true:
typescript
exarchos_orchestrate({
  action: "check_coverage_thresholds",
  coverageFile: "coverage/coverage-summary.json",
  lineThreshold: 80,
  branchThreshold: 70,
  functionThreshold: 100
})
  • Plan saved to
    docs/plans/
  • State file updated with plan path and tasks
  • 已阅读并理解设计文档
  • 已创建规格追溯表(
    exarchos_orchestrate({ action: "generate_traceability" })
  • 已声明范围(完整或部分,附带理由)
  • 任务已拆解为2-5分钟的粒度
  • 每个任务从失败测试开始
  • 已映射依赖关系
  • 已识别可并行分组
  • 计划验证通过 —
    exarchos_orchestrate({ action: "check_plan_coverage" })
    返回passed: true
  • 来源链已检查 —
    exarchos_orchestrate({ action: "check_provenance_chain" })
    通过(阻塞;漏洞必须解决后才能继续)
  • 任务拆解已检查 —
    exarchos_orchestrate({ action: "check_task_decomposition" })
    已运行(建议性;展示发现结果但不阻塞)
  • 规格覆盖度检查通过 —
    exarchos_orchestrate({ action: "spec_coverage_check" })
    返回passed: true
  • 覆盖度阈值已满足 —
    exarchos_orchestrate({ action: "check_coverage_thresholds" })
    返回passed: true:
typescript
exarchos_orchestrate({
  action: "check_coverage_thresholds",
  coverageFile: "coverage/coverage-summary.json",
  lineThreshold: 80,
  branchThreshold: 70,
  functionThreshold: 100
})
  • 计划已保存至
    docs/plans/
  • 状态文件已更新计划路径和任务

Transition

转换

After planning completes, auto-continue to plan-review (delta analysis). Set
.phase
to the appropriate review phase (feature:
plan-review
, refactor:
overhaul-plan-review
). Plan-review compares design sections against planned tasks:
  • Gaps found: set
    .planReview.gaps
    , auto-loop back to
    /plan --revise
  • No gaps: present to user for approval (human checkpoint)
  • On approval: set
    .planReview.approved = true
    , invoke
    /delegate
REQUIRED: Run
exarchos_orchestrate({ action: "check_plan_coverage" })
. If passed: false → auto-invoke
/plan --revise
. If passed: true → continue to the plan-review phase (feature:
plan-review
, refactor:
overhaul-plan-review
) and only invoke
/delegate
after plan-review approval.
规划完成后,**自动进入计划评审(差异分析)**阶段。将
.phase
设置为相应的评审阶段(功能开发:
plan-review
,重构:
overhaul-plan-review
)。计划评审将设计部分与计划任务进行对比:
  • 发现漏洞:设置
    .planReview.gaps
    ,自动循环回/plan --revise
  • 无漏洞:提交给用户审批(人工检查点)
  • 审批通过:设置
    .planReview.approved = true
    ,调用/delegate
必填: 运行
exarchos_orchestrate({ action: "check_plan_coverage" })
。若返回passed: false → 自动调用/plan --revise。若返回passed: true → 进入计划评审阶段(功能开发:
plan-review
,重构:
overhaul-plan-review
),仅在计划评审通过后调用/delegate。

Exarchos Integration

Exarchos集成

Phase transitions auto-emit
workflow.transition
events via
exarchos_workflow
set
. No manual
exarchos_event
append needed.
阶段转换通过
exarchos_workflow
set
动作自动发送
workflow.transition
事件。无需手动添加
exarchos_event

Troubleshooting

故障排除

IssueCauseResolution
check_plan_coverage
returns passed: false
Design sections not mapped to tasksAdd tasks for uncovered sections or add explicit deferral rationale
spec_coverage_check
passed: false
Planned test files missing or failingCreate missing test stubs, verify file paths in plan match actual paths
generate_traceability
passed: false
Design doc missing expected
##
/
###
headers
Verify design uses standard Markdown headings
Revision loop (3+ attempts)Persistent gaps between design and planSet
planReview.revisionsExhausted = true
, suggest
/ideate --redesign
问题原因解决方案
check_plan_coverage
返回passed: false
设计部分未映射到任务为未覆盖部分添加任务或添加明确的推迟理由
spec_coverage_check
返回passed: false
计划的测试文件缺失或失败创建缺失的测试桩,验证计划中的文件路径与实际路径匹配
generate_traceability
返回passed: false
设计文档缺少预期的
##
/
###
标题
验证设计使用标准Markdown标题
修订循环(3次以上尝试)设计与计划之间存在持续漏洞设置
planReview.revisionsExhausted = true
,建议使用/ideate --redesign

Performance Notes

性能注意事项

  • Complete each step fully before advancing — quality over speed
  • Do not skip validation checks even when the change appears trivial
  • Trace every design section to at least one task. Do not leave uncovered sections without explicit rationale.
  • 在进入下一步前完成每个步骤 — 质量优先于速度
  • 即使变更看似微不足道,也不要跳过验证检查
  • 将每个设计部分追溯到至少一个任务。若无明确理由,不要留下未覆盖的部分。