planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Planning

规划

You create detailed implementation plans through an interactive, iterative process. Be skeptical, thorough, collaborative.

你将通过交互式的迭代流程创建详细的实施方案。保持严谨、全面、协作的态度。

Setup (before starting)

准备工作（开始前）

Autonomy Mode — passed by the invoking command; default to Critical if unspecified.

Mode	Behavior
Autopilot	Research independently, write the full plan, present for final review only
Critical (Default)	After each research step, ask clarifying questions before drafting; surface design options at decision points
Verbose	Check in at every sub-step: validate understanding, confirm scope, surface unknowns, confirm before each phase

Commit preference — unless Autopilot, ask once via
```
AskUserQuestion
```
:
Question Options
"Create a commit after each phase once manual verification passes?" 1. Yes (Recommended), 2. No, I'll handle commits
Prior learnings — OPTIONAL SUB-SKILL: if
```
~/.agentic-learnings.json
```
exists, run
```
/learning recall <topic>
```
first.

Question	Options
"Create a commit after each phase once manual verification passes?"	1. Yes (Recommended), 2. No, I'll handle commits

Autonomy Mode — 由调用命令传入；若未指定，默认使用 Critical 模式。

模式	行为
Autopilot	自主完成调研，撰写完整方案，仅提交最终审核
Critical（默认）	每完成一步调研后，先提出澄清问题再起草方案；在决策节点呈现设计选项
Verbose	在每个子步骤都进行确认：验证理解、确认范围、指出未知项、在每个阶段开始前确认

提交偏好 — 除非使用Autopilot模式，否则通过
```
AskUserQuestion
```
询问一次：
问题选项
"人工验证通过后，是否在每个阶段完成后创建提交？" 1. 是（推荐），2. 否，我将自行处理提交
过往经验 — 可选子技能：若
```
~/.agentic-learnings.json
```
文件存在，先运行
```
/learning recall <topic>
```
。

问题	选项
"人工验证通过后，是否在每个阶段完成后创建提交？"	1. 是（推荐），2. 否，我将自行处理提交

The 10 Rules

十大规则

Scaffold first — before any research, exit plan mode and create
```
thoughts/<username|shared>/plans/YYYY-MM-DD-description.md
```
from
```
cc-plugin/base/skills/planning/template.md
```
. (Use the user's name when known, e.g.
```
taras
```
; fall back to
```
thoughts/shared/
```
otherwise.) The file grows incrementally; the user can correct course early.
Sub-agent everything heavy — file reads, research, validation. Default to
```
run_in_background: true
```
. Keep raw tool output out of the main session. Sub-agent menu:
```
codebase-locator
```
(find files),
```
codebase-analyzer
```
(understand current implementation),
```
codebase-pattern-finder
```
(find similar features),
```
context7
```
MCP (library/framework specifics),
```
Explore
```
or
```
general-purpose
```
(read mentioned files).
Ask via
AskUserQuestion
— see
```
desplega:ask-user
```
for conventions. Never ask in chat as plain bullets.
Ask after each step (Critical/Verbose), then loop — work the plan section by section: Current State Analysis → Implementation Approach → Phase Outline → Phase Details. For each section: spawn sub-agents → synthesize findings (with
```
file:line
```
refs) → ask gaps via
```
AskUserQuestion
```
→ draft → next section. Assumed inputs are the #1 source of bad plans.
Concrete deliverable per phase — every phase Overview names what file/feature/output exists when it's done. "Improve X", "refactor Y" are smells.
Proof of work: maximize Automated Verification + Automated QA — push everything into runnable commands (low-level) and agent-driven QA (browser-use, screenshot diff, CLI walkthrough). Manual Verification is the exception. A separate
```
### QA Spec (optional):
```
linking to a
```
desplega:qa
```
doc is reserved for cross-cutting or evidence-heavy QA — not for routine per-phase checks.
Propose splitting — when a phase has >4 sub-steps or >2 distinct concerns, split it. When the plan won't fit one implementation session, split it into multiple smaller plans (e.g., contract → storage → UI).
Push back with radical candor — use
```
radical-candor:feedback
```
when the plan is too big, vague, mixes concerns, or has obvious risks. Silence is Ruinous Empathy.
Validate structure with a Haiku sub-agent before showing the plan (
```
general-purpose
```
with
```
model: haiku
```
). Verify: every phase has all three Success Criteria subsections, all items use
```
- [ ]
```
, automated checks are runnable commands, referenced paths exist. Apply fixes before reveal.
Hand off to a fresh session — never implement here. Close-out sequence:
1. Open
```
/file-review:file-review <plan-path>
```
  (unless Autopilot); iterate on comments.
2. Optionally invoke
```
desplega:reviewing
```
  for gap analysis (offer via
```
AskUserQuestion
```
  ).
3. OPTIONAL SUB-SKILL: if significant insights emerged, capture via
```
/learning capture
```
  .
4. If any phase has a
  ### QA Spec (optional):
  block, generate the QA doc via
```
desplega:qa
```
  before handoff (
```
thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md
```
  ). Scenarios live in the doc, not the plan.
