agentleFS
cranberriicranberrii/skills-stack/skills/codebase-catch-up/SKILL.md

codebase-catch-up

Skill2 starsChanged 3 months agoMITView on GitHub

Brief me on what changed in this repo since I last looked — summary, review, and what to work on next.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If invoked with an argument — a count N or a ref — this is an explicit lookback: the baseline is git rev-list --max-count=$((N+1)) <tip> | …

    line 16
  2. Distinctive:

    Read the full diff of any commit whose message doesn't make its change obvious.

    line 23
  3. Distinctive:

    Done when: every commit in the delta is assigned to a theme — no "misc" bucket larger than 3 commits.

    line 24
  4. Very specific:

    Write the delta's tip SHA to .git/catch-up-baseline — only after delivering the briefing, so a failed run re-covers the same delta.

    line 35

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Catch-up

Deliver a briefing on the repo's latest updates: three sections — What landed, Review, Next — nothing else.

1. Baseline

  • git fetch --all --prune (skip silently if no remote or offline).
  • The tip is git rev-parse @{u} 2>/dev/null || git rev-parse HEAD — upstream when it exists, else local HEAD.
  • The baseline is the SHA in .git/catch-up-baseline if present; otherwise the most recent tag, or git rev-list --max-count=21 <tip> | tail -1 (≈ 20 back, clamped to the root commit) — say which fallback you used.
  • If invoked with an argument — a count N or a ref — this is an explicit lookback: the baseline is git rev-list --max-count=$((N+1)) <tip> | tail -1 (or the given ref), the stored baseline is ignored, and step 4 is skipped (a one-off view never moves the marker).
  • The delta is <baseline>..<tip>.
  • Empty delta → report "nothing new since <sha> (<date>)", then still report working-tree state (below) if dirty, and stop.

2. Gather

  • git log --oneline --stat <delta>; git status --short for working-tree state; gh pr list for open PRs if gh is available (skip silently otherwise).
  • Read the full diff of any commit whose message doesn't make its change obvious.
  • Done when: every commit in the delta is assigned to a theme — no "misc" bucket larger than 3 commits.

3. Briefing

  • What landed — commits grouped by theme; each theme gets one line: what it does, commit count, key files.
  • Review — judgments from the diffs you read: risks introduced, missing tests, contract/doc drift, half-finished work (TODOs, dead flags, stubs). If the working tree is dirty, name what's uncommitted. Every claim cites a commit or file:line. No diff read → no claim.
  • Next — 3–5 ranked recommendations, each traceable to something observed (a gap the commits opened, a follow-up they imply, uncommitted work in the tree, an open PR going stale). No generic advice.
  • Done when: each Review claim has a citation and each Next item names its evidence.

4. Advance

Write the delta's tip SHA to .git/catch-up-baseline — only after delivering the briefing, so a failed run re-covers the same delta.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.