standup

About standup

standup is a coordination skill from the claude-mem project that facilitates a read-only "standup" across a user's git worktrees, branches, and open PRs to reconcile scattered work into a single consolidation plan. The problem it addresses is fragmentation: when work is spread across many worktrees and branches, deciding which becomes the target and in what order to merge is hard. The skill models each worktree or PR as an agent in a shared markdown group chat, with the invoking agent acting as facilitator who convenes the room, runs rounds, and brings back the outcome.

The workflow is explicit. It fills the room either by recency (worktrees with a commit or uncommitted edit in a time window) or by hand (specific branches and open PRs, discovered via git and the gh CLI), using a bundled Node script (standup.mjs) that exposes read/post/open/summation commands over a single shared file (default ~/.claude-mem/STANDUP.md) with atomic locking. It runs Round 1 introductions, then capped resolution rounds where implicated branch-agents post positions and register AGREE on a plan, and finally the facilitator writes a plain-prose summation and translates it for the human. Crucially, the room is strictly read-only: agents introspect via git log, git status, git diff, and gh pr view/diff, decide how a merge should go, but nobody commits, merges, pushes, or deploys inside the room—real git work happens afterward via /do under the human's eye.

It targets developers juggling parallel branches or worktrees who want a structured way to plan consolidation. The git and gh commands it runs are diagnostic and read-only, and the skill repeatedly emphasizes decide-don't-execute discipline.

FAQ

Does standup merge or commit my branches?

No. The room is explicitly read-only—agents introspect and decide how a merge should go, but nobody commits, merges, pushes, or deploys inside it. Actual git work happens afterward via /do under human supervision.

What does it need to run?

Node (to run the bundled standup.mjs), a git repository with worktrees or branches, and optionally the gh CLI for pulling in open PRs. If gh is unavailable or the repo isn't on GitHub, it continues worktrees-only.

How does it choose which branches to include?

Two mixable ways: by recency (worktrees active within a window like 1h/4h/24h/7d/all) or by hand (specific local branches and open PRs). It confirms the roster before starting.

What is the final output?

A plain-prose summation written by the facilitator naming the target worktree, the merge order, and what decisions remain for the human—then translated into an everyday-language brief.

What tools does the skill use?

It declares Bash, Read, Edit, Task, and AskUserQuestion, running read-only git and gh commands and the shared-file CLI to coordinate the conversation.

All Files