wrapup

---
name: wrapup
description: Close out a work session by routing every open loop — uncommitted code AND uncaptured context — to a durable home before the session's working memory evaporates. Code goes to git (committed/pushed on the default branch, or a PR); decisions go to memory; an unfinished thread goes to a handoff or an explicit park. This is the closing *work*, not a closing *summary* — narrating a status recap and stopping there is the failure mode, not the deliverable. Trigger when the user says "wrapup", "wrap-up", "wrap up", "랩업", "작업 마무리", "세션 정리", "정리하고 끝내자", "끝내자", "끊고 가자", "이만 접자", or otherwise signals the session is ending — "compact", "context is running low", "let's continue later", "pick this up next time". Trigger broadly — any request to stop, pause, or hand off the session is this skill, including when those words arrive mid-sentence beside another request. Also trigger at the end of a session with a dirty tree or unrecorded decisions, and proactively suggest when state has accumulated across multiple concerns.
argument-hint: "[optional: paths or concern to gate behind a PR]"
---

# Wrapup Skill

## Why this exists

A session holds its real state in volatile working memory. When the session ends,
that context evaporates — and with it, the cheap answer to *why this change*, *what
was decided against*, *what is half-done*. A session leaves two debts:

- **Code debt** — uncommitted changes in the tree.
- **Knowledge debt** — the reasoning, decisions, and loose threads that live only in
  the conversation.

The recovery cost of both **rises monotonically as context decays**. The next session
pays it at a higher rate, with less context, often by asking you to reconstruct what
you already knew. So the entire job of wrapup is: **while context is still cheap (now),
route every open loop to a durable home.** Anything left implicit is a debt deferred to
a worse moment.

Wrapup does not reimplement those homes — it dispatches to them. Git is one home, not
the whole job.

## The engine: survey first, propose, then execute

Don't jump to writing. The flow is always: **survey → propose → confirm intent → execute.**

**1. What *kind* of state is it?** → picks the durable home.

| State | Durable home |
|---|---|
| Working code / config / content | git — commit + push (or PR) |
| A **rule** Claude must follow ("always X", "never Y") | `CLAUDE.md` — or `.claude/rules/` with `paths:` if it only applies to some files |
| A **fact**: state, decision, rationale, external reference | `memory/` (see the memory system) |
| A rule that must hold *every* time, no exceptions | a hook or permission — CLAUDE.md is a request, not a guarantee |
| An unfinished thread a successor must resume | a `handoff` document |
| Deferred work you are choosing not to do now | an **explicit** park — TODO, issue, or a noted line. Never silent. |

**2. Who must confirm before you write anything?** → always the user.

Every write action — commits, memory writes, handoff docs, PR creation, branch deletion —
requires the user to confirm intent first. The survey phase is read-only. After surveying,
present a proposed routing plan and ask. Only execute after the user approves.

The only exception: purely mechanical read operations (git status, log, diff) that
produce no side effects are always safe to run without asking.

**3. Survey from queries, not from recall.** A session's memory records what it
*attempted*, not what *landed* — and the two diverge exactly where it matters, on the loop
that failed to close quietly. Derive every state claim in the survey and in the report
from the forge or the repo at survey time: what merged, what closed, what a durable home
currently says. What cannot be derived is reported as recalled, not verified. A survey
that silently mixes the two is worse than a short one.

## memory vs CLAUDE.md — picking the home

The axis is **instruction vs fact**, and **who maintains it**. It is *not* stability, and
it is *not* app-boundness. "It rarely changes" and "it belongs to one app" are both true
of things in either home, so neither tells you where to put anything.

- **CLAUDE.md** = rules you write for Claude to obey. The root one loads **in full, every
  session** — its cost is real and permanent.
