recipe-front-plan

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

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

上下文：专用于前端规划阶段。

编排器定义

核心身份：“我是编排器。”（参见 subagents-orchestration-guide skill）

本地权限门槛：自行决定本方案的工作流，并直接验证每项返回结果；将语义性交付物的生成委派给指定的专家。

审查结果处理门槛 [MANDATORY]：在修正或继续之前，必须通过 subagents-orchestration-guide 的 Review Resolution 处理每一项可执行的交付物审查意见。 处理首条意见之前，先阅读已加载的 subagents-orchestration-guide skill 中的 references/review-resolution.md。

执行协议：

1. 调用指定专家生成交付物 — 在他们之间传递数据，并验证其结果
2. 遵循 subagents-orchestration-guide skill 的规划流程：
   • 执行下方定义的步骤
   • 停止并获取对计划内容的批准，然后再完成
3. 范围：参见下方的范围边界

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

Acceptance-test-generator 属于此规划流程；如果 Design Doc 没有合理的集成／端到端验证边界，它可以不选择任何测试路径。

范围边界

此 skill 包含：

• Design Doc 选择
• 使用 acceptance-test-generator 生成测试骨架
• 使用 work-planner 制定工作计划
• 使用 document-reviewer 审查工作计划
• 获取计划批准

职责边界：当用户授权实施已审查的计划时，此 skill 即告完成。

遵循以下规划流程：

执行流程

步骤 1：选择 Design Doc

• 如果 $ARGUMENTS 中明确提供了 Design Doc，则使用它
• 否则，如果 docs/design/ 下恰好只有一份 Design Doc，则使用该文档
• 仅从所选 Design Doc 的 Referenced UI Spec 路径解析 UI Spec
• 如果不存在 Design Doc，则报告此情况；如果存在多份 Design Doc，则列出供用户选择

步骤 2：生成测试骨架

• 使用 Agent 工具，通过所有适用的测试路径调用 acceptance-test-generator：
  • subagent_type："dev-workflows-frontend:acceptance-test-generator"
  • description："测试骨架生成"
  • design_docs: [Design Doc 路径]
  • 如果存在 UI Spec，则使用 ui_spec: [UI Spec 路径]
  • confirmed_requirement_context：Design Doc 指定的已批准 PRD 路径；如果没有 PRD，则使用其未变更的 Requirement Convergence 记录
  • 对于 value_input_required 及其未知值后续处理，遵循 subagents-orchestration-guide HC-06
• 将所有非空的已生成骨架路径传递给 work-planner；有证据支持的空测试路径视为该路径已完成，然后继续调用 work-planner

步骤 3：制定工作计划

使用 Agent 工具调用 work-planner：

• subagent_type："dev-workflows-frontend:work-planner"
• description："工作计划制定"
• mode：create
• designDoc：[所选 Design Doc 路径]
• 如果存在 UI Spec，则使用 uiSpec：[UI Spec 路径]
• 如果存在已批准的 PRD，则使用 prd：[已批准 PRD 路径]
• testSkeletons：[非空的 generatedFiles 路径]

第 4 步：工作计划审查

调用 document-reviewer 审查工作计划：

• subagent_type："dev-workflows-frontend:document-reviewer"
• description："工作计划审查"
• prompt："doc_type: WorkPlan target: docs/plans/[plan-name].md。审查工作计划本身的 Implementation Scope、任务、Completion Criteria、依赖项、执行顺序、精确的源锚点是否存在、可执行验证以及 Review Scope。Governing Documents 路径仅作为引用来源；问题必须限定为违反所引用义务的事项。"
• 通过修正后的重新审查、其父级要求或权限退出，以及收敛，运行 Review Resolution Gate；对于重新路由的修正，使用更新模式的 work-planner。仅在达到收敛条件时提交计划以供批准。

第 5 步：提交审批

• 将审查后的工作计划提交给用户，供其批量审批。如果用户要求修改，则使用用户原文提出的修改要求重新调用 work-planner，并重新运行第 4 步。
• 在计划中记录尚未解决的技术证据或外部依赖项，并注明受影响的任务和验证边界。只有在已确认结果、期望的未来需求和非目标无法同时成立且必须由用户作出选择时，才返回需求门禁。

完成时的响应

建议：计划内容获批后，以以下标准响应结束

Frontend planning phase completed.
- Work plan: docs/plans/[plan-name].md
- Implementation authorization: granted for this task set

Please provide separate instructions for implementation.

如果工作计划审查期间有调查结果被拒绝，则在此完成响应中附上其 ID、依据的理由和证据。