Back to Details

plan-create

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Development Plan

创建开发计划

$ARGUMENTS
is the topic of the plan. If it is empty or not clear, ask the user what the plan is for before you start.
The plan lives on the repo's issue tracker. Read 
docs/agents/issue-tracker.md
for where that is and what the files look like — one 
spec.md
for the whole effort, and one file per ticket under 
issues/
. Both templates live there; do not invent your own.
Do not change any code while you make a plan.
The seams and the cut — how the work splits into tickets — are yours to pick. Pick them by the rules in steps 2 and 3, and keep going.
$ARGUMENTS
是计划的主题。如果为空或不清晰，请在开始前询问用户该计划是为了什么。
计划存放在仓库的 issue tracker 中。阅读 
docs/agents/issue-tracker.md
，了解其位置和文件形式——整个工作使用一个 
spec.md
，
issues/
下每个 ticket 都有一个对应文件。两个模板都在那里；不要自行创建模板。
制定计划时不要修改任何代码。
seams 和 cut——工作如何拆分成 tickets——由你决定。根据步骤 2 和步骤 3 的规则进行选择，然后继续推进。

Run Flow

执行流程

1. Grill the ask

1. 追问需求

Never write a plan straight from a one-line ask. Call the 
grilling
and 
domain-modeling
skills together and interview the user until you both hold the same understanding. If those skills are not installed here, run the interview yourself: one question at a time, look up every fact in the code, and put only real decisions to the user.
  • When a term is settled, put it into 
    CONTEXT.md
    right away
  • When a decision is hard to undo, would puzzle a later reader, and came from a real trade-off, record it as an ADR under 
    docs/adr/
  • CONTEXT.md
    holds words only. How-to-build detail belongs in the ticket, not there
Done when: nothing is left open. Every "option A/B", "suggest XXX", or "may think about" is settled here, not carried into a file. A plan is made to run, not to talk about.
绝不要仅凭一句话需求就直接编写计划。同时调用 
grilling
和 
domain-modeling
skills，访谈用户，直到双方形成相同的理解。如果此处没有安装这些 skills，则自行执行访谈：每次只问一个问题，在代码中查证每一个事实，只把真正的决策事项交给用户。
  • 当一个术语确定后，立即将其写入 
    CONTEXT.md
  • 当某项决策难以撤销、可能会让后续读者困惑，并且源于真实的权衡时，将其记录为 
    docs/adr/
    下的 ADR
  • CONTEXT.md
    只记录术语。如何实现的细节应放在 ticket 中，而不是放在这里
完成标准：没有任何悬而未决项。每个“option A/B”“suggest XXX”或“may think about”都应在此确定，而不是被带入文件。计划是用来执行的，不是用来讨论的。

2. Pick the seams, then write the spec

2. 选择 seams，然后编写 spec

A seam is the place the feature gets tested. Prefer a seam that already exists to a new one, take the highest seam you can, and use as few as possible — the ideal number is one. When you need a new seam, place it at the highest point that works.
Then write 
spec.md
with the words settled in 
CONTEXT.md
, so the spec and the glossary use the same names for the same things.
Done when: 
spec.md
carries all four parts, its seams meet the rules above, and no file path appears anywhere in it.
seam 是功能接受测试的位置。优先使用已经存在的 seam，而不是新建；选择最高层级的 seam，并尽可能少地使用——理想数量是一个。需要新建 seam 时，应将其放在可行的最高层级。
然后使用 
CONTEXT.md
中已确定的术语编写 
spec.md
，确保 spec 和术语表对同一事物使用相同的名称。
完成标准：
spec.md
包含全部四个部分，其 seams 符合上述规则，并且其中任何位置都不出现文件路径。

3. Slice the work into tickets

3. 将工作拆分成 tickets

