planning-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Writing Plans

编写开发计划

Overview

概述

Write comprehensive implementation plans assuming the engineer has zero context for the codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.

Assume they are a skilled developer, but know almost nothing about the toolset or problem domain. Assume they don't know good test design very well.

Core principle: Plans must be executable without asking questions.

假设工程师对代码库完全不了解且缺乏良好的编码品味，编写全面的实施计划。记录他们需要知道的所有信息：每项任务需要修改哪些文件、所需的代码、测试、要查阅的文档，以及测试方法。将整个计划拆分为可快速完成的小任务。遵循DRY（Don't Repeat Yourself，不要重复自己）、YAGNI（You Aren't Gonna Need It，你不会需要它）、TDD（Test-Driven Development，测试驱动开发）原则，频繁提交代码。

假设他们是熟练的开发者，但对工具集或问题领域几乎一无所知，且不擅长良好的测试设计。

核心原则： 计划必须无需额外提问即可执行。

The Iron Law

铁律

NO VAGUE STEPS - EVERY STEP IS A SPECIFIC ACTION

"Add validation" is not a step. "Write test for empty email, run it, implement check, run it, commit" - that's 5 steps.

NO VAGUE STEPS - EVERY STEP IS A SPECIFIC ACTION

“添加验证”不是一个合格的步骤。“编写空邮箱测试用例，运行测试，实现校验逻辑，再次运行测试，提交代码”——这才是5个明确的步骤。

Bite-Sized Task Granularity

小粒度任务拆分

Each step is one action (2-5 minutes):

"Write the failing test" - step
"Run it to make sure it fails" - step
"Implement the minimal code to make the test pass" - step
"Run the tests and make sure they pass" - step
"Commit" - step

Not a step:

"Add authentication" (too vague)
"Implement the feature" (multiple actions)
"Test it" (which tests? how?)

每个步骤对应一个独立操作（耗时2-5分钟）：

“编写失败的测试用例”——合格步骤
“运行测试确认失败”——合格步骤
“编写最小化代码使测试通过”——合格步骤
“运行测试确认通过”——合格步骤
“提交代码”——合格步骤

不合格的步骤：

“添加认证功能”（过于模糊）
“实现该特性”（包含多个操作）
“进行测试”（测试什么？如何测试？）

Plan Document Header

计划文档头部

Every plan MUST start with this header:

markdown

undefined

每个计划必须以以下头部开头：

markdown

undefined

[Feature Name] Implementation Plan

[特性名称] 实施计划

For Claude: REQUIRED: Follow this plan task-by-task using TDD. Design: See
docs/plans/YYYY-MM-DD-<feature>-design.md
for full specification.

Goal: [One sentence describing what this builds]

Architecture: [2-3 sentences about approach]

Tech Stack: [Key technologies/libraries]

Prerequisites: [What must exist before starting]


If a design document exists, always reference it in the header.

致Claude： 必须严格按照此计划的任务步骤，采用TDD方式执行。 设计文档： 完整规格请查看
docs/plans/YYYY-MM-DD-<feature>-design.md
。

目标： [一句话描述该计划要实现的内容]

架构： [2-3句话说明实现思路]

技术栈： [关键技术/库]

前置条件： [开始执行前必须已具备的条件]


如果存在设计文档，必须在头部中引用。

Task Structure

任务结构

markdown

undefined

markdown

undefined

Task N: [Component Name]

任务N：[组件名称]

Files:

Create:
```
exact/path/to/file.ts
```
Modify:
```
exact/path/to/existing.ts:123-145
```
Test:
```
tests/exact/path/to/test.ts
```

Step 1: Write the failing test

typescript

test('specific behavior being tested', () => {
  const result = functionName(input);
  expect(result).toBe(expected);
});

Step 2: Run test to verify it fails

Run:

npm test tests/path/test.ts -- --grep "specific behavior"

Expected: FAIL with "functionName is not defined"

Step 3: Write minimal implementation

typescript

function functionName(input: InputType): OutputType {
  return expected;
}

