How do I install the Standup Summary skill?

Run npx skillmds@latest add khaledsaeed18/standup-summary in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Standup Summary safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Standup Summary?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Standup Summary free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Standup Summary?

KhaledSaeed18 (@khaledsaeed18) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Standup Summary by khaledsaeed18 — Agent Skill

Name: Standup Summary
Author: KhaledSaeed18

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".

KhaledSaeed18 0fc5cdc 2 files · 4.5 KB Updated Sep 17, 2026

File contents

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.

---name: standup-summarydescription: 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 evidencePer repository:```bash# Commits by the author in the window, all branchesgit log --all --author="<email-or-name>" --since="<window>" \ --pretty="%h %ad %s" --date=short# Branches touched recentlygit 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:```bashgh pr list --author "@me" --state all --limit 15 \ --json number,title,state,updatedAt,isDraftgh search prs --reviewed-by "@me" --updated ">$(date -v-7d +%Y-%m-%d)" --limit 10 2>/dev/nullgh 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 altitudeGroup 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 shapeDefault 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.

Frequently asked questions