cc-os/plugins/os-shortcuts/skills/wrap/SKILL.md

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.