Arasz/ai-badger

任务编排技能

将单个待办任务作为一个独立的、可跟踪 token 消耗的工作单元来运行。高杠杆思考——规划和最终质量把关——被委托给高推理能力的模型；实施模型执行具体工作；编排会话整合并跟踪所有内容，以便死掉的会话可以恢复。

所有项目具体信息都来自 .ai-badger/config.json——绝不硬编码构建命令、角色名称或仓库。跟踪数据存放在 .ai-badger/task-tracking/ 目录下（已被 gitignore）。脚本存放在本技能的 scripts/ 目录中。

配置协议（先读取）

从 .ai-badger/config.json 读取：

• commands.build / commands.test / commands.lint —— 阶段 3 的验证命令。
• personaRouting —— 将工作类型映射到已配置的角色设定；驱动阶段 2 的调度。
• sourceControl —— 平台 + 仓库/项目 URL；控制源代码扩展的启用（PR 流程、审查循环、议题/看板集成）。如果 sourceControl.platform == "github" 并且存在 repoUrl，则该技能的 extensions/github/ 片段被激活——请按照其指导进行下面的 PR/审查循环步骤。否则，在本地提交并根据你的平台进行集成。

模型与委托策略

将高推理能力用于计划、分解和审查——而不是用于编写实现。编排会话通过显式委托获得这些推理结果，而不是假设自身的模型能力。

• 委托给高推理能力的代理（阶段 1 中的规划/分解；阶段 3 中的最终正确性 + 架构把关）。给此类调用的描述添加前缀，以便一眼看清模型。
• 委托给与工作匹配的实现代理，使用来自 config.json 的 personaRouting 中的角色设定。对于代码，必须进行 TDD。
• 委托给廉价模型执行重复性机械工作（文档/注释更新、常规重构、测试补充）。
• 编排会话直接执行的操作： 获取任务、读取文档、记录 token 使用情况、每个子代理的轻量级完成检查、运行配置的构建/测试，以及在质量把关阶段发现的微小修复。

子代理提示必须自包含：范围、验收标准、要读取的文件/文档、项目的 TDD + 代码风格规则（指引它们查看 CLAUDE.md），以及需要报告的内容。运行相互独立的子代理时并行执行。

已知显示问题——不要误判为调度错误： 实时代理面板中每个任务的 model 字段（以及任何读取它的自定义状态行）可能会暂时显示过时的值——例如，显示父会话的模型，而实际分派的子代理使用了不同的 model 覆盖。根本原因：面板字段来自一个异步的实时状态流，与 resolvedModel 的代码路径不同（resolvedModel 是 Claude Code 在调用完成时写入会话转录的工具结果元数据中的）。转录是事实来源；面板是可能滞后的快照。如果对某个分派实际使用的模型有疑问，请在会话的 .jsonl 转录中搜索 description 匹配的 Agent tool_use，并检查其配对的 tool_result 的 toolUseResult.resolvedModel，而不是相信面板。除非转录本身显示了错误的 resolvedModel，否则不要花时间重新调查此问题作为调度代码问题。

缓存感知调度： 每个代理的请求前缀都包含你项目的始终加载的上下文（CLAUDE.md/AGENTS.md 等效指令、.ai-badger/state.json 以及你项目在每个轮次加载的任何其他文件）——在一个任务内保持它们的字节稳定性（绝不在任务中途重写它们；完成协议在任务之间写入状态），这样它们可以作为缓存读取（大约十分之一的成本），而不是新的写入。子代理缓存是独立的冷启动，TTL 大约为 5 分钟，因此：对于一组相关的步骤，优先使用一个多轮交互的子代理而不是许多一次性的调度（摊销冷启动成本），并且在任务内使用 /rewind 而不是 /compact 来进行回溯（rewind 重用缓存前缀；compact 需要支付一次新的摘要写入）。仅在任务边界（阶段 0）进行 compact。token-usage.json 记录主会话的 cacheEfficiency（cache_read ÷ (cache_read + cache_creation)）；低比率意味着前缀在频繁变动。无法获取每个子代理的缓存拆分——完成通知仅暴露 total_tokens。

如果你无法生成子代理（你本身作为子代理运行，或者 Agent 工具不可用），则直接在会话中利用任何可用的模型执行工作——工作流的跟踪和完成协议仍然适用，但在摘要中注明由于无法进行高推理能力委托，规划/审查的执行力度有所降低。

