sprint-plan

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,story_granularity,workflow

已在上方解析——直接使用；--review 会覆盖 review_mode。未配置区块 → 默认值见 .claude/docs/config-resolution.md。

冲刺计划

现有冲刺

!ls production/sprints/ 2>/dev/null || echo "(no production/sprints/ directory yet)"

已在此技能运行前解析——在第 1 阶段用它识别上一个冲刺，而不是重新执行 glob。

---

阶段 0：解析参数

提取模式参数（new、update 或 status）。

完整检查模式见 .claude/docs/director-gates.md。各个 gate 定义位于 .claude/docs/director-gates/[gate-id].md——被启动的 Agent 会读取自己的 gate 文件；不要在父会话中读取。

每次 AskUserQuestion 调用都遵循 .claude/docs/automation-modes.md （collaborative 始终提问 · guided 仅重大事项提问 · autonomous 记录后继续； automation_always_ask 类别始终提问）。

story_granularity——它决定每个冲刺要分配多少个故事，并按速度缩放：coarse 时为 2–4（默认值，通过 rigor: minimal 设置），balanced 时为 6–10（rigor: standard），fine 时为 15–25。Ready 积压项少于此范围时，就按整体规划——绝不填入虚构故事。

审查模式检查（运行 gate 前）：

• 使用上方已解析区块中的审查模式（本次运行可由 --review 覆盖）——不要重新解析，也不要询问。若未配置，则遵循 modes.rigor：minimal 对应 solo，standard 对应 lean。
• 绝不要写入审查模式——既不要写入 project.yaml，也不要写入 production/review-mode.txt。modes.review_mode 是 modes.rigor 控制的一项设置：在 project.yaml 中固定该值会遮蔽 rigor 的展开结果，而旧版文件的优先级又高于该展开结果，因此任何一种写入都会永久固定 director 审查深度。临时调整可使用 --review。如果用户想持久更改深度，请引导他们修改 modes.rigor（/settings modes.rigor=<minimal|standard|full>），或有意将其固定为 /settings --local modes.review_mode=<full|lean|solo>（在 project.local.yaml 中进行个人覆盖）。

---

阶段 1：收集上下文

1. 读取当前里程碑（如果存在），路径为 production/milestones/。 没有任何技能会写入此目录——它由人工根据 .claude/docs/templates/milestone-definition.md 编写。大多数项目都没有 此目录，这是正常情况，并非遗漏：注明“未定义里程碑——仅根据故事 待办列表制定计划”，然后继续。绝不要因此阻止冲刺规划，也不要从冲刺文件 推断里程碑。

2. 读取上一冲刺（如果有），路径为 production/sprints/，以了解速度和 延续事项。在 new 模式下：

   • 新冲刺的编号 [N] 为 Existing Sprints 列表中最高的 sprint-NNN.md 编号加一（如果没有，则为 001）。它就是计划标题、QA 计划路径和写入请求中的 [N]。
   • 上一冲刺中所有状态不是 Complete 的故事——状态以 production/sprint-status.yaml 为准，否则使用故事文件中的 Status 行—— 都要列入 Carryover 表，并注明 Reason 和 New Estimate。它们只能出现在该表中， 不得再作为新的 Must Have / Should Have / Nice to Have 工作出现。

3. 查找要规划的故事——这是实际的待办列表，也是本阶段不可缺少的唯一输入：

   Glob production/epics/**/story-*.md
   Grep pattern="^> \*\*Status\*\*" glob="production/epics/**/story-*.md" output_mode="content"
   

   故事位于 production/epics/[epic-slug]/story-NNN-[slug].md—— /create-stories 会在此处写入故事，/dev-story 也会在此处查找故事。根据标记为 Ready 的故事进行规划。使用 grep，而不是逐个读取故事：此阶段需要的是状态和标题， 而不是正文。

   如果 glob 没有返回任何结果：“在 production/epics/ 下未找到故事。请先运行 /create-stories（在 standard/full 下，需先运行 /create-epics）。” 不要继续虚构工作项——引用不存在故事的冲刺计划无法实施。结论：阻塞——没有可规划的故事。

