59 lines
3.0 KiB
Markdown
59 lines
3.0 KiB
Markdown
---
|
|
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.
|