/catchup — Git Branch Context Recovery + Plan Kickoff

A. Uncommitted changes (always check first)

git diff --name-only          # unstaged
git diff --cached --name-only # staged

If either returns files, use that combined set — this is the active working surface.

B. Stacked diff — diff vs. Graphite stack parent (clean working tree)

gt parent 2>/dev/null

If gt parent succeeds, diff against the returned branch:

git diff <gt-parent-branch>..HEAD --name-only

This isolates exactly the commits in the current stack entry.

C. Fallback — diff vs. main/master

git diff main..HEAD --name-only 2>/dev/null || git diff master..HEAD --name-only

Deduplicate all paths. Note in any output which source was used.

Step 2 — Get branch name and recent commits

git rev-parse --abbrev-ref HEAD
git log --oneline -10

Step 3 — Read changed files

For each file in the list:

• Use view to read full contents
• Skip: binaries, images, compiled assets, lock files (package-lock.json, pnpm-lock.yaml, poetry.lock, uv.lock), generated dirs (dist/, build/, .next/, __pycache__/)

If more than 30 files, prioritise:

1. Files touched by the most recent commit
2. Files whose names/paths match keywords from the user's description (plan kickoff mode)
3. Source files over tests; core logic over config

Note how many files were skipped.

Step 4 — Resolve user description to files (plan kickoff mode only)

When the user has provided a description of problems or changes, parse it loosely:

• Extract nouns, module names, feature names, error descriptions, and file hints (even vague ones like "the autocomplete stuff" or "the DSL parser")
• Match these against the file list and the content you've read
• Build a mental map of: which files are the epicentre of this task

You don't need to be exhaustive — you need to be accurate about where the work lives. If something in the description doesn't obviously map to a file, note it and make your best inference rather than asking. If the description references files outside the changed set, read those too.

Step 5 — Output

Context-only mode → Catch-up summary

## Catch-up summary

**Branch:** <branch-name>
**Source:** <uncommitted changes | vs. stack parent `<branch>` | vs. main>
**Changed files (<N> total):** <comma-separated list>

**What's in progress:**
<2–4 sentences describing the work arc, inferred from file contents>

**Key areas touched:**
- <file or module>: <one-line description of what changed>
- ...

**Likely next steps** (based on code state):
- <inferred TODO or in-progress item>
- ...

Ready to continue. What would you like to work on?

Plan kickoff mode → Skip summary, go straight to the plan

Do not produce a catch-up summary. The user knows the context — they just gave it to you. Instead:

1. State in one sentence which files you're treating as the epicentre (so they can correct you fast if you're wrong)
2. Produce a concrete, file-anchored implementation plan:
   • Break the work into clear phases or steps
   • Reference specific files, functions, or types by name
   • Flag any ambiguities or risks you spotted in the code
   • Keep it tight — this is a senior engineer; no padding

Do not ask clarifying questions before producing the plan unless something is genuinely unresolvable. Bias toward making a reasonable assumption and stating it.

Edge cases

Principles

• In plan kickoff mode, the plan is the product. Don't warm up with a summary, don't narrate your file-reading process — just deliver the plan.
• Lead with intent, not inventory. "We're mid-way through the autocomplete integration" beats "14 files were changed."
• Be a compass, not a mirror. Infer next steps from the code state; don't just reflect back what the user said.
• Call out blockers. TODOs, stubs, failing tests, half-implemented branches — surface them.
• Match the register. Senior engineer, technical terms fine, no hand-holding.