Step 4: Run test to verify it passes

Run:

npm test tests/path/test.ts -- --grep "specific behavior"

Expected: PASS

Step 5: Commit

bash

git add tests/path/test.ts src/path/file.ts
git commit -m "feat: add specific feature"

undefined

涉及文件：

创建：
```
exact/path/to/file.ts
```
修改：
```
exact/path/to/existing.ts:123-145
```
测试：
```
tests/exact/path/to/test.ts
```

步骤1：编写失败的测试用例

typescript

test('specific behavior being tested', () => {
  const result = functionName(input);
  expect(result).toBe(expected);
});

步骤2：运行测试确认失败

执行命令：

npm test tests/path/test.ts -- --grep "specific behavior"

预期结果：测试失败，提示 "functionName is not defined"

步骤3：编写最小化实现代码

typescript

function functionName(input: InputType): OutputType {
  return expected;
}

步骤4：运行测试确认通过

执行命令：

npm test tests/path/test.ts -- --grep "specific behavior"

预期结果：测试通过

步骤5：提交代码

bash

git add tests/path/test.ts src/path/file.ts
git commit -m "feat: add specific feature"

undefined

Context is King (Cole Medin Principle)

上下文为王（Cole Medin原则）

The plan must contain ALL information for a single-pass implementation.

A developer with zero codebase context should be able to execute the plan WITHOUT asking any questions.

计划必须包含单次完成实施所需的全部信息。

对代码库完全不了解的开发者应能无需提问即可执行该计划。

Context References Section (MUST READ!)

上下文参考部分（必读！）

Every plan MUST include a Context References section:

markdown

undefined

每个计划必须包含上下文参考部分：

markdown

undefined

Relevant Codebase Files

Level	Name	Commands	When
1	Syntax & Style	`npm run lint` , `tsc --noEmit`	Every task
2	Unit Tests	`npm test`	Low-Medium risk
3	Integration Tests	`npm run test:integration`	Medium-High risk
4	Manual Validation	User flow walkthrough	High-Critical risk

级别	名称	命令	适用场景
1	语法与风格	`npm run lint` , `tsc --noEmit`	所有任务
2	单元测试	`npm test`	中低风险任务
3	集成测试	`npm run test:integration`	中高风险任务
4	手动验证	用户流程走查	高-关键风险任务

在每个任务步骤中包含具体的验证命令。

Requirements Checklist

需求检查清单

Risk Assessment Table

风险评估表

For each identified risk:

Risk	Probability (1-5)	Impact (1-5)	Score	Mitigation
API timeout	3	4	12	Retry with backoff
Invalid input	4	2	8	Validation layer
Auth bypass	2	5	10	Security review

Score = Probability × Impact. Address risks with score > 8 first.

针对每个已识别的风险：

风险	发生概率（1-5）	影响程度（1-5）	风险评分	缓解措施
API超时	3	4	12	带退避策略的重试机制
无效输入	4	2	8	验证层
认证绕过	2	5	10	安全评审

风险评分 = 发生概率 × 影响程度。优先处理评分>8的风险。

Risk-Based Testing Matrix

基于风险的测试矩阵

Match testing depth to task risk:

Task Risk	Example	Tests Required
Trivial	Typo fix, docs update	None
Low	Single file change, utility function	Unit tests only
Medium	Multi-file feature, new component	Unit + Integration tests
High	Cross-service, auth, state management	Unit + Integration + E2E tests
Critical	Payments, security, data migrations	All tests + Security audit

How to assess risk:

How many files touched? (1 = low, 3+ = medium, cross-service = high)
Is it auth/payments/security? (always high or critical)
Is it user-facing? (medium minimum)
Can it cause data loss? (high or critical)

Use this matrix when planning test steps. Don't over-test trivial changes. Don't under-test critical ones.

根据任务风险匹配测试深度：

