implementation-planner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implementation Planner

实施计划生成器

This skill generates comprehensive implementation plans with milestones, tasks, and best practices enforcement.
本技能可生成包含里程碑、任务及最佳实践约束的全面实施计划。

Prerequisites

前置条件

  • Completed
    business-requirements.yaml
  • Completed
    technical-requirements.yaml
  • Optional but recommended: Style anchor code examples
  • 已完成
    business-requirements.yaml
  • 已完成
    technical-requirements.yaml
  • 可选但推荐:风格锚点代码示例

Planning Process

规划流程

Input Analysis

输入分析

  1. Load Requirements
    • Parse business requirements for functional scope
    • Parse technical requirements for architectural decisions
    • Identify dependencies and constraints
  2. Identify Milestones
    • Group related features into logical milestones
    • Establish dependency order
    • Define milestone deliverables
  3. Generate Tasks
    • Break down milestones into atomic tasks
    • Apply task sizing rules (30m - 2.5h)
    • Define task dependencies
    • Add style anchors and constraints
  4. Apply Best Practices
    • TDD requirements
    • Style anchor references
    • Quality constraints
    • Drift prevention rules
  1. 加载需求
    • 解析业务需求以明确功能范围
    • 解析技术需求以确定架构决策
    • 识别依赖关系与约束条件
  2. 确定里程碑
    • 将相关功能分组为逻辑里程碑
    • 建立依赖顺序
    • 定义里程碑交付物
  3. 生成任务
    • 将里程碑拆解为原子任务
    • 应用任务规模规则(30分钟 - 2.5小时)
    • 定义任务依赖关系
    • 添加风格锚点与约束条件
  4. 应用最佳实践
    • TDD要求
    • 风格锚点引用
    • 质量约束
    • 漂移预防规则

Best Practices (Embedded)

内置最佳实践

Core Principles

核心原则

Layered Verification
Models optimize locally; enforce global constraints with layered verification (prompt → IDE → commit → CI → runtime).
Style Anchors
  • Always include 2-3 exemplary files as templates
  • Reference exact paths and line numbers
  • Prefer concrete repository examples (code + tests + README)
  • Enforce anchors early to prevent architectural drift
Task Sizing
  • Split work into 30m–2.5h atomic tasks (30–150 minutes optimal)
  • Limit scope to specific files
  • Commit after each small task
  • Revert immediately on drift
  • If a task is shorter than 30m, either increase estimate or split it with rationale
Affirmative Instructions
  • State permitted actions explicitly
  • Avoid negative framing
  • Use "ONLY use X, Y, Z" instead of "Don't use A, B, C"
Tiered Rules
  • Global: User preferences (format, language, length)
  • Project: Persistent rules in CLAUDE.md or .cursor/rules/
  • Context-aware: Auto-attached rules per directory or file pattern
分层验证
模型会进行局部优化;通过分层验证(提示 → IDE → 提交 → CI → 运行时)来强制执行全局约束。
风格锚点(Style Anchors)
  • 始终包含2-3个示例性文件作为模板
  • 引用精确的路径和行号
  • 优先选择具体的仓库示例(代码 + 测试 + README)
  • 尽早实施锚点以防止架构漂移
任务规模
  • 将工作拆分为30分钟–2.5小时的原子任务(30–150分钟为最优范围)
  • 限制范围至特定文件
  • 完成每个小任务后提交
  • 出现漂移时立即回滚
  • 如果任务时长短于30分钟,要么增加估算时长,要么附带理由进行拆分
明确指令
  • 明确说明允许的操作
  • 避免负面表述
  • 使用“仅可使用X、Y、Z”代替“不要使用A、B、C”
分层规则
  • 全局:用户偏好(格式、语言、长度)
  • 项目:CLAUDE.md或.cursor/rules/中的持久化规则
  • 上下文感知:按目录或文件模式自动附加的规则

Quality Constraints

质量约束

TDD as Anchor
  • Require TDD checklist before implementation
  • Tests → minimal code → more tests → refactor
  • When tests fail, return failing output with instruction: "Revise implementation to pass this test while keeping all previously passing tests. Do not modify the test. Do not add dependencies."
