编排完整的 x-workflow
当前会话是父协调器。在调度之前，请阅读 references/workflow.md。根据需要阅读其他三个技能；它们的阶段语义和共享合同适用于每个工作者。不要因为请求中的名称拼写错误而运行不相关的 kauto 工作流。
准备与分配
- 确定请求的结果、约束和范围。找到 Git 根目录、当前分支/HEAD、适用的指令和脏/索引状态。需要 Git；停止而非静默初始化。选择一个干净的、独占的任务检出点。保留不相关的工作；可能时隔离，否则请求所需的处理方式。在单独分支上工作时，不要承诺在用户的原始分支上提交。
- 分配任务 ID 和规范的工件路径。规划者可能会提出多个有界单元加上共享设计；父协调器集中分配额外的 ID，并保持对完整请求的覆盖。
- 发现可用的委派工具。首先使用子会话；仅当不可用时才使用子代理。遵循主机的委派/生命周期规则。不要假设工具名称或在父会话中用另一条消息伪造新的上下文。如果两种机制都不存在，则停止并解释独立的编排工作流不可用；不要静默地在原地运行每个角色。
- 除非用户或适用的指令选择了模型/框架/工作量，否则继承它们。使用新的审查者上下文，而不是包含作者私人推理的分叉。审查者可以看到请求、代码、工件和先前的公开发现，但不能是编写了审查过的计划/实现的那个工作者。
- 使用共享合同捕获父会话的来源。在其交接中请求每个工作者的协调器 ID 和本地对话 ID；在工作日志中保留它们，而不仅仅是临时的工作者名称。
分发明确的阶段简报
每个工作者获得：目标、相关用户约束、技能和调用、任务 ID、确切的检出点和起始 HEAD、输入/输出路径、允许的编辑、提交权限、检查要求和现有的验证证据、预期的交接（包括会话来源）和停止条件。 包括结果将用于何处。提供计划或请求，而不是工作者应该独立验证的假设。
阶段在共享检出点中是顺序进行的。默认为一次一个写入者；只有在单元的文件和依赖关系真正独立且集成/审查所有权明确的情况下，才同时运行独立的单元。在下一阶段之前，确认每个子会话的实际目录/HEAD；按照共享合同所述，集成隔离工作者交接的提交。切勿删除未转移的结果。
规划 → 审查计划
- 使用
xplan <request>启动一个规划者，且不授予生产代码编辑权限。规划者研究棘手问题，确定工程决策，并返回准备好的计划、小任务简报或具体的障碍。 - 检查返回的工件和覆盖率。将计划/共享设计记录提交为
plan，然后将每个执行计划使用xreview plan .agents/plans/ID.md发送给独立的工作者。将其审查轮次提交为plan-review。 - 对于发现的问题，向规划者返回一个具体的修正任务。提交修订后的计划。父协调器对照发现和相关证据检查修正，记录其处置以及最终计划/指导信息，并在没有剩余重大缺陷时继续。这是父协调器的执行决策，而不是声称审查者批准了未见的修订。不要将每次修订都发送到另一轮完整的计划审查。额外的独立评估需要特定的、重大的问题，而先前的审查和修正检查无法解决；指明该问题并仅请求所需的评估。措辞、元数据和常规修正不能作为重新开始审查的理由。共享设计的编辑需要检查受影响的单元，而不是自动为每个单元启用另一轮审查。
- 对于真正微小的工作，保留规划者边界明确的简报用于 xwork，跳过单独的计划/审查工件；后续的工作日志会记录原因。不要通过将大型未解决的分配称为简报来绕过规范化。
- 拆分请求在完成其第一个单元后并未结束。在共享设计中跟踪单元依赖关系，按顺序执行每个请求的单元，并在依赖项发生更改时重新检查共享接口/中间状态。
实现 → 审查实现
- 使用
xwork .agents/plans/ID.md分发一个实现者，或者使用显式的小任务简报。提供已接受的审查/计划和关联的指导信息。仅授权任务持有的代码和日志提交。xwork 记录一个固定的 Code 基础，提交经过验证的代码，然后使用已知的 Code HEAD 单独提交其日志。 - 对照 Git 和记录的测试输出检查交接；子会话的“完成”消息并不能证明正确的树、完成的检查或已提交的文件。解决集成映射并在最终日志中使用任务检出的哈希值。
- 使用
xreview work .agents/work/ID.md启动一个独立的审查者。提供请求、计划/简报、完整的 Code 基础..Code HEAD 范围、工作日志和相关的仓库指令。审查者阅读代码和测试，而不仅仅是日志，并在不修复实现的情况下编写审查。将其审查提交为work-review。 - 传递记录的 Code HEAD 的可检查的检查结果。首先要求审查者检查/重用该证据，并在选择新的检查之前识别任何剩余的不确定性。不要对相同的未更改代码例行请求重点重复、完整包运行和仓库测试套件。显式的全新运行要求仍然适用。
- 将可操作的发现发送给实现者。实现者提交修复和附加的日志条目，保留原始基础。将完整的更新后的更改返回给独立审查者；先前的发现需要解决证据，而不是一张新的空白检查清单。保留所有审查轮次。审查者可以在独立于作者的情况下被重用；没有一个角色可以批准它刚刚编写的代码。
- 如果实现暴露了无效的设计，在继续之前将决策路由回规划者和父协调器。对受影响的依赖单元应用相同的修正检查；额外的独立评估需要特定的重大不确定性，而不仅仅是更改后的计划信息。不要让 xwork 静默扩大范围或将困难抉择留到编码时。
解决发现并诚实完成
无需常规确认即可继续，但当意图、范围、权限或重大的权衡确实需要用户时，请询问。在所需的工具/检查不可用或存在争议的决策时停止。在普通维修取得进展时继续；如果一轮重复了相同的失败方法，需要用户决策，或者超出明确的预算，则停止并报告未解决的证据，而不是生成无限的审查循环。切勿为了完成周期而接受缺陷。
在成功之前，父协调器验证：
- 每个请求的执行单元都已实现，所需的检查确实通过了，并且其最终代码已获得独立的已接受的工作审查。
- 在单元审查过的 Code HEAD 之后的每个代码/测试/配置更改都被后续单元在集成任务检出点上的已接受审查范围所覆盖，或者重新经过验证和工作审查。仅工作流记录变更无需重新审查代码。解释所有提交/差异，而不仅仅是匹配的路径名称。集成冲突修复和违反早期合同的行为需要重新进行检查/审查；后续接受的单元不会自动豁免它们。
- 工作日志包含已接受的计划/简报、固定的基础、最终审查过的 HEAD、实际提交、父/工作者本地对话 ID（或显式的不可用原因）、运行/重用的验证证据和审查路径。将它们设置为
complete并提交剩余的任务持有记录为complete。 - 所有任务持有的更改和新记录都提交在报告的分支上。使用 Git 验证，保留不相关的工作，不要推送到或自动合并到不同的分支。原始代码 HEAD 不必等于最终的 HEAD，因为后续提交包含记录或其他独立接受的单元。
- 在结束移除其分支/工作树的会话之前，保存每个子会话的会话来源并集成/保存每个结果。留下一个可访问的已提交结果并遵循主机的清理规则。失败的周期报告部分提交和障碍，而不是成功。
返回简洁的结果、任务 ID、工件路径、分支和最终提交 ID、检查、审查结论以及任何剩余的限制。父协调器拥有此验证和最终报告的所有权；不要仅仅拼接工作者摘要。