sprint-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Phase 0: Parse Arguments

阶段0：解析参数

Extract the mode argument (

new

update

, or

status

) and resolve the review mode (once, store for all gate spawns this run):

If
```
--review [full|lean|solo]
```
was passed → use that
Else read
```
production/review-mode.txt
```
→ use that value
Else → default to
```
lean
```

See

.claude/docs/director-gates.md

for the full check pattern.

提取mode参数（

new

、

update

或

status

）并确定评审模式（单次生效，或在本次运行中对所有gate实例生效）：

如果传入了
```
--review [full|lean|solo]
```
→ 使用该值
否则读取
```
production/review-mode.txt
```
→ 使用该文件中的值
否则 → 默认使用
```
lean
```

完整的检查规则请参见

.claude/docs/director-gates.md

。

Phase 1: Gather Context

阶段1：收集上下文信息

Read the current milestone from
```
production/milestones/
```
.
Read the previous sprint (if any) from
```
production/sprints/
```
to understand velocity and carryover.
Scan design documents in
```
design/gdd/
```
for features tagged as ready for implementation.
Check the risk register at
```
production/risk-register/
```
.

从
```
production/milestones/
```
读取当前里程碑。
从
```
production/sprints/
```
读取上一个Sprint（如果存在），以了解团队速度和遗留任务。
扫描
```
design/gdd/
```
中的设计文档，找出标记为可实施的功能。
查看
```
production/risk-register/
```
中的风险登记册。

Phase 2: Generate Output

阶段2：生成输出

For

new

Generate a sprint plan following this format and present it to the user. Do NOT ask to write yet — the producer feasibility gate (Phase 4) runs first and may require revisions before the file is written.

markdown

undefined

当模式为

new

时：

生成Sprint计划，遵循以下格式并呈现给用户。请勿直接写入文件——需先运行第4阶段的producer可行性校验门，可能需要修订后再写入文件。

markdown

undefined

Sprint [N] -- [Start Date] to [End Date]

Sprint Goal

[One sentence describing what this sprint achieves toward the milestone]

[一句话描述本Sprint为达成里程碑所实现的目标]

Capacity

Total days: [X]
Buffer (20%): [Y days reserved for unplanned work]
Available: [Z days]

Total days: [X]
Buffer (20%): [Y days reserved for unplanned work]
Available: [Z days]

Tasks

Must Have (Critical Path)

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

Should Have

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

Nice to Have

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

ID	Task	Agent/Owner	Est. Days	Dependencies	Acceptance Criteria

Carryover from Previous Sprint

Task	Reason	New Estimate

Task	Reason	New Estimate

Risks

Risk	Probability	Impact	Mitigation

Risk	Probability	Impact	Mitigation

Dependencies on External Factors

[List any external dependencies]

[列出所有外部依赖项]

Definition of Done for this Sprint

All Must Have tasks completed
All tasks pass acceptance criteria
QA plan exists (
```
production/qa/qa-plan-sprint-[N].md
```
)
All Logic/Integration stories have passing unit/integration tests
Smoke check passed (
```
/smoke-check sprint
```
)
QA sign-off report: APPROVED or APPROVED WITH CONDITIONS (
```
/team-qa sprint
```
)
No S1 or S2 bugs in delivered features
Design documents updated for any deviations
Code reviewed and merged


For `status`:

**Generate a status report**:

```markdown

All Must Have tasks completed
All tasks pass acceptance criteria
QA plan exists (
```
production/qa/qa-plan-sprint-[N].md
```
)
All Logic/Integration stories have passing unit/integration tests
Smoke check passed (
```
/smoke-check sprint
```
)
QA sign-off report: APPROVED or APPROVED WITH CONDITIONS (
```
/team-qa sprint
```
)
No S1 or S2 bugs in delivered features
Design documents updated for any deviations
Code reviewed and merged


当模式为`status`时：

**生成状态报告**：

```markdown

Sprint [N] Status -- [Date]

Progress: [X/Y tasks complete] ([Z%])

Completed

Task	Completed By	Notes

Task	Completed By	Notes

In Progress

Task	Owner	% Done	Blockers

Task	Owner	% Done	Blockers

Not Started

Task	Owner	At Risk?	Notes

Task	Owner	At Risk?	Notes

Blocked

Task	Blocker	Owner of Blocker	ETA

Task	Blocker	Owner of Blocker	ETA

Burndown Assessment

[On track / Behind / Ahead] [If behind: What is being cut or deferred]

Emerging Risks

[Any new risks identified this sprint]

---

[Any new risks identified this sprint]

---

Phase 3: Write Sprint Status File

阶段3：写入Sprint状态文件

