用途
story-done 用于在实现任意 story 结束时关闭设计与实现之间的循环。它的目标是确保：每条验收标准在 story 被标记完成前都经过验证；对 GDD（游戏设计文档）和 ADR（架构决策记录）的偏离被显式记录而非悄悄引入；代码审查被主动触发而非被遗忘；story 文件反映真实的完成状态。
主要能力
该技能按八个阶段组织执行：
- 定位 story（Find the Story）
- 读取 story（Read the Story）
- 验证验收标准（Verify Acceptance Criteria）
- 检查偏差（Check for Deviations）
- 主程序代码审查门禁（Lead Programmer Code Review Gate）
- 呈现完成报告（Present the Completion Report）
- 更新 story 状态（Update Story Status）
- 引出下一个 story（Surface the Next Story）
每个阶段的具体步骤存放在对应的 references 文件中（如 references/1-find-story.md 等），技能正文只负责引导读取并执行。
输出为：更新后的 story 文件（Status: Complete）以及被引出的下一个 story。
使用方式
在实现任意 story 结束时运行该技能。技能开头会通过 bash 调用 yaml-helper.sh 解析配置项，包括 review_mode、automation、workflow、story_granularity、qa.level、testing.strict、system_overrides；解析结果按原样使用，--review 可覆盖 review_mode；若无对应配置块，则采用 .claude/docs/config-resolution.md 中的默认值。
协作协议（默认协作模式）要点：
- 绝不在未经用户批准的情况下将 story 标记为完成——阶段 7 在编辑任何文件前需要明确的“yes”。
- 绝不自动修复未通过的验收标准——报告并询问如何处理。
- 偏差是事实而非判断——中性呈现，由用户决定是否可接受。
- BLOCKED 与 NOT ASSESSED 判定为建议性质——用户可覆盖并标记完成，但需显式记录风险。对 NOT ASSESSED，记录的风险是该标准从未被评估，而非其失败；需记录具体是哪些标准，以便日后可补救而非被掩盖。
- 使用 AskUserQuestion 进行代码审查提示以及批量确认手动标准。
关于引导模式与自主模式，参见 .claude/docs/automation-modes.md；BLOCKED 覆盖式关闭（阶段 7）无论何种模式都会提示（属于 scope_changes 的 always-ask 决策）。
适用场景
适用于采用 story 驱动开发流程的游戏项目，在单个 story 实现完成后进行收尾审查。推荐的后续步骤包括：
- 最低限度：运行 /dev-story [next-story-path]（对处于 In Review 的 story 运行 /story-done）；当所有 story 都 Complete 后，试玩构建，然后运行 /create-stories 获取更多 story，或运行 /settings 提高 modes.rigor。
- 有 sprint 计划时：运行 /story-readiness [next-story-path] 在开始实现前验证下一个 story。
- 若存在 sprint 计划且其所有 Must Have story 均已完成：运行 /smoke-check sprint → /team-qa sprint → /gate-check。
- 若记录了技术债：通过 /tech-debt 跟踪以保持登记表最新。
限制
该技能不会自动修复未通过的验收标准，也不会在未经用户明确批准的情况下标记 story 完成。BLOCKED 与 NOT ASSESSED 判定仅为建议，用户可覆盖，但需记录风险。关于具体配置项取值、各阶段详细步骤、以及引导/自主模式的具体规则，资料中未完整提供，需查阅对应的 references 文件与 .claude/docs 下的文档。