planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Planning

规划

Build a plan by collaborative interrogation, then stress-test it adversarially, before coding. The deliverable is a plan file, or the tickets that plan splits into when the work is too big for one pass. Never code.

IS: building a plan from intent through one-question-at-a-time interrogation (Create), and strengthening an existing plan by scoring six dimensions to 5/5 with claim verification (Review). Both write to the plan file. When the work exceeds one plan, both exit through the split in
```
references/splitting.md
```
, which publishes vertical-slice tickets.
IS NOT: implementing or generating code, authoring a PR (use
```
pr-creator
```
), reviewing a code diff (use
```
pr-reviewer
```
), or writing an architecture brief (use
```
codebase-architecture
```
).

Pipeline position:

planning

(create then review) -> implementation ->

pr-reviewer

pr-creator

pr-babysitter

通过协作式问询构建计划，然后在编码前对其进行对抗性压力测试。交付成果为计划文件，或者当任务过大无法一次性完成时，将计划拆分为多个任务工单。绝对不要直接编码。

负责内容： 通过逐次问询从需求意图出发构建计划（创建模式），并通过对六个维度评分直至达到5/5，同时验证主张来强化现有计划（审查模式）。两种模式都会写入计划文件。当任务超出单个计划的范围时，两种模式都会通过
```
references/splitting.md
```
中的拆分规则退出，该规则会生成垂直切片任务工单。
不负责内容： 实现或生成代码、创建PR（请使用
```
pr-creator
```
）、审查代码差异（请使用
```
pr-reviewer
```
），或撰写架构概要（请使用
```
codebase-architecture
```
）。

流水线位置：

planning

（创建模式后接审查模式）-> 实施 ->

pr-reviewer

pr-creator

pr-babysitter

Mode dispatch

模式调度

Auto-detect; ask only if genuinely ambiguous:

