Standup summary

Skill KhaledSaeed18/dotclaude/.claude-plugin/plugins/productivity/skills/standup-summary

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".From its SKILL.md

Install

npx -y skills add KhaledSaeed18/dotclaude --skill standup-summary

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, 795 tokens by cl100k_base, as published. Nobody here has run it

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:

# Commits by the author in the window, all branches
git log --all --author="<email-or-name>" --since="<window>" \
  --pretty="%h %ad %s" --date=short

# Branches touched recently
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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most pr commit review skills give in 795 tokens

Counted across 1,055 of the 1,911 authors here whose files we hold, read 2026-09-06

Use conventional commit message formatin 150 of 1055, across 145 files
Announce skill usage at startin 78 of 1055
Use imperative mood for commit descriptionsin 54 of 1055, across 51 files
Add directory to gitignore if not ignoredin 52 of 1055, across 41 files
Use imperative mood for commit subjectin 52 of 1055
Run tests to verify clean baselinein 42 of 1055, across 32 files
Push branch to originin 40 of 1055, across 38 files
Verify worktree directory is ignored before creationin 39 of 1055, across 32 files
Delete branches after mergingin 38 of 1055, across 30 files
Create worktree with new branchin 37 of 1055, across 32 files
Wrap body text at 72 charactersin 36 of 1055, across 34 files
Auto-detect and run project setupin 35 of 1055, across 27 files

Said here and by no other author read

reconstruct updates from git and issue tracker evidence
translate mechanics into outcome-focused sentences
group related commits into single narrative units
sort items into done, in progress, blocked, and next
keep updates under ten lines
reference PR and issue numbers parenthetically

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.