recipe-design

明确的用户指示：用户明确指示并授权执行本方案中点名的每一次子 Agent 调用。满足前置条件后，执行每一项适用调用。

在文档路由或创建之前，执行技能：documentation-criteria。 在编写 Agent 提示词、交接内容或生成的产物之前，执行技能：llm-friendly-context。 在调用 Agent 或解决发现项之前，执行技能：subagents-orchestration-guide。 在首次处置发现项之前，阅读已加载的 subagents-orchestration-guide 技能中的 references/review-resolution.md。

结果与职责归属

协调从仓库证据到获批设计文档的设计阶段。用户负责产品需求和排除项；协调者负责收敛就绪状态、Structural Scale、ADR 资格判定、证据选择和 Review Resolution。指定的专家负责语义调查和产物撰写。

对于 Medium/Large 工作，设计文档始终是完整的实施设计。符合条件的 ADR 批次会在设计文档之前缩小技术选择范围，而设计文档仍保留完整流程和实施边界。

需求：$ARGUMENTS

流程

requirement source -> codebase-analyzer -> scope/decision confirmation [Stop]
                                             |
                               optional ADR batch -> batch review [Stop]
                                             |
                 Design Doc -> code-verifier -> Review Resolution
                                             |
                     document-reviewer -> design-sync -> approval [Stop]

每当存在前置证据，就执行相应的依赖步骤。在处理所有可执行的验证者、审查者或设计同步发现项时，使用 Review Resolution。在每个 [Stop] 处等待用户明确确认。

在以下每个 Invoke 处，通过机械提取构建 Agent 提示词：将指定的源值复制到对应字段，仅应用声明的序列化方式，然后立即调用。

第 1 步：选择主导需求来源

如果存在获批的 PRD 路径，则使用该路径。否则，原样使用已确认的需求。

将 confirmed_requirement_context 设为获批的 PRD 路径，且必须完全一致。仅当不存在获批的 PRD 时，使用协调者确认的收敛记录，且不得修改。

第 2 步：收集决策材料

调用 dev-workflows:codebase-analyzer：

prd_path: [approved PRD path]

或者，在不存在获批的 PRD 时：

requirements: [confirmed requirements verbatim]

针对完整的已确认范围调用一次。要求返回一个有效的 JSON 结果，并让分析器发现受影响路径、职责边界和跨层契约。将其关注领域视为现有行为的保障措施，而非新增需求。

这种独立发现可确保范围和选项收敛以仓库证据为依据，而不是建立在协调者未经验证的实施假设之上。

步骤 3：确认范围和 ADR 决策

执行 Skill：requirement-convergence。编排器根据用户请求和步骤 2 的证据构建并判定收敛记录。

判定全部四个收敛字段。根据步骤 2 的结构证据指定 cost，并记录其未知项；仅对低于 ready 的字段进行听证。

根据结果和职责边界确定结构规模。文件数量仅作为辅助证据。

根据具有约束力的需求来源、适用的 simplifications、reuse 和 invalidations，审查 decisionMaterials.candidateDecisionPoints。如果证据已收敛到一个足够的方案，则移除该决策点。对每个剩余项目，按顺序应用文档标准筛选条件：

1. 在已确认范围内，选择需要在至少两个可信且存在实质差异的选项之间进行判断。
2. 该选择会产生持久的实质影响。

将所有通过筛选的项目记录为 adrDecisionPoints；如果列表为空，则直接进入 Design Doc。仅可为同时通过两项筛选的项目创建 ADR。

提供需求收敛范围确认。将目标职责及其最有力的文件证据、适用的简化及其条件，以及每个符合条件的 ADR 决策点及其筛选证据或 none，放在 Decision evidence 下；将结构规模及其边界依据和建议的文档路线放在 Workflow 下。

提供继续选项，或允许用户更正范围并重新运行分析。仅当答案可能改变某个收敛字段、已确认的结果或范围时，才提出问题。仅当每个收敛字段均为 ready 或 weak-but-explicit 时继续。[停止：范围确认]。

步骤 4：必要时创建并审批 ADR 批次

