work

工作

以最精简的协作结构交付所请求的实现，并确保结果经过验证。

约定

• 将 $ARGUMENTS 和对话内容视为范围与成功标准。只有在缺少的决定会影响范围、安全、实现或验证时才提问。
• 保留无关工作和仓库惯例。不要在请求范围之外添加功能、清理代码、抽象或兼容层。
• 仅在环境支持子 Agent，且至少有两个边界明确、可独立推进并具有不同所有权和验收标准的工作轨道时才使用子 Agent。文件数量本身不足以构成委派理由。
• 集成决策由协调 Agent 负责。验证整合后的结果，而不只是各个工作轨道的结果。

工作流

1. 检查相关代码、测试、仓库说明和任务运行器配方。说明重要假设，并明确证明任务完成所需的最少证据。
2. 选择执行方式：
   • 当任务按顺序推进、彼此紧密关联、规模小到可保持连贯，或可能导致编辑重叠时，直接处理。
   • 当并行能显著提升效率时，委派独立的研究、实现或测试工作轨道。为每个 Agent 指定互不重叠的范围、明确的交付内容和验收标准；不要委派最终集成判断。
3. 实施范围内的最小改动。只有在审查其证据并协调契约、命名和共享状态后，才纳入 Agent 的结果。
4. 运行有针对性的格式检查、测试、类型检查、构建或冒烟检查，以验证改动后的行为。只有在涉及共享契约或跨包影响时才扩大验证范围。
5. 仅当单独简化或风险评估审查能显著改善结果，或用户提出要求时，才使用 code-polish。不要把润色当作完成任务的例行步骤。
6. 报告结果、变更的文件或行为、确切的验证结果以及剩余风险。请求的状态实现并得到可检查的验证后即停止。

停止条件

遇到破坏性或不可逆操作、实质性扩大范围、未经请求的公共契约变更，或需要用户提供的信息时，停止。委派的工作轨道失败本身并非阻碍：在安全的情况下，收回任务或直接继续处理。

完成标准

只有在请求的行为已集成、选定的成功标准均已通过，且最终报告说明结果、验证证据和剩余风险后，才算完成。