After generating a new sprint plan, also write

production/sprint-status.yaml

. This is the machine-readable source of truth for story status — read by

/sprint-status

/story-done

, and

/help

without markdown parsing.

Ask: "May I also write

production/sprint-status.yaml

to track story status?"

Format:

yaml

undefined

生成新的Sprint计划后，还需写入

production/sprint-status.yaml

文件。这是故事状态的机器可读权威来源——

/sprint-status

、

/story-done

和

/help

会读取该文件，无需解析markdown。

询问用户："是否允许我写入

production/sprint-status.yaml

以跟踪故事状态？"

格式如下：

yaml

undefined

Auto-generated by /sprint-plan. Updated by /story-done.

DO NOT edit manually — use /story-done to update story status.

sprint: [N] goal: "[sprint goal]" start: "[YYYY-MM-DD]" end: "[YYYY-MM-DD]" generated: "[YYYY-MM-DD]" updated: "[YYYY-MM-DD]"

stories:

id: "[epic-story, e.g. 1-1]" name: "[story name]" file: "[production/stories/path.md]" priority: must-have # must-have | should-have | nice-to-have status: ready-for-dev # backlog | ready-for-dev | in-progress | review | done | blocked owner: "" estimate_days: 0 blocker: "" completed: ""


Initialize each story from the sprint plan's task tables:
- Must Have tasks → `priority: must-have`, `status: ready-for-dev`
- Should Have tasks → `priority: should-have`, `status: backlog`
- Nice to Have tasks → `priority: nice-to-have`, `status: backlog`

For `update`: read the existing `sprint-status.yaml`, carry over statuses for
stories that haven't changed, add new stories, remove dropped ones.

---

sprint: [N] goal: "[sprint goal]" start: "[YYYY-MM-DD]" end: "[YYYY-MM-DD]" generated: "[YYYY-MM-DD]" updated: "[YYYY-MM-DD]"

stories:

id: "[epic-story, e.g. 1-1]" name: "[story name]" file: "[production/stories/path.md]" priority: must-have # must-have | should-have | nice-to-have status: ready-for-dev # backlog | ready-for-dev | in-progress | review | done | blocked owner: "" estimate_days: 0 blocker: "" completed: ""


从Sprint计划的任务表中初始化每个故事：
- Must Have任务 → `priority: must-have`，`status: ready-for-dev`
- Should Have任务 → `priority: should-have`，`status: backlog`
- Nice to Have任务 → `priority: nice-to-have`，`status: backlog`

当模式为`update`时：读取现有的`sprint-status.yaml`，保留未变更故事的状态，添加新故事，移除已删除的故事。

---

Phase 4: Producer Feasibility Gate

阶段4：Producer可行性校验门

Review mode check — apply before spawning PR-SPRINT:

```
solo
```
→ skip. Note: "PR-SPRINT skipped — Solo mode." Proceed to Phase 5 (QA plan gate).
```
lean
```
→ skip (not a PHASE-GATE). Note: "PR-SPRINT skipped — Lean mode." Proceed to Phase 5 (QA plan gate).
```
full
```
→ spawn as normal.

Before finalising the sprint plan, spawn

producer

