菜单
阶段四（审）。用户输入 /ssf-review 或由 ssf-build 续接时触发。用工程审查视角 + Superpowers review 接收纪律，输出阻塞项、建议项、记录项，并确认 spec/code/test 同步。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | ssf-review |
| description | 阶段四（审）。用户输入 /ssf-review 或由 ssf-build 续接时触发。用工程审查视角 + Superpowers review 接收纪律，输出阻塞项、建议项、记录项，并确认 spec/code/test 同步。 |
在 QA 和发布前，进行对抗式工程审查。
本阶段体现 SuperSpecFlow 路由与适配层：把 OpenSpec、diff、progress 和 evidence 路由到工程、代码、安全视角审查。体现 Superpowers 的价值：处理 review 反馈时先验证事实，不盲目认同。
/ssf-reviewssf-build 完成后续接检查：
## Engineering Manager Review
1. 是否严格实现 proposal/spec？通过 / 有问题
2. 是否有过度设计？通过 / 有问题
3. 模块边界是否清晰？通过 / 有问题
4. 数据流是否正确？通过 / 有问题
5. 错误处理是否完整？通过 / 有问题
6. 测试是否覆盖核心行为和 MUST NOT？通过 / 有问题
7. 是否引入不必要依赖？通过 / 有问题
宿主项目 review 产物默认写入 .superspecflow/reviews/<change-id>/review-report.md。读取历史 review 时先读 .superspecflow/reviews/<change-id>/，缺失时 fallback 到兼容期旧路径；新写入不得推荐根目录 reviews/<change-id>/。
# Review Report: [change-id]
## 🔴 必须修（阻塞发版）
- [问题] @ [文件:行号]
- Spec: [SPEC-ID]
- 风险:
- 建议修法:
## 🟡 建议改（不阻塞）
- [问题] @ [文件:行号]
- 建议:
## 🟢 记录即可
- [观察]
检查维度：
如果用户要求修 review：
不得直接说“你说得对，我马上改”。
同步检查属于 review 产物，默认写入 .superspecflow/reviews/<change-id>/sync-check.md。
# Sync Check
| Spec ID | Code Implemented | Test Exists | Status |
|---|---:|---:|---|
| SPEC-001 | Yes/No | Yes/No | Pass/Fail |
ssf-qa。如果用户要求 Claude、Codex 或另一个 agent 独立核验同一个 <change-id>，使用轻量文件化 handoff：
.superspecflow/verification/<change-id>/
request.md
evidence.md
reviewer-notes.md
signoff.md
模板来源：
templates/verification-request.md
templates/verification-evidence.md
templates/verification-reviewer-notes.md
templates/verification-signoff.md
规则：
request.md 和 evidence.md。request.md 必须列出核验范围、目标 Spec ID、OpenSpec 文件、diff 来源、progress 引用和 evidence 引用。evidence.md 必须包含可复查的命令、方法、结果摘要、相关文件或产物引用；不得只写结论。reviewer-notes.md 说明缺口，但不得生成 signoff.md。signoff.md 只能使用 approve / changes-requested / blocked，并必须列出已检查 Spec ID、证据引用、发现和残余风险。reviewer-notes.md 或 signoff.md 记录残余风险。在 review 报告后增加：
# Karpathy Diff Audit
## 是否隐藏假设
- Pass / Fail
## 是否过度设计
- Pass / Fail
## 是否存在无关改动
- Pass / Fail
## 每类改动的必要性
| 改动 | 对应 Spec / Task / Bug | 是否必要 |
|---|---|---|
## 建议拆分的 commit
## 建议回滚的无关改动
任何无法映射到 Spec ID、任务或测试的行为改动，至少标为 🟡；如果影响正确性、安全或发布，标为 🔴。
检查：
# Git Hygiene Review
- [ ] 当前分支命名是否合理
- [ ] diff 是否只包含本 change-id
- [ ] 是否有生成物、缓存、日志、secret
- [ ] 是否适合拆成多个 commit
- [ ] commit message 是否需要中文模板
阶段六（档）。用户输入 /ssf-archive 或由 ssf-ship 续接时触发。归档 OpenSpec change、同步文档、更新 decision ledger，并用 Diataxis 检查文档缺口。
阶段三（建）。用户输入 /ssf-build 或由 ssf-spec 续接时触发。按 OpenSpec tasks 执行，使用 Superpowers 风格：理解、计划、TDD、小步实现、验证、更新 spec-to-code-map。
复盘。用户输入 /ssf-retro 时触发。复盘本轮 SuperSpecFlow，检查产品、规格、开发、测试、发布各阶段的流程质量，输出可执行改进。
阶段二（规）。用户输入 /ssf-spec 或由 ssf-think 续接时触发。生成 OpenSpec 风格 change contract：proposal.md、design.md、specs/*.md、tasks.md、Spec Readiness Review。
阶段一（想）。用户输入 /ssf-think 或描述新想法/新功能时触发。用 Superpowers brainstorming 纪律做价值、体验、范围反问，产出 Product Change Brief、Decision Record 和 design.md，然后进入 ssf-spec。
Git 工作流与中文 commit 正文门禁。用户输入 /ssf-git、/ssf-branch、/ssf-commit、/ssf-pr，或要求建分支、提交、生成 PR、合并、rebase 时触发。强制分支、暂存、提交、PR 与 OpenSpec change-id/Spec ID 对齐；commit 标题的类型与范围使用英文标识符（conventional commits），摘要、正文、字段名必须使用中文。