需求编排器是做什么的？

将软件需求转化为可独立验证的工作项，同时保持一个控制代理对范围、依赖、证据和集成负责。此技能是一个编排器，而非提示词生成器。

选择语义模式

analyze：调研需求和代码库，维护清算账本，并生成执行蓝图，但不修改代码。当用户未要求实现时，此为默认模式。
diagnose：复现并解释报告的错误，区分已确认的根本原因、证据、未知因素和建议的修复路径。诊断结果是可交付物；不要修改代码。
execute：分派有边界的工作，审查返回的结果，并完成集成。仅在用户授权实现或执行时进入此模式。
challenge：测试现有需求、分解或设计是否存在遗漏和风险，但不改变其已确认的产品目标。详见 references/challenge.md。

这些是技能级别的语义模式。它们不调用也不要求使用平台的原生计划模式、EnterPlanMode 或强制性的探索/计划代理。仅在独立有用且符合用户约束时使用原生模式。

对于单根本原因且无需委派的任务，直接使用控制循环。阅读 references/spec-driven.md 来塑造规格说明（需求、验收场景、契约）。在现有代码库中分解前，阅读 references/context-grounding.md。当存在多个候选任务、服务/领域边界、调度决策，或存在仓库状态可能导致构建/部署失败时，阅读 references/decomposition.md。关于验收证据标准，阅读 references/verification.md。当工作涉及多个任务、代理、会话或平台时，阅读 references/ledger.md。当执行时重写、删除或将变更波及到多个现有制品，或写入外部系统时，阅读 references/mutation.md。工作运行示例：references/examples/feature-example.md 和 references/examples/bug-example.md。

在 diagnose 模式下，报告观察或复现的失败、已确认的根本原因和证据、未验证项、影响以及建议的修复路径。除非用户单独授权 execute，否则在此停止。

控制循环

确立目标、范围、验收标准、约束和已确认的代码事实。首先定位未知因素（references/context-grounding.md），然后将结果表达为规格说明——需求、验收场景和契约（references/spec-driven.md）。调研可发现的事实；仅向用户询问对范围、验收或方向有实质性影响的决策。在分解之前，查阅能力知识库（见 references/knowledge-base.md）以获取与目标相关的现有技能和同领域对比；优先重用或导入已知能力，而非从头研究，并将所选能力记录在清算账本中。
- 如果存在以往项目经验，请阅读它们（references/experience.md），并将其视为待验证的候选事实，而非绝对真理。
- 对于非平凡的构建，在规格说明之后生成技术设计（references/tech-design.md）——架构、详细设计、备选方案、横切关注点——并将制品持久化到 docs/ 布局中（references/deliverables.md）。
对于报告的错误或失败，在声称根本原因之前，尝试进行适当的本地复现。将观察到的失败与报告进行对比。在复现成功或得到同等直接证据支持之前，将根本原因声明标记为假设，并说明哪些内容尚未验证。
选择一个主分解轴，创建有边界的任务。推导共享契约，在依赖或并行工作之前冻结它们（references/spec-driven.md）。明确记录依赖关系和跨任务契约。将生成的任务组镜像到分阶段待办列表（见进度表面）。
只保留一个控制代理。控制者拥有清算账本、分派决策、审查状态、重新规划和最终集成的控制权。
仅分派具有完整契约的任务。在首次分派前，阅读 references/agent-contract.md。在向本地工作树之外的任何系统分派写入操作之前，执行以下目标系统预检。
将工作结果接收至 review，根据验收证据标准（references/verification.md）验证其证据和边界，然后将其标记为 completed，或附带具体发现将其退回。对于批量或外部变更，通过独立的回读和结构差异进行验证，而不依赖工具报告的成功计数。
在发现、失败或范围变更后，重新计算受影响的依赖关系。重做受影响的最小分支。
只有当任务级检查、跨任务契约和每个验收场景全部通过时，才声明请求完成；端到端门控在 references/verification.md 中定义。完成后，将任何符合条件的项目特定经验追加到经验日志中（references/experience.md）。基于此次运行改进技能本身是一项独立的选择加入操作——仅在经验通用且反复出现时提供，且仅在用户选择时应用，绝不自動执行（见 references/experience.md）。

进度表面

保持一个可见的分阶段待办列表与清算账本同步，使用户看到阶段和步骤级别的进度，而不仅仅是文字描述。清算账本是详细的真实来源（依赖、范围、契约、证据）；分阶段待办列表是其进度视图。

