# Wrap

> Close out a session — record what was learned, update any connected stores, and report what's left dirty.

- Skill: `theyoungastronauts/wrap` (Agent Skill)
- Install (CLI): `npx skillmds@latest add theyoungastronauts/wrap`
- Raw SKILL.md: https://api.skillmd.com/api/skills/theyoungastronauts/wrap/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: theyoungastronauts (https://skillmd.com/u/theyoungastronauts)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/theyoungastronauts/wrap

---


# Wrap

End-of-session close-out. Run at a milestone, when the work is worth recording and the session may not be returned to.

Two stores ship with Polaris, and both are local to this machine and this repo:

| Store | What lives there |
|---|---|
| Session memory — `~/.claude/projects/<path>/memory/` | Corrections, preferences, how to work with this user |
| Project context — `.claude/context/` | Decisions, conventions, patterns for *this* repo |

Anything beyond that — a cross-project knowledge base, an external task tracker — is an **extension**. See below. If none is installed, wrap is memory, context, and a repo report.

Not to be confused with [`relay`](../relay/SKILL.md): relay hands in-flight work to a fresh session mid-task. Wrap closes work out.

## Order matters

The command exists because the session may be abandoned. **Every unattended write happens before the first question is asked**, so walking away mid-wrap still leaves the durable stores current.

That splits the run into two phases, and the split is by risk:

| Phase 1 — written outright | Phase 2 — proposed, written on approval |
|---|---|
| Cheap to correct, and wrong entries are visible next session | Curated, or read by other people, or hard to undo |
| Session memory, project context | Commits |
| Whatever an extension declares safe | Whatever an extension declares curated |

Never invert it. A wrap that stops to ask before writing anything, and is then abandoned, has done nothing at all.

## Phase 1 — write

**Memory and project context.** Follow the [`reflect`](../reflect/SKILL.md) skill's process — scan, filter, classify, write. Read it rather than re-deriving the formats; it owns them.

One change: **write the surviving findings instead of proposing them.** Reflect proposes because it's used interactively. Wrap assumes nobody is watching. The filter carries the weight — anything failing reflect's four checks is discarded, not written and not mentioned.

**Then run each extension's Phase 1.**

## Phase 2 — propose

Run each extension's Phase 2, then handle the repo.

**Repo state.** Report what's uncommitted, untracked, or unpushed.

If the working tree holds one coherent change, propose a message and commit on approval. If it holds several unrelated changes, or work that's plainly half-finished, say so and commit nothing — close-out is exactly when unfinished work gets shipped by accident. Never push unless asked.

## Extensions

Some setups have stores that Polaris knows nothing about: a personal knowledge vault, a shared team wiki, an issue tracker, a status page.

**Wrap does not define those. It runs them.**

An extension is any available skill that owns such a store and documents a `## Close-out` section. Its description will say what it owns — a second brain, a vault, cross-project knowledge, a task tracker. At wrap time, check the available skills for one, read it, and follow its `## Close-out` section, honouring its Phase 1 / Phase 2 split.

If nothing is installed, skip both extension steps silently. Absence is the normal case, not an error.

### Writing a Close-out section

Two requirements, and discovery fails without the first: **the skill's `description` must name what it owns** (a second brain, a vault, a task tracker) — that description is the only thing wrap sees when scanning for extensions, so a Close-out section in a skill whose description doesn't flag it will never be found. Second, the section itself:

```markdown
## Close-out

Invoked by `/wrap`. Resolve the target first — never guess which record to write.

**Phase 1 (write):** <the cheap, correctable writes — capture files, completing
work that demonstrably finished>

**Phase 2 (propose, with exact text):** <the curated writes — status lines,
priority ordering, anything another person reads>
```

Two rules for any extension:

- **Resolve the target before writing.** If the current repo can't be matched to a record with confidence, capture to whatever the store's inbox equivalent is and say so. A confident write into the wrong record is worse than no write.
- **Never record what's derivable.** Branch state, deploy status, test results — all recomputable in seconds, all stale by the next read, and all still reading as authoritative. Record what happened and why.

## Report

Close with what landed, what's waiting on the user, and what's still dirty. A few lines.

If a store was skipped, say which and why. Silence implies it was covered.

## Common mistakes

- **Asking before writing.** Phase 1 must finish first. A blocked-then-abandoned wrap accomplishes nothing.
- **Committing to be tidy.** Half-finished work shipped at close-out is the failure this is most likely to cause.
- **Re-deriving reflect's formats, or an extension's.** Read the skill that owns them.
- **Treating a missing extension as a problem.** Most setups have none.
- **Reporting only successes.** What's still dirty is the most useful line in the summary.