via Task using gate PR-SPRINT (

.claude/docs/director-gates.md

Pass: proposed story list (titles, estimates, dependencies), total team capacity in hours/days, any carryover from the previous sprint, milestone constraints and deadline.

Present the producer's assessment. If UNREALISTIC, revise the story selection (defer stories to Should Have or Nice to Have) before asking for write approval. If CONCERNS, surface them and let the user decide whether to adjust.

After handling the producer's verdict, ask: "May I write this sprint plan to

production/sprints/sprint-[N].md

?" If yes, write the file, creating the directory if needed. Verdict: COMPLETE — sprint plan created. If no: Verdict: BLOCKED — user declined write.

After writing, add:

Scope check: If this sprint includes stories added beyond the original epic scope, run
/scope-check [epic]
to detect scope creep before implementation begins.

评审模式检查 —— 在生成PR-SPRINT前执行：

```
solo
```
→ 跳过。备注："PR-SPRINT已跳过——Solo模式。" 直接进入第5阶段（QA计划校验门）。
```
lean
```
→ 跳过（非PHASE-GATE）。备注："PR-SPRINT已跳过——Lean模式。" 直接进入第5阶段（QA计划校验门）。
```
full
```
→ 正常生成。

在最终确定Sprint计划前，通过Task生成

producer

并使用PR-SPRINT校验门（参见

.claude/docs/director-gates.md

）。

传递信息：拟议的故事列表（标题、估算、依赖）、团队总产能（小时/天）、上一个Sprint的遗留任务、里程碑约束和截止日期。

展示producer的评估结果。如果评估为UNREALISTIC（不切实际），则修订故事选择（将故事推迟至Should Have或Nice to Have），然后询问用户是否允许写入。如果评估为CONCERNS（存在顾虑），则将问题告知用户，由用户决定是否调整。

处理完producer的评估结果后，询问用户："是否允许我将此Sprint计划写入

production/sprints/sprint-[N].md

？" 如果同意，则写入文件，必要时创建目录。结果：COMPLETE——Sprint计划已创建。如果拒绝：结果：BLOCKED——用户拒绝写入。

写入完成后，添加以下内容：

范围检查：如果本Sprint包含超出原始史诗范围的故事，请在实施开始前运行
/scope-check [epic]
以检测范围蔓延。

Phase 5: QA Plan Gate

阶段5：QA计划校验门

Before closing the sprint plan, check whether a QA plan exists for this sprint.

Use

Glob

to look for

production/qa/qa-plan-sprint-[N].md

or any file in

production/qa/

referencing this sprint number.

If a QA plan is found: note it in the sprint plan output — "QA Plan:

[path]

" — and proceed.

If no QA plan exists: do not silently proceed. Surface this explicitly:

"This sprint has no QA plan. A sprint plan without a QA plan means test requirements are undefined — developers won't know what 'done' looks like from a QA perspective, and the sprint cannot pass the Production → Polish gate without one.
Run
/qa-plan sprint
now, before starting any implementation. It takes one session and produces the test case requirements each story needs."

Use

AskUserQuestion

Prompt: "No QA plan found for this sprint. How do you want to proceed?"

Options:

[A] Run /qa-plan sprint now — I'll do that before starting implementation (Recommended)

[B] Skip for now — I understand QA sign-off will be blocked at the Production → Polish gate

If [A]: close with "Sprint plan written. Run

/qa-plan sprint

next — then begin implementation." If [B]: add a warning block to the sprint plan document:

markdown

> ⚠️ **No QA Plan**: This sprint was started without a QA plan. Run `/qa-plan sprint`
> before the last story is implemented. The Production → Polish gate requires a QA
> sign-off report, which requires a QA plan.

在完成Sprint计划前，检查本Sprint是否存在QA计划。

使用

Glob

查找

production/qa/qa-plan-sprint-[N].md

或

production/qa/

中任何引用本Sprint编号的文件。

如果找到QA计划：在Sprint计划输出中备注——"QA计划：

[path]

"——然后继续。

如果未找到QA计划：请勿静默继续。需明确告知用户：

"本Sprint没有QA计划。没有QA计划的Sprint计划意味着测试需求未定义——开发人员无法从QA角度了解'完成'的标准，且Sprint无法通过Production → Polish校验门。
请立即运行
/qa-plan sprint
，在开始任何实施前完成。该流程只需一个会话，会生成每个故事所需的测试用例要求。"

使用

AskUserQuestion

：

提示："未找到本Sprint的QA计划。您希望如何处理？"

选项：

[A] 立即运行/qa-plan sprint —— 我会在开始实施前完成（推荐）

[B] 暂时跳过 —— 我了解在Production → Polish校验门处QA签核会被阻止

如果选择[A]：结束时提示"Sprint计划已写入。接下来请运行

/qa-plan sprint

——然后开始实施。" 如果选择[B]：在Sprint计划文档中添加警告块：

markdown

> ⚠️ **无QA计划**：本Sprint在未创建QA计划的情况下启动。请在最后一个故事实施前运行`/qa-plan sprint`。Production → Polish校验门需要QA签核报告，而签核报告依赖于QA计划。

Phase 6: Next Steps

阶段6：后续步骤

After the sprint plan is written and QA plan status is resolved:

```
/qa-plan sprint
```
— required before implementation begins — defines test cases per story so developers implement against QA specs, not a blank slate
```
/story-readiness [story-file]
```
— validate a story is ready before starting it
```
/dev-story [story-file]
```
— begin implementing the first story
```
/sprint-status
```
— check progress mid-sprint
```
/scope-check [epic]
```
— verify no scope creep before implementation begins

Sprint计划写入完成且QA计划状态确定后：

```
/qa-plan sprint
```
—— 实施开始前必须完成——为每个故事定义测试用例，确保开发人员根据QA规范进行开发，而非无据可依
```
/story-readiness [story-file]
```
—— 在开始故事前验证其是否准备就绪
```
/dev-story [story-file]
```
—— 开始实施第一个故事
```
/sprint-status
```
—— 在Sprint中期检查进度
```
/scope-check [epic]
```
—— 在实施开始前验证是否存在范围蔓延