# Recipe: repo snapshot, where it stands and what changed

A copy-paste prompt: your agent reads git and GitHub since a date or tag and writes a dated snapshot of what shipped, what changed and what needs doing.

> [!info]
> **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

Open your agent inside the repo, copy the prompt, and replace the parts in `<angle brackets>`.

```text
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

1. Finds the last snapshot
   search locates the previous snapshot, so each one starts where the last ended and links back to it.
2. 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.
3. 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.
4. Connects it to decisions
   list_decisions finds the accepted decisions the work carried out and links them, without changing their status.
5. Remembers only what lasts
   A new required setting or deploy step becomes a fact for later sessions. Ordinary changes do not.
6. Hands you the summary
   A link and three bullets to paste into chat.

## What you get

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

<!-- onecell:block {"type":"embed","documentId":"87beaf44-fd73-4d1e-85fd-a36e5bf39864"} -->
[Sample repo snapshot: Tally, 1 to 14 August](https://onecell.io/p/sample-repo-snapshot-tally)

## Variations

<details>
<summary>A weekly shipped note on the team hive</summary>

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.

</details>

<details>
<summary>Release notes from a tag</summary>

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.

</details>

<details>
<summary>Catching up after time away</summary>

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.

</details>

## 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](https://onecell.io/help/recipes/recipe-onboard-into-a-project), then keep up with snapshots.

---

Part of [onecell recipes](https://onecell.io/help/recipes): copy-paste prompts for using onecell in your work.