当 adrDecisionPoints 非空时：

1. 使用精确输入调用一次 dev-workflows:technical-designer：document_to_create: ADRBatch；confirmed_requirement_context；将步骤 3 中已确认的 adrDecisionPoints 按顺序原样作为 decision_points；并将步骤 2 decisionMaterials.candidateDecisionPoints 中对应的对象按该顺序原样复制为 decision_materials。
2. 使用精确输入调用一次 dev-workflows:document-reviewer：doc_type: ADRBatch、targets: [all returned paths] 和 confirmed_requirement_context。
3. 优先处理审查者的判定：pass 则在 issues: [] 的情况下继续；needs_revision 则应用 Review Resolution，按路径逐个更新 ADR，并重新审查整个批次；rejected 则先解决具有约束力的来源冲突，再进行下一次审查。
4. 仅在审查 pass 后提出一次批次决策。[停止：ADR 批次审批]。
5. 用户批准后，将每个 ADR 状态更新为 Accepted，并验证状态已更改。

步骤 5：创建 Design Doc

根据经过审查的工件和未更改的仓库证据，创建完整的 MVP 实现设计；这样可确保 Design Doc 可追溯至已批准的来源，而非编排器编写的影子设计。

使用以下精确内容调用 dev-workflows:technical-designer：

• document_to_create: DesignDoc；
• confirmed_requirement_context；
• structural_scale；
• adr_paths: [accepted paths or []]；
• codebase_analysis: [complete Step 2 JSON unchanged]。

Design Doc 负责完整的端到端设计，并保留 documentation-criteria 模板中所有适用的下游保障措施。

第 6 步：验证并解决仓库声明

保持验证器的观察结果不变，以便更正始终可追溯到观察到的仓库证据，而不是变成由协调器编写的设计指令。

使用 doc_type: design-doc 和设计文档路径调用 dev-workflows:code-verifier，以验证当前前提和可行性，同时将计划中的行为视为意图。

在文档审查前，对每项差异应用 Review Resolution。仅将 apply 发现发送给全新的 technical-designer 更新调用，并附上 Operation Mode: update、Existing Document: [Design Doc path] 和 correction_findings: [除处置结果外保持完整发现内容不变]。如果某项发现指出了未经验证且会改变决策的前提，设计师将应用由审查触发的有界自我验证门槛；这位全新的设计师是唯一的更正专家，并负责选择证据途径。更正后，使用之前的完整结果、处置结果以及更正差异或路径作为 prior_feedback，重新运行 code-verifier。根据最新结果构建 Review Resolution 定义的单个 verification_evidence 对象，并在满足其收敛条件时继续。

第 7 步：审查并批准

使用以下确切输入调用 dev-workflows:document-reviewer：doc_type: DesignDoc、target、review_context: creation、作为 requirements_verbatim 的原始用户需求（逐字提供）、confirmed_requirement_context、codebase_analysis，以及来自第 6 步的 verification_evidence。

• pass：继续。
• needs_revision：应用 Review Resolution，通过全新的 technical-designer 调用进行更新，并使用现有路径和完整的已应用发现，然后针对受影响的边界重新运行第 6 至第 7 步。
• rejected：通过 Review Resolution 解决技术治理来源冲突；只有在已确认的结果、期望的未来需求和非目标无法同时成立，且必须由用户选择变更内容时，才询问用户。

调用 dev-workflows:design-sync，确保与其他设计文档保持一致，并对可执行的冲突应用 Review Resolution。如果只有一个设计文档，则明确报告 SKIPPED。

提供设计文档、已接受的 ADR 路径、已解决的限制/拒绝事项，以及 design-sync 结果。[停止：设计批准]。

完成标准

• 已根据结果和职责边界确认范围与结构规模。
• ADR 仅针对同时通过两项筛选条件的决策点创建，且整个批次完成了一次审查和批准。
• 无论是否需要 ADR，都存在设计文档。
• 适用的现有行为、契约、假设、等效性和验证防护措施均已纳入设计文档。
• Review Resolution 仅将 needs_revision 问题纳入更正工作。
• 所有停止点均已获得用户明确确认。