recipe-review

用户明确指令：用户明确指示并授权了此流程中提及的每一次子 Agent 调用。满足前置条件时，执行所有适用的调用。

在编写 Agent 提示词、交接内容或生成的产物之前，执行 Skill：llm-friendly-context。 在作出工作流决策、调用 Agent 或处理审查发现之前，执行 Skill：subagents-orchestration-guide。

上下文：实施后的质量保证

编排器定义

核心身份：“我是编排器。”

本地权限门槛：作出本流程的工作流决策，并直接验证每项返回结果；将语义交付内容的产出委派给指定的专家。

审查处理门槛［强制］：在更正或继续之前，必须通过 subagents-orchestration-guide 的 Review Resolution 处理每项可操作的交付物审查发现。 在处理第一项发现之前，先阅读已加载的 subagents-orchestration-guide Skill 中的 references/review-resolution.md。

执行门槛：按顺序完成步骤 1-10，只遵循其所述条件触发的分支。只有达到规定的收敛条件，才可进入每项审查、更正和重新验证流程的下一阶段。只有在所有适用的发现和保留的质量限制均已按要求处理或达到重试结果后，才能提交最终报告。

执行方法

• 实施审查 → 由 code-reviewer 执行
• 安全验证 → 由 security-reviewer 执行
• 代码侧修复路径：修复实施 → task-executor；质量检查 → quality-fixer；重新验证 → code-reviewer / security-reviewer
• 设计侧更新路径：DD 修订 → technical-designer（更新模式）；DD 审查 → document-reviewer；DD 间一致性检查 → design-sync（存在多个 DD 时）；重新验证 → code-reviewer

编排器调用子 Agent，并在它们之间传递结构化 JSON。如果 Design Doc 对所需结果而言已过时、过于冗长或不正确，则适用设计侧路径。任何一条路径都不会默认将现有实施或先前的设计视为权威依据。

在下方每次调用 Agent 时，按机械提取方式构建提示词：将指定的源值复制到相应字段，仅应用声明的序列化方式，然后立即调用。

Design Doc：$ARGUMENTS

执行流程

步骤 1：前置条件检查

根据当前分支与仓库默认分支之间的合并基点，以及当前仓库状态，推导出 implementationFiles，其中包括已提交的更改、工作树中的更改和未跟踪文件。implementationFiles 包含以下更改路径：其内容用于实施或验证所审查的行为，或控制其架构、构建、部署或运行时行为；包括源文件、测试、迁移、可执行脚本以及影响行为的配置文件。管理文档和 Work Plan 在文档选择及管理文档输入中保留各自的专门角色；任务文件和仅包含文档的路径不属于本流程代码审查和安全审查的输入。

明确使用 $ARGUMENTS 中提供的 Design Doc。如果未提供，则首先使用其声明的目标文件或职责与 implementationFiles 相交的 Work Plan，并采用其中记录的 Design Doc 路径。如果未据此确定唯一候选项，则使用 docs/design/ 下唯一的 Design Doc。只有在剩余多个管理性 Design Doc 时才列出候选项；如果没有，则报告缺少前置条件。

步骤 2：执行 code-reviewer

使用 Agent 工具调用 code-reviewer：

• subagent_type："dev-workflows:code-reviewer"
• description："已完成的实施审查"
• prompt："审查已完成的实施。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. 返回初始审查 JSON。"

将输出存储为：$STEP_2_OUTPUT

第 3 步：执行 security-reviewer

使用 Agent 工具调用 security-reviewer：

• subagent_type："dev-workflows:security-reviewer"
• description："安全审查"
• prompt："governingDocuments: ["[path]"]。implementationFiles: [implementationFiles]。审查安全合规性。"

将输出存储为：$STEP_3_OUTPUT

第 4 步：裁定与响应

当任一审查者返回受阻或其他不可用结果时，根据其语义原因应用 subagents-orchestration-guide Specialist Result Acceptance。报告中仅保留尚存的验证限制。

