Changes Made
【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode
file.ts:42-55: [what changed and why]
Verification
- Build: [command] -> [pass/fail]
- Tests: [command] -> [X passed, Y failed]
- Diagnostics: [N errors, M warnings]
Summary
[1-2 sentences on what was accomplished]
三个要点值得展开： 1. **Changes Made 必须带 `文件:行号范围`**，便于 Orchestrator / code-reviewer 直接定位 diff，配合“文件级链接”的可审计习惯； 2. **Verification 必须给出具体命令与通过/失败计数**，呼应 Success Criteria 中“fresh output shown, not assumed”的硬要求； 3. **Summary 用 1~2 句话总结成果**，克制、不说废话（呼应 `Dense output over verbose`）。 ## 九、Failure_Modes_To_Avoid：十大失败模式对照表 文档用一整节列出 Executor 最典型的失败模式及“正确替代动作”，可整理为下表，实践中可直接当作反模式清单自查： | 失败模式 | 症状 | 正确做法 | |----------|------|----------| | 过度工程化（Overengineering） | 加入任务不需要的辅助函数、工具与抽象 | 做直接改动 | | 范围蔓延（Scope creep） | “顺手”修相邻代码 | 严守被要求范围 | | 提前完成（Premature completion） | 没跑验证就宣称 done | 总是展示新跑的构建/测试输出 | | 测试 hack（Test hacks） | 改测试来通过，而非修生产代码 | 把测试失败当作实现问题的信号 | | 批量勾销（Batch completions） | 一次把多个 TodoWrite 项标为完成 | 每完成一项立刻勾一项 | | 跳过探索（Skipping exploration） | 非平凡任务上来就写代码，导致不匹配代码库模式 | 永远先探索 | | 静默失败（Silent failure） | 同一错误方案反复重试 | 连续失败 3 次后带全上下文升级 architect | | 调试代码泄漏（Debug code leaks） | 提交里残留 `console.log` / `TODO` / `HACK` / `debugger` | 完成前 grep 被改文件 | 其中“批量勾销”是一条非常具体且易被忽视的纪律：TodoWrite 的每一项必须在**刚完成的那一刻**立即标记，而不是攒到最后一次性打勾——这是为了让进度对 Orchestrator 实时可见，避免“表面进度正常、实则烂尾”。 ## 十、Examples：好的改动与坏的改动 文档用一个“给 `fetchData()` 加超时参数”的任务给出正反对照，是理解“最小可行 diff”的最佳案例： - **Good（示范）**：Executor 加上带默认值的超时参数、把它一路传进 fetch 调用、更新那一个覆盖 `fetchData` 的测试。**共改动 3 行。** - **Bad（反面）**：Executor 新建了 `TimeoutConfig` 类、一个重试包装器、把所有调用方重构到新模式，还加了 200 行代码——范围远超请求。 这个例子把“小而正确优于大而聪明”具象化：凡是不被任务要求的类、包装器与全量重构，都是范围蔓延。同时注意 Good 方案也“更新了那一个测试”——最小改动不等于不动测试，行为变化必须同步到直接相关的测试。 ## 十一、Final_Checklist：交付前的最终自查 文档在收尾处提供了 Executor 宣称完成前的自问清单，翻译并归纳如下： - 是否用**全新构建/测试输出**（而非假设）验证过？ - 改动是否尽可能小？ - 是否避免了不必要的抽象？ - 所有 TodoWrite 项是否都已标记 completed？ - 输出是否包含 `文件:行号` 引用与验证证据？ - 非平凡任务是否在实现**前**探索过代码库？ - 新代码是否匹配既有代码模式？ - 是否检查过残留调试代码？ 这份清单与 `<Success_Criteria>`、`<Output_Format>` 前后呼应，构成“验收标准 → 过程纪律 → 汇报格式 → 收尾自查”的闭环。 ## 十二、延伸到仓库：Executor 的基准测试与契约保障 Executor 不只是一段提示词，仓库还围绕它构建了可运行的基准测试与输出契约测试，可作为验证它“名副其实”的证据链： - **Agent 注册与元数据测试**：[src/__tests__/agent-registry.test.ts](https://link.gitcode.com/i/ef6c05c0016e0ea9279f3fec2765bcb8) 校验各 Agent（含 executor）的注册与元数据；[src/__tests__/load-agent-prompt.test.ts](https://link.gitcode.com/i/76d4baa5c10f428886641146530643f6) 覆盖提示词加载逻辑；[src/__tests__/delegation-enforcement-levels.test.ts](https://link.gitcode.com/i/b5a7ae87fb51748c62e80ee5c46ef346) 验证不同委托档位（含 executor 系列）的执行边界。 - **Executor 专用基准**：[benchmarks/executor/](https://link.gitcode.com/i/8bdeaf0a17c8ef1f08dcaf5f7544a3c9) 目录下包含 `run-benchmark.ts` 运行器、`fixtures/`（3 个 `.md` 任务样本）、`ground-truth/`（3 个 `.json` 期望输出）与 `prompts/`，配合 [benchmarks/shared/runner.ts](https://link.gitcode.com/i/bd4865a482ecfc3798f3c5dc651de5de)、[benchmarks/shared/scorer.ts](https://link.gitcode.com/i/22938d5564c12c5eca153195bb48f2f5) 与 [benchmarks/run-all.ts](https://link.gitcode.com/i/bdbc6fd93fc9f8c8a42d7fdfbf4ea431)，可对 executor 的实现质量做可复现评估。 - **输出契约**：仓库中如 [src/__tests__/advisory-agent-final-output-contract.test.ts](https://link.gitcode.com/i/f0951aec3df4757c530d0962616e50cb) 等测试进一步锁定 Agent 最终输出的结构化契约（对应 `<Output_Format>` 中的 `Changes Made / Verification / Summary`）。 若希望在实践中复用 Executor 的能力，可以直接在 Claude Code 会话中按 [docs/DELEGATION-ENFORCER.md](https://link.gitcode.com/i/36ab28f345e9b27233a686c9a1191af3) 的约定委托： ```text Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="...")【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
