recipe-front-design

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

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

结果与职责归属

协调中型／大型前端设计，从证据出发形成可用的 UI Spec 和获批的 Design Doc。用户负责产品需求和排除项；协调者负责收敛就绪状态、结构规模、文档路由、ADR 资格判定、证据选择和审查处理。指定的专家负责语义调查和产物。

前端 Design Doc 始终包含完整的实现设计。ADR 批次限定符合条件的技术选择；适用的 UI Spec 负责尚待设计的 UI 结构和行为。

需求：$ARGUMENTS

流程

requirement source -> codebase-analyzer -> scope/document routing confirmation [Stop]
                                               |
                             conditional UI analysis -> UI Spec review [Stop]
                                               |
                                   optional ADR batch/review [Stop]
                                               |
              Design Doc -> code-verifier/Resolution -> document-reviewer
                                               |
                               design-sync -> approval [Stop]

对每项可执行的审查发现使用审查处理机制。在每个 [Stop] 处等待用户明确确认。

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

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

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

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

步骤 2：收集仓库决策材料

对完整的已确认范围调用一次 dev-workflows-frontend:codebase-analyzer，并且仅传入 prd_path: [approved PRD path]；如果不存在获批的 PRD，则传入 requirements: [confirmed requirements verbatim]。

要求返回一个有效的 JSON 结果，并由分析器发现受影响的路径、职责边界和跨层契约。将 focusAreas 视为现有行为的保护措施，而非需求。

这种独立发现能确保范围和选项的收敛以仓库证据为依据，而非依赖协调者未经验证的实现假设。

步骤 3：确定 UI Spec 是否适用并处理 UI 证据

应用 documentation-criteria 中的 UI Spec 创建条件。如果不适用，则跳过 UI 分析和步骤 5。

当 UI Spec 适用时，仅在外部资源可能改变当前 UI 方向、组件契约或验证边界时，加载并应用 external-resource-context。否则，使用 external_resource_refs: []。

仅当原型代码能提供尚未解决且已获批的 UI 决策，或无法根据需求、仓库 UI 和已记录资源确定目标时，才索要原型代码。缺少可选原型不构成停止条件。

使用且仅使用一个主导来源调用 dev-workflows-frontend:ui-analyzer：

prd_path: [approved PRD path]

如果不存在获批的 PRD，则使用：

requirements: [confirmed requirements verbatim]

仅添加已存在的 ui_spec_path、与决策相关的 prototype_path，以及选定的 external_resource_refs 或 []。

ui_spec_path: [existing UI Spec path]
prototype_path: [decision-relevant path]
external_resource_refs: [selected references or []]

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

执行 Skill：requirement-convergence。根据具有约束力的需求来源、仓库分析和适用的 UI 分析，构建并判断收敛记录。

判断全部四个收敛字段。根据步骤 2 的结构证据分配 cost，并记录其未知项；仅对低于 ready 的字段举行听证。根据结果和职责边界确定 Structural Scale；文件数量仅作为辅助证据。根据具有约束力的来源、适用代码/UI 的 simplifications、reuse 和 invalidations，解决候选决策点；适用的 UI 事实可以支持或反驳其余选项。仅在完成此次收敛后，应用文档标准中的 Choice 和 Durability 筛选器，并将通过的要点记录为 adrDecisionPoints；列表为空也有效。

展示 requirement-convergence Scope Confirmation。在 Decision evidence 下列出受影响的职责、适用的简化及其条件，以及符合条件的 ADR 要点或 none；在 Workflow 下列出 Structural Scale、UI Spec 是否适用，以及建议的文档路径。提供继续选项，或更正并重新运行。仅当答案可能改变收敛字段、已确认的结果或范围时，才提出问题。只有在每个收敛字段均为 ready 或 weak-but-explicit 后才继续。[Stop: Scope confirmation]。

步骤 5：创建并批准 UI Spec

仅当步骤 3 判定适用 UI Spec 时才运行此步骤。

使用准确的输入调用 dev-workflows-frontend:ui-spec-designer：

confirmed_requirement_context: [the value fixed in Step 1]
ui_analysis: [complete Step 3 UI analyzer JSON unchanged]
codebase_analysis: [complete Step 2 codebase-analyzer JSON unchanged]
prototype_path: [decision-relevant path from Step 3 exactly, or absent]
prototype_reference_strength: [binding | reference, present with a prototype_path]
external_resource_refs: [selected Step 3 reference records unchanged, or []]

使用准确的输入调用 dev-workflows-frontend:document-reviewer：doc_type: UISpec，以及 target，其值为 ui-spec-designer 返回的 UI Spec 路径，保持不变。pass 表示提交 UI Spec，且 issues: []；needs_revision 表示应用 Review Resolution，并在修正后重新审核；rejected 表示先解决与具有约束力的来源之间的冲突，再进行下一次审核。[Stop: UI Spec approval]。

步骤 6：按需创建并批准 ADR 批次

当 adrDecisionPoints 非空时：