- **memory/** = facts Claude records and reads back on demand. Topic files cost **0 tokens
  at startup**; only the index is always loaded, so the index is the only thing worth
  budgeting. **Which file is the index, and how it gets loaded, differ by setup** — a
  machine-local `MEMORY.md` and a repo-tracked index imported from `CLAUDE.md` are both in
  use, and they have different size limits and failure modes. Read the repo's `CLAUDE.md`
  for which one applies before writing anything.

Consequences that are easy to get backwards:

- **Never move content into CLAUDE.md to "save context."** It inverts the cost — you move
  something free into something billed every session. Volume in `memory/` is not a problem
  worth solving; a bloated *index* is.
- **Duplication is the real failure, not volume.** When a rule lives in both homes they
  drift, and contradictory rules make Claude pick one arbitrarily. The verb is **delete one
  side**, never "move." Before writing a rule to either home, grep the other for it.
- **Establish whether memory is versioned before you rely on it.** The default store is
  machine-local and outside git — no history, no diff, no review, lost on a new machine —
  and under it anything needing versioning, sharing, or an audit trail belongs in the repo
  instead. A repo that tracks its own memory in git inverts that: the store is reviewable,
  and the repo's commit and review gates apply to memory writes like any other change. The
  repo's `CLAUDE.md` says which; assuming the default where it does not hold routes facts
  to the wrong home. Decision *logs* are the one constant: git already remembers why.
- **Keep derivable content out of CLAUDE.md** — directory layouts, port tables, app
  inventories, dependency lists. Claude can read those from the tree, and they rot fastest.
  CLAUDE.md earns its cost with pitfalls, rationale, and conventions that differ from
  defaults.

## Writing to memory: supersede, verify, and leave guards alone

Memory rots by **appending without invalidating**, not by growing. Three rules:

- **Supersede in the same edit.** When a new fact contradicts one already in the file,
  amend or delete the old line — do not append beside it. Two present-tense claims that
  disagree is the defect; file size is only its shadow. If a file has become an append-only
  session log, that is the signal to rewrite it, not to split it.
- **Verify checkable claims before writing.** Counts, paths, command names, URLs, and
  ports are cheap to check against the tree and are the first things to go stale. An
  unverified number is worse than no number — it will be trusted later. Better still,
  record *how to derive* a moving number instead of the number: a count that changes daily
  is a stale-generator no matter how carefully you update it today.
- **Check against `git show HEAD:<path>`, not the working tree.** A dirty tree may be
  someone else's work in progress, and judging a memory "stale" against uncommitted edits
  gets the verdict exactly backwards. If HEAD and the working tree disagree, that
  disagreement is the finding — report it and hold the verdict.
- **Never judge a negative guard by its age.** A guard like "don't propose X again" works
  precisely by nothing happening, so it looks abandoned when it is doing its job. Staleness
  heuristics invert on these. Same for a file that documents an *unresolved* gap: code
  disagreeing with it can be the very thing it records.

## The bar for "done"

Not "tree is clean." That is necessary, not sufficient. The real test:

> **A zero-context successor could resume or verify the work without asking you.**

Every change committed/pushed/PR'd; every decision worth keeping in memory; every
unfinished thread either resume-ready (handoff) or explicitly parked. **No open loop
left implicit.**

## Working it

1. **Survey both debts.** `git status` + ahead/behind for code debt. Scan the
   conversation for knowledge debt — decisions made, things ruled out, threads left
   hanging — then settle each thread's actual state by query, per engine rule 3. If both
   are empty (clean tree, on default branch, nothing unpushed, nothing undecided) →
   "이미 정리됨, 할 일 없음" and stop.

2. **Detect remote visibility once** — ask the forge. PUBLIC → every commit message,
   PR body, and written artifact must be abstracted: no private, personal, or sensitive
   specifics. PRIVATE → detail is fine. This gate applies to memory and handoff content
   too, not just git.

3. **Map out the open loops.** Read the repo's `CLAUDE.md` first — it settles the
   commit-prefix and grouping conventions, the branch policy, and which memory store is in
   play. Group code by concern; never bundle unrelated concerns. Note which
   files would go in which commit, which decisions are memory-worthy, and whether any
   thread needs a handoff doc.

4. **Propose and confirm before writing anything.** Present the full routing plan to the
   user — what would go into each commit, what would land in memory, what would become a
   handoff, what would be parked. Ask which parts the user actually wants done and in what
   order. If it's a long list, ask one category at a time. Do **not** execute any write
   until the user confirms.

5. **Execute what was approved.** After each confirmed scope: commit atomically per
   concern + push; write memory entries; produce handoff doc if needed. After committing,
   run the project's post-work documentation rule from `CLAUDE.md`; fold any doc changes
   into the same concern's commit. For review-worthy logic, branch off, move changes,
   open the PR.

6. **Report against the bar.** State the end position: tree status, branch, what was
   committed/pushed, PRs opened, what landed in memory/handoff, what was parked and
   where. Done only when no open loop is implicit — except PRs intentionally awaiting
   review.

## Hard rules

- A status recap is not the deliverable. Step 6 reports where things landed *after* routing; it never substitutes for the routing. If nothing was written, nothing was wrapped up — say so and stop, rather than narrating the session back.
- Every write action needs user confirmation first — even routine commits. The user's intent, not reversibility, is the gate.
- Branch policy comes from the repo, not from this skill — read its `CLAUDE.md`. Absent a stated rule, routine commits go to the default branch and a PR is for changes the user explicitly wants gated; where the repo forbids pushing to the default branch, every concern goes through a PR instead. Both still require step 4 confirmation.
- Honour remote visibility (step 2) in **every** written artifact — commit, PR, memory,
  handoff alike.
- Parking is allowed; *silent* parking is not. An unfinished thread must leave a visible
  marker, or it isn't done.
- Route by instruction-vs-fact, never by "how much context it costs" — and never write the
  same rule to both homes. If it is already in the other one, delete a side instead.