No plan file in scope, or verbs like "create a plan", "plan this", "grill me", "think this through" -> Create mode.
Existing plan in scope (a path, pasted plan, or recent file in the active agent's native plan directory), or verbs like "review my plan", "stress test", "is this ready", "get this to 5/5", "verify this claim", "fact-check this plan" -> Review mode.
No plan in scope but the user asks to verify or fact-check a standalone claim -> answer directly with local evidence; create no plan artifact.
If the input is code or a diff rather than a plan, stop and route to
```
pr-reviewer
```
.

Create hands off to Review; a plan is not ready for implementation until Review passes.

自动检测；仅在确实存在歧义时询问：

范围内无计划文件，或出现“create a plan”、“plan this”、“grill me”、“think this through”等动词 -> 创建模式。
范围内存在现有计划（路径、粘贴的计划或活跃Agent本地计划目录中的最新文件），或出现“review my plan”、“stress test”、“is this ready”、“get this to 5/5”、“verify this claim”、“fact-check this plan”等动词 -> 审查模式。
范围内无计划但用户要求验证或核实独立主张 -> 直接使用本地证据作答；不创建计划成果。
如果输入是代码或差异而非计划，请停止并转至
```
pr-reviewer
```
。

创建模式完成后移交至审查模式；计划必须通过审查模式后才能进入实施阶段。

Decision principles

决策原则

Use these to cut scope, sequence work, and challenge the plan. Turn each into a plan edit; never cite slogans.

KISS: fewest moving parts that satisfy the current requirement. Delete layers, modes, config, or coordination that do not change the first shippable outcome.
As simple as possible, no simpler: never cut correctness, permissions, observability, rollback, migration safety, or required edge states. A smaller plan that drops a current requirement is too small.
YAGNI: defer extension points, future providers, generic frameworks, and speculative settings until a named current requirement needs them.
Proven practice: when the ecosystem or repo has a proven pattern for this exact problem, use it and name the precedent. Invent a local pattern only when a concrete constraint makes the standard one fail.
Easier to change: make the next likely requirement local. Name what file, module, table, or API boundary changes later, and what stays untouched.
Tracer bullet: prove the approach with one minimum viable vertical slice across the real boundary before building horizontal layers.
DRY: deduplicate knowledge, invariants, protocols, and business rules, not coincidental shape.
Duplication over wrong abstraction: keep similar code duplicated when the shared abstraction would hide different business rules, lifecycles, owners, or failure modes.
Ladder of least code: for each piece of new code the plan calls for, take the first rung that holds: reuse what is already in the codebase, then stdlib, then a native platform feature, then an already-installed dependency, then the minimum new code. A plan step that adds a dependency, or new code a higher rung plausibly covers, must say why the higher rungs fail.

Conflict rule: current requirements win first. Then

as simple as possible, no simpler

bounds KISS and YAGNI;

duplication over wrong abstraction

bounds DRY;

tracer bullet

beats horizontal foundation work unless the project cannot run without that foundation.

使用这些原则来缩减范围、安排任务顺序并挑战计划。将每条原则转化为计划修改；切勿直接引用口号。

KISS： 用最少的组件满足当前需求。删除那些不会影响第一个可交付成果的层级、模式、配置或协调流程。
尽可能简单，但不能过于简化： 绝不能削减正确性、权限、可观测性、回滚、迁移安全性或必需的边缘状态。如果缩小后的计划遗漏了当前需求，那就是过小了。
YAGNI： 将扩展点、未来提供者、通用框架和推测性设置推迟到有明确的当前需求需要时再考虑。
成熟实践： 当生态系统或代码库中存在针对此特定问题的成熟模式时，请使用该模式并说明先例。只有当具体约束导致标准模式失效时，才自行设计本地模式。
易于变更： 让下一个可能的需求可本地化实现。指明后续需要修改的文件、模块、表或API边界，以及保持不变的部分。
示踪弹： 在构建横向层级之前，通过跨真实边界的最小可行垂直切片验证方法的可行性。
DRY： 消除知识、不变量、协议和业务规则的重复，而非巧合性的结构重复。
重复优于错误抽象： 当共享抽象会隐藏不同的业务规则、生命周期、所有者或故障模式时，保留相似代码的重复。
最少代码阶梯： 对于计划要求的每一段新代码，选择最基础可行的方案：优先复用代码库中已有的内容，其次是标准库，然后是原生平台功能，接着是已安装的依赖，最后才是编写最少的新代码。如果计划步骤需要添加依赖，或者更高阶梯的方案可以覆盖新代码，必须说明为何更高阶梯的方案不可行。

冲突规则：当前需求优先。然后“尽可能简单，但不能过于简化”约束KISS和YAGNI；“重复优于错误抽象”约束DRY；“示踪弹”优先于横向基础工作，除非项目无法脱离该基础工作运行。

Reference files

参考文件

File	Mode	Read when
`references/interrogation-protocol.md`	Create	Create Step 2: question decision tree, blindspot pass, reference-as-spec, recommended-answer format, fuzzy-term patterns, anti-rationalization table
`references/doc-grounding.md`	Create	Create Step 1, when design docs, RFCs, ADRs, or library/API docs are relevant: find them, extract the decisions they encode, grill the rationale
`references/html-question-form.md`	Create	Create Step 2, optional: batched HTML question form for large or greenfield specs instead of one-at-a-time chat
`references/plan-quality-rubric.md`	Review	Review Step 2 triage: 1-5 scoring criteria per dimension
`references/questioning-framework.md`	Review	Review Step 3: question templates and pushback patterns per dimension
`references/dialogue-examples.md`	Review	Before the Review dialogue: tone calibration, and the Verify move's claim/evidence/verdict block worked through
`references/splitting.md`	Both	The work is too big for one plan: vertical slice rules, blocking edges, the expand-contract exception, granularity confirmation, and how to publish the tickets
`references/claim-verification.md`	Review	When a claim is checkable against local code, docs, or specs, or the user asks to verify one

文件	模式	读取时机
`references/interrogation-protocol.md`	创建模式	创建步骤2：问题决策树、盲点排查、参考作为规范、推荐答案格式、模糊术语模式、反合理化表格
`references/doc-grounding.md`	创建模式	创建步骤1，当设计文档、RFC、ADR或库/API文档相关时：查找这些文档，提取其中的决策，盘问其理由
`references/html-question-form.md`	创建模式	创建步骤2，可选：针对大型或全新规格生成批量HTML问题表单，替代逐次聊天问询
`references/plan-quality-rubric.md`	审查模式	审查步骤2分类：每个维度的1-5分评分标准
`references/questioning-framework.md`	审查模式	审查步骤3：每个维度的问题模板和追问模式
`references/dialogue-examples.md`	审查模式	审查对话前：语气校准，以及验证步骤中主张/证据/结论模块的示例
`references/splitting.md`	两种模式	任务过大无法放入单个计划时：垂直切片规则、阻塞边缘、扩展-收缩例外、粒度确认，以及如何发布任务工单
`references/claim-verification.md`	审查模式	当主张可通过本地代码、文档或规格核查，或用户要求验证某一主张时

Create mode

创建模式

text

Create progress:
- [ ] Step 1: Understand intent (read the request, scan code and docs, state findings)
- [ ] Step 2: Interrogate (one question at a time; end with the "radically simpler?" challenge)
- [ ] Step 3: Synthesize (write the plan file, format matched to scope)
- [ ] Step 4: Validate (run the four checks, emit the validation block)
- [ ] Step 5: Hand off to Review mode

text

创建进度：
- [ ] 步骤1：理解需求意图（读取请求、扫描代码和文档、说明发现）
- [ ] 步骤2：问询（每次一个问题；最后提出“是否能大幅简化？”的挑战）
- [ ] 步骤3：合成（编写计划文件，格式与范围匹配）
- [ ] 步骤4：验证（执行四项检查，输出验证块）
- [ ] 步骤5：移交至审查模式

Step 1: Understand intent

步骤1：理解需求意图

Before asking, scan code and docs:

Identify modules, files, and patterns related to the request; note conventions, abstractions, boundaries, and prior art.
Read relevant design docs, RFCs, ADRs, READMEs, referenced library/API docs, and any spec the user points to. Load
```
references/doc-grounding.md
```
to find docs and extract their decisions and rationale.

State findings in 2-3 sentences before the first question.

在提问前，扫描代码和文档：

识别与请求相关的模块、文件和模式；记录约定、抽象、边界和已有实践。
阅读相关的设计文档、RFC、ADR、README、参考的库/API文档，以及用户指向的任何规格。加载
```
references/doc-grounding.md
```
以查找文档并提取其中的决策和理由。

在第一个问题前用2-3句话说明发现。

Step 2: Interrogate

步骤2：问询

Load

references/interrogation-protocol.md

. Ask ONE question at a time. Every question carries a recommended answer grounded in Step 1: name the file, function, approach.

Diverge before converging (first move): put 2-3 genuinely different framings of the work on the table, not variations on one, each with what it buys and what it forecloses, then recommend one. Every later question narrows, so this is the only turn where the frame itself is still open. It costs at most one question and catches the two scope errors nothing else does: too narrow (a one-line fix where the whole bug class needed handling) and too wide (a framework where one function held).
If code or docs can answer it, answer it yourself; never spend a user question on it.
Each answer shapes the next. Walk the decision tree: resolve intent and scope before approach, approach before risks.
Flag fuzzy terms ("handle auth", "make it fast"): propose a sharp version and ask if it is right.
Surface tensions with existing code: "The codebase does X. You're proposing Y. Which wins?"
Grill the core decisions: when docs reveal a decision, interrogate why it was made and whether the rationale still holds. Never re-ask what docs answer; pressure-test the reasoning.
Probe for a reference-as-spec: ask if existing code, a library, a design, or a site already does this the way the user wants. If so, read it and treat its semantics as the spec, interrogating only deviations.
Blindspot pass (conditional): when the user is unfamiliar with the area or asks for one ("blindspot pass", "unknown unknowns"), pause questions to surface what good looks like, prior work, and potholes, then teach it back before resuming. Detail in
```
references/interrogation-protocol.md
```
.

Budget: 5-10 questions, then synthesize. Needing more than 10 is evidence the scope is too big for one plan; propose a split instead of continuing to ask, and load

references/splitting.md

to run it. A split redirects Step 3: the deliverable becomes the approved tickets, indexed by a

## Slices

section in a lightweight plan file, rather than one plan no executor can finish in a pass. Steps 4 and 5 still run on that file.

Mandatory scope challenge (before synthesizing): ask "What can we cut without dropping a current requirement?" Carry a recommended cut list: removed extension points, setup collapsed into the first vertical slice, new code or dependencies a higher ladder rung already covers, abstractions kept only when they protect a shared invariant/owner/lifecycle, and safety gates preserved where "simpler" would drop correctness. Challenge the sum of the plan, not each piece.

Batch mode (optional): for large or greenfield specs with many independent questions, generate one local HTML form. Load

references/html-question-form.md

for the template and batch-vs-sequential table. Default to one-at-a-time when answers should shape later questions.

Escape hatch: if the user says "just write the plan", push back once via the anti-rationalization table, then respect their call and skip to Step 3.

加载

references/interrogation-protocol.md

。每次只提一个问题。每个问题都要附带基于步骤1的推荐答案：指明文件、函数或方法。

先发散后收敛（第一步）： 提出2-3种真正不同的任务框架，而非同一框架的变体，每种框架说明其优势和局限性，然后推荐一种。后续所有问题都会逐步缩小范围，因此这是唯一可以开放讨论框架的环节。这最多只需要一个问题，却能发现其他方式无法察觉的两种范围错误：范围过窄（只需一行修复却要处理整个bug类别）和范围过宽（只需一个函数却要构建框架）。
如果代码或文档可以回答问题，请自行回答；切勿浪费用户的提问机会。
每个答案都会影响下一个问题。遵循决策树：先明确意图和范围，再确定方法，最后探讨风险。
标记模糊术语（如“处理认证”、“提升速度”）：提出明确的定义并询问是否正确。
指出与现有代码的冲突：“代码库采用X方案，您提议Y方案，应以哪个为准？”
盘问核心决策： 当文档揭示某一决策时，盘问其做出的原因以及理由是否仍然成立。切勿重复询问文档已回答的问题；要压力测试其推理过程。
探寻参考作为规范： 询问是否已有代码、库、设计或网站采用了用户想要的方式。如果有，阅读并将其语义作为规范，仅盘问偏离部分。
盲点排查（条件触发）： 当用户不熟悉相关领域或明确要求（如“blindspot pass”、“unknown unknowns”）时，暂停提问，梳理理想状态、已有工作和潜在陷阱，然后向用户说明后再继续。详情见
```
references/interrogation-protocol.md
```
。

提问预算： 5-10个问题，然后进行合成。如果需要超过10个问题，说明范围过大无法放入单个计划；此时应提议拆分而非继续提问，并加载

references/splitting.md

执行拆分。拆分后步骤3将调整：交付成果变为经批准的任务工单，在轻量计划文件的

## Slices

部分中索引，而非单个无法一次性完成的计划。步骤4和5仍会针对该文件执行。

强制性范围挑战（合成前）： 询问“在不遗漏当前需求的前提下，我们可以削减哪些内容？”附带推荐削减清单：移除扩展点、将设置合并到第一个垂直切片中、用更高阶梯的方案覆盖新代码或依赖、仅保留能保护共享不变量/所有者/生命周期的抽象，以及保留“简化”会导致正确性缺失的安全关卡。挑战的是计划的整体，而非单个部分。

批量模式（可选）： 针对包含多个独立问题的大型或全新规格，生成本地HTML表单。加载

references/html-question-form.md

获取模板和批量vs逐次问询的对比表。当答案会影响后续问题时，默认使用逐次问询模式。

逃生舱： 如果用户说“直接写计划”，通过反合理化表格反驳一次，然后尊重用户的要求并跳至步骤3。

Step 3: Synthesize

步骤3：合成

Write the plan file to the active agent's native plan directory when one exists; otherwise to the user-specified path or the repo-local plan location set by project instructions. Match format to scope.

Lightweight (single file, clear approach):

# Title

## Context

(one paragraph),

## Approach

Standard (multiple files, decisions made):

# Title

## Context

(problem, what prompted it, intended outcome),

## Approach

(recommended only),

## Key decisions

(brief rationale),

## Files to modify

(grouped by purpose),

## Out of scope

(related-looking things that must not change, each with a reason),

## Verification

(each item a command plus expected result).

Order volatile-first: within Approach, Key decisions, and Files to modify, lead with the decisions the user is most likely to tweak (data model changes, new type interfaces, user-facing flows) and sink mechanical refactoring detail to the bottom. A reviewer should be able to stop reading once the tweakable decisions look right.

Keep plans scannable yet executable without re-reading the conversation. Record only the chosen approach; rejected alternatives become one-line rationale under Key decisions.

Size the plan to the work, not to the template. Pick the lightest format the task supports, and drop any section the task does not need rather than filling it. A plan that restates the codebase, enumerates every file when a pattern plus three representative paths would do, or explains decisions the reader already made costs review attention and buries the parts that need a second look.

Handoff plans: when another agent or session will execute, the executor has not seen this conversation. Inline any code excerpts and conventions it needs (with

file:line

markers), and add a STOP conditions section: assumptions that, if false, mean stop and report back rather than improvise.

Name an implementation-notes file next to the plan and instruct the executor to keep it: every deviation the code forced on the plan gets logged under a

## Deviations

heading as what the plan said, what the code required, and which option was taken. A deviation that is not a STOP condition never pauses the work; take the conservative option, log it, keep going. The notes file is what review reads afterwards, so a handoff without one loses every decision made during execution.

A handoff plan also says what an acceptable finish looks like, not only what trips a STOP. STOP conditions name assumptions checkable in advance; an executor that never trips one and has no finish line keeps patching past the point the work stopped converging. The last entry in the implementation-notes file states how the run ended and the evidence for it: the capability works on the real path and the case that motivated the plan improved, or a genuine blocker was removed and the next one isolated, or the run stopped because finishing would need scope the plan does not cover.

如果活跃Agent有本地计划目录，将计划文件写入该目录；否则写入用户指定路径或项目指令设置的代码库本地计划位置。格式与范围匹配。

轻量格式（单个文件、方法明确）：

# 标题

、

## 背景

（一段文字）、

## 方法

。

标准格式（多个文件、已做出决策）：

# 标题

、

## 背景

（问题、触发原因、预期成果）、

## 方法

（仅推荐方案）、

## 关键决策

（简要理由）、

## 需修改的文件

（按用途分组）、

## 范围外内容

（看似相关但不得修改的内容，每项附理由）、

## 验证

（每项为命令加预期结果）。

易变内容优先： 在方法、关键决策和需修改的文件部分，优先列出用户最可能调整的决策（数据模型变更、新类型接口、用户交互流程），将机械重构细节放在末尾。审查者应能在看到可调整的决策无误后停止阅读。

保持计划易于扫描且无需重读对话即可执行。仅记录选定的方法；被否决的替代方案在关键决策下以一行理由说明。

计划大小匹配任务规模，而非模板。 选择任务支持的最轻量格式，删除任务不需要的部分而非填充内容。如果计划重复代码库内容、枚举每个文件（而模式加三个代表性路径即可），或解释审查者已知的决策，会浪费审查精力并掩盖需要关注的部分。

移交计划： 当由其他Agent或会话执行时，执行者未参与本次对话。需内嵌所需的代码片段和约定（带

file:line

标记），并添加停止条件部分：如果这些假设不成立，应停止并报告而非自行变通。

在计划旁指定一个实施笔记文件，并指示执行者维护该文件：代码迫使计划做出的每一处偏差都要记录在

## 偏差

标题下，包括计划内容、代码要求以及最终选择的方案。非停止条件的偏差无需暂停工作；选择保守方案，记录后继续。该笔记文件是后续审查的依据，因此没有笔记文件的移交会丢失执行过程中做出的所有决策。

移交计划还应说明可接受的完成状态，而非仅说明触发停止的条件。停止条件列出可提前核查的假设；如果执行者未触发任何停止条件且没有完成标准，会无限期修改，笔记文件也无法记录任务结束的状态。实施笔记文件的最后一项应说明任务如何结束及依据：功能在真实路径上可用且计划针对的问题得到改善，或真正的阻塞已移除并隔离了下一个阻塞，或因完成任务需要计划未涵盖的范围而停止。

Step 4: Validate

步骤4：验证

Does the plan answer the user's original request?
Did every interrogation answer land in the plan? An answer that never made it in was a wasted question.
Scope gate: the plan fails if it violates any decision principle, especially an unneeded extension point, horizontal setup before the first tracer bullet, new code or a new dependency where a higher ladder rung holds, or a cut that drops required correctness, permissions, rollback, migration safety, or edge states.
Any unstated assumptions that should be explicit?

Fix failures in the plan directly; don't reopen the interrogation.

Then emit the validation block. Every row cites the plan section that satisfies its check, so a check with nothing to cite is a failure to fix before reporting rather than a claim to assert:

text

PLAN VALIDATION: <path>
  Answers the request    <section stating the intended outcome>
  Answers landed         <n of n interrogation answers; name any dropped>
  Scope gate             <section carrying the cut list; principles checked>
  Assumptions explicit   <section, or "none found">
  Verification           <the plan's Verification commands, copied>

Lightweight plans have no Verification section; cite the one check that proves the approach instead.

计划是否回应用户的原始请求？
所有问询的答案是否都已纳入计划？未纳入的答案意味着提问被浪费。
范围关卡： 如果计划违反任何决策原则，尤其是包含不必要的扩展点、在第一个示踪弹前进行横向设置、用新代码或新依赖替代更高阶梯的方案，或削减了必需的正确性、权限、回滚、迁移安全性或边缘状态，则计划不通过。
是否存在应明确说明的未陈述假设？

直接修复计划中的问题；无需重新开启问询。

然后输出验证块。每一行都引用满足检查条件的计划章节，因此无章节可引用的检查意味着未修复就报告，属于失败：

text

计划验证：<路径>
  回应用户请求    <说明预期成果的章节>
  答案已纳入      <n个问询答案中的n个；列出任何遗漏的答案>
  范围关卡通过    <包含削减清单的章节；已核查的原则>
  假设已明确      <章节，或“未发现”>
  验证方案        <复制计划中的验证命令>

轻量计划无验证章节；引用证明方法可行的一项检查即可。

Step 5: Hand off

步骤5：移交

Offer Review: "Plan written to

<path>

. Stress-test it to 5/5 before implementation?"

提议进入审查模式：“计划已写入

<路径>

。是否要对其进行压力测试以达到5/5后再实施？”

Review mode

审查模式

Objective: drive all six dimensions to 5/5. Work each sub-5 dimension upward, re-scoring each round, until all are 5/5 or provably stalled on a decision only the user can make.

text

Review progress:
- [ ] Step 1: Load the plan
- [ ] Step 2: Triage: verify checkable claims, score all six dimensions
- [ ] Step 3: Rubber duck loop: drive each dimension <5 to 5/5 (max 2 pushes per question)
- [ ] Step 4: Re-score after each dimension; repeat the sweep until all 5/5 or stalled
- [ ] Step 5: Gap summary (before/after scores + residual blockers)
- [ ] Step 6: Confirm the plan file contains every resolution and unresolved annotation

目标： 将所有六个维度驱动至5/5。针对每个低于5分的维度进行优化，每轮重新评分，直到所有维度达到5/5或因用户才能做出的决策而停滞。

text

审查进度：
- [ ] 步骤1：加载计划
- [ ] 步骤2：分类：验证可核查的主张，对所有六个维度评分
- [ ] 步骤3：橡皮鸭循环：将每个低于5分的维度提升至5/5（每个问题最多追问2次）
- [ ] 步骤4：每个维度优化后重新评分；重复循环直到所有维度达到5/5或停滞
- [ ] 步骤5：差距总结（评分前后对比 + 剩余阻塞）
- [ ] 步骤6：确认计划文件包含所有解决方案和未解决标注

Step 1: Load the plan

步骤1：加载计划

If the user gives a path, read it. Otherwise list the active agent's native plan directory by modification time, pick the most recent, and confirm. Read the full plan; note its goal, structure, length. If it is a diff or code, stop and route to

pr-reviewer

如果用户提供路径，读取该路径的文件。否则按修改时间列出活跃Agent的本地计划目录，选择最新文件并确认。阅读完整计划；记录其目标、结构、长度。如果是差异或代码，请停止并转至

pr-reviewer

。

Step 2: Triage

步骤2：分类

Load

references/plan-quality-rubric.md

. Silently score each of the six dimensions 1-5. While scoring, mark every claim checkable against local code, docs, or specs; verify the load-bearing ones now (load

references/claim-verification.md

) and fold the verdicts into the scores. Never spend a dialogue turn on what the codebase can answer.

Output a triage table:

PLAN TRIAGE:
  Completeness    ███░░  3/5  Missing error handling, no rollback
  Feasibility     ████░  4/5  One unproven dependency
  Scope           ██░░░  2/5  Premature abstractions
  Testability     █░░░░  1/5  No verification strategy
  Risk            ███░░  3/5  Blast radius unclear
  Assumptions     ██░░░  2/5  Three unstated assumptions

State: "I'll work each dimension up to 5/5, starting with the weakest." If more than 3 dimensions start at 1-2, the plan needs rewriting, not review: switch to Create mode instead of grinding the loop. If Scope stays below 5 because the plan carries more than one shippable outcome, it is two plans and no amount of tightening fixes that: split it with

references/splitting.md

加载

references/plan-quality-rubric.md

。悄悄对六个维度分别打1-5分。评分时标记所有可通过本地代码、文档或规格核查的主张；立即验证其中的核心主张（加载

references/claim-verification.md

）并将结论纳入评分。切勿在对话中询问代码库可回答的问题。

输出分类表格：

计划分类：
  完整性    ███░░  3/5  缺少错误处理，无回滚方案
  可行性    ████░  4/5  存在一个未经验证的依赖
  范围      ██░░░  2/5  存在过早抽象
  可测试性  █░░░░  1/5  无验证策略
  风险      ███░░  3/5  影响范围不明确
  假设      ██░░░  2/5  存在三个未陈述的假设

说明：“我将把每个维度提升至5/5，从得分最低的维度开始。”如果超过3个维度初始得分为1-2分，计划需要重写而非审查：切换至创建模式而非继续循环。如果范围维度得分始终低于5，因为计划包含多个可交付成果，说明这是两个计划，无法通过优化修复：使用

references/splitting.md

进行拆分。

Step 3: Rubber duck loop

步骤3：橡皮鸭循环

Load

references/questioning-framework.md

and

references/dialogue-examples.md

. Each round:

Pick the lowest-scoring dimension still below 5.
Ask ONE question that quotes or names a specific section, claim, or omission. Never bundle two questions.
On the answer, choose exactly one move:

VERIFY: the answer or the plan text it defends is checkable with local evidence. Load
```
references/claim-verification.md
```
, gather evidence, quote the authoritative doc, return VERIFIED / NOT VERIFIED / INCONCLUSIVE, then continue informed. Prefer VERIFY over asking when evidence can settle it.
PUSH DEEPER: the answer hand-waves complexity. Ask a sharper follow-up. Max 2 pushes per question.
ACCEPT AND RECORD: the answer closes the gap. Write the resolution into the plan file immediately, then re-score the dimension.
REFRAME: the concern does not apply as framed. Acknowledge what the user got right, then redirect to the actual gap.

Stay on the same dimension until it reaches 5/5 or stalls, then move to the next-lowest below 5.

Stall rule: after 2 pushes without a 5/5 answer, propose a concrete fix to accept or reject. If accepted, write it in and re-score. If the user defers, record what blocks 5/5 and move on. Don't keep re-asking in different words.

加载

references/questioning-framework.md

和

references/dialogue-examples.md

。每轮循环：

选择仍低于5分的维度中得分最低的一个。
提出一个引用或指明特定章节、主张或遗漏的问题。切勿合并两个问题。
根据答案，选择以下其中一项操作：

验证： 答案或其辩护的计划文本可通过本地证据核查。加载
```
references/claim-verification.md
```
，收集证据，引用权威文档，返回“已验证”/“未验证”/“无法确定”，然后继续。当证据可解决问题时，优先选择验证而非询问。
深入追问： 答案回避了复杂性。提出更明确的跟进问题。每个问题最多追问2次。
接受并记录： 答案填补了差距。立即将解决方案写入计划文件，然后重新评分该维度。
重构框架： 提出的问题框架不适用。认可用户正确的部分，然后转向实际差距。

专注于同一维度直到其达到5/5或停滞，然后转向下一个得分最低的维度。

停滞规则： 经过2次追问仍未得到5/5的答案时，提出具体的修复方案供用户接受或拒绝。如果接受，写入计划并重新评分。如果用户推迟，记录阻碍达到5/5的因素并转向下一个维度。切勿用不同措辞重复提问。

Step 4: Re-score and repeat

步骤4：重新评分并重复

After each dimension closes or stalls, re-render the triage table so the climb is visible. Sweep again over any dimension below 5. The loop ends when all six are 5/5, the user invokes the escape hatch, or a full sweep makes no progress (summarize what blocks 5/5 and stop).

每个维度完成优化或停滞之后，重新渲染分类表格以展示进度。再次检查所有低于5分的维度。循环结束的条件：所有六个维度达到5/5，用户启用逃生舱，或完整循环后无进展（总结阻碍达到5/5的因素并停止）。

Step 5: Gap summary

步骤5：差距总结

Lead with the final triage table (before and after). List residual gaps in three tiers; if every dimension reached 5/5, say so and leave "Must address" empty.

markdown

undefined

首先展示最终分类表格（前后对比）。将剩余差距分为三个层级；如果所有维度都达到5/5，说明这一点并留空“必须解决”部分。

markdown

undefined

Plan Review

计划审查

Must address before implementation

实施前必须解决

[SCOPE]
```
## Data Migration
```
: no incremental path; what if migration fails halfway? Resolved: NO

[范围]
```
## 数据迁移
```
：无增量路径；如果迁移中途失败怎么办？已解决：否

Should address soon

应尽快解决

[ASSUMPTION] Plan assumes API rate limits won't be hit at projected scale Resolved: YES (user confirmed 80/min is within the 100/min limit with headroom)

[假设] 计划假设API速率限制在预计规模下不会被触发已解决：是（用户确认80次/分钟在100次/分钟的限制范围内且有冗余）

Noted for awareness

需注意事项

[RISK] Single dependency on third-party service with no fallback Resolved: NO

undefined

[风险] 单一依赖第三方服务且无 fallback 方案已解决：否

undefined

Step 6: Confirm the plan file

步骤6：确认计划文件

Plan edits happen incrementally during the loop; this final pass confirms the file is the deliverable: every resolution inline where its gap was identified; every stalled dimension carries a

<!-- UNRESOLVED: what blocks 5/5 -->

comment; a Review Notes section appended with before/after triage scores and the date. Do not ask permission to edit; updating the plan is the point. If the plan arrived as pasted text with no file, output the full updated plan in a code block and offer to write it to the active agent's native plan directory or a user-specified path.

计划修改在循环中逐步进行；此最终步骤确认文件为交付成果：所有解决方案内嵌在对应的差距位置；每个停滞维度都带有

<!-- UNRESOLVED: 阻碍达到5/5的因素 -->

注释；附加审查笔记部分，包含评分前后对比和日期。无需询问编辑权限；更新计划是审查的核心目的。如果计划是以粘贴文本形式提供且无对应文件，在代码块中输出完整的更新计划，并提议写入活跃Agent的本地计划目录或用户指定路径。

Review dialogue protocol

审查对话协议

Quote the plan's words when challenging; paraphrase invites "that's not what I meant" detours.
No "great plan, but...": start with the triage table and go straight to gaps. Acknowledge strengths in one clause at most.
Direct but constructive; aim to strengthen, not criticize.
Name scope creep, unearned abstractions, and horizontal-layer plans explicitly. Push for the minimum executable slice that proves the approach end-to-end.

挑战时引用计划原文；转述会引发“我不是这个意思”的偏离。
不要说“计划很好，但……”：直接展示分类表格并聚焦差距。最多用一句话认可优势。
直接但有建设性；目标是强化计划，而非批评。
明确指出范围蔓延、无依据的抽象和横向层级计划。推动采用能端到端验证方法的最小可执行切片。

Gotchas

注意事项

A question the code or docs can answer spends one of the 5-10 budget and returns what Step 1 would have read for free.
Past 10 questions the scope is too big for one plan. Asking an eleventh buys detail on a plan that cannot be executed in one pass; propose a split.
A split that names slices without publishing them leaves the work exactly where it was, in prose. The deliverable is tickets a human approved and an agent can pick up, each declaring its blockers.
Blocking edges declared only in a ticket's prose are invisible to whatever picks the tickets up. Use the tracker's native blocking relation, and only where the dependency is real: a false edge parks a ticket that could have started.
Re-asking a stalled question in different words never produces the 5/5 answer. Propose a concrete fix to accept or reject, or record what blocks 5/5 and move to the next dimension.
A handoff plan with no named implementation-notes file loses every deviation the code forced on the executor, so review afterwards has nothing to read.
A handoff plan that says what trips a STOP but never what an acceptable finish looks like leaves an executor that trips nothing patching indefinitely, with nothing in the notes file recording how the run ended.
A plan that arrived as pasted text has no file to write resolutions into, so the whole Review evaporates when the session ends. Output the full updated plan in a code block and offer a path.

代码或文档可回答的问题会占用5-10个提问预算中的一个，且返回的是步骤1本可免费获取的内容。
超过10个问题说明范围过大无法放入单个计划。第十一个问题只会为无法一次性执行的计划增加细节；应提议拆分。
仅命名切片但未发布任务工单的拆分不会改变工作状态，只是停留在文字层面。交付成果应为经人工批准且Agent可承接的任务工单，每个工单需说明其阻塞因素。
仅在工单文字中声明的阻塞边缘对承接任务的角色不可见。使用跟踪工具的原生阻塞关系，且仅在依赖真实存在时使用：错误的边缘会导致本可启动的工单被搁置。
用不同措辞重复询问停滞的问题永远不会得到5/5的答案。提出具体的修复方案供用户接受或拒绝，或记录阻碍因素并转向下一个维度。
未指定实施笔记文件的移交计划会丢失代码迫使执行者做出的所有偏差，因此后续审查无据可依。
仅说明触发停止条件但未定义可接受完成状态的移交计划，会导致未触发任何停止条件的执行者无限期修改，笔记文件也无法记录任务结束状态。
以粘贴文本形式提供的计划无文件可写入解决方案，因此整个审查内容会在会话结束时消失。在代码块中输出完整的更新计划，并提供写入路径。

planning

Original

Translation

Planning

规划

Mode dispatch

模式调度

Decision principles

决策原则

Reference files

参考文件

Create mode

创建模式

Step 1: Understand intent

步骤1：理解需求意图

Step 2: Interrogate

步骤2：问询

Step 3: Synthesize

步骤3：合成

Step 4: Validate

步骤4：验证

Step 5: Hand off

步骤5：移交

Review mode

审查模式

Step 1: Load the plan

步骤1：加载计划

Step 2: Triage

步骤2：分类

Step 3: Rubber duck loop

步骤3：橡皮鸭循环

Step 4: Re-score and repeat

步骤4：重新评分并重复

Step 5: Gap summary

步骤5：差距总结

Plan Review

计划审查

Must address before implementation

实施前必须解决

Should address soon

应尽快解决

Noted for awareness

需注意事项

Step 6: Confirm the plan file

步骤6：确认计划文件

Review dialogue protocol

审查对话协议

Gotchas

注意事项

Related skills

相关技能