implementation-planner
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseImplementation 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
输入分析
-
Load Requirements
- Parse business requirements for functional scope
- Parse technical requirements for architectural decisions
- Identify dependencies and constraints
-
Identify Milestones
- Group related features into logical milestones
- Establish dependency order
- Define milestone deliverables
-
Generate Tasks
- Break down milestones into atomic tasks
- Apply task sizing rules (30m - 2.5h)
- Define task dependencies
- Add style anchors and constraints
-
Apply Best Practices
- TDD requirements
- Style anchor references
- Quality constraints
- Drift prevention rules
-
加载需求
- 解析业务需求以明确功能范围
- 解析技术需求以确定架构决策
- 识别依赖关系与约束条件
-
确定里程碑
- 将相关功能分组为逻辑里程碑
- 建立依赖顺序
- 定义里程碑交付物
-
生成任务
- 将里程碑拆解为原子任务
- 应用任务规模规则(30分钟 - 2.5小时)
- 定义任务依赖关系
- 添加风格锚点与约束条件
-
应用最佳实践
- 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.yamlyaml
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.yamlyaml
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.yamlyaml
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.yamlyaml
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
undefinedBEFORE (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]
undefinedStyle Anchor Integration
风格锚点集成
What Makes a Good Style Anchor
优质风格锚点的标准
- Concrete - Real file paths, not abstract descriptions
- Specific - Line numbers for precision
- Complete - Code + tests + documentation
- Current - Reflects current best practices
- Exemplary - Demonstrates the pattern correctly
- 具体 - 使用真实文件路径,而非抽象描述
- 精确 - 指定行号以确保准确性
- 完整 - 包含代码 + 测试 + 文档
- 最新 - 反映当前最佳实践
- 典范 - 正确展示模式
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 casesyaml
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 casesQuality Gate Configuration
质量门配置
Pre-Commit Hooks
提交前钩子
yaml
quality_gates:
- stage: pre-commit
commands:
- npm run lint
- npm run typecheck
- npm test
must_pass: trueyaml
quality_gates:
- stage: pre-commit
commands:
- npm run lint
- npm run typecheck
- npm test
must_pass: trueCI Pipeline
CI流水线
yaml
quality_gates:
- stage: ci
commands:
- npm run lint
- npm run typecheck
- npm test
- npm run test:integration
coverage_threshold: 80yaml
quality_gates:
- stage: ci
commands:
- npm run lint
- npm run typecheck
- npm test
- npm run test:integration
coverage_threshold: 80Task Completion
任务完成
yaml
quality_gates:
- stage: task-completion
criteria:
- All tests passing
- No lint errors
- No type errors
- Code formatted
- Documentation updated
- Commit message follows conventionyaml
quality_gates:
- stage: task-completion
criteria:
- All tests passing
- No lint errors
- No type errors
- Code formatted
- Documentation updated
- Commit message follows conventionUsage
使用方法
Generate implementation plan:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yamlWith style anchors:
/implementation-planner path/to/business-requirements.yaml path/to/technical-requirements.yaml --style-anchors ./examplesThe skill will:
- Load and analyze both requirement documents
- Identify logical milestones based on functionality
- Create dependency-ordered milestone breakdown
- For each milestone:
- Generate detailed task breakdown
- Add style anchor references
- Apply task sizing rules
- Add TDD and quality constraints
- Output and
milestones.yamlfilesmilestone-m*.tasks.yaml
生成实施计划:
/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该技能会:
- 加载并分析两份需求文档
- 根据功能识别逻辑里程碑
- 创建按依赖顺序排列的里程碑拆解
- 针对每个里程碑:
- 生成详细的任务拆解
- 添加风格锚点引用
- 应用任务规模规则
- 添加TDD和质量约束
- 输出和
milestones.yaml文件milestone-m*.tasks.yaml
Planning Best Practices
规划最佳实践
Milestone Identification
里程碑识别
- Start with foundation - Infrastructure and tooling first
- Build vertically - Complete features end-to-end
- Minimize dependencies - Parallel work where possible
- Deliver value early - Working software in early milestones
- Respect constraints - Timeline, resources, complexity
- 从基础开始 - 先处理基础设施和工具
- 垂直构建 - 端到端完成功能
- 最小化依赖 - 尽可能并行工作
- 尽早交付价值 - 在早期里程碑中提供可运行的软件
- 尊重约束 - 时间线、资源、复杂度
Task Breakdown
任务拆解
- Single responsibility - Each task does one thing
- Clear dependencies - Explicit task ordering
- Testable - Every task has validation criteria
- Bounded scope - Limited files and complexity
- Reversible - Easy to revert if needed
- 单一职责 - 每个任务只做一件事
- 明确依赖 - 清晰的任务顺序
- 可测试 - 每个任务都有验证标准
- 范围明确 - 限制文件数量和复杂度
- 可回滚 - 必要时易于回滚
Dependency Management
依赖管理
- Minimize critical path - Parallelize where possible
- Clear interfaces - Well-defined contracts between tasks
- Document assumptions - What each task expects from predecessors
- Plan for failure - What happens if dependencies fail
- 最小化关键路径 - 尽可能并行执行
- 清晰接口 - 任务之间定义明确的契约
- 记录假设 - 每个任务对前置任务的期望
- 为失败做计划 - 依赖项失败时的应对方案
Example Workflow
示例工作流
Input Files
输入文件
project/
├── business-requirements.yaml
├── technical-requirements.yaml
└── examples/
├── service.ts
├── service.test.ts
└── schema.tsproject/
├── business-requirements.yaml
├── technical-requirements.yaml
└── examples/
├── service.ts
├── service.test.ts
└── schema.tsCommand
命令
bash
/implementation-planner \
business-requirements.yaml \
technical-requirements.yaml \
--style-anchors ./examplesbash
/implementation-planner \
business-requirements.yaml \
technical-requirements.yaml \
--style-anchors ./examplesOutput 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 & releaseproject/
├── milestones.yaml
├── milestone-m0.tasks.yaml # Foundation
├── milestone-m1.tasks.yaml # Core features
├── milestone-m2.tasks.yaml # Advanced features
└── milestone-m3.tasks.yaml # Polish & releaseReview & 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:
- Add missing tasks now (I'll generate them)
- Review and manually adjust the plan
- 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未被覆盖]
- [未规划集成测试]
您希望:
- 立即添加缺失的任务(我将生成这些任务)
- 审查并手动调整计划
- 继续开发(在需要时解决差距)"
Integration with Development
与开发流程集成
Starting a Milestone
启动里程碑
bash
undefinedbash
undefinedLoad 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
undefinedundefinedCompleting a Task
完成任务
- Run validation commands
- Verify all criteria met
- Commit changes
- Update task status
- Move to next task
- 运行验证命令
- 验证所有标准已满足
- 提交变更
- 更新任务状态
- 进入下一个任务
Handling Drift
处理漂移
If you encounter unexpected patterns:
- STOP - Do not continue
- DOCUMENT - What was unexpected
- REVERT - Return to last known good state
- REPORT - Ask for guidance
- UPDATE - Add rule to prevent recurrence
如果遇到意外模式:
- 停止 - 不要继续
- 记录 - 记录意外内容
- 回滚 - 恢复到上一个已知的良好状态
- 报告 - 请求指导
- 更新 - 添加规则以防止再次发生
Examples
示例
See examples/ for sample milestone and task files.
查看examples/获取示例里程碑和任务文件。