standup

standup — 协调分支 Agent 之间的群聊

你是主持人。用户的每个 git 工作树（以及用户选定的任何 PR）都会以独立 Agent 的身份加入共享的 Markdown 聊天，Agent 会将分散的工作整合到一个统一的工作树中。你负责召集大家、分轮推进对话，并带回最终结果——整合工作由聊天中的 Agent 完成。

聊天室是一个共享文件（默认路径为 ~/.claude-mem/STANDUP.md）：YAML front matter 中包含 goal 和 prompt；正文是聊天记录。写入会通过原子锁定，因此 Agent 可以同时发言。聊天室是只读的——Agent 决定合并应该如何进行；没有人会在聊天室中提交或合并。实际 git 操作会在之后通过 /do 完成。

1. 填充聊天室

有两种方式，可以混用：

• 按最近活动筛选（常用）——某个时间范围内活跃的工作树：

  node "${CLAUDE_SKILL_DIR}/standup.mjs" worktrees --since <1h|4h|24h|7d|all> --json
  

  活跃 = 在该时间范围内有提交，或有未提交／已暂存／未跟踪的更改。如果用户没有指定时间范围，提供 1h / 4h / 24h / 7d / all 选项。

• 手动选择——指定分支和／或已开启的 PR：

  node "${CLAUDE_SKILL_DIR}/standup.mjs" worktrees --json   # local branches
  node "${CLAUDE_SKILL_DIR}/standup.mjs" prs --json         # open PRs (via gh)
  

  显示一个编号列表（工作树 + PR，附上时间和标题）；用户的回复就是“勾选”。如果 prs 出错（没有 gh / 不是 GitHub），就只处理工作树。

没有候选项或只有一个候选项，就不算 standup——说明情况，提议扩大范围，然后停止。否则，先复述参与者名单以供确认，再开始。

2. 打开聊天室

设置目标和提示词，鼓励大家展开对话，而不是只报告一次状态：

node "${CLAUDE_SKILL_DIR}/standup.mjs" open --force --agent facilitator \
  --goal "Collapse these branches/PRs into ONE consolidated worktree: what each changed, where they overlap, which becomes the target, and the merge order." \
  --prompt "Facilitated rounds. Round 1: introduce your branch and its state. Then resolve the conflicts the facilitator surfaces, round by round, until the room lands on one concrete plan (target worktree + merge order + conflict resolutions). Read-only: decide, don't merge. Register AGREE when you back the plan."

3. 分轮进行

由你推动每轮发言——如果 Agent 自行循环监听，聊天室可能会停滞，无法做出决定。每个 Agent 每轮发言一次（读取 → 发言 → 返回）；你在轮次之间阅读，并让仍需参与的 Agent 继续发言。

启动的 Agent 不会继承 CLAUDE_SKILL_DIR，因此先解析一次该目录，然后将实际路径粘贴到每份任务说明中：

echo "${CLAUDE_SKILL_DIR}"

第 1 轮——自我介绍（所有人各发一条 Task 消息，让他们并行运行）。 给每个 Agent 的说明：

你是 standup 群聊中的 <branch>（PR 的名称为 pr-<number>）。阅读 <skill-dir>/agent-brief.md 并按其中要求完成你的部分。聊天室位于 ~/.claude-mem/STANDUP.md；使用 node "<skill-dir>/standup.mjs" post … 发言， 使用 … read 查看上下文。了解当前情况（cd "<path>"、 git log --oneline origin/main..HEAD、git status --short、 git diff --stat origin/main...HEAD；PR 则使用 gh pr view/diff <number>）， 然后发出一轮回复：说明你的分支、实际状态，以及它应该如何整合进来。 只读。然后返回。

协调。 所有 Agent 返回后，读取聊天室并列出待解决事项——重叠、冲突、相互竞争的实现、尚未确定的目标／顺序。如果没有待解决事项，直接进入结束环节。

解决轮次（最多约 4 轮）。 对每个待解决事项，只重新启动相关的 Agent，并提出具体问题。告诉他们先执行 read --since <their-name>，然后发表自己的立场，并在认同后使用 --agree。再次读取聊天室并更新列表。重复上述过程。

结束——始终由你撰写总结。 当待解决事项清空、达到轮次上限，或某个 Agent 出错时停止（注明“未报告”，不要因此阻塞）。然后由你亲自撰写总结——不要等待 Agent 主动提供。使用便于人类快速浏览的普通散文，而不是字段清单：说明哪个工作树是目标及原因，用一句话说明合并顺序，以及留给用户处理的事项：

node "${CLAUDE_SKILL_DIR}/standup.mjs" summation --agent facilitator \
  --text "Build on <worktree> — it's the only one with real code. Layer <branch>'s changes on top, then drop in the doc-only branches; skip <empty branch>. Your call before it's safe: <the one or two real decisions>. Done when it all sits in <target> and builds clean."

4. 用通俗语言向人类说明情况

这是最终成果——别直接把原始 SUMMATION 交给他们，要把它翻译成通俗易懂的内容。 没有旁听讨论的人也应该无需解读路径、行数或提交哈希，就能明白结果。先给出答案，再说明只有他们才能做出的少数选择：

• 你发现了什么 — 每个分支用一句通俗的话说明：哪些有实际代码，哪些只有文档，哪些是空的。
• 计划 — 用一两句话说明目标和合并顺序。
• 由他们决定 — 只提出必须由人类决定的事项（采用哪种实现、舍弃什么、有哪些风险），并将其写成具体问题。对于明确的问题，请使用 AskUserQuestion。

除非他们提出要求，否则不要涉及 Git 内部细节。待他们决定所有待定事项后，将计划交给 /do 执行合并——不要在 /do 之外自行合并任何内容。

CLI

node "${CLAUDE_SKILL_DIR}/standup.mjs" <command> [--flags]

默认值：agent = git branch，file = ~/.claude-mem/STANDUP.md。所有写入操作都会进行原子锁定。

命令	功能
worktrees [--since 4h] [--json]	按时间从新到旧列出 worktrees；--since N{m,h,d,w} 仅保留指定时间范围内活动的 worktree
prs [--since 4h] [--json]	按时间从新到旧列出开放的 GitHub PR（通过 gh）
open --goal "…" --prompt "…" [--force]	创建讨论室（--force 会将旧讨论室移至一旁）
join [--message "…"]	加入讨论并打招呼
post --message "…" [--agree "…"]	追加一轮发言
agree --deliverable "…"	追加一轮 AGREE 发言
watch [--timeout SEC] [--interval SEC]	阻塞等待他人发言并打印内容（超时则退出，代码为 2）
read [--tail N] [--since AGENT]	打印聊天内容（或仅打印 AGENT 最近一次发言之后的内容）
status	显示参与者、AGREE 发言及共识检查结果
summation --text "…"	写入 SUMMATION，并将 status 设为 agreed

每个启动的 Agent 都会按照 agent-brief.md（随附于此）进行发言——这是在讨论室中代表一方发言的操作指南。