4. 扫描设计文档，从 design/gdd/ 中查找这些故事所实现功能的更多上下文。按章节 阅读文档：使用 Grep 工具（模式 ^#，内容模式）查找所需标题，再通过 offset 和 limit 读取相应范围。在 workflow: minimal 下没有按系统划分的 GDD——请改用 design/game-brief.md，不要将缺少的 GDD 视为待补工作。（注意：在 minimal 下， /sprint-plan 是可选的——简报中的 Build order 本身就是计划。）

5. 检查风险登记表，路径为 production/risk-register/（如果存在）。 与上面的里程碑一样，没有任何技能会写入此目录——条目由人工根据 .claude/docs/templates/risk-register-entry.md 编写。如果目录不存在，请说明一次 （“无风险登记表——仅根据冲刺内容评估风险”），不要默默跳过风险评估。

---

阶段 2：生成输出

对于 new：

生成冲刺计划，遵循以下格式并提交给用户。此时不要询问是否写入——需先运行门禁阶段， 且在写入文件之前可能需要修改：制作人可行性门禁（阶段 4，仅在 full 审查模式下启动； 在 lean/solo 下跳过）以及 QA 计划检查（阶段 5，适用于所有模式）。

# Sprint [N] — [Start Date] to [End Date]

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

## Goal Prerequisites
| Needed to show the goal | Status |
|-------------------------|--------|

## Capacity
- 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 |
|----|------|-------------|-----------|-------------|-------------------|

### Should Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

### Nice to Have
| ID | Task | Agent/Owner | Est. Days | Dependencies | Acceptance Criteria |
|----|------|-------------|-----------|-------------|-------------------|

## Carryover from Previous Sprint
| Task | Reason | New Estimate |
|------|--------|-------------|

