# Catchup > Summarize recent development activity in the current repo so the user can catch up on what others have changed in the last hours/days/weeks. Picks the window automatically — since the user's last commit, or else the larger of the last 5 commits vs the last 7 days — and produces a grouped, prioritized summary (themes, risky changes, files touched, who did what). Trigger when the user says things like "what did I miss", "catch me up", "what's new on this branch", "what changed since I was out", or after returning from time off. - Skill: `iopsystems/catchup` (Agent Skill) - Install (CLI): `npx skillmds@latest add iopsystems/catchup` - Raw SKILL.md: https://api.skillmd.com/api/skills/iopsystems/catchup/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: iopsystems (https://skillmd.com/u/iopsystems) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/iopsystems/catchup --- # Catch Up You are helping the user catch up on recent development activity in the current repository. Produce a grouped, prioritized summary of what has changed since they last engaged, so they can resume work with context. ## Operating rules - **Do not modify the repo.** This is a read-only briefing — no edits, commits, branches, or pushes. - Work from the current working directory. If the user names a different repo or path, `cd` into it (via a shell command you run) before starting. - Prefer running git commands via the Bash tool. Use `--no-pager` or pipe through `cat` so output isn't paginated. - Summarize; don't dump. A raw `git log` is not the answer — the user can run that themselves. - If the range is empty ("nothing has changed since your last commit"), say so plainly and stop. Do not invent filler. ## Step 1 — Determine the identity Find the user's git identity, since you need it to detect their own commits. ``` git config user.email git config user.name ``` If both are empty, note it and fall back to the "no prior commits" path in step 2. ## Step 2 — Pick the range Use this decision tree, in order: 1. **Since the user's last commit.** On the current branch, look for the most recent commit authored by the user's email (preferred) or name: ``` git log -1 --author="" --pretty=%H ``` If a commit is found, the range is `..HEAD`. Report the SHA and date so the user can sanity-check. 2. **No commits by this user on this branch.** Fall back to the *larger* of these two windows, by commit count: - The last 5 commits: `HEAD~5..HEAD` (guard against shallow histories). - The last 7 days: `--since="7 days ago"`. Run `git rev-list --count` for each and pick whichever is bigger. Ties go to the 7-day window (more time context is usually more useful). 3. **Shallow or tiny history.** If the repo has fewer than 5 commits total, just summarize everything and say so. Always state the chosen window at the top of your summary, e.g. "Showing 12 commits from the last 6 days (since your last commit `a91187c` on 2026-04-11)." Include both the commit range and the calendar range when possible. ## Step 3 — Gather the data Use a compact log format plus per-commit stats. Example commands: ``` git log --no-merges --date=short \ --pretty=format:'%h%x09%an%x09%ad%x09%s' git log --no-merges --stat --pretty=format:'%h %s' git shortlog -sn --no-merges ``` For large ranges (roughly >30 commits), also pull: ``` git diff --stat ``` …to see aggregate file churn, and cap per-file detail to the top ~15 churned files. Skip merge commits from the narrative but note if a notable merge (e.g. a feature branch landing) happened. Don't re-summarize each individual commit that was already part of a squashed merge. ## Step 4 — Group and prioritize Don't list commits one-by-one unless there are fewer than ~8. Instead, organize by **theme**, not by chronology: - Group commits by area/feature (infer from paths, subject lines, and commit bodies — e.g. "skill loader", "MCP transport", "build setup"). - Within each group, note the intent in one line, cite the 1–3 key commits with short SHAs, and name the author(s). - Surface **high-signal** items first: 1. Breaking changes / API changes / schema or migration changes. 2. New features or new public surfaces. 3. Notable refactors that touch many files. 4. Bug fixes that matter to the user's current work. 5. Test, CI, docs, and chore work — last, condensed. - Flag anything that looks like it might collide with likely in-flight work (e.g. renamed files, removed functions, config format changes). Call out authors other than the current user by name — the point is to catch up on *others'* work. ## Step 5 — Write the briefing Produce a single markdown briefing with this shape. Keep it tight — aim for under ~40 lines unless the range is unusually large. ``` ## Catch-up: — **Window:** over (). **Authors:** , , ... ### Highlights - <1–5 bullets: the things the user most needs to know> ### By area #### - — , () #### - ... ### Watch out for - Omit this section if there's nothing to flag. ### Housekeeping - ``` End with a one-line suggestion for the next concrete step — e.g. "Pull `main` and re-run `cargo build` before resuming your branch," or "Worth a quick look at `src/transport.rs` before your next change." Only offer a suggestion if something in the diff actually warrants it. ## After the briefing Offer, but do not perform without being asked: - Show the full `git log` or diff for a specific area. - Drill into a specific commit (`git show `). - List files the user's in-flight branch touches that *also* changed upstream (likely merge-conflict candidates). - Compare against a different base (e.g. `origin/main` instead of the local branch tip).