implementation-planning
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseImplementation 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.mdTriggers
触发条件
Activate this skill when:
- User runs command
/plan - 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 after design completion
/ideate - Auto-chained from plan-review with flag (gaps found)
--revise
在以下场景激活此Skill:
- 用户运行/plan命令
- 用户希望将设计拆解为任务
- 已存在设计文档且需要实现步骤
- 用户说出类似“plan the implementation”的表述
- 在/ideate完成设计后自动链式触发
- 在计划评审中发现漏洞时,通过--revise标志自动链式触发
Revision Mode (--revise flag)
修订模式(--revise标志)
When invoked with , plan-review found gaps. Read from state, re-read the design, add tasks to address each gap, update the plan file, then clear gaps via .
--revise.planReview.gapsmcp__exarchos__exarchos_workflowaction: "set"当使用--revise标志调用时,说明计划评审发现了漏洞。从状态中读取,重新读取设计文档,添加任务以解决每个漏洞,更新计划文件,然后通过的清除漏洞。
.planReview.gapsmcp__exarchos__exarchos_workflowaction: "set"Revision Loop Guard
修订循环防护
Max revisions: 3 per plan.
After 3 failed revisions:
- Set
planReview.revisionsExhausted = true - Output: "Plan revision failed after 3 attempts. Design may be incomplete."
- Escalate: Suggest to revisit design
/ideate --redesign
MANDATORY: Before accepting any rationalization for skipping tests, planning, or TDD steps, consult. Every common excuse is catalogued with a counter-argument and the correct action.references/rationalization-refutation.md
最大修订次数:每个计划最多3次。
经过3次失败修订后:
- 设置
planReview.revisionsExhausted = true - 输出:“经过3次尝试后,计划修订失败。设计可能不完整。”
- 升级处理:建议使用/ideate --redesign重新审视设计
强制性要求: 在接受任何跳过测试、规划或TDD步骤的理由之前,请参考。每个常见借口都有对应的反驳论据和正确操作说明。references/rationalization-refutation.md
The Iron Law
铁律
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Every implementation task MUST:
- Start with writing a failing test
- Specify the expected failure reason
- 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>"
})- — All commits have test files before or alongside implementation
passed: true - — Violations found; commits have implementation without corresponding tests
passed: false
未先编写失败测试,不得编写生产代码
每个实现任务必须:
- 从编写失败测试开始
- 指定预期的失败原因
- 仅实现通过测试所需的最少代码
实现后在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 for the methodology and template.
references/spec-tracing-guide.mdPre-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"
})- — Matrix generated; review and fill in "Key Requirements" column
passed: true - — Parse error; design document may lack expected
passed: false/##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.mdGranularity Guidelines:
- Each task: 2-5 minutes of focused work
- One test = one behavior
- Prefer many small tasks over few large ones
Assign a to each task using to control which verification techniques agents apply. Auto-determine and flags by matching each task's description and file paths against the category tables — do not leave these for the implementer to decide.
testingStrategyreferences/testing-strategy-guide.mdpropertyTestsbenchmarksTask Ordering:
- Foundation first (types, interfaces, data structures)
- Core behaviors second
- Edge cases and error handling third
- Integration and glue code last
每个任务遵循中的TDD格式。
references/task-template.md粒度指南:
- 每个任务:2-5分钟的专注工作
- 一个测试对应一个行为
- 优先拆分为多个小任务,而非少数大任务
使用为每个任务分配,以控制Agent应用的验证技术。通过将每个任务的描述和文件路径与类别表匹配,自动确定和标志 — 不要将这些留给实现者决定。
references/testing-strategy-guide.mdtestingStrategypropertyTestsbenchmarks任务排序:
- 基础任务优先(类型、接口、数据结构)
- 核心行为次之
- 边缘情况和错误处理第三
- 集成和粘合代码最后
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:
Use the template from .
docs/plans/YYYY-MM-DD-<feature>.mdreferences/plan-document-template.md保存至:
使用中的模板。
docs/plans/YYYY-MM-DD-<feature>.mdreferences/plan-document-template.mdStep 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 field:
Implements: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: false — Block: gaps or orphan references found. Add to tasks for each uncovered requirement before proceeding. Every DR-N requirement MUST trace to at least one task.
**Implements:** DR-N - 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
})- — All planned tests found and passing; plan verification complete
passed: true - — Missing test files or test failures; create missing tests or fix failures
passed: false
For reference, consult for the underlying methodology.
references/spec-tracing-guide.md运行确定性验证脚本,而非手动检查清单。
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 — 阻塞: 发现漏洞或孤立引用。为每个未覆盖的需求在任务中添加后再继续。每个DR-N需求必须至少追溯到一个任务。
**Implements:** 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.mdAnti-Patterns
反模式
| Don't | Do Instead |
|---|---|
| Write implementation first | Write failing test first |
| Create large tasks | Break into 2-5 min chunks |
| Skip dependency analysis | Identify parallel opportunities |
| Vague test descriptions | Specific: Method_Scenario_Outcome |
| Assume tests pass | Verify each test fails first |
| Add "nice to have" code | Only what the test requires |
| 请勿 | 正确做法 |
|---|---|
| 先编写实现代码 | 先编写失败测试 |
| 创建大型任务 | 拆分为2-5分钟的小任务 |
| 跳过依赖分析 | 识别可并行的机会 |
| 模糊的测试描述 | 具体化:方法_场景_结果 |
| 假设测试通过 | 先验证每个测试失败 |
| 添加“锦上添花”的代码 | 只编写测试要求的代码 |
Rationalization Debunking
理由反驳
| Excuse | Reality |
|---|---|
| "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 : feature → , refactor → .
workflowTypeplan-reviewoverhaul-plan-reviewaction: "set", featureId: "<id>", phase: "<plan-review-phase>", updates: {
"artifacts": { "plan": "<plan-file-path>" },
"tasks": [{ "id": "001", "title": "...", "status": "pending", "branch": "...", "blockedBy": [] }, ...]
}保存计划时,根据转换阶段:功能开发 → ,重构 → 。
workflowTypeplan-reviewoverhaul-plan-reviewaction: "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.mdQuick reference: The → transition requires guard — set in the same call as .
planplan-reviewplan-artifact-existsartifacts.plansetphase完整的转换表请参考。
@skills/workflow-state/references/phase-transitions.md快速参考: → 转换需要防护 — 在设置的同一个调用中设置。
planplan-reviewplan-artifact-existsphasesetartifacts.planSchema Discovery
架构发现
Use for
parameter schemas and
(or , ) for phase transitions, guards, and playbook guidance.
Use
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"] })使用获取参数架构,使用(或, )获取阶段转换、防护和剧本指导。使用获取编排动作架构。
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 — returns passed: true
exarchos_orchestrate({ action: "check_plan_coverage" }) - Provenance chain checked — passed (blocking; gaps must be resolved before proceeding)
exarchos_orchestrate({ action: "check_provenance_chain" }) - Task decomposition checked — run (advisory; findings presented but non-blocking)
exarchos_orchestrate({ action: "check_task_decomposition" }) - Spec coverage check passed — passed: true
exarchos_orchestrate({ action: "spec_coverage_check" }) - Coverage thresholds met — passed: true:
exarchos_orchestrate({ action: "check_coverage_thresholds" })
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分钟的粒度
- 每个任务从失败测试开始
- 已映射依赖关系
- 已识别可并行分组
- 计划验证通过 — 返回passed: true
exarchos_orchestrate({ action: "check_plan_coverage" }) - 来源链已检查 — 通过(阻塞;漏洞必须解决后才能继续)
exarchos_orchestrate({ action: "check_provenance_chain" }) - 任务拆解已检查 — 已运行(建议性;展示发现结果但不阻塞)
exarchos_orchestrate({ action: "check_task_decomposition" }) - 规格覆盖度检查通过 — 返回passed: true
exarchos_orchestrate({ action: "spec_coverage_check" }) - 覆盖度阈值已满足 — 返回passed: true:
exarchos_orchestrate({ action: "check_coverage_thresholds" })
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 to the appropriate review phase (feature: , refactor: ). Plan-review compares design sections against planned tasks:
.phaseplan-reviewoverhaul-plan-review- Gaps found: set , auto-loop back to
.planReview.gaps/plan --revise - No gaps: present to user for approval (human checkpoint)
- On approval: set , invoke
.planReview.approved = true/delegate
REQUIRED: Run . If passed: false → auto-invoke . If passed: true → continue to the plan-review phase (feature: , refactor: ) and only invoke after plan-review approval.
exarchos_orchestrate({ action: "check_plan_coverage" })/plan --reviseplan-reviewoverhaul-plan-review/delegate规划完成后,**自动进入计划评审(差异分析)**阶段。将设置为相应的评审阶段(功能开发:,重构:)。计划评审将设计部分与计划任务进行对比:
.phaseplan-reviewoverhaul-plan-review- 发现漏洞:设置,自动循环回/plan --revise
.planReview.gaps - 无漏洞:提交给用户审批(人工检查点)
- 审批通过:设置,调用/delegate
.planReview.approved = true
必填: 运行。若返回passed: false → 自动调用/plan --revise。若返回passed: true → 进入计划评审阶段(功能开发:,重构:),仅在计划评审通过后调用/delegate。
exarchos_orchestrate({ action: "check_plan_coverage" })plan-reviewoverhaul-plan-reviewExarchos Integration
Exarchos集成
Phase transitions auto-emit events via . No manual append needed.
workflow.transitionexarchos_workflowsetexarchos_event阶段转换通过的动作自动发送事件。无需手动添加。
exarchos_workflowsetworkflow.transitionexarchos_eventTroubleshooting
故障排除
| Issue | Cause | Resolution |
|---|---|---|
| Design sections not mapped to tasks | Add tasks for uncovered sections or add explicit deferral rationale |
| Planned test files missing or failing | Create missing test stubs, verify file paths in plan match actual paths |
| Design doc missing expected | Verify design uses standard Markdown headings |
| Revision loop (3+ attempts) | Persistent gaps between design and plan | Set |
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 设计部分未映射到任务 | 为未覆盖部分添加任务或添加明确的推迟理由 |
| 计划的测试文件缺失或失败 | 创建缺失的测试桩,验证计划中的文件路径与实际路径匹配 |
| 设计文档缺少预期的 | 验证设计使用标准Markdown标题 |
| 修订循环(3次以上尝试) | 设计与计划之间存在持续漏洞 | 设置 |
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.
- 在进入下一步前完成每个步骤 — 质量优先于速度
- 即使变更看似微不足道,也不要跳过验证检查
- 将每个设计部分追溯到至少一个任务。若无明确理由,不要留下未覆盖的部分。