Recap

---
name: recap
description: Give a short product-level summary of what a worktree accomplished, in the words a customer or a co-founder would use, plus the exact steps needed to merge and deploy it safely (new env vars, migrations, one-off tasks, dashboard and DNS setup). Use whenever the user asks what was done in this worktree, what this branch was about, "remind me what we were working on", "summarize this worktree", "what did we build here", "what did this get us", "recap", "3-sentence summary", "anything I need to do to deploy this", or asks for a summary right before committing, merging, or opening a PR. Also use when returning to a stale worktree and needing the context back fast. Prefer this over reading the diff aloud: the answer is about customer impact and what shipping it requires, never about files, functions, or APIs.
---

# Recap

Answer two questions: what does the work in this worktree get us, and what has to happen for it to ship safely?

The user is standing at the commit. They may have many worktrees open across many projects, and they need the memory of this one back in about ten seconds. Long agent sessions leave behind a wall of completed tasks and success criteria. Your job is to throw that away and say what it means.

They do not want the diff read back to them. They can read the diff.

This works the same on an ordinary branch checkout. Worktrees are just the common case, because that is where work sits unnamed and half remembered.

## The rule that carries the summary

Every sentence must survive being read out loud to someone who has never seen the code.

A sentence fails if it contains a file name, a function, a class, a table, an endpoint, a library, a framework, a line count, a file count, or the words *refactor*, *implement*, *wire up*, *migrate*, *scaffold*, or *abstraction*. Rewrite it as something a person can now do.

For each cluster of change, ask: **who can now do what they could not do before?**

If the honest answer is "nobody yet", say that plainly. Infrastructure phases are real and normal. Inventing customer value for a plumbing phase is the worst failure mode here, worse than being boring, because the user makes shipping decisions off this summary. Name the foundation, then name the customer-visible thing it leads to.

This plain-language rule governs the three summary sentences only. The ship list below is the opposite: it must be exact and technical, because the user is going to copy names straight out of it.

## Gather the evidence

Read-only. Change nothing. Run nothing but git and file reads.

```bash
git rev-parse --show-toplevel && git branch --show-current
git status --short
git log --oneline "$BASE"..HEAD
git diff --stat "$(git merge-base HEAD "$BASE")"
```

`$BASE` is `origin/HEAD` if it resolves, otherwise `main`, otherwise `master`.

The user runs this right before committing, so most of the work is usually **uncommitted**. `git diff` against the merge base covers staged and unstaged changes; `git status --short` catches untracked files. Missing either one means summarizing the wrong worktree state.

Sources of meaning, in order of value:

1. **Planning docs the work was driven from**, if the repo has them: a progress or implementation file under `docs/`, a spec, a plan, a linked ticket, an ADR. These already carry the phase title, the rationale for doing it, and the session log, which makes them the fastest path to intent. Use the part that matches the changes in front of you, not the whole feature.
2. **The branch name and commit subjects.** Compressed intent, usually honest.
3. **The user-facing surfaces inside the diff**: UI copy and templates, pages and routes, emails and notifications, plan and pricing logic, onboarding steps, feature flags, CHANGELOG or README lines.
4. **This session's conversation**, if the work happened here.