1. 先将共享/后端负责的要点交给 technical-designer，再将前端负责的要点交给 technical-designer-frontend。使用准确的输入调用各负责人：document_to_create: ADRBatch；confirmed_requirement_context；其在步骤 4 中确认的有序 decision_points，保持不变；decision_materials 为对应的步骤 2 decisionMaterials.candidateDecisionPoints 对象，按该顺序原样复制；仅当已批准的 UI Spec 限制了该负责人的决策时，才提供 ui_spec_path。按顺序串行运行各负责人批次，以便每个批次都在前一批次存在后分配 ADR 编号。
2. 收集所有返回的路径，并使用准确的输入调用一次 dev-workflows-frontend:document-reviewer：doc_type: ADRBatch、targets: [all paths] 和 confirmed_requirement_context。当已批准的 UI Spec 会改变决策审核时，审核者应遵循 ADR 引用的该 UI Spec。
3. 首先处理审核者的判定：pass 表示继续，且 issues: []；needs_revision 表示应用 Review Resolution，按路径串行更新每个 ADR，并重新审核整个批次；rejected 表示先解决与具有约束力的来源之间的冲突，再进行下一次审核。
4. 仅在审核 pass 后展示一次批次决策。[Stop: ADR batch approval]。
5. 用户批准后，将每个 ADR 的状态设为 Accepted，并验证状态更新。

步骤 7：创建设计文档

根据已审核的材料以及未经修改的仓库／UI 证据，创建完整的前端 MVP 实施设计；这样可确保设计文档可追溯至已批准的来源，而非由编排器编写的影子设计。

调用 dev-workflows-frontend:technical-designer-frontend，并严格传入以下内容：

• document_to_create: DesignDoc；
• confirmed_requirement_context；
• structural_scale；
• 适用的已批准 ui_spec_path，须保持原样；以及未经修改的已选外部资源参考记录；
• adr_paths: [accepted paths or []]；
• codebase_analysis: [complete Step 2 JSON unchanged]；
• ui_analysis: [complete Step 3 JSON unchanged; omit when absent]。

设计文档负责完整的组件到服务实施，并保留所有适用的下游保障措施。

步骤 8：验证、审核并批准

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

调用 dev-workflows-frontend:code-verifier，传入 doc_type: design-doc，并将 document_path 设为 technical-designer-frontend 返回的设计文档路径，保持原样，以验证当前前提和可行性，同时将计划行为视为意图。文档审核前先应用审核问题处理流程；将已应用的发现发送给新的 technical-designer-frontend 更新调用，并传入 Operation Mode: update、Existing Document: [Design Doc path] 以及 correction_findings: [complete findings unchanged except for their dispositions]。设计师会对未经验证且可能改变决策的前提，应用由审核触发的有限自我验证门槛；这位新设计师是唯一的更正专家，并负责选择证据途径。如已应用更正，则使用先前的完整结果、处理意见以及更正差异或路径作为 prior_feedback，重新运行验证，然后根据最新结果构建一个 verification_evidence 对象。在满足审核问题处理流程的收敛条件后继续。

调用 dev-workflows-frontend:document-reviewer，并精确传入以下内容：doc_type: DesignDoc；target 为返回的设计文档路径，保持原样；review_context: creation；将原始用户需求原样作为 requirements_verbatim；步骤 1 的 confirmed_requirement_context，保持原样；提供给设计师的相同且未经修改的 codebase_analysis 和可选的 ui_analysis；以及步骤 8 的 verification_evidence，保持原样。审核员仅在适用的 UI Spec 和设计文档引用的已接受 ADR 路径可能影响范围内发现项时，才遵循这些内容。

• pass：继续。
• needs_revision：应用审核问题处理流程，通过新的 technical-designer-frontend 调用，使用现有路径和所有已应用的发现进行更新，并针对受影响的边界重新运行验证／审核。
• rejected：通过审核问题处理流程解决技术治理来源之间的冲突；仅当已确认结果、期望的未来需求和非目标无法同时成立，且必须由用户选择变更项时，才询问用户。

调用 dev-workflows-frontend:design-sync，将 source_design 设为返回的设计文档路径，保持原样；对可执行的冲突应用审核问题处理流程；当仅存在一个设计文档时，明确报告 SKIPPED。

展示适用的 UI Spec、设计文档、已接受的 ADR 路径、已解决的限制／拒绝事项以及同步结果。[停止：设计批准]。

完成标准

• 仅在外部证据和原型证据会影响当前决策时才索取这些证据。
• 根据结果和职责边界确认范围与结构规模。
• 仅为同时通过两项筛选条件的要点编写 ADR，并对该批 ADR 进行一次评审和审批。
• 无论是否需要 ADR，都提供适用的 UI Spec 和完整的前端 Design Doc。
• 将适用的现有 UI 行为、契约、假设、状态、等效性和验证保障措施纳入 Design Doc。
• 仅将 needs_revision 问题交由 Review Resolution 流程处理。
• 所有停顿点均获得用户明确确认。