## Risks
| 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-slug]-[date].md`, from `/qa-plan sprint`)
- [ ] 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

检查目标的前置条件

在展示 new 计划之前，检查能否在冲刺结束前展示目标的实际效果。目标可能需要没有任何故事会构建的内容：试玩测试需要一个可运行的场景。此检查只报告问题，不会阻止计划。它不会添加问题，也不会添加自己的故事。

1. 确定目标。 如果里程碑有目标，就引用该目标；否则，根据选定的故事写一句话。
2. 列出展示目标所需的内容。 玩家可以看到或体验的目标（可玩循环、端到端运行的功能、试玩测试）需要其运行所在的场景或关卡，以及启动该场景或关卡的设置：project.godot 中的 run/main_scene、Unity 的 ProjectSettings/EditorBuildSettings.asset 中的场景列表，或 Unreal 的 Config/DefaultEngine.ini 中的 GameDefaultMap。添加选定故事的验收标准、备注或依赖项中提到，但没有任何选定故事会创建的文件、场景或系统。无需运行或展示任何内容的目标（仅逻辑和测试）则不需要任何前置条件。
3. 逐项检查。 如果某项已存在于项目中，或由选定的故事构建，则视为已满足。根据引擎的场景文件查找场景（project.yaml 中的 engine.name）：Godot 使用 *.tscn，Unity 使用 Assets/**/*.unity，Unreal 使用 Content/**/*.umap。其他内容则按故事中使用的路径或名称查找。如果未设置引擎，只按名称检查，并说明未搜索场景。
4. 填写 Goal Prerequisites 部分：对每项需求标注 exists、built by [story ID] 或 missing，或者仅填写一行“None: the goal has nothing to run or show”。将每项缺失内容复制到 Risks 中。展示计划时，列出每项缺失内容，以及用户可选择的三种解决方式：纳入构建该内容的 Ready 故事（说出故事名称，并说明这样做是否会使冲刺超出其 story_granularity 范围，或是否需要先完成其依赖的故事）；先用 /create-stories 为其编写故事；或重写目标，只承诺冲刺能够展示的内容。将这些选项作为计划的一部分提供，而不是提问：唯一的问题仍是写入请求，想要解决缺失项的用户可以在回复该请求时提出。报告缺口；不要解决缺口。 无论缺失的前置条件看起来多么简单（例如平坦的测试关卡、输入映射），在此计划中都必须保持缺失状态：不要为其规划任务，也不要把相关工作纳入选定的故事，即使只是作为准备工作也不行。该内容必须先有一个故事，这是 /create-stories 的职责。绝不能添加待办列表中没有的故事，也绝不能扩大选定故事的范围或编辑故事文件来填补缺口。

对于 update：

更新现有冲刺计划：

1. 从 production/sprints/ 中读取最新的冲刺计划。
2. 展示当前故事列表及其在 production/sprint-status.yaml 中的当前状态。
3. 询问用户要做哪些更改：添加、移除、重新排序或重新估算哪些故事。使用 AskUserQuestion 收集更改。
4. 应用更改，并重新展示完整修订计划以供审核。如果目标或 Must Have 故事有变，先重新检查目标的前置条件。
5. 在修订后的计划上重新运行生产者可行性检查（Phase 4）。
6. 写入更新后的 Markdown 计划和 YAML 文件（与 new 模式一样，需获得同一批准）。

注意：update 模式不会重置故事状态。已标记为 in-progress 或 done 的故事会保留其状态。只有 backlog 和 ready-for-dev 状态的故事可以自由移除或重新排序。

对于 status：

生成状态报告：

# Sprint [N] Status -- [Date]

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

### Completed
| Task | Completed By | Notes |
|------|-------------|-------|

### In Progress
| Task | Owner | % Done | Blockers |
|------|-------|--------|----------|

### Not Started
| Task | Owner | At Risk? | Notes |
|------|-------|----------|-------|

### Blocked
| 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]

---

阶段 3：准备冲刺状态文件

生成新的冲刺计划后，同时准备 production/sprint-status.yaml 的内容。 这是故事状态的机器可读事实来源，由 /sprint-status、/story-done 和 /help 读取，无需解析 Markdown。

暂时不要写入 yaml——先将其保留在上下文中。制作人可行性关卡（阶段 4，仅限 full 审查模式）可能会修改故事列表；QA 计划检查（阶段 5）在所有模式下都会运行。两个文件将在阶段 5 后通过一次写入审批一并写入。

格式：

# Auto-generated by /sprint-plan. Updated by /story-done and /dev-story.
# DO NOT edit manually — use /story-done to update story status.
#
# Status value mapping (yaml ↔ story file Status field):
#   backlog        ↔  Not Started
#   ready-for-dev  ↔  Ready
#   in-progress    ↔  In Progress
#   review         ↔  In Review
#   done           ↔  Complete
#   blocked        ↔  Blocked

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/epics/[epic-slug]/story-NNN-[slug].md]"   # the real path, verbatim from the Glob above
    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: ""

根据冲刺计划中的任务表初始化每个故事：

• 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
• 延续项 → 故事先前的 priority，以及其当前的 status

对于 update：读取现有的 sprint-status.yaml，保留未变更故事的状态，添加新故事，移除已删除的故事。

---

阶段 4：制作人可行性关卡

审查模式检查——在启动 PR-SPRINT 前应用：

• solo → 跳过。备注：“已跳过 PR-SPRINT——Solo 模式。”继续阶段 5（QA 计划关卡）。
• lean → 跳过（不是 PHASE-GATE）。备注：“已跳过 PR-SPRINT——Lean 模式。”继续阶段 5（QA 计划关卡）。
• full → 正常启动。

在最终确定冲刺计划前，通过 Agent 启动 producer，使用关卡 PR-SPRINT（.claude/docs/director-gates/pr-sprint.md）。

提供：拟定的故事列表（标题、估算、依赖关系）、团队总产能（小时／天）、上一冲刺的任何延续项、里程碑限制和截止日期，以及任何缺失的目标前提条件。

展示制作人的评估。

如果评估为 UNREALISTIC：修改故事选择（将故事推迟到 Should Have 或 Nice to Have），重新展示更新后的计划，然后继续阶段 5。

如果评估为 NOT ASSESSED：指出缺失的输入——该计划并非 REALISTIC。补充该输入并重新运行 PR-SPRINT，或者在计划的标题（.claude/docs/director-gates.md）中记录 NOT ASSESSED — [missing input]，然后继续阶段 5，并在请求写入时再次说明。

如果评估为 CONCERNS，使用 AskUserQuestion：

• 提示：“制作人指出此冲刺计划存在顾虑。你想如何继续？”
• 选项：
  • [A] 按计划进行——我接受风险
  • [B] 调整范围——推迟部分 Should Have 故事
  • [C] 延长冲刺时间线

如果选择 [A]：继续阶段 5。 如果选择 [B]：修改故事列表，重新展示更新后的计划，然后继续阶段 5。 如果选择 [C]：调整冲刺日期和产能，重新展示更新后的计划，然后继续阶段 5。

处理完制作人的评估后，继续阶段 5。写入将在阶段 5 结束时进行，因此你审批的文件已包含阶段 5 添加的所有内容。

---

阶段 5：QA 计划关卡

关闭冲刺计划前，检查本次冲刺是否已有 QA 计划。

使用 Glob 搜索 production/qa/qa-plan-*.md——/qa-plan 会写入 qa-plan-[sprint-slug]-[date].md——并保留文件名或内容中提及本次冲刺编号的文件。

如果找到 QA 计划：在冲刺计划输出中注明——“QA 计划：[path]”——然后继续。

如果没有 QA 计划：不要默默继续。明确说明：

“本次冲刺没有 QA 计划。没有 QA 计划的冲刺计划意味着测试要求尚未定义——开发人员不知道从 QA 角度来看什么才算‘完成’，而且没有 QA 计划，冲刺就无法通过 Production → Polish 关卡。

现在运行 /qa-plan sprint，然后再开始任何实现工作。只需一个会话，即可生成每个故事所需的测试用例要求。”

使用 AskUserQuestion：

• 提示：“未找到本次冲刺的 QA 计划。你希望如何继续？”
• 选项：
  • [A] 现在运行 /qa-plan sprint——我会在开始实现前完成此操作（推荐）
  • [B] 暂时跳过——我知道没有 QA 签字批准就无法通过 Production → Polish 关卡

在下方的写入询问之前等待用户回答——这是两个独立的问题。 此处的回答绝不代表批准写入，即使回答“是，可以继续”或“计划写好后也可以”也不例外： 接下来询问是否写入，只有得到肯定答复后才能写入。

如果选择 [A]：在计划中注明“QA 计划：在开始实现前运行 /qa-plan sprint。” 如果选择 [B]：在冲刺计划文档中添加警告块：

> ⚠️ **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.

写入计划

询问：“我可以将冲刺计划写入 production/sprints/sprint-NNN.md（[N] 补零至三位数）以及 production/sprint-status.yaml 吗？”即使之前的回答听起来像是肯定答复，也要询问。如果答复为是，则写入这两个文件（按需创建目录）。判定结果：完成 — 已创建冲刺计划和状态文件。如果答复为否： 判定结果：受阻 — 用户拒绝写入。

写入后，添加：

**范围检查：**如果本次冲刺包含超出原始 Epic 范围的故事，请在开始实现前运行 /scope-check [epic]，以检测范围蔓延。

如果用户在阶段 5 选择了“现在运行 /qa-plan sprint”，则以“冲刺计划已写入。接下来运行 /qa-plan sprint，然后开始实现。”结束。

---

阶段 6：后续步骤

冲刺计划写入且 QA 计划状态已确定后：

• /qa-plan sprint — 必须在开始实现前运行 — 为每个故事定义测试用例，让开发人员依据 QA 规范实现，而不是从零开始
• /story-readiness [story-file] — 在开始处理某个故事前，验证其是否已准备就绪
• /dev-story [story-file] — 开始实现第一个故事
• /sprint-status — 在冲刺进行期间检查进度
• /scope-check [epic] — 在开始实现前，确认没有范围蔓延

**审查模式配置：**所有 director 关卡（制作人可行性评估、QA 审查、代码审查）都遵循项目审查模式。该模式在本技能顶部的代码块中解析（--review 标志 → project.local.yaml → project.yaml 中的 modes.review_mode → production/review-mode.txt → modes.rigor 扩展；标准严格度对应 lean，最低严格度对应 solo）。本技能不会询问或写入该模式；阶段 0 会说明希望调整审查深度的用户应查看哪里。模式为以下之一：

• lean — 跳过非阶段关卡的 director 关卡（rigor: standard 的值）
• full — 将所有 director 关卡作为生成的子 Agent 运行
• solo — 无条件跳过所有关卡生成（单个开发人员，无审查）

project.yaml 中的 modes.review_mode 是主要来源；production/review-mode.txt 是旧版回退来源。/sprint-plan、/story-readiness、/story-done 以及其他使用关卡的技能都会在启动时读取这两处设置。