plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Decompose reviewed design into agent-sized implementation issues →

## Implementation Plan

section in the living doc + numbered issue files in

./issues/<feature-name>/

Pipeline: explore → define → [design] → architect → plan → agent implementation.

Phase: Engineering. User is technical.

将经过评审的设计分解为适合Agent处理的实现任务→在动态文档中添加

## Implementation Plan

章节，并在

./issues/<feature-name>/

目录下生成带编号的任务文件。

流程管线：探索→定义→[设计]→架构设计→任务规划→Agent实现。

阶段：工程实现。用户为技术人员。

Starting

开始执行

Ask user for living doc path or list

./plans/*.md

and ask.

## Rollback Notes

has content: this takes priority. Read notes, skip validation, resume only affected domains, clear after resolving.

Validate by checking for

## Technical Design

with

### Phased Build Plan

Has Technical Design + Phased Build Plan: Proceed.
Has Requirements but no Technical Design: Stop. "Run
```
/architect
```
first."
Has Scope only: Stop. "Run
```
/define
```
then
```
/architect
```
first."
Simple fix plan (specific file changes, no phases): Accept — produces 1-2 issues.

向用户询问动态文档路径，或列出

./plans/*.md

文件供用户选择。

若

## Rollback Notes

章节有内容：需优先处理该部分。阅读回滚说明，跳过验证步骤，仅恢复受影响的领域，问题解决后清空该章节内容。

通过检查是否存在包含

### Phased Build Plan

的

## Technical Design

章节进行验证：

存在技术设计+分阶段构建计划：继续执行。
仅需求无技术设计：终止操作。提示“请先运行
```
/architect
```
指令。”
仅范围定义：终止操作。提示“请先运行
```
/define
```
再运行
```
/architect
```
指令。”
简单修复计划（仅涉及特定文件修改，无阶段划分）：接受该计划——将生成1-2个任务。

Process

执行流程

1. Read the codebase

1. 读取代码库

Read
```
CLAUDE.md
```
and
```
AGENTS.md
```
for conventions and quality gates.
Read every source file referenced in the design. For each: line count, key interfaces/types + line numbers, pattern landmarks (insertion points, code to follow), import paths.
For each new file the plan calls for, find the closest existing analog as "pattern reference."

读取
```
CLAUDE.md
```
和
```
AGENTS.md
```
文件，了解编码规范与质量管控标准。
读取设计文档中引用的所有源文件。针对每个文件：统计行数，记录关键接口/类型及对应行号、模式标记（插入点、需遵循的代码）、导入路径。
针对计划中要求创建的每个新文件，找到最相似的现有文件作为“模式参考”。

2. Decompose into vertical slices

2. 分解为垂直切片

Break into vertical slices (tracer bullets). Each issue delivers one working capability through all layers it touches — schema + service + route + UI together when they serve one feature.

Anti-pattern — horizontal layers: Issue 1 = "all schema tables", Issue 2 = "all services", Issue 3 = "all UI pages". Also bad: splitting "template service" and "template UI" into separate issues — same capability, should be one issue. Instead: Issue 1 = "template CRUD" (schema + service + settings UI), Issue 2 = "public signing" (page + action + customer linking). Each issue is a thin vertical thread, not a thick horizontal slab.

Foundation exception: A schema-only issue is acceptable when its tables serve 3+ downstream issues (shared migration). Otherwise merge schema into its first consuming capability.

Sizing: 1-6 files per issue, hard cap 8. If exceeding 6, split by feature boundary — not by layer. A capability's service and UI belong in the same issue. Cross-cutting concerns (email, notifications, cron) get own issues after the code they wire into. Each issue includes its own tests. Zero design decisions remaining.

Classify each: AFK (agent implements autonomously) or HITL (needs human review — UX layout, visual design, open tradeoffs).

将任务分解为垂直切片（追踪式任务）。每个任务需交付一个可运行的完整功能，覆盖其涉及的所有层级——若某功能同时涉及数据库schema、服务、路由和UI，则需将这些部分整合为一个任务。

反模式——水平分层：例如任务1=“所有数据库表”，任务2=“所有服务”，任务3=“所有UI页面”。另一种不良做法：将“模板服务”和“模板UI”拆分为两个独立任务——二者属于同一功能，应合并为一个任务。正确做法：任务1=“模板CRUD”（schema+服务+设置UI），任务2=“公开签名”（页面+操作+客户关联）。每个任务应是一条细的垂直线索，而非厚的水平板块。

基础例外情况：若某数据库表需为3个及以上下游任务提供支持（共享迁移），则可单独创建一个仅涉及schema的任务。否则应将schema合并至首个使用该schema的功能任务中。

任务规模：每个任务涉及1-6个文件，上限为8个。若超过6个文件，需按功能边界拆分——而非按层级拆分。同一功能的服务和UI应属于同一任务。横切关注点（邮件、通知、定时任务cron）需在其关联的核心代码任务完成后，再单独创建任务。每个任务需包含自身的测试用例。任务规划完成后不应遗留任何待决策的设计问题。

对每个任务进行分类：AFK（Agent可自主实现）或HITL（需人工审核——如UX布局、视觉设计、未决权衡项）。

3. Present breakdown

3. 展示任务分解结果

Show table with columns: #, Title, Files, Depends on, Type, Parallel with. Ask for approval via

AskUserQuestion

— header (≤12 chars), 2–4 options, one marked "(Recommended)". Max 3 targeted questions if genuine ambiguities exist.

If unambiguous: "No questions — the design resolves all decisions. Approve?"

Iterate until approved.

展示包含以下列的表格：编号、标题、涉及文件、依赖项、类型、可并行任务。通过

AskUserQuestion

请求用户批准——标题（≤12字符），提供2-4个选项，其中一个标记为“(推荐)”。若存在真实歧义，最多提出3个针对性问题。

若不存在歧义：提示“无疑问——设计已明确所有决策。是否批准？”

反复迭代直至获得批准。

4. Generate issues

4. 生成任务文件

Create

./issues/<feature-name>/

(kebab-case from living doc filename). Write each issue in dependency order using the template in

assets/issue-template.md

. No

00-overview.md

— that content goes in the living doc.

创建

./issues/<feature-name>/

目录（目录名为动态文档文件名的短横线分隔格式）。按照依赖顺序，使用

assets/issue-template.md

中的模板编写每个任务文件。无需创建

00-overview.md

——相关内容应写入动态文档。

5. Write Implementation Plan

5. 编写实现计划

Write

## Implementation Plan

into the living doc using the template in

assets/implementation-plan-template.md

. Update

## Pipeline Status

with plan row.

使用

assets/implementation-plan-template.md

中的模板，在动态文档中添加

## Implementation Plan

章节。更新

## Pipeline Status

章节，添加计划相关行。

6. Finish

6. 完成规划

Print overview table. Note AFK vs HITL. Suggest: "To start, hand

01-...

to an agent. Parallelizable issues can run concurrently in separate worktrees."

打印任务概览表格。标注AFK与HITL任务。建议：“开始执行时，可将

01-...

任务分配给Agent。可并行的任务可在独立工作树中同时执行。”

Rollback

回滚机制

Receiving: Read

## Rollback Notes

for trigger, affected domains, decisions to preserve. Resume only affected domains — do not re-decompose resolved issues. Update plan, clear

## Rollback Notes

, direct user back to triggering skill.

Triggering:

Scope too large (>15 issues or phases with unclear boundaries) → roll back to
```
/architect
```
.
Underspecified (missing file paths, acceptance criteria, or behavior specs) → roll back to
```
/architect
```
.
Product gap (missing user story or contradictory requirements) → roll back to
```
/architect
```
(may cascade to
```
/define
```
).

Append trigger details and decisions to preserve to

## Rollback Notes

in the living doc.

接收回滚请求：读取

## Rollback Notes

章节中的触发原因、受影响领域、需保留的决策。仅恢复受影响的领域——无需重新分解已解决的任务。更新计划，清空

## Rollback Notes

章节，引导用户返回触发回滚的指令。

触发回滚：

范围过大（任务数量>15或阶段边界不清晰）→ 回滚至
```
/architect
```
指令环节。
规格不明确（缺失文件路径、验收标准或行为规范）→ 回滚至
```
/architect
```
指令环节。
产品缺口（缺失用户故事或需求矛盾）→ 回滚至
```
/architect
```
指令环节（可能需进一步回滚至
```
/define
```
环节）。

将触发回滚的详情及需保留的决策追加至动态文档的

## Rollback Notes

章节。