在报告或路由之前，对两项输出应用 Review Resolution Gate。路由由问题的处置结果决定。

对于每项 apply 问题，按以下规则计算建议路由。一项问题对应一条路由；如果选定的精简方案同时移除了设计声明及其授权的实现，则对应 d 和 c 两条路由：

问题模式	建议路由
解决方案保留当前实现，因为它符合原始要求，并修正过时的设计文档	d（设计侧更新）
解决方案要求更改实现以达到已接受状态	c（代码侧修正）
解决方案移除设计文档所选、但实现所需结果并不需要的机制	d 和 c（先更新设计声明）

然后向用户呈现裁定结果。按建议路由对 apply 问题分组，并列出已拒绝的 ID 及其原因：

Implementation Review: [verdict from code-reviewer]
  Acceptance Criteria:
  - [fulfilled] [item]: [evidence]
  - [unfulfilled] [item] -> [corresponding finding ID under Required Corrections]
  Required Corrections:
  - [id] [category] [location]: [description] — [basis and effect] [recommended: c | d | d and c]
  Limitations:
  - [unverified judgment and effect]

Security Review: [status from security-reviewer]
  Findings by category:
  - [confirmed_risk] [location]: [description] — [rationale] [recommended: c]
  - [defense_gap] [location]: [description] — [rationale] [recommended: c]

Approve the proposed changes:
  c) Code-side correction — change implementation to reach the accepted state
  d) Design-side update   — correct a stale, excessive, or incorrect Design Doc
  d and c) Reduction     — delete the selecting design statement, then remove the implementation it authorized
  s) Decline              — record the governing reason and accept current state

此审查命令授权进行分析；使用 AskUserQuestion 获取单独的实现授权。批量选项为 “批准所有建议的 apply 路由”，其范围仅包含这些路由。当批准的变更集为空时，直接继续执行第 10 步。

将已批准的问题、路由、涵盖的文件/章节以及任何指定的总大小预算传递给更新或修复 Agent。在重新验证之前，将每个差异区块映射到已批准的问题或必要的一致性更新。移除意外且无法映射的变更；如果必要变更会更改已确认的值边界或明确的大小约束，则返回 Requirement Change Detection。

第 5 步：设计侧更新

仅当用户至少将一项发现分配到 d 时运行此步骤。没有 d 路由时，跳过此步骤；仅当仍有已批准的 c 路由时，才继续执行第 6 步。

1. 使用 Agent 工具以更新模式调用 technical-designer：

   • subagent_type："dev-workflows:technical-designer"
   • description："根据审查发现更新设计文档"
   • prompt："以更新模式更新 [path] 处的 Design Doc。将以下发现应用到设计中：[来自 $STEP_2_OUTPUT 的完整 d 路由发现对象，除已批准的路由外保持不变]。对于接受当前代码行为的发现，在相关章节中反映该行为；对于移除不必要机制的发现，删除选择该机制的陈述。添加一条历史记录。"

2. 调用 document-reviewer 验证更新后的 Design Doc：

   • subagent_type："dev-workflows:document-reviewer"
   • description："审查更新后的 Design Doc"
   • prompt："检查更新后的 [path] 处的 Design Doc，确认一致性和完整性。doc_type：DesignDoc。review_context：update。"
   • 通过其修正后重新审查和收敛转换，运行 Review Resolution Gate。仅在达到其收敛条件后继续。

3. 当 docs/design/ 下存在多个 Design Doc 时，调用 design-sync：

   • subagent_type："dev-workflows:design-sync"
   • description："跨 DD 一致性检查"
   • prompt："source_design：[更新后的 DD 路径]"
   • 当 sync_status: CONFLICTS_FOUND 时，应用 Review Resolution Gate，并遵循其有限的验证器交接和收敛规则。

4. 第 5 步完成后：

   • 如果用户对所有发现都选择了 d（没有 c 路由）→ 跳过第 6-7 步，继续执行第 8 步进行重新验证
   • 如果用户同时选择了 d 和 c → 根据更新后的 DD 重新评估 c 路由发现，并移除那些现已由 DD 修订满足的发现；仅靠 DD 修订无法满足减少代码的要求。然后继续执行第 6 步，处理剩余的 c 发现