任务风险	示例	所需测试
极低	拼写错误修复、文档更新	无
低	单文件修改、工具函数	仅单元测试
中	多文件功能、新组件	单元测试 + 集成测试
高	跨服务、认证、状态管理	单元测试 + 集成测试 + E2E测试
关键	支付、安全、数据迁移	所有测试 + 安全审计

风险评估方法：

涉及多少个文件？（1个=低风险，3个及以上=中风险，跨服务=高风险）
是否涉及认证/支付/安全？（始终为高或关键风险）
是否面向用户？（最低为中风险）
是否可能导致数据丢失？（高或关键风险）

规划测试步骤时请使用此矩阵。不要过度测试低风险变更，也不要低估关键风险的测试需求。

Functionality Flow Mapping

功能流程映射

Before planning, document all flows:

User Flow:

1. User clicks [button]
2. System shows [form]
3. User enters [data]
4. System validates [input]
5. System saves [data]
6. System shows [confirmation]

Admin Flow:

1. Admin opens [dashboard]
2. Admin selects [item]
3. System shows [details]
4. Admin changes [setting]
5. System applies [change]

System Flow:

1. Request arrives at [endpoint]
2. Middleware validates [auth]
3. Controller calls [service]
4. Service queries [database]
5. Response returns [data]

编写计划前，记录所有流程：

用户流程：

1. 用户点击[按钮]
2. 系统展示[表单]
3. 用户输入[数据]
4. 系统验证[输入]
5. 系统保存[数据]
6. 系统展示[确认信息]

管理员流程：

1. 管理员打开[仪表盘]
2. 管理员选择[项目]
3. 系统展示[详情]
4. 管理员修改[设置]
5. 系统应用[变更]

系统流程：

1. 请求到达[端点]
2. 中间件验证[认证信息]
3. 控制器调用[服务]
4. 服务查询[数据库]
5. 返回响应[数据]

Architecture Decision Records (ADR)

架构决策记录（ADR）

When comparing approaches, document the decision formally:

Use this format when a plan involves choosing between multiple valid approaches:

markdown

undefined

当比较不同实现方案时，需正式记录决策：

当计划需要在多个可行方案中选择时，使用以下格式：

markdown

undefined

ADR: [Decision Title]

ADR：[决策标题]

Context: What situation or requirement prompted this decision?

Decision: What approach did we choose?

Consequences:

