用途
recipe-build 是一个用于「自主执行模式」的工作流配方，其核心目标是执行已物化的任务文件（materialized task files）。它把自身定位为编排器（orchestrator），负责做出本配方的工作流决策、验证各子代理返回的结果，并将语义性交付物的生产委派给指定的专家子代理。
该配方适用于用户已提供执行指令、且存在工作计划（Work Plan）或任务文件的场景。此时用户的执行指令即被视为批量批准（batch approval），配方随即进入自主执行模式。
主要能力
- 工作计划解析：优先使用 $ARGUMENTS 中显式提供的工作计划；否则按 {plan-name}-task-*.md 命名约定对单层任务文件分组，并映射到 docs/plans/{plan-name}.md；当分组无候选时，若 docs/plans/ 下恰好只有一个工作计划则使用它；多个候选时呈现给用户选择；无候选时走缺失前置条件分支。
- 计算消费任务集（Consumed Task Set）：确定本次运行所拥有、执行并随后删除的确切文件，使用与工作计划解析相同的受限模式，排除分层感知的 fullstack 任务集。
- 任务生成决策流：根据任务集与工作计划的存在情况决定下一步——任务存在则立即进入自主执行；无任务但有计划则运行 task-decomposer；两者皆无但有设计文档（docs/design/*.md）则调用 work-planner 创建计划并运行 document-reviewer；三者皆无则报告缺失前置条件并停止。
- 任务物化阶段（条件性）：当消费任务集为空时，调用 dev-workflows:task-decomposer 读取工作计划并输出单个单提交任务文件到 docs/plans/tasks/，随后重新计算消费任务集进行验证。
- 四步任务执行循环：对消费任务集中的每个任务，依次执行 EXECUTE（调用 dev-workflows:task-executor）、BRANCH ON EXECUTOR RESULT（根据 escalation_needed/blocked、requiresTestReview、pass、needs_revision、completed 等状态分支）、QUALITY-FIX（调用 quality-fixer，处理 stub_detected、blocked、verification_incomplete、pass）、COMMIT（应用提交边界检查后执行 git commit）。
- 实现后审查：所有任务完成后，解析工作计划的 Design Doc，在一条消息中同时发出 code-reviewer 与 security-reviewer 调用，应用状态路由与修复/重跑规则，呈现统一报告。
- 最终清理：在完成报告前提交审查后修正，删除本配方消费的实现任务文件，保留工作计划本身。
- 完成报告契约：报告需包含任务物化状态、已实现任务数、质量检查结果、最终重试后仍存在的验证限制、提交数、清理结果、被拒绝的可操作发现（含 ID、理由与证据）以及升级或阻塞摘要。
使用方式
该配方通过 $ARGUMENTS 接收工作计划。执行前需满足前置条件：确认消费任务集非空、识别任务执行顺序（依赖关系）、进行环境检查（能否执行逐任务提交循环）。若提交能力不可用，需先应用专家结果接受（Specialist Result Acceptance）再进入自主模式；其他环境（测试、质量工具）下质量代理保留证明限制，任务循环继续。
配方要求在执行前先执行 llm-friendly-context 技能（在编写 Agent 提示、交接或生成产物之前），以及 subagents-orchestration-guide 技能（在做出工作流决策、调用代理或解决发现之前）。在首次发现处置前，需读取已加载 subagents-orchestration-guide 技能中的 references/review-resolution.md。
适用场景
- 已有工作计划或任务文件，希望批量自主执行开发任务。
- 需要按单提交粒度逐个执行任务，并在每个任务后做质量修复与提交。
- 需要在全部任务完成后进行代码审查与安全审查，并清理临时任务文件。
限制
- 提交只能在 quality-fixer 返回 pass 或 verification_incomplete 之后进行；quality-fixer 的 pass 授权在已定义的提交点提交，但本身不创建提交。
- 执行过程中若检测到需求变更，需先向用户升级并附变更摘要，再继续。
- 缺失输入会阻塞审查（例如无法解析工作计划的 Design Doc）。
- 若任务文件删除遇到文件系统错误，需报告失败并继续完成报告。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。