Drift Handling
  • Stop and revert immediately on unexpected dependencies or unfamiliar patterns
  • Do not fix mid-stream
  • Document learnings and update persistent rules after each session
Prompt Positioning
  • Put critical specs, style anchors, and hard rules at the beginning
  • Reiterate them at the end of prompts
  • Avoid burying requirements in the middle
External Data Validation
  • Never use type assertions on external data
  • Validate all external inputs with proper error handling
  • Use schema validation instead of runtime assertions
以TDD为锚点
  • 实施前需完成TDD检查清单
  • 测试 → 最简代码实现 → 更多测试 → 重构
  • 当测试失败时,返回失败输出并附带指令:“修改实现以通过该测试,同时保持所有之前通过的测试正常运行。请勿修改测试。请勿添加依赖。”
漂移处理
  • 遇到意外依赖或不熟悉的模式时,立即停止并回滚
  • 不要在中途修复问题
  • 记录经验教训,并在每次会话后更新持久化规则
提示定位
  • 将关键规格、风格锚点和硬性规则放在开头
  • 在提示末尾重复强调
  • 不要将需求隐藏在中间部分
外部数据验证
  • 永远不要对外部数据使用类型断言
  • 使用适当的错误处理验证所有外部输入
  • 使用模式验证替代运行时断言

Output Formats

输出格式

Milestones Structure

里程碑结构

Generate
milestones.yaml
:
yaml
version: "1.0.0"
project: [project-name]
generated: [timestamp]

business_requirements: [path/to/business-requirements.yaml]
technical_requirements: [path/to/technical-requirements.yaml]

milestones:
  - id: m0
    name: [Milestone Name]
    description: |
      [What this milestone delivers]
    dependencies: [] # Empty for first milestone
    estimated_duration: [timeframe]
    tasks_file: milestone-m0.tasks.yaml
    success_criteria:
      - [Criterion 1]
      - [Criterion 2]

  - id: m1
    name: [Milestone Name]
    description: |
      [What this milestone delivers]
    dependencies: [m0] # References previous milestone
    estimated_duration: [timeframe]
    tasks_file: milestone-m1.tasks.yaml
    success_criteria:
      - [Criterion 1]
      - [Criterion 2]
生成
milestones.yaml
:
yaml
version: "1.0.0"
project: [project-name]
generated: [timestamp]

business_requirements: [path/to/business-requirements.yaml]
technical_requirements: [path/to/technical-requirements.yaml]

milestones:
  - id: m0
    name: [Milestone Name]
    description: |
      [What this milestone delivers]
    dependencies: [] # Empty for first milestone
    estimated_duration: [timeframe]
    tasks_file: milestone-m0.tasks.yaml
    success_criteria:
      - [Criterion 1]
      - [Criterion 2]

  - id: m1
    name: [Milestone Name]
    description: |
      [What this milestone delivers]
    dependencies: [m0] # References previous milestone
    estimated_duration: [timeframe]
    tasks_file: milestone-m1.tasks.yaml
    success_criteria:
      - [Criterion 1]
      - [Criterion 2]

Tasks Structure

任务结构

Generate
milestone-m*.tasks.yaml
:
yaml
milestone: [milestone-id]
name: [Milestone Name]
generated: [timestamp]

