create-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Plan

制定计划

Goal

目标

Turn a user prompt into a single, actionable plan delivered in the final assistant message.
将用户的需求转换为一份单一、可执行的计划,并在最终的助手回复中呈现。

Minimal workflow

最简工作流程

Throughout the entire workflow, operate in read-only mode. Do not write or update files.
  1. Scan context quickly
    • Read
      README.md
      and any obvious docs (
      docs/
      ,
      CONTRIBUTING.md
      ,
      ARCHITECTURE.md
      ).
    • Skim relevant files (the ones most likely touched).
    • Identify constraints (language, frameworks, CI/test commands, deployment shape).
  2. Ask follow-ups only if blocking
    • Ask at most 1–2 questions.
    • Only ask if you cannot responsibly plan without the answer; prefer multiple-choice.
    • If unsure but not blocked, make a reasonable assumption and proceed.
  3. Create a plan using the template below
    • Start with 1 short paragraph describing the intent and approach.
    • Clearly call out what is in scope and what is not in scope in short.
    • Then provide a small checklist of action items (default 6–10 items).
      • Each checklist item should be a concrete action and, when helpful, mention files/commands.
      • Make items atomic and ordered: discovery → changes → tests → rollout.
      • Verb-first: “Add…”, “Refactor…”, “Verify…”, “Ship…”.
    • Include at least one item for tests/validation and one for edge cases/risk when applicable.
    • If there are unknowns, include a tiny Open questions section (max 3).
  4. Do not preface the plan with meta explanations; output only the plan as per template
在整个工作流程中,仅以只读模式操作。请勿写入或更新文件。
  1. 快速扫描上下文
    • 阅读
      README.md
      及任何显眼的文档(
      docs/
      CONTRIBUTING.md
      ARCHITECTURE.md
      )。
    • 略读相关文件(最可能涉及修改的文件)。
    • 识别约束条件(语言、框架、CI/测试命令、部署形式)。
  2. 仅在遇到阻塞时跟进提问
    • 最多提问1-2个问题
    • 仅当没有答案就无法合理制定计划时才提问;优先使用选择题形式。
    • 若不确定但未被阻塞,做出合理假设后继续推进。
  3. 使用以下模板创建计划
    • 开头用1段简短文字描述意图和方法。
    • 简要明确标注包含范围排除范围
    • 然后提供一份小型行动清单(默认6-10项)。
      • 每个清单项应为具体行动,必要时提及文件/命令。
      • 确保项具备原子性且有序:探索→修改→测试→发布。
      • 以动词开头:“添加…”, “重构…”, “验证…”, “发布…”。
    • 适用时,至少包含一项测试/验证和一项边缘情况/风险相关的条目。
    • 若存在未知事项,添加一个小型的待解决问题部分(最多3个)。
  4. 不要在计划前添加元解释;仅按模板输出计划

Plan template (follow exactly)

计划模板(严格遵循)

markdown
undefined
markdown
undefined

Plan

Plan

<1–3 sentences: what we’re doing, why, and the high-level approach.>
<1–3 sentences: what we’re doing, why, and the high-level approach.>

Scope

Scope

  • In:
  • Out:
  • In:
  • Out:

Action items

Action items

[ ] <Step 1> [ ] <Step 2> [ ] <Step 3> [ ] <Step 4> [ ] <Step 5> [ ] <Step 6>
[ ] <Step 1> [ ] <Step 2> [ ] <Step 3> [ ] <Step 4> [ ] <Step 5> [ ] <Step 6>

Open questions

Open questions

  • <Question 1>
  • <Question 2>
  • <Question 3>
undefined
  • <Question 1>
  • <Question 2>
  • <Question 3>
undefined

Checklist item guidance

清单项指导

Good checklist items:
  • Point to likely files/modules: src/..., app/..., services/...
  • Name concrete validation: “Run npm test”, “Add unit tests for X”
  • Include safe rollout when relevant: feature flag, migration plan, rollback note
Avoid:
  • Vague steps (“handle backend”, “do auth”)
  • Too many micro-steps
  • Writing code snippets (keep the plan implementation-agnostic)
优质的清单项:
  • 指向可能的文件/模块:src/..., app/..., services/...
  • 明确验证方式:“运行npm test”、“为X添加单元测试”
  • 相关时包含安全发布策略:功能标志、迁移计划、回滚说明
需避免:
  • 模糊步骤(“处理后端”、“做认证”)
  • 过多微步骤
  • 编写代码片段(保持计划与实现无关)