用途：更新已有设计文档，包括 Design Doc、PRD 和 ADR。执行前需加载 documentation-criteria、subagents-orchestration-guide、llm-friendly-context 三个技能。工作流将编排者与执行者分离，所有工作交由子代理完成，编排者只负责调用、传递数据和汇报结果。
主要能力：识别 docs/design/、docs/prd/、docs/adr/ 下的目标文档；按路径判定文档类型与层次，Design Doc 与 ADR 还需区分前端或后端以选择更新代理；调用更新代理修改文档并补充变更历史；Design Doc 更新后用 code-verifier 对代码校验，再由 document-reviewer 评审，最后用 design-sync 校验与其他设计文档的一致性。
使用方式：以目标文档作为 $ARGUMENTS 传入。流程为：识别目标文档、确定类型与层次、澄清变更内容、更新文档、评审、一致性校验。在“确认变更”“评审通过”“最终批准”等标记处必须暂停等待用户明确确认才能继续。子代理调用统一使用 fork_turns="none"。
适用场景：需要修改既有设计文档、PRD 或 ADR，且希望获得评审和一致性保障的情况。ADR 小改动直接更新原文件，重大改动（决策反转、范围显著变化）应新建 ADR 取代原文件。
限制：不负责新需求分析、工作计划或实现，这些应转向 recipe-design、recipe-plan 或 recipe-task；未找到文档时应报告并建议改用 recipe-design；评审被拒后最多修订 2 次，超过则转人工处理；design-sync 发现冲突时由用户决定处理方式。工作流在更新文档获得批准后完成。