/wrapup — Session Close-Out
Close out the current session cleanly: review what got done, update project tracking files, commit changes, capture session knowledge, and confirm everything is documented. This is the "I'm done" skill — no next-session opener is produced. For passoff (future-you or a coworker), use /handoff instead.
Three modes:
- Default (
/wrapup) — Per-step gated review. Each tracked surface (session summary, PROGRESS, CLAUDE.md, memory, commit, /extract prompt) prompts for explicit confirmation before writing. auto(/wrapup auto) — Implicit-yes on all gates. Run silently. Apply all drafts and chain/extractwithout confirmation. Emit final report only. Use when the session is short and unambiguous, or when you've already authorized a combined-go (yes to all,yes to all with extract).snap(/wrapup snap) — Likeauto, but archives the raw transcript via/snapshotfor later extraction instead of running/extractnow. Use when context is high: you still get the full silent close-out + commit, but defer the expensive, compaction-risky knowledge synthesis to a later session (or the next/audit-knowledgedigest pass, which reads the snapshot automatically).
snap is auto plus one swap. Everywhere a step below says "If mode = auto (or snap)", snap follows auto's behavior exactly — implicit-yes, silent, apply all drafts, no per-step prompts. The single difference is the capture step (Step 8): snap runs /snapshot (archive the transcript for later) while auto runs /extract (synthesize now). Nothing else differs.
Runtime Gate (per ADR-094)
Canonical resolution: This is the Claude Code variant. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /wrapup resolves to this skill — aria-knowledge (Code) is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. The Cowork variant is namespaced-only: /aria-cowork:wrapup.
Before Step 0: Check that the Bash tool is available in this session. If Bash is NOT available (you are running in Claude Cowork or another non-Code runtime), surface the following notification and wait for explicit user confirmation:
⚠️ Runtime mismatch — you invoked aria-knowledge's /wrapup from a non-Code runtime.
This variant runsgit status/git commitvia Bash, which isn't available here. For the Cowork-native variant (emits a copy-paste commit message instead, skips ADR-005 tracked-artifacts check), use/aria-cowork:wrapup.
Use/aria-cowork:wrapupinstead? (y/n)
Wait for an explicit reply:
y/yes— Use theSkilltool to invokearia-cowork:wrapupwith the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the cowork variant takes over and runs to completion. This is the default-yes path — auto-redirect is the helpful action.n/no— Proceed with this (aria-knowledge) variant anyway despite the runtime mismatch. The user has explicitly opted in.- No response / any other reply — Treat as "do not proceed" and exit cleanly without running either variant.
This gate applies even when mode = auto or mode = snap per ADR-094 §Part 3. Auto/snap's "implicit-yes on all gates" rule is suspended for the runtime-mismatch check — they trust that the user invoked the correct variant, and this gate enforces that precondition. All other auto/snap-mode gates remain bypassed. The friction cost is now low: on y, the auto-redirect runs the correct variant with the original args. (snap especially depends on Bash — its /snapshot capture step runs save-transcript.sh — so the gate is load-bearing for snap.)
If Bash is available, proceed to Step 0.
Step 0: Resolve Config and Parse Mode
Read ~/.claude/aria-knowledge.local.md and extract knowledge_folder. If the file doesn't exist, stop: "aria-knowledge is not configured. Run /setup to get started."
Parse the argument:
- No arg, or arg is empty →
mode = gated(default) - Arg matches
auto(case-insensitive) →mode = auto - Arg matches
snap(case-insensitive) →mode = snap - Any other arg → stop: "Unknown argument '{arg}'. Use '/wrapup', '/wrapup auto', or '/wrapup snap'."
Use {knowledge_folder} as the base path for all file operations in subsequent steps.
Step 1: Identify Project Context
Detect the active project by scanning the working directory for project markers:
- Search upward from cwd for
PROGRESS.mdandCLAUDE.mdfiles - Also check for
CODEMAP.md(indicates a mapped codebase) - Check for project-level memory files in
~/.claude/projects/matching the current path
Multi-project-root disambiguation (required for correct SESSION.md placement): if the upward search resolves to a multi-project/workspace root — e.g. ~/Projects, or any directory whose CLAUDE.md indexes multiple child projects rather than describing one project, and which has no project-specific PROGRESS.md — do NOT treat that root as the project (writing SESSION.md there would be wrong). Instead infer the active project from this session's actual work: the files edited, the repos committed to, or the project the user named. Use that project's own root (its nearest CLAUDE.md/PROGRESS.md) for every per-project write, especially SESSION.md. This mirrors the SessionStart re-entry instruction's "which project" signal. If the session genuinely spans no single project, skip the SESSION.md write (Step 6.5) and note it.
Record:
- Project root — the directory containing PROGRESS.md and/or CLAUDE.md
- PROGRESS.md path — if it exists
- CLAUDE.md path(s) — root-level and any subfolder-level ones relevant to the session
- Memory files — any
project_*.mdfiles in the Claude memory directory for this project path - Git repos — run
git statusin any git repositories within the project to detect uncommitted changes
If no PROGRESS.md or CLAUDE.md is found, note this — the session may be in a project that doesn't use these conventions. Continue with the steps that are applicable.
Step 2: Review Session Work
Summarize what was accomplished in this session:
- Files changed — list files created, modified, or deleted during this session (from conversation context, not git — git may include changes from before this session)
- Key decisions — architectural choices, design decisions, approach selections made during the session
- Current state — what's working, what's in progress, what's blocked
- Next steps — what the user indicated should happen next, or what logically follows
Present this summary to the user:
## Session Summary
**Project:** [project name/path]
**Focus:** [1-line description of session goal]
**Work completed:**
- [bullet list of what was done]
**Decisions made:**
- [bullet list of key decisions]
**Next steps:**
- [what follows from here]
If mode = auto (or snap): skip the prompt and proceed with the drafted summary as-is.
Otherwise (gated mode): Ask: "Does this summary look right? (yes / edit)"
If the user wants to edit, incorporate their corrections before proceeding.
Step 3: Update PROGRESS.md
If a PROGRESS.md exists for this project:
- Read the current PROGRESS.md
- Check if a session entry already exists for today's work (the user or a previous /wrapup may have already added one)
- If no entry exists, draft a new session entry using the project's existing format (match the heading style, content structure, and level of detail of previous entries)
- Show the draft to the user
If mode = auto (or snap): append the drafted entry without prompting (equivalent to yes).
Otherwise (gated mode): Ask: "Add this session entry to PROGRESS.md? (yes / edit / skip)"
- yes — append the entry
- edit — let the user modify, then append
- skip — leave PROGRESS.md as-is
If