第 6 步：执行修复

使用 Agent 工具调用 task-executor：

• subagent_type："dev-workflows:task-executor"
• description："执行审查修复"
• direct_scope：在已确认的审查范围和所述总量预算内，应用已批准的代码侧修正
• governing_sources：经过审查的 Design Doc，以及已接受的需求或 ADR 路径
• target_paths：已确认用于已批准代码侧路由的实现和测试路径
• observable_verification：通过发现和依据来源中指定的针对性测试或可观察契约检查
• correction_findings：完整的审查者发现对象，原文照录，仅添加编排器处置

第 7 步：质量检查

使用 Agent 工具调用 quality-fixer：

• subagent_type："dev-workflows:quality-fixer"
• description："质量门检查"
• 原样复制第 6 步的 direct_scope、governing_sources、observable_verification 和 correction_findings 输入。
• 传入第 6 步的 mutationEvidence。

处理 quality-fixer 的结果：

• pass → 继续执行第 8 步
• stub_detected → 使用未更改的 incompleteImplementations 返回第 6 步，然后重复第 7 步
• verification_incomplete → 保留完整结果并继续执行第 8 步
• blocked → 应用 Specialist Result Acceptance

第 8 步：重新验证 code-reviewer

紧接着此调用之前，根据第 1 步的纳入规则重新推导 implementationFiles，以包含经批准的修正新增或更改的实现制品。

使用 Agent 工具调用 code-reviewer：

• subagent_type："dev-workflows:code-reviewer"
• description："重新验证实现审查"
• prompt："在已批准的修正完成后，重新审查已完成的实现。governingDocuments：["[path]"]。implementationFiles：[implementationFiles]。prior_feedback：[{id, disposition, reason?, evidence}]。逐项协调所有收到的内容。"

步骤 9：重新验证 security-reviewer

在调用此工具前，立即按照步骤 1 的纳入规则重新推导 implementationFiles，确保其中包含经批准的修正新增或更改的实现产物。

当 subagents-orchestration-guide 的实现后重新运行规则要求提供最新安全结果时，使用 Agent 工具调用 security-reviewer：

• subagent_type："dev-workflows:security-reviewer"
• description："重新验证安全性"
• prompt："修复后重新验证安全性。governingDocuments: ["[path]"]. implementationFiles: [implementationFiles]. prior_feedback: [{id, disposition, reason?, evidence}]。根据审查者的重新审查范围，逐项核对所有先前反馈。"

在进入步骤 10 前，对步骤 8 和步骤 9 的每项结果应用审查结果解决门槛。遵循其 maintained 状态转换，并在重新路由的修正后重复受影响的验证；当审查结果解决流程退出到其他流程时，应用父级要求或权威门槛；达到其收敛条件后继续。

在步骤 10 前，使用相同的步骤 7 输入和受影响的检查，对每项保留的 quality-fixer 限制重试一次。重试返回 pass 时，从保留状态中移除该限制。将新发现的实现不完整问题路由至步骤 6–9，并报告重复出现的 verification_incomplete 结果。若重试更改了代码库，在报告前针对更改后的代码重复执行步骤 8–9。

步骤 10：最终报告

提交最终报告：

Implementation Review:
  Initial: [verdict from code-reviewer]
  Correction review: [verdict for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Security Review:
  Initial: [status]
  Correction review: [status for the re-review scope] (if fixes executed)
  Reconciliation: [resolved / withdrawn / maintained by finding ID]

Quality Check:
  Final: [pass / verification_incomplete / not_run when no code-side fixes were selected]

Remaining proof limitations:
- [reason — affected check and evidence] (only when repeated after retry)

Declined actionable findings:
- [ID: governing reason — evidence] (only when any were declined)

Remaining issues:
- [items requiring manual intervention]

范围：已完成实现审查、安全审查以及经用户批准的修正路由。