Repo snapshot

Where it stands and what changed.

For: A release owner, tech lead, or anyone asked “what shipped?”
When: End of the week, before a release or planning meeting, or after time away
Takes: About three minutes of agent time
You get: A dated snapshot in onecell that links to the previous one, and three bullets ready to paste into team chat

Run it where the repo is checked out. The GitHub CLI (gh) is optional; with it, the snapshot includes open pull requests.

The prompt

Not connected yet? Set up your AI Run in Claude Run in ChatGPT

Snapshot <repo> in onecell: where it stands and what changed since <since>.
<since> can be a date, a tag, or "last snapshot". Save it to <cell>
(default: my Inbox).

1. Find the previous snapshot: search onecell for "Repo snapshot: <repo>".
   If <since> is "last snapshot", start where that one ended; if there is
   none, use the last 7 days.

2. Gather from git and GitHub, read-only:
   - git log --first-parent main --since=<since> --format='%h %ad %s' --date=short
   - git diff --shortstat and --dirstat from the first commit in range to HEAD
   - migrations, config and .env.example changes in the range
   - tags cut in the range, and open PRs (gh pr list) if gh is available
   With squash merges, git reports merged branches as unmerged: use PR
   state, not branch state, to say what is in flight.

3. Draft "Repo snapshot: <repo>, <start> to <end>" with create_document
   (dry run first):
   - A stats block: merges, files changed, lines added and removed, open PRs
   - A timeline of merges by day, in plain words, with PR numbers
   - A table of what changed by area: area, change, PRs
   - One diff block for the change a reviewer must act on (new settings,
     a schema change or an API change), trimmed to what matters
   - Decisions that shipped: call list_decisions, link the ones this work
     carried out, and leave their status alone
   - Follow-ups as a checklist: migrations, settings, cleanup, risks
   - A link to the previous snapshot

4. Only if something durable changed, such as a new required setting or a
   new deploy step: call recall, then remember it with entity "<repo>".

5. Reply with the link and three bullets I can paste into team chat.
   Keep the document a draft; don't publish or share it unless I ask.

What your agent does

Finds the last snapshot
search locates the previous snapshot, so each one starts where the last ended and links back to it.
Reads the history, read-only
Merges to main, the size and shape of the change, migrations and new settings, tags, and open pull requests. Nothing in the repo changes.
Writes the snapshot as a draft
create_document, dry run first: stats, a timeline, changes by area, the one diff that needs action, and follow-ups.
Connects it to decisions
list_decisions finds the accepted decisions the work carried out and links them, without changing their status.
Remembers only what lasts
A new required setting or deploy step becomes a fact for later sessions. Ordinary changes do not.
Hands you the summary
A link and three bullets to paste into chat.

What you get back

Open the full example →

Two weeks of Tally, a made-up invoicing app: 23 merges, grouped so a reviewer sees the new settings and the follow-ups first.

Sample repo snapshot: Tally, 1 to 14 August

Merged: 23; pull requests
Contributors: 4
Migrations: 2; both run on deploy
Open pull requests: 5; 2 waiting on review

Shipped, by area

Area	What changed
Invoices	Partial payments; invoice PDFs in the client's language
Payments	Bank transfers in euros via Stripe; clearer failed-payment emails
Reminders	The job-queue version, behind a flag and off in production
Settings	Two-factor sign-in for every account
Fixes	Rounding on invoices with more than 20 lines; the CSV export date format

Settings and operations

New setting REMINDERS_QUEUE, off by default. Turn it on only after the dry run.
Stripe webhook now also listens for payment_intent.processing; update the endpoint in the Stripe dashboard.

Needs doing

Review the two pull requests waiting more than three days
Write the release note for partial payments
Record the decision behind the fourth retry on annual plans

.md for agents

Variations

A weekly shipped note on the team hive

Set <since> to “last snapshot” and <cell> to the team's hive, and run it every Friday. After a quick read, publish it: the hive keeps a dated history of what shipped that any agent can search.

Release notes from a tag

Set <since> to the last release tag and add: “Write it for customers: group by what they can now do, leave out internal changes, and end with anything they must change.” Share the page with a link once it reads right.

Catching up after time away

Set <since> to the day you left and add: “End with what I need to know before I touch <area> again.” Pair it with the project primer if the codebase is new to you.

Tips

Keep every snapshot of a repo in one cell, so the next one finds the last and the history reads in order.
--first-parent keeps the history to what landed on main, one line per merge.
The diff block is for the change someone must act on, not the biggest change.
New to the repo? Start with Recipe: onboard into a project, then keep up with snapshots.

Repo snapshot

The prompt

What your agent does

Finds the last snapshot

Reads the history, read-only

Writes the snapshot as a draft

Connects it to decisions

Remembers only what lasts

Hands you the summary