阶段 0 —— 上下文清洁

1. python3 scripts/task_tracker.py status。如果前一个任务未完成，则完成或暂存它。
2. 确认 .ai-badger/state.json 反映了最后一个已完成的任务；如果不符则进行修复。
3. 如果本次会话有大量历史记录，告知用户进行 /compact（或开启新会话）并在干净上下文中重新调用 /task <id>，然后停止——除非是自主模式。

阶段 1 —— 启动

1. 解析任务（一个议题 URL，或作为范围/标题的自由文本；如果源代码控制扩展已激活，则通过它交叉验证项目看板）。阅读引用的文档。
2. 注册：python3 scripts/task_tracker.py start <taskId> --title "<title>" --branch task/<taskId>-<slug>。
3. 请用户将会话重命名为与任务匹配的名称（自主模式下跳过此步骤）。
4. 创建/切换到任务分支。
5. 规划：将分解工作委托给高推理能力的代理（architect 角色设定），为其提供任务正文和文档摘录。使用其计划来驱动阶段 2。

阶段 2 —— 执行

1. 根据 personaRouting 分派实现子代理。指示每个代码子代理首先编写失败的测试（TDD）。
2. 在完成后记录每个子代理的 total_tokens： python3 scripts/task_tracker.py subagent <taskId> <total_tokens> --description "<其工作描述>"。
3. 检查每个结果的衔接处（是否匹配计划？是否满足验收标准？）。如果不是重写，而是发送后续修改请求，除非修复只有几行。
4. 按工作包进行提交和推送（小提交）。如果源代码控制扩展已激活，尽早根据 extensions/github/ 创建草稿 PR。

阶段 3 —— 质量把关

亲自运行配置的 commands.build 和 commands.test 并捕获输出。然后将审查委托给高推理能力的代理（code-reviewer 角色设定），提供差异、验收标准、相关架构文档以及构建/测试输出。要求其判断实现正确性（逻辑、边界情况、测试的诚实性）和架构（层次纯度、与文档的一致性）。修复发现的问题（小问题自行修复，重大修改通过子代理），重新运行构建/测试，然后继续。

阶段 4 —— 完成协议

1. 如果源代码控制扩展已激活，按照 extensions/github/ 的指导进行 PR 就绪、审查轮次循环和压缩合并。否则根据你的平台进行集成。
2. 更新状态文件： 将已完成任务的精简条目添加到 .ai-badger/state.json 的 completedTasks 列表中，刷新 next/lastUpdated；将详细的注释/决策写入项目的 notes 文件。
3. 如果项目跟踪了 CLAUDE.md，则进行压缩检查。
4. 关闭跟踪：python3 scripts/task_tracker.py finish <taskId>。
5. 请用户为技能评分 0–5：python3 scripts/task_tracker.py grade <taskId> <0-5>（自主模式下跳过/不设置）。
6. 报告任务的 token 成本，并建议在下一个任务前进行 /compact 或开启新会话——这是默认的结束方式。已授权的自动继续（替代路径，仅在满足可观察条件时：auto-wm 技能的自主/协作模式已激活，或用户的原始调用明确指示继续到下一个任务）：阶段 5 完成后，根据阶段 0 的建议进行压缩，读取 .ai-badger/state.json 的 next 字段中的下一个任务（或已配置的待办事项源中下一个未认领的项），并为此任务再次调用本技能。如果两个条件都不满足且没有用户可用，则开启一个新会话并告知用户重新调用该技能，以便下一个任务在干净的上下文中开始。

阶段 5 —— 文档差距审计

集成完成后，委托一个文档审计代理（工作树隔离）检查 CLAUDE.md 和项目的文档是否与合并后的代码一致，修复小的偏差，并报告需要决策的差距。

恢复

task_tracker.py 记录每个任务的会话 ID 和恢复命令；一个恢复定时器监控停滞的会话。如果你在恢复的会话中中途醒来，首先运行 python3 scripts/task_tracker.py reattach <taskId>，然后继续。

扩展： 源代码控制的 PR/议题/审查循环行为定义在 extensions/<name>/ 中，并且只有当 config.json 提供所需数据时，welcome-ai-badger 才会嵌入这些内容。上述基础技能保持平台和栈的中立性。