用途
recipe-review 是一套面向“实现完成后”阶段的质量保证工作流配方，用于审查已完成的实现是否满足治理来源（governing source）合规、范围经济、仓库质量与安全要求，并在获得用户批准后应用修正。它本身是一个编排流程，不直接产出语义交付物，而是把审查与修复工作委派给具名子代理。
主要能力
- 实现审查：由 code-reviewer 执行，检查验收标准是否满足，并给出必需修正项。
- 安全审查：由 security-reviewer 执行，按类别列出 confirmed_risk 与 defense_gap 等发现。
- 审查处置门（Review Resolution Gate）：对每条可执行的审查发现进行处置，决定路由。
- 双路径修正：代码侧修正（Fix implementation → task-executor；质量检查 → quality-fixer；再验证 → code-reviewer / security-reviewer）与设计侧更新（DD 修订 → technical-designer 更新模式；DD 审查 → document-reviewer；跨 DD 一致性 → design-sync；再验证 → code-reviewer）。
- 再验证与收敛：修正后重新运行 code-reviewer 与 security-reviewer，并对质量限制进行重试。
- 最终报告：汇总初始与修正后审查结论、对账结果、质量检查状态、剩余证明限制、被拒绝的发现与剩余问题。
使用方式
该配方以命令形式使用，接受一个 Design Doc 参数（$ARGUMENTS）。执行流程共 10 步：
- 前置检查：从当前分支与仓库默认分支的合并基点之间的变更推导 implementationFiles，包含已提交、工作区与未跟踪文件；确定治理文档（优先使用显式传入的 Design Doc，其次使用与 implementationFiles 相交的 Work Plan 所记录的 Design Doc 路径，再次使用 docs/design/ 下唯一的 Design Doc）。
- 调用 code-reviewer 审查已完成实现，返回初始审查 JSON。
- 调用 security-reviewer 审查安全合规。
- 判定与响应：对两个输出应用 Review Resolution Gate，按发现模式计算建议路由（d 设计侧更新、c 代码侧修正、d and c 缩减），并通过 AskUserQuestion 获取实施授权；批准集为空时直接进入第 10 步。
- 设计侧更新：仅当存在 d 路由时运行，调用 technical-designer（更新模式）与 document-reviewer，必要时调用 design-sync。
- 执行修复：调用 task-executor 应用已批准的代码侧修正。
- 质量检查：调用 quality-fixer，按 pass / stub_detected / verification_incomplete / blocked 路由。
- 再验证 code-reviewer。
- 再验证 security-reviewer（当规则要求当前安全结果时）。
- 最终报告。
配方要求在执行前先运行 llm-friendly-context 技能（在编写 Agent 提示、交接或生成产物之前）与 subagents-orchestration-guide 技能（在做出工作流决策、调用代理或解决发现之前），并在首次发现处置前阅读 references/review-resolution.md。
适用场景
- 实现已完成、需要对照治理文档做合规与质量把关时。
- 需要同时覆盖代码质量与安全审查，并按发现类型分流到代码修正或设计文档更新时。
- 存在多个 Design Doc、需要跨文档一致性检查时。
- 需要用户逐项批准修正路由、并保留完整审查与对账记录时。
限制
- 该配方授权的是分析；实施授权需通过 AskUserQuestion 单独获取。
- 任务文件与纯文档路径不属于本配方的代码与安全审查输入。
- 设计侧路径仅在 Design Doc 过时、过度或对所需结果不正确时适用；现有实现或先前设计默认都不具权威性。
- 具体子代理的可用性、运行环境与依赖技能（llm-friendly-context、subagents-orchestration-guide）的获取方式，资料中暂未提供。
- 收费、价格、平台支持与效果数据，资料中暂未提供。