---
name: wrapup
description: Wrap up the session - update memory, tidy it, commit and push (with permission), list what's open, set a checkpoint. Use when the user runs /wrapup or asks to wrap up, close out or checkpoint the session.
disable-model-invocation: true
---

Wrap up this session so the next one can start cold. Do the steps in order, in one pass, with
bounded command output. Don't re-read files that are already in context. $ARGUMENTS

This works in any session, in any folder. If a step has nothing to act on (no memory directory,
not a git repo, no project notes), say so in one line and go on to the next step.

## 1. Memory
- Open the project's memory index (`MEMORY.md` in this project's memory directory) and the files
  this session touched or made stale.
- Save what is durable and would change future behaviour: corrections the user gave,
  preferences, decisions, answers to open questions, pointers to external resources. Record the
  user's words where they matter, and mark your own interpretations as yours.
- Don't save a diary of completed work, anything the repo or git history already records, or
  anything that only mattered to this conversation.

## 2. Remove what is redundant
- Merge duplicates, delete memories that turned out wrong or are superseded, and trim status
  paragraphs that a newer one replaces. Fix `MEMORY.md` so every line points at a file that
  exists and its hook is still true.
- Do the same for the project's own notes if it has them (a log, a codebase map, a local
  instructions file): bring them in line with what was built, nothing more.
- Say in one line what you removed or merged.

## 3. Git
- In every repo this session changed: `git status --short` and `git diff --stat` first.
- Follow that project's git rules exactly (attribution, forbidden names, what must never be
  committed). Run its pre-push checks if it has any.
- **If the user has given standing permission to commit and push in this project** (its
  instructions or memory say so), commit and push without asking. **Otherwise show the summary
  and the proposed commit message and ask before `git add`, commit or push.**
- Never force-push or rewrite history. If there is nothing to commit, say so.

## 4. Checkpoint
- Write one checkpoint at the top of the project's status memory (the one `MEMORY.md` marks as
  the place to start; create `project_checkpoint.md` and its index line if there is none).
  Replace the previous checkpoint instead of stacking a new one. It holds:
  - the date and the last commit of each repo touched, and whether the tree is clean;
  - what was built this session, one line each;
  - what the user has not yet confirmed working on their machine;
  - what is next, in the agreed order;
  - open questions for the user;
  - anything running the user should know about (servers, background jobs, leftover processes).

## 5. Report
End with a short report, no preamble:
- **Saved:** what went into memory, and what was removed.
- **Git:** what was committed and pushed (hashes), or what is waiting on the user's yes.
- **Open for next session:** things to try, things to decide, and what comes next.
- **Still running:** anything left alive, or "nothing".