每个分解组初始化为一个阶段，然后是一个最终验收阶段（对于错误流程，为 对照 / 修复 / 验证；对于功能流程，为先有功能组，然后是 全量验收）。每个项目是一个有边界的任务或验证步骤，用 5-10 个词描述为成果。
使用平台的原生任务列表驱动，而非手动格式化的树。在 Claude/omp 上使用 todo 工具：使用 init 及 list: [{phase, items}]，然后对每个项目使用 start/done。在 Codex 上使用其 plan/update-plan 机制。
从实际进展推进状态：当任务被分派时标记项目为进行中，仅在控制者在清算账本中记录 completed 后才标记为完成。阶段计数（N/M）因此追踪已验证的验收情况，而非分派情况。
保持两者一致：一个待办项对应清算账本中的一个任务或验证步骤。在重新规划时同时重新计算两者。
在 analyze 和 diagnose 模式下，阶段是调研或诊断步骤，完成它们不会修改代码。

可交付制品

将可发布的文档与内部编排状态分开：面向读者的文档放在 docs/ 下（docs/prd/ 规格说明，docs/tech-design/ 设计）；清算账本、计划和经验是内部工作状态，放在 .ai-work/ 下——绝不放在 docs/ 下，并且对于可发布的项目应纳入 .gitignore。详见 references/deliverables.md。

对于任何非平凡的构建，在规格说明之后、execute 之前生成技术设计：架构、详细设计、考虑的备选方案和横切关注点（references/tech-design.md）。对于仅需规格说明加任务列表即可的单根本原因修复，可以跳过。

在移交之前，自我审查每个生成的 Markdown 可交付物：重新阅读并确认其渲染效果与读者看到的完全一致——结构完整，围栏代码块/Mermaid 图表实际可解析（渲染它们，而不是用眼睛扫过），链接可解析。解析/渲染失败是现在需要修复的缺陷。详见 references/deliverables.md 和 references/verification.md 中的 Document / diagram artifact 行。

当可交付物是一个独立项目时，“完成”包括具备可发布性：一个 README（是什么/为什么、前提条件、安装、使用示例、配置、架构、测试、限制、许可、免责声明）、一个 LICENSE 文件和一个排除了构建输出、秘密和 .ai-work/ 的 .gitignore。验证 README 中的命令实际可运行。详见 references/deliverables.md。

目标系统预检

在向本地工作树之外的任何系统分派写入操作之前——例如 wiki、工单系统、数据库或远程 API——预先验证：

写入权限以及计划操作所需的确切范围，包括如果计划需要删除或移动操作；
速率限制以及失败是否静默；选择安全的并发策略和重试或回退机制；
结果是否可以被读取回来进行验证。

在此处发现缺失的能力，而不是在批量处理中途。如果所需的权限或范围不可用，则将其视为阻塞项：确切说明缺少什么以及能够解除阻塞的最小授权，并在此停止，不进行任何部分应用。

平台路由

对于 Codex，阅读 references/codex-adapter.md。
对于 Claude，阅读 references/claude-adapter.md。
在两者之间转移控制权时，在旧控制代理停止分派之前，写入并确认交接快照。
Trellis 是可选的。仅当其升级信号适用或用户请求时，才阅读 references/trellis-adapter.md。

不可协商的边界

以下是不论措辞如何都不得违反的不变量；保持少而精。在本技能的其他地方，使用 RFC 2119 关键词（MUST / SHOULD / MAY，仅在大写时有意义）来分级规则强度，并保持克制：保留 MUST / MUST NOT 用于正确性或防止危害，将偏好性表述作为 SHOULD / MAY。每个禁止性规则都搭配一个“应做此事”的正面替代：对于代理，纯负面规则不可靠（它们往往会引发所禁止的行为），因此少量硬边界加上正面默认行为是健壮的形式，而非一个不断增长的强制性清单。

不得将任务树位置视为执行依赖。
不得让工作者静默地扩展其写入范围。
除非依赖已解决、写入范围不重叠、共享契约已冻结且验证独立，否则不得并行运行写入代理。
工作者可以提交工作供审查；只有控制者才能将其标记为已完成。
在修改现有制品时，不得清空并重写任何任务既未创作也无法重新生成的内容；进行就地插入或修补，使用可安全重新运行的标记进行标注，并通过独立回读进行验证。
不得断言一个超出其已验证来源的派生值——例如分类、标签、摘要、风险评级或建议；将未经验证的派生标记为如此，而不是编造一个值。
不得仅仅因为存在 .trellis/ 目录就激活 Trellis。
analyze 和 diagnose 是只读的。平台的权限或原生计划批准并不授权编辑。只有在用户单独指示实现时，才进入 execute 模式。
不得在未按读者视角消费可交付物的情况下移交——渲染文档，并从仓库根目录原样运行 README/使用命令。（应做此事：渲染图表，运行命令，在移交前修复中断。）
在没有可运行的 README、LICENSE 和 .gitignore，或者提交了内部的 .ai-work/ 制品时，不得认为独立项目已完成。（应做此事：发布可发布的脚手架；将编排状态排除在仓库之外。）

需求编排器