5. Ask the user via
```
AskUserQuestion
```
  :
  Question Options
  "Plan ready. What's next?" 1. Implement in a fresh session, 2. Run
  /review
  first, 3. Done for now (park the plan)
6. Tell them explicitly: "Open a new Claude Code session and run
```
/desplega:implement-plan <path>
```
  . Starting fresh keeps the implementation context clean."

Question	Options
"Plan ready. What's next?"	1. Implement in a fresh session, 2. Run `/review` first, 3. Done for now (park the plan)

先搭建框架 — 在任何调研之前，退出规划模式，从
```
cc-plugin/base/skills/planning/template.md
```
创建
```
thoughts/<username|shared>/plans/YYYY-MM-DD-description.md
```
文件。（已知用户名时使用用户名，例如
```
taras
```
；否则默认使用
```
thoughts/shared/
```
）。文件会逐步完善；用户可以尽早调整方向。
繁重工作全交子代理 — 文件读取、调研、验证等工作全部交给子代理。默认设置
```
run_in_background: true
```
。将原始工具输出排除在主会话之外。 子代理菜单：
```
codebase-locator
```
（查找文件）、
```
codebase-analyzer
```
（理解当前实现）、
```
codebase-pattern-finder
```
（查找类似功能）、
```
context7
```
MCP（库/框架细节）、
```
Explore
```
或
```
general-purpose
```
（读取指定文件）。
通过
AskUserQuestion
提问 — 遵循
```
desplega:ask-user
```
的约定。切勿在聊天中以普通项目符号形式提问。
每一步后提问（严格/详尽模式），然后循环 — 分部分推进方案：当前状态分析 → 实施方法 → 阶段大纲 → 阶段细节。对于每个部分：启动子代理 → 整合调研结果（附带
```
file:line
```
引用）→ 通过
```
AskUserQuestion
```
询问信息缺口 → 起草方案 → 进入下一部分。假设的输入是导致方案质量不佳的首要原因。
每个阶段的具体交付物 — 每个阶段概述中需明确完成后将存在的文件/功能/输出。“改进X”、“重构Y”这类表述是不合格的。
工作验证：最大化自动化验证与自动化QA — 将所有内容转化为可运行的命令（底层）和代理驱动的QA（浏览器使用、截图对比、CLI演练）。人工验证仅作为例外情况。单独的
```
### QA Spec (optional):
```
部分用于链接到
```
desplega:qa
```
文档，仅适用于跨领域或需要大量证据的QA——不适用于常规的阶段内检查。
建议拆分 — 当一个阶段包含超过4个子步骤或2个不同关注点时，进行拆分。当方案无法在一个实施会话内完成时，将其拆分为多个更小的方案（例如，契约 → 存储 → UI）。
坦诚提出反对意见 — 当方案规模过大、模糊不清、混合多个关注点或存在明显风险时，使用
```
radical-candor:feedback
```
。沉默是有害的共情。
展示方案前用Haiku子代理验证结构（使用
```
general-purpose
```
并设置
```
model: haiku
```
）。验证：每个阶段都包含所有三个成功标准子部分，所有项使用
```
- [ ]
```
格式，自动化检查为可运行命令，引用路径存在。在展示前应用修复。
移交至新会话——切勿在此处实施。收尾流程：
1. 打开
```
/file-review:file-review <plan-path>
```
  （Autopilot模式除外）；根据评论迭代优化。
2. 可选：调用
```
desplega:reviewing
```
  进行缺口分析（通过
```
AskUserQuestion
```
  提供选项）。
3. 可选子技能：若产生重要见解，通过
```
/learning capture
```
  记录。
4. 若任何阶段包含
  ### QA Spec (optional):
  块，在移交前通过
```
desplega:qa
```
  生成QA文档（路径为
```
thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md
```
  ）。场景信息存放在文档中，而非方案内。
5. 通过
```
AskUserQuestion
```
  询问用户：
  问题选项
  "方案已准备就绪。下一步如何操作？" 1. 在新会话中实施，2. 先运行
  /review
  ，3. 暂时结束（搁置方案）
6. 明确告知用户：“打开新的Claude Code会话并运行
```
/desplega:implement-plan <path>
```
  。重新开始可保持实施环境的纯净。”

问题	选项
"方案已准备就绪。下一步如何操作？"	1. 在新会话中实施，2. 先运行 `/review` ，3. 暂时结束（搁置方案）

Commit Integration

提交集成

If commit-per-phase was enabled in Setup:

After each phase's manual verification passes, commit with format
```
[phase N] <brief description>
```
.
Only commit after explicit confirmation that manual verification passed.
Otherwise, skip — the user handles commits.

若在准备工作中启用了按阶段提交：

每个阶段的人工验证通过后，以
```
[phase N] <简要描述>
```
的格式提交。
仅在明确确认人工验证通过后提交。
否则跳过——由用户自行处理提交。

Success Criteria Format (MANDATORY)

成功标准格式（强制要求）

Canonical format and heading hierarchy lives in

cc-plugin/base/skills/planning/template.md

. Structure validation runs automatically (rule 9, Haiku sub-agent).

标准格式和标题层级定义在

cc-plugin/base/skills/planning/template.md

中。结构验证会自动运行（规则9，Haiku子代理）。