| name | standup-summary |
| description | Generate a standup or weekly-review update from actual work evidence - commits, branches, PRs, and issues across one or more repositories - grouped into done / in progress / blocked / next, written in plain human sentences rather than commit-message-speak. Use when preparing a daily standup, a weekly review, a sprint update, or answering "what did I work on this week". |
Reconstruct the update from evidence, not memory. Git and the issue tracker already know what happened; the job is to translate that record into the three or four sentences a teammate actually wants to hear, at the altitude of outcomes ("shipped the retry logic for webhooks") rather than mechanics ("bumped a dependency, fixed a typo, refactored a helper").
Step 1: Establish scope
- Time window: since the last workday for a standup, the last 5-7 days for a weekly. Confirm if unstated and ambiguous.
- Identity: the git author to filter by -
git config user.name / user.email in the current repo, unless told otherwise.
- Repositories: default to the current one; ask whether other repos should be included when the user's request implies more ("what did I do this week" often spans several).
Step 2: Collect the evidence
Per repository:
git log --all --author="<email-or-name>" --since="<window>" \
--pretty="%h %ad %s" --date=short
git for-each-ref --sort=-committerdate refs/heads/ \
--format="%(committerdate:short) %(refname:short)" | head -10
When gh is available and the repo has a GitHub remote, add the PR and review picture:
gh pr list --author "@me" --state all --limit 15 \
--json number,title,state,updatedAt,isDraft
gh search prs --reviewed-by "@me" --updated ">$(date -v-7d +%Y-%m-%d)" --limit 10 2>/dev/null
gh issue list --assignee "@me" --state all --limit 15 --json number,title,state,updatedAt
Uncommitted work counts too: git status --short plus the current branch name usually reveals what is in progress right now.
Step 3: Synthesize at outcome altitude
Group raw items into narrative units - a feature, a fix, a review effort - not one bullet per commit. Fifteen commits on one branch are one line. Then sort into:
- Done: merged, shipped, closed. Lead with the user-visible or team-visible effect.
- In progress: open PRs (note if awaiting review - that is a nudge, not filler), the active branch, drafts.
- Blocked / waiting: PRs awaiting someone else, issues waiting on answers, anything the log shows stalled for days. Only include real blockers; do not invent one for symmetry.
- Next: only what the evidence supports (assigned issues, an obvious follow-up) or what the user tells you. Never fabricate plans.
Translate mechanics to outcomes: "fix flaky auth test, bump vitest, retry CI" becomes "stabilized the auth test suite; CI is green again". Keep PR/issue numbers as parenthetical references.
Step 4: Deliver in the requested shape
Default format, ready to paste into chat:
**Yesterday / this week**
- Shipped X (#123): <one-clause effect>
- Reviewed Y's Z PR (#125)
**Today / next**
- Finish A (PR #124, awaiting review)
**Blocked**
- B: waiting on <who/what> since <when>
Match the team's medium when told (Slack markdown, plain text, bullet-less prose). Keep the whole update under ten lines unless asked for the long form; the detail lives in the links. If some evidence source was unavailable (no gh, a repo you could not read), say so in one trailing line rather than silently narrowing the window.