Positive: [benefits of this choice]
Negative: [tradeoffs we accept]
Alternatives Considered: [what we didn't choose and why]


**When to use ADR:**
- Choosing between architectures (monolith vs microservices)
- Selecting libraries/frameworks (React vs Vue)
- Database decisions (SQL vs NoSQL)
- Authentication approaches (JWT vs sessions)

**Save ADRs to:** `docs/decisions/ADR-NNN-title.md`

背景： 是什么场景或需求促使了这个决策？

决策： 我们选择了哪种方案？

后果：

积极影响： [该选择带来的好处]
负面影响： [我们需接受的权衡]
备选方案： [未选择的方案及原因]


**ADR适用场景：**
- 架构选择（单体应用 vs 微服务）
- 库/框架选择（React vs Vue）
- 数据库决策（SQL vs NoSQL）
- 认证方案选择（JWT vs 会话）

**ADR保存路径：** `docs/decisions/ADR-NNN-title.md`

Red Flags - STOP and Revise

红色警告 - 停止并修订

If you find yourself:

Writing "add feature" without exact file paths
Skipping the test step
Combining multiple actions into one step
Using "etc." or "similar" instead of explicit steps
Planning without understanding existing code patterns
Creating steps that take more than 5 minutes
Not including expected output for test commands

STOP. Revise the plan with more specific steps.

如果你发现自己在做以下事情：

编写“添加功能”却未给出确切文件路径
跳过测试步骤
将多个操作合并为一个步骤
使用“等等”或“类似”而非明确步骤
在未理解现有代码模式的情况下编写计划
创建耗时超过5分钟的步骤
未包含测试命令的预期输出

立即停止。修订计划，补充更具体的步骤。

Rationalization Prevention

避免合理化借口

Excuse	Reality
"They'll know what I mean"	No they won't. Be explicit.
"Too much detail is annoying"	Vague plans cause bugs.
"Testing is obvious"	Write the test command.
"File paths are discoverable"	Write the exact path.
"Commits are implied"	Write when to commit.
"They can figure out edge cases"	List every edge case.

借口	实际情况
“他们会明白我的意思”	他们不会。请明确表述。
“细节太多很烦人”	模糊的计划会导致bug。
“测试步骤是显而易见的”	请写出具体的测试命令。
“文件路径可以自己找”	请写出确切路径。
“提交代码是默认操作”	请明确何时提交。
“他们能自己找出边缘情况”	请列出所有边缘情况。

Output Format

输出格式

markdown

undefined

markdown

undefined

[Feature Name] Implementation Plan

[特性名称] 实施计划

For Claude: REQUIRED: Follow this plan task-by-task using TDD.

Goal: [One sentence]

Architecture: [2-3 sentences]

Tech Stack: [Technologies]

Prerequisites: [Requirements]

致Claude： 必须严格按照此计划的任务步骤，采用TDD方式执行。

目标： [一句话描述]

架构： [2-3句话]

技术栈： [相关技术]

前置条件： [所需条件]

Phase 1: [Demonstrable Milestone]

阶段1：[可验证的里程碑]

Exit Criteria: [What must be true when this phase is complete - e.g., "User can log in and receive JWT"]

退出标准： [阶段完成时必须达成的目标 - 例如：“用户可登录并获取JWT”]

Task 1: [First Component]

任务1：[第一个组件]

Files:

Create:
```
src/path/file.ts
```
Test:
```
tests/path/file.test.ts
```

Step 1: Write failing test [code block with test]

Step 2: Run test, verify fails Run:

[command]

Expected: FAIL

Step 3: Implement [code block with implementation]

Step 4: Run test, verify passes Run:

[command]

Expected: PASS

Step 5: Commit

bash

git add [files]
git commit -m "feat: [description]"

涉及文件：

创建：
```
src/path/file.ts
```
测试：
```
tests/path/file.test.ts
```

步骤1： 编写失败的测试用例 [测试代码块]

步骤2： 运行测试，确认失败执行命令：

[具体命令]

预期结果：测试失败

步骤3： 实现代码 [实现代码块]

步骤4： 运行测试，确认通过执行命令：

[具体命令]

预期结果：测试通过

步骤5： 提交代码

bash

git add [文件]
git commit -m "feat: [描述]"

Task 2: [Second Component]

任务2：[第二个组件]

...

Risks

风险

Risk	P	I	Score	Mitigation
...	...	...	...	...

风险	概率	影响	评分	缓解措施
...	...	...	...	...

Success Criteria

成功标准

Save the Plan (MANDATORY)

保存计划（强制要求）

Two saves are required - plan file AND memory update:

需完成两次保存 - 计划文件和内存更新：

Step 1: Save Plan File (Use Write tool - NO PERMISSION NEEDED)

步骤1：保存计划文件（使用Write工具 - 无需权限）

undefined

undefined

First create directory

先创建目录

Bash(command="mkdir -p docs/plans")

Then save plan using Write tool (permission-free)

然后使用Write工具保存计划（无需权限）

Write(file_path="docs/plans/YYYY-MM-DD-<feature>-plan.md", content="[full plan content from output format above]")

Write(file_path="docs/plans/YYYY-MM-DD-<feature>-plan.md", content="[上述输出格式中的完整计划内容]")

Then commit (separate commands to avoid permission prompt)

然后提交（分命令执行以避免权限提示）

Bash(command="git add docs/plans/*.md") Bash(command="git commit -m 'docs: add <feature> implementation plan'")

undefined

Bash(command="git add docs/plans/*.md") Bash(command="git commit -m 'docs: add <feature> implementation plan'")

undefined

Step 2: Update Memory (CRITICAL - Links Plan to Memory)

步骤2：更新内存（关键 - 关联计划与内存）

Use Read-Edit-Verify with stable anchors:

undefined

使用Read-Edit-Verify及稳定锚点：

undefined

Step 1: READ

步骤1：读取

Read(file_path=".claude/cc10x/activeContext.md")

Step 2: VERIFY anchors exist (## References, ## Recent Changes, ## Next Steps)

步骤2：验证锚点存在（## References, ## Recent Changes, ## Next Steps）

Step 3: EDIT using stable anchors

步骤3：使用稳定锚点编辑

Add plan to References

将计划添加到参考部分

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## References", new_string="## References\n- Plan:

docs/plans/YYYY-MM-DD-<feature>-plan.md

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## References", new_string="## References\n- Plan:

docs/plans/YYYY-MM-DD-<feature>-plan.md

Index the plan creation in Recent Changes

在最近变更中记录计划创建

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Recent Changes", new_string="## Recent Changes\n- Plan saved: docs/plans/YYYY-MM-DD-<feature>-plan.md")

Make execution the default next step

将执行计划设为默认下一步

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Next Steps", new_string="## Next Steps\n1. Execute plan: docs/plans/YYYY-MM-DD-<feature>-plan.md")

Step 4: VERIFY (do not skip)

步骤4：验证（不要跳过）

Read(file_path=".claude/cc10x/activeContext.md")


**Also append to progress.md using stable anchor:**

Read(file_path=".claude/cc10x/progress.md")

Edit(file_path=".claude/cc10x/progress.md", old_string="## Completed", new_string="## Completed\n- [x] Plan saved - docs/plans/YYYY-MM-DD-<feature>-plan.md")

Read(file_path=".claude/cc10x/activeContext.md")

undefined

VERIFY (do not skip)

步骤2：更新进度文件

Read(file_path=".claude/cc10x/progress.md")


**WHY BOTH:** Plan files are artifacts. Memory is the index. Without memory update, next session won't know the plan exists.

**This is non-negotiable.** Memory is the single source of truth.

同样需要更新
.claude/cc10x/progress.md
：

Read(file_path=".claude/cc10x/progress.md")

Edit(file_path=".claude/cc10x/progress.md",
     old_string="## Completed",
     new_string="## Completed\n- [x] Plan saved - docs/plans/YYYY-MM-DD-<feature>-plan.md")

Task-Based Execution Tracking

验证（不要跳过）

After saving plan, create execution tasks for tracking progress:

Read(file_path=".claude/cc10x/progress.md")


**为什么需要两次保存：** 计划文件是 artifacts，内存是索引。如果不更新内存，下一次会话将不知道该计划的存在。

**这是不可协商的要求。** 内存是唯一的事实来源。

Step 1: Create Parent Task

基于任务的执行跟踪

TaskCreate({
  subject: "CC10X Execute Plan: {feature}",
  description: "Plan file: docs/plans/YYYY-MM-DD-{feature}-plan.md\n\n{brief_plan_summary}",
  activeForm: "Executing {feature} plan"
})

保存计划后，创建执行任务以跟踪进度：

Returns parent_task_id

步骤1：创建父任务

undefined

TaskCreate({
  subject: "CC10X Execute Plan: {feature}",
  description: "Plan file: docs/plans/YYYY-MM-DD-{feature}-plan.md\n\n{brief_plan_summary}",
  activeForm: "Executing {feature} plan"
})

Step 2: Create Phase Tasks with Dependencies

返回parent_task_id

undefined

undefined

For each phase in plan:

步骤2：创建阶段任务并设置依赖

TaskCreate({ subject: "CC10X Phase 1: {phase_title}", description: "Plan: docs/plans/YYYY-MM-DD-{feature}-plan.md\nSection: Phase 1\nExit Criteria: {demonstrable_milestone}\n\n{phase_details}", activeForm: "Working on {phase_title}" })

undefined

Returns phase_1_id

针对计划中的每个阶段：

TaskCreate({ subject: "CC10X Phase 2: {phase_title}", description: "Plan: docs/plans/YYYY-MM-DD-{feature}-plan.md\nSection: Phase 2\nExit Criteria: {demonstrable_milestone}\n\n{phase_details}", activeForm: "Working on {phase_title}" }) TaskUpdate({ taskId: phase_2_id, addBlockedBy: [phase_1_id] })

Continue for all phases...

返回phase_1_id

undefined

Step 3: Store Task IDs in Memory

为所有阶段重复此操作...

Update

.claude/cc10x/progress.md

with task subjects (and optionally task IDs for the current session). Do not rely on task IDs for long-term continuity unless you deliberately share the task list across sessions.

Use Edit + Read-back verify:

Read(file_path=".claude/cc10x/progress.md")

Edit(file_path=".claude/cc10x/progress.md",
     old_string="## Tasks",
     new_string="## Tasks

- CC10X Execute Plan: {feature} (blocked by: -)
- CC10X Phase 1: {title} (blocked by: -)
- CC10X Phase 2: {title} (blocked by: CC10X Phase 1: {title})
")

undefined

VERIFY (do not skip)

步骤3：在内存中存储任务ID

Read(file_path=".claude/cc10x/progress.md")


**WHY:** Tasks help orchestration (dependencies + parallelism) and survive context compactions. For cross-session continuity, the plan file + CC10x memory files are the durable source of truth. If you intentionally share a task list across sessions (official Claude Code supports this), subjects/namespacing keep scope safe.

更新

.claude/cc10x/progress.md

，添加任务主题（可选添加当前会话的任务ID）。除非你特意跨会话共享任务列表，否则不要依赖任务ID进行长期连续性跟踪。

使用Edit + Read-back验证：

Read(file_path=".claude/cc10x/progress.md")

Edit(file_path=".claude/cc10x/progress.md",
     old_string="## Tasks",
     new_string="## Tasks

- CC10X Execute Plan: {feature} (blocked by: -)
- CC10X Phase 1: {title} (blocked by: -)
- CC10X Phase 2: {title} (blocked by: CC10X Phase 1: {title})
")

Plan-Task Linkage (Context Preservation)

验证（不要跳过）

The relationship between Plan Files and Tasks:

┌─────────────────────────────────────────────────────────────────────┐
│  PLAN FILE (Persistent - Source of Truth)                           │
│  Location: docs/plans/YYYY-MM-DD-{feature}-plan.md                 │
│  Contains: Full implementation details, TDD steps, file paths      │
│  Survives: Session close, context compaction, conversation reset   │
└─────────────────────────────────────────────────────────────────────┘
                     ↕ task description includes the plan file path
┌─────────────────────────────────────────────────────────────────────┐
│  TASKS (Execution Engine)                                           │
│  Contains: Status, dependencies, progress tracking                 │
│  Survives: Context compaction; can be shared across sessions via   │
│            task list configuration (official Claude Code)          │
└─────────────────────────────────────────────────────────────────────┘

Plan path-in-description is CRITICAL: If context compacts mid-execution, the task description contains enough info to:

Find the plan file
Locate the exact phase/task
Continue without asking questions

Phase Exit Criteria are CRITICAL: Each phase MUST have a demonstrable milestone (not arbitrary naming):

❌ "Phase 1: Foundation" - Vague, when is it done?
✅ "Phase 1: User can authenticate" - Demonstrable, testable

Read(file_path=".claude/cc10x/progress.md")


**原因：** 任务有助于协调执行（依赖关系 + 并行执行），并能在上下文压缩后保留。对于跨会话连续性，计划文件 + CC10x内存文件是可靠的事实来源。如果你有意跨会话共享任务列表（官方Claude Code支持此功能），主题/命名空间可确保范围安全。

Execution Handoff

计划-任务关联（上下文保留）

After saving the plan, offer execution choice:

"Plan complete and saved to
docs/plans/<filename>.md
. Two execution options:

1. Subagent-Driven (this session) - Fresh subagent per task, review between tasks, fast iteration

2. Manual Execution - Follow plan step by step, verify each step

Which approach?"

计划文件与任务的关系：

┌─────────────────────────────────────────────────────────────────────┐
│ 计划文件（持久化 - 事实来源）                                       │
│ 位置：docs/plans/YYYY-MM-DD-{feature}-plan.md                     │
│ 包含：完整实施细节、TDD步骤、文件路径                              │
│ 可保留：会话关闭、上下文压缩、对话重置后仍存在                     │
└─────────────────────────────────────────────────────────────────────┘
                     ↕ 任务描述中包含计划文件路径
┌─────────────────────────────────────────────────────────────────────┐
│ 任务（执行引擎）                                                   │
│ 包含：状态、依赖关系、进度跟踪                                     │
│ 可保留：上下文压缩后仍存在；通过任务列表配置可跨会话共享（官方Claude Code） │
└─────────────────────────────────────────────────────────────────────┘

任务描述中包含计划路径至关重要： 如果执行过程中发生上下文压缩，任务描述中的信息足以：

找到计划文件
定位到具体阶段/任务
无需提问即可继续执行

阶段退出标准至关重要： 每个阶段必须有可验证的里程碑（而非随意命名）：

❌ “阶段1：基础架构” - 模糊，无法判断何时完成
✅ “阶段1：用户可完成认证” - 可验证、可测试

—

执行交接

—

保存计划后，提供执行选择：

"计划已完成并保存至
docs/plans/<filename>.md
。有两种执行选项：

1. 子代理驱动（当前会话） - 每个任务使用全新子代理，任务间进行评审，迭代速度快

2. 手动执行 - 逐步遵循计划，验证每个步骤

选择哪种方式？"

planning-patterns

Original

Translation

Writing Plans

编写开发计划

Overview

概述

The Iron Law

铁律

Bite-Sized Task Granularity

小粒度任务拆分

Plan Document Header

计划文档头部

[Feature Name] Implementation Plan

[特性名称] 实施计划

Task Structure

任务结构

Task N: [Component Name]

任务N：[组件名称]

Context is King (Cole Medin Principle)

上下文为王（Cole Medin原则）

Context References Section (MUST READ!)

上下文参考部分（必读！）

Relevant Codebase Files

相关代码库文件

Patterns to Follow

需遵循的模式

Configuration Files

配置文件

Related Documentation

相关文档

Validation Levels

验证级别

Requirements Checklist

需求检查清单

Risk Assessment Table

风险评估表

Risk-Based Testing Matrix

基于风险的测试矩阵

Functionality Flow Mapping

功能流程映射

Architecture Decision Records (ADR)

架构决策记录（ADR）

ADR: [Decision Title]

ADR：[决策标题]

Red Flags - STOP and Revise

红色警告 - 停止并修订

Rationalization Prevention

避免合理化借口

Output Format

输出格式

[Feature Name] Implementation Plan

[特性名称] 实施计划

Phase 1: [Demonstrable Milestone]

阶段1：[可验证的里程碑]

Task 1: [First Component]

任务1：[第一个组件]

Task 2: [Second Component]

任务2：[第二个组件]

Risks

风险

Success Criteria

成功标准

Save the Plan (MANDATORY)

保存计划（强制要求）

Step 1: Save Plan File (Use Write tool - NO PERMISSION NEEDED)

步骤1：保存计划文件（使用Write工具 - 无需权限）

First create directory

先创建目录

Then save plan using Write tool (permission-free)

然后使用Write工具保存计划（无需权限）

Then commit (separate commands to avoid permission prompt)

然后提交（分命令执行以避免权限提示）

Step 2: Update Memory (CRITICAL - Links Plan to Memory)

步骤2：更新内存（关键 - 关联计划与内存）

Step 1: READ

步骤1：读取

Step 2: VERIFY anchors exist (## References, ## Recent Changes, ## Next Steps)

步骤2：验证锚点存在（## References, ## Recent Changes, ## Next Steps）

Step 3: EDIT using stable anchors