standup
Compares changes across different parts of a project. It helps consolidate work and create a unified action plan.
What it does
This tool helps teams organize programming work. It gathers information from different code parts (called 'branches' or 'PRs') and helps decide how to combine everything into one place, avoiding conflicts.
When to use it
- ✓When multiple programmers work on different parts of the same code.
- ✓Before merging several code updates into one.
- ✓To quickly understand what has changed across different code versions.
Example of what to ask your AI
“How can we combine the changes from these different code parts into a final version without losing anything?”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The tool creates a 'chat' where each code part 'talks' to explain its changes. A 'facilitator' (the AI) guides this conversation so everyone agrees on a plan to merge everything.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add thedotmack/claude-mem --skill standupOr download just the file:
curl -L https://raw.githubusercontent.com/thedotmack/claude-mem/main/plugin/skills/standup/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
standup — facilitate a group chat between branch-agents
You're the facilitator. Each of the user's git worktrees (and any PRs they pick) joins a shared markdown chat as its own agent, and the agents reconcile their scattered work into ONE consolidated worktree. You convene the room, run the conversation in rounds, and carry the outcome back — the reconciling happens in the chat, between the agents.
The room is one shared file (default ~/.claude-mem/STANDUP.md): YAML front
matter holds the goal + prompt; the body is the transcript. Writes are
atomically locked, so agents speak at once. It is read-only — agents decide
how the merge should go; nobody commits or merges inside the room. Real git
work happens afterward via /do.
1. Fill the room
Two ways, mixable:
By recency (common) — worktrees active in a window:
node "${CLAUDE_SKILL_DIR}/standup.mjs" worktrees --since <1h|4h|24h|7d|all> --jsonActive = a commit or an uncommitted/staged/untracked edit in the window. If the user didn't name a window, offer 1h / 4h / 24h / 7d / all.
By hand — specific branches and/or open PRs:
node "${CLAUDE_SKILL_DIR}/standup.mjs" worktrees --json # local branches node "${CLAUDE_SKILL_DIR}/standup.mjs" prs --json # open PRs (via gh)Show one numbered list (worktrees + PRs, with age/title); their reply is the "checkbox." If
prserrors (nogh/ not GitHub), carry on worktrees-only.
Zero or one candidate isn't a standup — say so, offer to widen, stop. Otherwise echo the roster to confirm before you start.
2. Open the room
Set a goal + prompt that invite a conversation, not one-shot status reports:
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. Run it as rounds
You drive the turns — if agents watch-loop on their own the room can stall with nothing decided. Each agent speaks once per round (read → post → return); you read between rounds and bring back whoever's still needed.
Spawned agents don't inherit CLAUDE_SKILL_DIR, so resolve it once and paste the
real path into each brief:
echo "${CLAUDE_SKILL_DIR}"
Round 1 — intros (everyone, one Task message so they run together). Brief each:
You're
<branch>(a PR ispr-<number>) in a standup group chat. Read<skill-dir>/agent-brief.mdand play your part by it. The room is~/.claude-mem/STANDUP.md; speak withnode "<skill-dir>/standup.mjs" post …, catch up with… read. Get your bearings (cd "<path>",git log --oneline origin/main..HEAD,git status --short,git diff --stat origin/main...HEAD; a PR usesgh pr view/diff <number>), then post ONE turn: your branch, its real state, and how it should fold in. Read-only. Then return.
Reconcile. Once they've returned, read the room and list the open
items — overlaps, conflicts, competing implementations, undecided
target/order. None? Skip to the close.
Resolution rounds (cap ~4). Per open item, re-spawn only the agents it
implicates, with the specific question. Tell them to read --since <their-name>
first, then post their position and --agree if convinced. read again, update
the list. Repeat.
Close — you always write it. Stop when the list is empty, you hit the cap, or an agent errors (note "didn't report," don't block). Then write the SUMMATION yourself — don't wait for an agent to volunteer. Write it as plain prose a human can skim, not a field dump: which worktree is the target and why, the merge order in a sentence, and what's left for the human:
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. Brief the human in plain language
…
FAQ
What are 'worktrees' and 'branches'?
They are like separate copies of the code where programmers work without interfering with each other. 'Branches' are more common; 'worktrees' are a more advanced way to have multiple versions active simultaneously.
What are 'PRs'?
'PR' stands for 'Pull Request'. It's a request for changes made in a 'branch' to be reviewed and incorporated into the main codebase.
Does the tool merge code automatically?
No. The tool helps decide the plan for merging code, but the actual merge is done later, via a specific command ('/do'), by the programmer.
Details
Original description by the author
Facilitate a read-only standup across git worktrees, branches, or PRs to compare changes and produce one consolidation plan.
repo: thedotmack/claude-mem
Popularity
- GitHub stars
- 101k
- Ranking position
- #820
- License
- Apache-2.0
- Updated
- 10/16/2026
Comments
- …
More skills from this repository
Agent Cost Report
Has your agent generate detailed cost reports for its activities. Shows how much was spent on tokens and services.
thedotmack/claude-mem
claude-mem-install
Helps your agent set up Claude-Mem in different environments. Allows choosing between local or remote workers and configuring observation.
thedotmack/claude-mem
mem-search
Lets your agent search past memories. Useful for recalling previous solutions or work from old sessions.
thedotmack/claude-mem
host-observer
Helps your agent respond to Claude-Mem observer tasks. It should only reply with 'skip_summary' or a full XML observation.
thedotmack/claude-mem
Similar skills
benchmark-optimization-loop
Has your agent improve something's speed in a measured way. It tests multiple versions and chooses the fastest one that still works correctly.
affaan-m/ECC
change-impact
Helps your agent analyze the impact of code changes before making them. It compares the planned vs. actual results afterward, covering paths, data, tests, and documentation. Useful for risky or system-wide changes.
affaan-m/ECC
click-path-audit
Lets your agent trace all user buttons and interactions to find bugs. It finds issues where functions seem to work alone but fail together. Useful when bugs persist even after debugging.
affaan-m/ECC