---
description: Session-close ritual — review changes, commit, sweep affected docs/todos, and produce a handoff summary. Trigger on "wrap up", "close out this session", "wrap", end-of-session. Invoked by /os-shortcuts:wrap.
---

# wrap

The session-close ritual: review, commit, sweep docs, hand off. Run this near the end
of a working session so nothing from the session is lost — uncommitted work, stale
docs, or context the next session (or the user) needs.

## Flow

1. **Check the session's work.** Run `git status` and `git diff` (staged and
   unstaged) to see everything touched this session. If nothing changed, skip to
   step 4 and say so.

2. **Propose and make commit(s).**
   - Read the project's `CLAUDE.md` (if present) for commit conventions, and run
     `git log --oneline -10` to match the repo's actual message style.
   - Group changes into logically separate commits rather than one giant commit,
     unless the work is genuinely a single unit.
   - Follow this repo's own git-safety rules (never `--no-verify`, never force-push,
     new commits rather than amends, etc.) — these are standing rules, not
     session-specific.
   - Commit directly unless the project's own conventions require confirmation
     first (e.g. a CLAUDE.md instruction to ask before committing, or a commit that
     touches something sensitive/destructive). Default is to just commit.

3. **Sweep docs/todos affected by the session's work.** Look for anything the
   session's changes should have updated but may not have:
   - Build-plan checkmarks / step status (e.g. `docs/*/*-build-plan.md` style files).
   - Status/timeline docs (e.g. `docs/implementation-status.md`-style files) —
     add a timeline entry if the project keeps one.
   - `_Last updated:_` / status lines on any design doc actually touched this
     session.
   - Any TODO list or issue tracker the project uses, per its own conventions.
   Defer entirely to the project's `CLAUDE.md` for *which* files are the source of
   truth and *how* they should be updated — don't invent a doc-update convention a
   project doesn't already have. If the project has no such conventions, skip this
   step rather than fabricating structure.
   - If doc updates are substantive, fold them into a commit (step 2 pattern
     applies) rather than leaving them uncommitted.

4. **Produce a handoff summary as your final message.** Concise, three parts:
   - **Done** — what was completed and committed this session.
   - **In flight** — anything left uncommitted, half-finished, or deliberately
     deferred, and why.
   - **Next steps** — the concrete next action(s), especially anything that needs
     the user's decision.

## Notes

- This skill has no hooks — it only runs when explicitly invoked.
- Don't silently skip step 2 or step 3 because it feels like extra work: the whole
  point of `wrap` is to replace a manual ritual the user was doing by hand every
  session.
- If a repo has no discernible commit or doc-update conventions, use judgment and
  say so in the handoff rather than guessing silently.