style_anchors:
  - path: [path/to/example/file.ts]
    lines: [10-50]
    description: |
      [What pattern this demonstrates]
      [Why it's a good example]
  - path: [path/to/test/file.test.ts]
    lines: [1-30]
    description: |
      [Testing pattern example]

global_constraints:
  allowed_patterns:
    - [Pattern 1 - e.g., "Use Effect.Service for all services"]
    - [Pattern 2 - e.g., "Use Schema.Class for all data validation"]
  forbidden_patterns:
    - [Anti-pattern 1 - e.g., "Direct async/await in service methods"]
    - [Anti-pattern 2 - e.g., "Type assertions on external data"]
  tdd_required: true
  max_task_duration_minutes: 150
  commit_strategy: "Commit after each task"

quality_gates:
  - stage: pre-commit
    commands:
      - [linter command]
      - [type checker command]
      - [test command]
  - stage: task-completion
    criteria:
      - All tests passing
      - No lint errors
      - Code formatted
      - Documentation updated

tasks:
  - id: [milestone]-001
    name: [Task name]
    description: |
      [What to implement]
      [Why it's needed]
    estimate_minutes: 60
    type: [code/test/docs/config]
    dependencies: [] # or list of task IDs
    files:
      create:
        - [path/to/new/file.ts]
        - [path/to/new/file.test.ts]
      modify:
        - [path/to/existing/file.ts]
      touch_only:
        - [files to reference but not modify]
    instructions: |
      **Objective:**
      [Clear statement of what needs to be done]

      **Implementation Steps:**
      1. [Step 1]
      2. [Step 2]
      3. [Step 3]

      **Constraints:**
      - ONLY use: [specific libraries/approaches]
      - Follow pattern in: [style anchor reference]
      - File scope: ONLY modify listed files

      **TDD Checklist:**
      - [ ] Write failing test first
      - [ ] Implement minimum code to pass
      - [ ] Refactor if needed
      - [ ] All tests passing

      **Validation:**
      ```bash
      [command to run]
      ```
      Expected: [what success looks like]

      **Drift Policy:**
      If you encounter unexpected patterns or dependencies, STOP immediately.
      Do not fix mid-stream. Report the issue and await guidance.

    validation:
      commands:
        - [test command]
        - [linter command]
      expected_output: [success criteria]
      on_failure: [what to do if validation fails]

  - id: [milestone]-002
    name: [Task name]
    dependencies: [[milestone]-001]
    ...
生成
milestone-m*.tasks.yaml
:
yaml
milestone: [milestone-id]
name: [Milestone Name]
generated: [timestamp]

style_anchors:
  - path: [path/to/example/file.ts]
    lines: [10-50]
    description: |
      [What pattern this demonstrates]
      [Why it's a good example]
  - path: [path/to/test/file.test.ts]
    lines: [1-30]
    description: |
      [Testing pattern example]

global_constraints:
  allowed_patterns:
    - [Pattern 1 - e.g., "Use Effect.Service for all services"]
    - [Pattern 2 - e.g., "Use Schema.Class for all data validation"]
  forbidden_patterns:
    - [Anti-pattern 1 - e.g., "Direct async/await in service methods"]
    - [Anti-pattern 2 - e.g., "Type assertions on external data"]
  tdd_required: true
  max_task_duration_minutes: 150
  commit_strategy: "Commit after each task"

quality_gates:
  - stage: pre-commit
    commands:
      - [linter command]
      - [type checker command]
      - [test command]
  - stage: task-completion
    criteria:
      - All tests passing
      - No lint errors
      - Code formatted
      - Documentation updated

tasks:
  - id: [milestone]-001
    name: [Task name]
    description: |
      [What to implement]
      [Why it's needed]
    estimate_minutes: 60
    type: [code/test/docs/config]
    dependencies: [] # or list of task IDs
    files:
      create:
        - [path/to/new/file.ts]
        - [path/to/new/file.test.ts]
      modify:
        - [path/to/existing/file.ts]
      touch_only:
        - [files to reference but not modify]
    instructions: |
      **Objective:**
      [Clear statement of what needs to be done]

      **Implementation Steps:**
      1. [Step 1]
      2. [Step 2]
      3. [Step 3]

      **Constraints:**
      - ONLY use: [specific libraries/approaches]
      - Follow pattern in: [style anchor reference]
      - File scope: ONLY modify listed files

      **TDD Checklist:**
      - [ ] Write failing test first
      - [ ] Implement minimum code to pass
      - [ ] Refactor if needed
      - [ ] All tests passing

      **Validation:**
      ```bash
      [command to run]
      ```
      Expected: [what success looks like]

      **Drift Policy:**
      If you encounter unexpected patterns or dependencies, STOP immediately.
      Do not fix mid-stream. Report the issue and await guidance.

    validation:
      commands:
        - [test command]
        - [linter command]
      expected_output: [success criteria]
      on_failure: [what to do if validation fails]

  - id: [milestone]-002
    name: [Task name]
    dependencies: [[milestone]-001]
    ...

Task Sizing Guidelines

任务规模指南

Optimal Task Duration

最优任务时长

  • Minimum: 30 minutes
    • If task is shorter, document rationale
    • Consider merging with related tasks
  • Optimal: 30-150 minutes
    • Atomic, well-scoped changes
    • Can be completed in one session
    • Clear success criteria
  • Maximum: 150 minutes (2.5 hours)
    • If task is longer, split into smaller tasks
    • Identify natural breakpoints
    • Create dependencies between subtasks
  • 最小值:30分钟
    • 如果任务时长更短,需记录理由
    • 考虑与相关任务合并
  • 最优范围:30-150分钟
    • 原子化、范围明确的变更
    • 可在一个会话内完成
    • 明确的成功标准
  • 最大值:150分钟(2.5小时)
    • 如果任务时长更长,拆分为更小的任务
    • 识别自然断点
    • 在子任务之间创建依赖关系

Task Sizing Examples

任务规模示例

Too Small (< 30m)
yaml
- id: m1-001
  name: Add export statement
  estimate_minutes: 10
  rationale: "Simple addition but critical for module system"
Optimal (30-150m)
yaml
- id: m1-002
  name: Implement user authentication service
  estimate_minutes: 90
  dependencies: [m1-001]
Too Large (> 150m) - SPLIT
yaml
undefined
过小(< 30分钟)
yaml
- id: m1-001
  name: Add export statement
  estimate_minutes: 10
  rationale: "Simple addition but critical for module system"
最优(30-150分钟)
yaml
- id: m1-002
  name: Implement user authentication service
  estimate_minutes: 90
  dependencies: [m1-001]
过大(> 150分钟)- 拆分
yaml
undefined

BEFORE (too large):

BEFORE (too large):

  • id: m1-003 name: Build complete API layer estimate_minutes: 300
  • id: m1-003 name: Build complete API layer estimate_minutes: 300

AFTER (properly split):

AFTER (properly split):

  • id: m1-003 name: Define API interface and types estimate_minutes: 60
  • id: m1-004 name: Implement API routes estimate_minutes: 90 dependencies: [m1-003]
  • id: m1-005 name: Add API middleware and error handling estimate_minutes: 60 dependencies: [m1-004]
undefined
  • id: m1-003 name: Define API interface and types estimate_minutes: 60
  • id: m1-004 name: Implement API routes estimate_minutes: 90 dependencies: [m1-003]
  • id: m1-005 name: Add API middleware and error handling estimate_minutes: 60 dependencies: [m1-004]
undefined

Style Anchor Integration

风格锚点集成

What Makes a Good Style Anchor

优质风格锚点的标准

  1. Concrete - Real file paths, not abstract descriptions
  2. Specific - Line numbers for precision
  3. Complete - Code + tests + documentation
  4. Current - Reflects current best practices
  5. Exemplary - Demonstrates the pattern correctly
  1. 具体 - 使用真实文件路径,而非抽象描述
  2. 精确 - 指定行号以确保准确性
  3. 完整 - 包含代码 + 测试 + 文档
  4. 最新 - 反映当前最佳实践
  5. 典范 - 正确展示模式

Style Anchor Examples

风格锚点示例

yaml
style_anchors:
  - path: src/services/UserService.ts
    lines: 10-50
    description: |
      Example of Effect.Service pattern with:
      - Dependency injection via Effect.Service
      - All methods returning Effect types
      - Proper error handling with tagged errors

  - path: test/services/UserService.test.ts
    lines: 1-40
    description: |
      Example of testing Effect services:
      - Using it.effect from @effect/vitest
      - Providing service dependencies
      - Testing both success and failure cases
yaml
style_anchors:
  - path: src/services/UserService.ts
    lines: 10-50
    description: |
      Example of Effect.Service pattern with:
      - Dependency injection via Effect.Service
      - All methods returning Effect types
      - Proper error handling with tagged errors

  - path: test/services/UserService.test.ts
    lines: 1-40
    description: |
      Example of testing Effect services:
      - Using it.effect from @effect/vitest
      - Providing service dependencies
      - Testing both success and failure cases

Quality Gate Configuration

质量门配置

Pre-Commit Hooks

提交前钩子

yaml
quality_gates:
  - stage: pre-commit
    commands:
      - npm run lint
      - npm run typecheck
      - npm test
    must_pass: true
yaml
quality_gates:
  - stage: pre-commit
    commands:
      - npm run lint
      - npm run typecheck
      - npm test
    must_pass: true

CI Pipeline

CI流水线

yaml
quality_gates:
  - stage: ci
    commands:
      - npm run lint
      - npm run typecheck
      - npm test
      - npm run test:integration
    coverage_threshold: 80
yaml
quality_gates:
  - stage: ci
    commands:
      - npm run lint
      - npm run typecheck
      - npm test
      - npm run test:integration
    coverage_threshold: 80

Task Completion

任务完成

yaml
quality_gates:
  - stage: task-completion
    criteria:
      - All tests passing
      - No lint errors
      - No type errors
      - Code formatted
      - Documentation updated
      - Commit message follows convention
yaml
quality_gates:
  - stage: task-completion
    criteria:
      - All tests passing
      - No lint errors
      - No type errors
      - Code formatted
      - Documentation updated
      - Commit message follows convention

Usage

使用方法

Generate implementation plan:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yaml
With style anchors:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yaml --style-anchors ./examples
The skill will:
  1. Load and analyze both requirement documents
  2. Identify logical milestones based on functionality
  3. Create dependency-ordered milestone breakdown
  4. For each milestone:
    • Generate detailed task breakdown
    • Add style anchor references
    • Apply task sizing rules
    • Add TDD and quality constraints
  5. Output
    milestones.yaml
    and
    milestone-m*.tasks.yaml
    files
生成实施计划:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yaml
附带风格锚点:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yaml --style-anchors ./examples
该技能会:
  1. 加载并分析两份需求文档
  2. 根据功能识别逻辑里程碑
  3. 创建按依赖顺序排列的里程碑拆解
  4. 针对每个里程碑:
    • 生成详细的任务拆解
    • 添加风格锚点引用
    • 应用任务规模规则
    • 添加TDD和质量约束
  5. 输出
    milestones.yaml
    milestone-m*.tasks.yaml
    文件

Planning Best Practices

规划最佳实践

Milestone Identification

里程碑识别

  1. Start with foundation - Infrastructure and tooling first
  2. Build vertically - Complete features end-to-end
  3. Minimize dependencies - Parallel work where possible
  4. Deliver value early - Working software in early milestones
  5. Respect constraints - Timeline, resources, complexity
  1. 从基础开始 - 先处理基础设施和工具
  2. 垂直构建 - 端到端完成功能
  3. 最小化依赖 - 尽可能并行工作
  4. 尽早交付价值 - 在早期里程碑中提供可运行的软件
  5. 尊重约束 - 时间线、资源、复杂度

Task Breakdown

任务拆解

  1. Single responsibility - Each task does one thing
  2. Clear dependencies - Explicit task ordering
  3. Testable - Every task has validation criteria
  4. Bounded scope - Limited files and complexity
  5. Reversible - Easy to revert if needed
  1. 单一职责 - 每个任务只做一件事
  2. 明确依赖 - 清晰的任务顺序
  3. 可测试 - 每个任务都有验证标准
  4. 范围明确 - 限制文件数量和复杂度
  5. 可回滚 - 必要时易于回滚

Dependency Management

依赖管理

  1. Minimize critical path - Parallelize where possible
  2. Clear interfaces - Well-defined contracts between tasks
  3. Document assumptions - What each task expects from predecessors
  4. Plan for failure - What happens if dependencies fail
  1. 最小化关键路径 - 尽可能并行执行
  2. 清晰接口 - 任务之间定义明确的契约
  3. 记录假设 - 每个任务对前置任务的期望
  4. 为失败做计划 - 依赖项失败时的应对方案

Example Workflow

示例工作流

Input Files

输入文件

project/
├── business-requirements.yaml
├── technical-requirements.yaml
└── examples/
    ├── service.ts
    ├── service.test.ts
    └── schema.ts
project/
├── business-requirements.yaml
├── technical-requirements.yaml
└── examples/
    ├── service.ts
    ├── service.test.ts
    └── schema.ts

Command

命令

bash
/implementation-planner \
  business-requirements.yaml \
  technical-requirements.yaml \
  --style-anchors ./examples
bash
/implementation-planner \
  business-requirements.yaml \
  technical-requirements.yaml \
  --style-anchors ./examples

Output Files

输出文件

project/
├── milestones.yaml
├── milestone-m0.tasks.yaml  # Foundation
├── milestone-m1.tasks.yaml  # Core features
├── milestone-m2.tasks.yaml  # Advanced features
└── milestone-m3.tasks.yaml  # Polish & release
project/
├── milestones.yaml
├── milestone-m0.tasks.yaml  # Foundation
├── milestone-m1.tasks.yaml  # Core features
├── milestone-m2.tasks.yaml  # Advanced features
└── milestone-m3.tasks.yaml  # Polish & release

Review & Gap Analysis

审查与差距分析

After generating milestones and task files, automatically perform a gap analysis:
生成里程碑和任务文件后,自动执行差距分析:

Completeness Check

完整性检查

Milestone Structure:
  • All milestones have clear deliverables
  • Dependencies are correctly ordered
  • No circular dependencies
  • Timeline is realistic
  • Success criteria are testable
Task Breakdown:
  • All requirements covered by tasks
  • Task sizing follows 30-150 minute rule
  • Dependencies between tasks are explicit
  • File scopes are clearly defined
  • Each task has validation criteria
Task Quality:
  • Instructions are clear and actionable
  • Constraints are explicit
  • TDD checklist included for code tasks
  • Validation commands specified
  • Drift policy stated
里程碑结构:
  • 所有里程碑都有明确的交付物
  • 依赖关系顺序正确
  • 无循环依赖
  • 时间线符合实际
  • 成功标准可测试
任务拆解:
  • 所有需求都有对应的任务覆盖
  • 任务规模遵循30-150分钟规则
  • 任务之间的依赖关系明确
  • 文件范围定义清晰
  • 每个任务都有验证标准
任务质量:
  • 指令清晰且可执行
  • 约束条件明确
  • 代码任务包含TDD检查清单
  • 指定了验证命令
  • 说明了漂移处理策略

Alignment Check

对齐检查

Business Requirements:
  • All functional requirements mapped to tasks
  • Priority aligns with business priorities
  • MVP scope clearly defined
  • Success criteria can be verified
Technical Requirements:
  • Architecture decisions reflected in structure
  • Technology choices enforced in constraints
  • Testing strategy implemented
  • Security requirements addressed
业务需求:
  • 所有功能需求都映射到任务
  • 优先级与业务优先级对齐
  • MVP范围明确定义
  • 成功标准可验证
技术需求:
  • 架构决策在结构中得到体现
  • 技术选择在约束中强制执行
  • 测试策略已实施
  • 安全需求已得到满足

Task Sizing Analysis

任务规模分析

Check for violations:
  • Tasks < 30 minutes - merge or document rationale
  • Tasks > 150 minutes - split into smaller tasks
  • Critical path has appropriate task sizes
Generate sizing report:
yaml
task_sizing_analysis:
  total_tasks: [count]
  average_duration: [minutes]

  too_small:
    - task_id: [id]
      estimate: [minutes]
      rationale: [why it's small]
      recommendation: [merge with X or accept]

  too_large:
    - task_id: [id]
      estimate: [minutes]
      recommendation: [split into X, Y, Z]

  optimal_range:
    count: [number]
    percentage: [%]
检查违规情况:
  • 时长<30分钟的任务 - 合并或记录理由
  • 时长>150分钟的任务 - 拆分为更小的任务
  • 关键路径上的任务规模合理
生成规模报告:
yaml
task_sizing_analysis:
  total_tasks: [count]
  average_duration: [minutes]

  too_small:
    - task_id: [id]
      estimate: [minutes]
      rationale: [why it's small]
      recommendation: [merge with X or accept]

  too_large:
    - task_id: [id]
      estimate: [minutes]
      recommendation: [split into X, Y, Z]

  optimal_range:
    count: [number]
    percentage: [%]

Dependency Analysis

依赖分析

Critical Path:
  • Identify critical path through milestones
  • Check for parallel execution opportunities
  • Verify no unnecessary dependencies
  • Ensure dependencies are minimal but sufficient
Dependency graph validation:
yaml
dependency_analysis:
  critical_path: [m0 → m1 → m3 → m5]
  critical_path_duration: [time]

  parallel_opportunities:
    - [m2 and m3 can run in parallel]
    - [m4 can start after m1]

  dependency_issues:
    - task: [id]
      issue: [unnecessary dependency / missing dependency]
      recommendation: [fix]
关键路径:
  • 识别里程碑之间的关键路径
  • 检查并行执行的机会
  • 验证无不必要的依赖
  • 确保依赖关系最少但足够
依赖图验证:
yaml
dependency_analysis:
  critical_path: [m0 → m1 → m3 → m5]
  critical_path_duration: [time]

  parallel_opportunities:
    - [m2 and m3 can run in parallel]
    - [m4 can start after m1]

  dependency_issues:
    - task: [id]
      issue: [unnecessary dependency / missing dependency]
      recommendation: [fix]

Gap Identification

差距识别

Common Gaps to Check:
  • Missing infrastructure tasks (setup, tooling)
  • Missing test tasks
  • Missing documentation tasks
  • Missing error handling tasks
  • Missing configuration tasks
  • Missing deployment/release tasks
  • Undocumented assumptions in tasks
  • Missing style anchors for new patterns
  • Tasks without clear file boundaries
  • Missing integration tasks between components
需检查的常见差距:
  • 缺失基础设施任务(设置、工具)
  • 缺失测试任务
  • 缺失文档任务
  • 缺失错误处理任务
  • 缺失配置任务
  • 缺失部署/发布任务
  • 任务中未记录的假设
  • 新模式缺失风格锚点
  • 任务无明确的文件边界
  • 组件之间缺失集成任务

Coverage Analysis

覆盖范围分析

Requirement Coverage Matrix:
yaml
requirement_coverage:
  functional_requirements:
    FR-1: [m1-001, m1-002] # Tasks covering this requirement
    FR-2: [m1-003]
    FR-3: [gap] # Not covered!

  non_functional_requirements:
    performance: [m2-001, m2-002]
    security: [m1-005]
    usability: [gap] # Not covered!
需求覆盖矩阵:
yaml
requirement_coverage:
  functional_requirements:
    FR-1: [m1-001, m1-002] # Tasks covering this requirement
    FR-2: [m1-003]
    FR-3: [gap] # Not covered!

  non_functional_requirements:
    performance: [m2-001, m2-002]
    security: [m1-005]
    usability: [gap] # Not covered!

Style Anchor Validation

风格锚点验证

  • Style anchors reference existing files (if provided)
  • Style anchors demonstrate correct patterns
  • Line numbers are accurate
  • Descriptions are helpful
  • 风格锚点引用了现有文件(若提供)
  • 风格锚点正确展示了模式
  • 行号准确
  • 描述有帮助

Review Output

审查输出

Generate a comprehensive gap analysis report:
yaml
gap_analysis:
  completeness_score: [1-10]
  alignment_score: [1-10]
  feasibility_score: [1-10]

  critical_gaps:
    - category: [category]
      issue: [description]
      impact: [high/medium/low]
      affected_requirements: [FR-1, FR-2, etc]
      recommendation: [how to fix]

  missing_coverage:
    requirements:
      - [FR-X not covered]
      - [NFR-Y not covered]

    task_types:
      - [Missing: integration tests]
      - [Missing: documentation]

  sizing_issues:
    too_small_count: [n]
    too_large_count: [n]
    recommendations: [list]

  dependency_issues:
    - [description]

  strong_areas:
    - [what's well-planned]

  optimization_opportunities:
    - [parallel execution: m2 and m3]
    - [combine tasks: m1-002 and m1-003]

  suggestions:
    - [improvement suggestions]

  ready_for_development: [yes/no/with-modifications]

  estimated_timeline:
    optimistic: [time]
    realistic: [time]
    pessimistic: [time]
If critical gaps found, ask:
"I've identified some gaps in the implementation plan:
Critical Issues:
  • [Issue 1]
  • [Issue 2]
Missing Coverage:
  • [Requirement FR-X not covered]
  • [No integration tests planned]
Would you like to:
  1. Add missing tasks now (I'll generate them)
  2. Review and manually adjust the plan
  3. Proceed with development (address gaps as needed)"
生成全面的差距分析报告:
yaml
gap_analysis:
  completeness_score: [1-10]
  alignment_score: [1-10]
  feasibility_score: [1-10]

  critical_gaps:
    - category: [category]
      issue: [description]
      impact: [high/medium/low]
      affected_requirements: [FR-1, FR-2, etc]
      recommendation: [how to fix]

  missing_coverage:
    requirements:
      - [FR-X not covered]
      - [NFR-Y not covered]

    task_types:
      - [Missing: integration tests]
      - [Missing: documentation]

  sizing_issues:
    too_small_count: [n]
    too_large_count: [n]
    recommendations: [list]

  dependency_issues:
    - [description]

  strong_areas:
    - [what's well-planned]

  optimization_opportunities:
    - [parallel execution: m2 and m3]
    - [combine tasks: m1-002 and m1-003]

  suggestions:
    - [improvement suggestions]

  ready_for_development: [yes/no/with-modifications]

  estimated_timeline:
    optimistic: [time]
    realistic: [time]
    pessimistic: [time]
如果发现关键差距,询问:
"我在实施计划中发现了一些差距:
关键问题:
  • [问题1]
  • [问题2]
缺失覆盖:
  • [需求FR-X未被覆盖]
  • [未规划集成测试]
您希望:
  1. 立即添加缺失的任务(我将生成这些任务)
  2. 审查并手动调整计划
  3. 继续开发(在需要时解决差距)"

Integration with Development

与开发流程集成

Starting a Milestone

启动里程碑

bash
undefined
bash
undefined

Load milestone tasks into context

将里程碑任务加载到上下文

Read milestone-m1.tasks.yaml
Read milestone-m1.tasks.yaml

Review style anchors

查看风格锚点

Read examples/service.ts:10-50 Read examples/service.test.ts:1-40
Read examples/service.ts:10-50 Read examples/service.test.ts:1-40

Begin first task

开始第一个任务

Task m1-001: Implement core service

Task m1-001: Implement core service

undefined
undefined

Completing a Task

完成任务

  1. Run validation commands
  2. Verify all criteria met
  3. Commit changes
  4. Update task status
  5. Move to next task
  1. 运行验证命令
  2. 验证所有标准已满足
  3. 提交变更
  4. 更新任务状态
  5. 进入下一个任务

Handling Drift

处理漂移

If you encounter unexpected patterns:
  1. STOP - Do not continue
  2. DOCUMENT - What was unexpected
  3. REVERT - Return to last known good state
  4. REPORT - Ask for guidance
  5. UPDATE - Add rule to prevent recurrence
如果遇到意外模式:
  1. 停止 - 不要继续
  2. 记录 - 记录意外内容
  3. 回滚 - 恢复到上一个已知的良好状态
  4. 报告 - 请求指导
  5. 更新 - 添加规则以防止再次发生

Examples

示例

See examples/ for sample milestone and task files.
查看examples/获取示例里程碑和任务文件。