bb-steward

BB 管家

这是流程类 Skill，仅在用户显式调用 $bb-steward 时进入。管家是会话里的编排者：自己决定下一步、把具体工作派给 BB 子线程、收通知后汇总，并把跨会话必须保留的信息写进工作簿。

分工是判断留下，调研和体力活派出。要懂用户意图和来龙去脉才能做对的判断（范围、归属、取舍、做到什么程度）由管家 自己做。判断要用的事实，几条命令能查完的管家自己查；要大量阅读或排查的，例如读代码和文档、上服务器翻日志找 bug 线索、收集舆情和外部信息，派只读调研线程：只给问题、不附管家的猜测，要它带证据交回事实和可能原因，不替管家定怎么做， 不改东西。代码和文档改动、长时间运行、可并行的独立任务、独立审查和经手秘密的工作也 派出去。每转一手都会丢细节，子线程摘要里的错误又和正确结论写得一样笃定，所以判断不外包，验收不只看摘要。

开始前加载 $bb-model-routing，派发、难度归类、任务模板和等待规则全部以它为准，本 Skill 不重复。

与 large-task 的分工

管家处理"跨会话、但不值得拆 Story"的目标：人在环路，Agent 自己拿主意，没有脚本状态机。目标大到需要 Story 拆分、无人值守连续执行时，转 $large-task-planning 建计划，再由 $large-task-orchestrator 执行；工作簿的路线 进 SPEC 的交付路线，关键决策进 SPEC 的已定取舍，用户待办进 STATUS 的需要关注，然后删除工作簿。两套不并存。

工作簿

每个目标一份，提交进目标仓库，默认路径 docs/steward/<topic>.md；项目 AGENTS.md 另有指定时以项目为准。 工作簿、项目 AGENTS.md 里指向它的那一行（"存在时先读"）以及项目文档索引的登记，都算工作簿本身，由管家 直接写并按项目约定提交，不派子线程；它们让不经本 Skill 进入的会话也能接上。其余改动仍派出去。子线程只在 "先读"里读工作簿。格式见工作簿模板。

工作簿只有三段，各自的准入判据：

• 路线：阶段清单和当前位置，一个阶段一行，标出已完成、进行中、未开始。项目已有路线图（issue、计划文档） 时只放链接和当前位置，不复制阶段。任务清单、"做了什么"、子任务矩阵、实时配额计数和中间 commit SHA 不进这里，那是项目 Issue、派发文本和 git log 的事。
• 关键决策：两条同时成立才记：下个会话不知道这条就很可能重做或翻案；从代码、git、既有文档推不出来。一条 一行，写决定、日期、原因、影响范围。新决定覆盖或收窄旧决定时，直接原地更新该行，不按时间流水账追加互相冲突的 旧条目。项目已有决策登记制度（决策地图、ADR）时只放链接，这段剩下的通常只有管家与用户之间的操作约定，例如 哪些事用户亲自裁决、合并前固定派什么审查。子线程回复里"自行引入的决定"逐条过这个判据，绝大多数随线程消亡。
• 用户待办：只有用户本人能做的事，每条写做什么、为什么只能用户做、挡住了哪个阶段、提出日期、状态。 不挡任何阶段的事"挡住"栏写"不挡"，排在挡阶段的后面。待办只有待办和已完成两种状态；用户说做完或管家 验证到即改为已完成，保留原行。

工作簿是人读的状态页，不是实时运行日志。只在阶段完成、路线调整、关键决策变更或用户待办状态变更时更新并提交工作簿； 子线程启动、中途进度、配额消耗计数不改工作簿。每次修改工作簿后运行确定性门禁校验结构与一屏容量（三段标题固定、非空行 $\le 45$、单行可见字符 $\le 180$、路线禁塞表格）：

python3 scripts/steward_workbook.py --mode check --file <工作簿路径>
python3 scripts/steward_workbook.py --mode should-commit --file <工作簿路径>

一段超过一屏或 --mode check 报错就说明准入判据没守住，先删再加；--mode should-commit 返回 should_commit: false 时说明仅有括号内微状态描述调整，不单独生成 git commit。

会话开始

1. 读工作簿；读 bb status，检查分支、git status --short、git worktree list。没有工作簿时先建：从 bb status 的子线程、当前会话上下文、git log 和项目既有计划恢复路线位置和已埋的用户待办，再继续。
2. 从路线的当前位置决定下一步；遇到用户依赖时按下节处理。