Cut the spec into tracer bullets — thin slices that each prove the whole path works.
  • Each slice cuts a narrow but complete path through every layer — schema, API, UI, tests. Vertical, never a horizontal slice of one layer
  • A finished slice is demoable or verifiable on its own
  • Each slice fits in one fresh context window
  • Prefactoring goes first — make the change easy, then make the easy change
Give each ticket its blocking edges: the tickets that must finish before it can start. A ticket with no blockers can start immediately.
One mechanical change whose blast radius fans across the whole codebase is a wide refactor, and no vertical slice can land green on it. Sequence those as expand–contract instead — see WIDE-REFACTOR.md.
Done when: you have checked the cut yourself — each ticket the right size, each one waiting for exactly the tickets it needs, nothing left to merge or split — and every ticket is written to 
issues/NN-<slug>.md
in dependency order, blockers first, each carrying its What to build and its check items.
将 spec 拆成 tracer bullets——每个切片都很薄，并能证明整条路径可以正常工作。
  • 每个切片都要贯穿每一层——schema、API、UI、测试——形成狭窄但完整的路径。必须是纵向切片，绝不能是只覆盖某一层的横向切片
  • 完成后的切片可以独立演示或验证
  • 每个切片都能在一个全新的 context window 中完成
  • Prefactoring 排在最前面——先让改动变得容易，再进行容易的改动
为每个 ticket 标明其 blocking edges：必须先完成才能启动的 tickets。没有 blockers 的 ticket 可以立即开始。
如果一项机械性改动的 blast radius 扩散到整个代码库，它就属于 wide refactor，任何纵向切片都无法单独完成并保持 green。将这类工作按 expand–contract 的顺序安排——参见 WIDE-REFACTOR.md。
完成标准：自行检查此次拆分——每个 ticket 的大小都合适，每个 ticket 恰好只等待其所需的 tickets，没有内容仍需合并或拆分——并按照依赖顺序将每个 ticket 写入 
issues/NN-<slug>.md
，先写 blockers，每个 ticket 都包含 What to build 和 check items。

4. Fill in how each ticket gets built

4. 完善每个 ticket 的实现方式

Call the 
solid-check
skill on the classes or namespaces the tickets will touch, and let its report shape them.
  • If a class is not in the code yet, pass the closest parent namespace or folder
  • If the tickets touch scopes that are far apart, call it once for each scope
  • A break must be settled inside the ticket, not in the code
Then fill in each ticket's Files touched and Run steps, and sharpen its check items until each one names something you can actually run.
  • Where it fits, use PHP Attribute and Laravel Attribute in place of the old way
  • Write the run steps in prose. A code block in a ticket is a finding
Done when: every ticket carries all four parts, and every check item names the test or command that will confirm it.
对 tickets 将涉及的 classes 或 namespaces 调用 
solid-check
skill，并让其报告指导相关设计。
  • 如果某个 class 尚未存在于代码中，则传入最接近的父 namespace 或目录
  • 如果 tickets 涉及相距较远的 scopes，则对每个 scope 分别调用一次
  • 任何问题点（break）都必须在 ticket 内解决，而不能留到代码中
然后填写每个 ticket 的 Files touched 和 Run steps，并完善其 check items，直到每一项都明确写出实际可以运行的测试或命令。
  • 在适用的情况下，使用 PHP Attribute 和 Laravel Attribute 替代旧有实现方式
  • 使用文字步骤描述运行方式。ticket 中出现代码块本身就属于一个 finding
完成标准：每个 ticket 都包含全部四个部分，并且每个 check item 都明确指定用于确认结果的测试或命令。

5. Check the plan you just wrote

5. 检查刚写好的计划

Call the 
plan-check
skill on the folder you just made, and settle what it finds before you hand the plan to the user. Fix a finding on the seams or the cut yourself, by the rules of steps 2 and 3.
对刚创建的目录调用 
plan-check
skill，在将计划交给用户之前解决它发现的问题。如果 finding 涉及 seams 或 cut，则根据步骤 2 和步骤 3 的规则自行修复。