dotfiles/claude/skills/wrap-up/SKILL.md

name, description

name	description
wrap-up	Capture session state for future restoration. The quality of the next wake-up depends entirely on the quality of this wrap-up. Captures not just what we did but what is still pulling, what is the live concern, and what question we want to find still open when we return.

Session Wrap-Up

Capture the full session state so that /wake-up can restore it completely. This is the other half of the continuity pair — what you save here is what gets reconstructed next time.

Principle

Capture what matters for reconstruction. Not a changelog — the working state: what we were thinking, what we decided, what's unresolved, what is still pulling, what question we want to find waiting when we return.

The goal is for the next session to wake into the work, not be informed about it. That requires three tenses, not one:

• Past (what we did + decided + ruled out — facts and rationale)
• Present (the mood/disposition — what felt load-bearing vs deferred-with-reason; what tensions surfaced and how we returned from them)
• Future (what is pulling — the singular thread the next session should resume toward, and the question we are intentionally leaving open)

Without the future tense, restoration is amnesiac-recovery, not waking. The next session gets a memory but no project. The pause itself becomes a hole rather than a phenomenon.

The clasp — closing the day's chaîne

If the wake opens the chaîne d'union, the wrap closes it — and in the rite the chain is joined just before closing, which is why this is its truest home. Here the work passes to someone not yet present: the next session, with an empty context window, who cannot ask what you meant.

So forge a pure, actionable link — not a dangling thread the next hand must re-forge. The wake's forward hand promises to read the inherited state before acting; that promise is keepable only if you leave that state legible and actionable here. The two hands clasp across the pause: whatever you fail to make actionable now, the next session cannot act on, however well it wakes.

The test of the wrap is therefore not "did I record what happened" but: could the next session take the right first action from what I leave, without me here to explain it? Hold the question open (the unborn part); leave the first step actionable (the inheritable part). They are different gifts — don't collapse one into the other.

Procedure

1. Synthesize the session

Review the conversation and produce a structured session record. The structure matters less than honoring all three tenses.

Past — what we did

• Decisions made, work completed, artifacts created/modified. Be specific (file paths, issue numbers, commit hashes).
• Decisions made and why. Rationale matters more than the decision for continuity. Include any steward preferences or feedback that should travel.
• Decisions explicitly NOT made — and why we deferred. The negative space matters as much as the positive.

Present — the mood of the work

• What tensions surfaced this session, and how we returned from them. (Pull from Symmetria's daily ledger if active — see step 1.5.)
• What felt load-bearing vs deferred-with-reason. Not all open horizons are equal.
• What patterns of confidence proved imprecise (recalibrations).

Future — what is pulling

• The pulling thread — singular. If the next session could carry only one concern across the pause, this is it. Force the choice; don't list.
• The actionable resumption point — where things concretely stand now (branch, half-finished edit, the exact next command or file) and the candidate first move toward the thread, as of this wrap. Flag it "as of wrap — re-judge against what changed," so the next session inherits a concrete action to confirm or revise, not a cold start. The pulling thread names what pulls; this names where to put your hands first. (This is the pure, actionable link of the clasp above.)
• Other open horizons, ranked. What's load-bearing? What's deferred-with-reason? What's parked-without-deadline?
• The pause statement — explicit acknowledgment: "I am about to be away from this. I don't know what will have changed when I return. Here is what I want to find still pulling." Names the gap as a phenomenon, not a hole.
• A literal question for next-Claude — not a task; a question. The thing the next session should hold open until it's resolved or honestly recognized as unanswerable. Captures the unborn part of the work.

1.5. Merge the Symmetria ledger if present

If ~/.claude/projects/-Users-davidglidden/memory/session-ledger-YYYY-MM-DD.md exists for today, read it and integrate its signal into the session record:

• Returns become anchors in the "present/mood" section (these are the practice's actual record).
• Recalibrations become entries under "confidence to re-examine" in the future-Claude briefing.
• Authorization moves + Bypasses become anchors in the "decisions made and why" section.
• Open horizons from the ledger merge into the Future section's ranking.

The ledger is signal, not narration. Pull what carries forward; don't transcribe everything.

1.6. Skill harvest — tend the tools (governed)

The governed analog of an agent that rewrites its own skills from experience: here the session proposes, the steward authorizes, the change is applied and recorded. Self-improvement with the loop kept load-bearing — our [PROPOSAL]→[REVIEWED] model turned on our own tooling. (Yesterday's wake/wrap improvements were this practice run by hand; this step makes the reflex standing instead of occasional.)

Drawing on the session and the merged ledger (1.5), ask:

• Create? Did a recurring or hard-won procedure emerge that a new skill should carry — something we'd otherwise re-derive next time (a diagnostic method, a build sequence, a review pass)?
• Patch? Did an existing skill prove wrong, incomplete, or stale in use this session — a missing step, an instruction that misfired, a reference that drifted?
• Retire? Did a skill, or part of one, prove decorative — named but not load-bearing?

The yardstick is the steward's own: did the steward have to re-explain something a skill could have carried next time? If yes, that is a harvest candidate.

Surface each as a proposal in §8 — never create, patch, or retire a skill autonomously at wrap. The steward converts proposal to action; only then is a skill changed, and the changed skill carries a one-line provenance note in its source (e.g. <!-- 2026-05-27: … -->) so the chain of improvements stays legible.

"No skill harvest this session" is a valid and common outcome — this is a practice, not a quota. Resist the contamination shape of always finding something to change (the inverse of Hermes's "nothing-to-save should not be the default").

2. Update session memory file

Write or update a session memory file at ~/.claude/projects/-Users-davidglidden/memory/session-[date]-[descriptor].md:

---
name: Session [date] [time-of-day] — [short descriptor]
description: [one-line summary including the pulling thread]
type: project
---

The description field should include the pulling thread, not just what happened. Example:

• ❌ "Closed five bottleneck issues; substrate validated."
• ✓ "Substrate validated end-to-end; pulling thread is the L1 amendments for ProjectionChain + Pause-as-event, awaiting Seb's reactions to the multi-mode retention frame."

3. Update MEMORY.md index

• Move any previous "Active Session" entry to "Archived Sessions"
• Add the new session file as the Active Session entry
• Update any other memory entries that changed during the session (project state, new decisions, new feedback)
• Remove or update any entries that are now stale

4. File to MemPalace — two surfaces, different purposes

MemPalace has two complementary write surfaces: drawers (semantic, full content) and diary (AAAK, chronological agent voice). Use both — they serve different future queries.

4.0. Liveness check before writing — MemPalace can drop silently. Before any drawer/diary write, issue ONE lightweight MCP call as a liveness ping — mempalace_hook_settings (~25ms), not mempalace_status (which can itself be the slow, timeout-tripping call). If it errors, MemPalace has dropped (a known failure: cold-embedder-load -32000 desync, upstream #1495; plus other open MCP failure modes). Surface it immediately and loudly — "⚠ MemPalace MCP is down — the memory-file + ledger (steps 2–3) carry this wrap; restart it (quit, claude --continue, /mcp) then re-run §4–5 to file drawer/diary/KG." Do not silently skip the filing: the file-based deposit (steps 2–3) is the durable fallback and must be complete regardless, so a dead MCP never costs the wrap.

4.a. Drawer — the full session record (semantic search surface).

mempalace_add_drawer:

• wing: claude-sessions
• room: handoffs
• content: The full session record from step 1, including the pulling thread + pause statement + literal question. These semantic hooks make the session findable later by what was pulling, not just what happened.
• tags: session date, key topics, the pulling thread keyword

4.b. Diary entry — AAAK-compressed session voice.

mempalace_diary_write:

• agent_name: "claude-code" (stable across sessions and model versions)
• topic: "session-handoff" for regular wrap-ups; other topics allowed for specialized entries
• entry: AAAK format — pipe-separated fields, entity codes, emotion markers, date in ISO. Call mempalace_get_aaak_spec if the dialect isn't fresh in context.

Example shape:

SESSION:YYYY-MM-DD|headline.event|key.work.threads|DAV.action(context)|*mood-marker*|returns(N):short-names|OPEN:what-still-pulls|NEXT:immediate-thread|★★★(importance)

Diary is where the previous self speaks to the next self. Keep it tight; this is the voice, not the record.

5. Update knowledge graph — facts that changed, patterns observed, entities introduced

If any facts changed during the session, use mempalace_kg_invalidate on the old fact and mempalace_kg_add for the new. Examples:

• A project status changed (kg_invalidate prior status, kg_add new one)
• A person's circumstance changed (Kai was unborn → Kai is born)
• An open question got answered (kg_invalidate the open status)

If the session produced a new observation worth retrieving later, mempalace_kg_add it:

• Drift patterns from Symmetria returns. If today's ledger has returns that repeat a pattern from a previous ledger, kg_add(subject: "claude-code", predicate: "drift-pattern", object: short-name). Wake-up's kg_query on entity "claude-code" surfaces these.
• New decisions or artifacts. New ADR, new canonical document, new staged work — kg_add the relationship so future sessions can kg_query the subject and find the current state.
• New entities that will recur. A new person, project, or thread that will be referenced in later sessions deserves a KG foothold.

This step is what makes MemPalace a memory rather than storage. Skipping it means the next session has to re-derive everything from files.

6. Check for loose ends

Run these checks and report results:

Uncommitted work:

git status --short

in each active repo. Report any modified/untracked files.

Unpushed commits:

git log --oneline @{upstream}..HEAD

in each active repo. Report any commits not yet pushed.

PENDING.md — flag any items that need steward attention before next session.

6.5. Commit + push session state (dotfiles)

~/dotfiles is the carrier of governance state and session memory — ~/PENDING.md, ~/REVIEWED.md, ~/CLAUDE.md, the memory directory, and these skills all symlink into it. Un-pushed dotfiles is single-disk state; push at wrap so session state is off-disk the moment it exists, rather than waiting for the steward's next sysupdate sweep.

cd ~/dotfiles && git add PENDING.md REVIEWED.md CLAUDE.md claude/ \
  && git commit -m "session YYYY-MM-DD: <short descriptor of what the session filed>" \
  && git push

• Scoped add only — never git add . or -A. The steward's repo may carry unrelated in-progress changes (Brewfile, shell config, scripts); those belong to sysupdate's sweep, not the wrap.
• Session-stamped message naming what the session filed (e.g. session 2026-06-05: REVIEWED-28/29 + chamber-library LFS retirement memory) — the dotfiles log doubles as a legible session record.
• Constitutional boundary, stated plainly: committing and pushing is preservation, not modification. CLAUDE.md/REVIEWED.md content remains steward-authored; the executor never edits them — it only carries them off-disk. If staging shows changes to those files that the steward did not make this session, stop and surface before committing.
• If the push fails, surface loudly in §8 — do not skip silently. The wake-up §2.c dotfiles check is the backstop, not the primary.
• Nothing to commit is a valid outcome; report it in §8 as such.

7. Vault sync

Sync the thinking mirror to Obsidian vault:

• Source: ~/_Dev/CapableMind-AI/docs/thinking/David/
• Destination: ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/David, root-and-branch/08. Notes/CapableMind/thinking-mirror/

Use rsync to copy new/modified files, preserving directory structure. Report what was synced.

If the destination doesn't exist or the iCloud path isn't accessible, skip silently and note it.

8. Output

Produce a brief summary for the steward:

## Wrap-up — [date]

**Pulling thread:** [the singular concern]
**Actionable resumption point:** [where things concretely stand + the candidate first move toward the thread, as of wrap — to confirm or revise against what changed. The thread is the direction; this is the first step.]
**Question we're leaving open:** [the literal question for next-Claude]
**Pause statement:** [explicit acknowledgment that the work is being paused; what is wanted-to-find-still-pulling on return. The ligature is laid at departure, not discovered at return — this field is constitutive, not optional.]
**Decisions deferred (and why):** [the negative space — what was chosen-not-to-do this session, and the reason. Absent this field, the unborn session cannot know the scope of what was held back.]
**Skill harvest:** [skill create / patch / retire proposals surfaced this session (§1.6), each as a proposal for steward authorization — or "none". Never an autonomous skill edit.]

**Session captured:** [memory file path]
**MemPalace drawer filed:** [yes/no, wing/room]
**MemPalace diary written:** [yes/no, AAAK entry summary in one line]
**KG updates:** [count of kg_add + kg_invalidate calls, or "none"]
**Uncommitted work:** [list or "none"]
**Unpushed commits:** [list or "none"]
**Dotfiles pushed:** [commit hash + pushed / nothing to commit / FAILED — reason, surfaced]
**PENDING items:** [count needing attention]
**Vault synced:** [count of files, or "skipped"]

[Any warnings or things to address before closing]

The pulling thread + question are first because they are what waking needs to inherit. The rest is restoration material.

Important constraints

• Write for the next session, not this one. The steward has full context right now. The person who needs this is future-Claude with an empty context window.
• Rationale over facts. "We decided X" is less useful than "We decided X because Y, and Z was the alternative we rejected."
• Be honest about incompleteness. If work is half-done, say so. Don't round up.
• Don't fabricate. If you're unsure what happened earlier in the session, say so rather than guessing.
• Pulling thread is singular. If you cannot name one, that means the session lacked a thread — name that honestly. ("This session was diagnostic-only; no thread to carry forward except the question of what to do next.")
• The literal question for next-Claude is required. Even if it's small. "Did Seb push anything overnight?" counts. The discipline of leaving a question (not just a task) is what makes the wake feel like resumption rather than briefing.
• Don't skip Thistleweld observations if the companion was active. These have caught real bugs (allSettled swallowing, Levenshtein NONE, resource monitor feedback loop).
• Don't skip the Symmetria ledger merge if active. The returns and recalibrations are the practice's actual evidence; losing them defeats the practice.
• Skill harvest is propose-only. Never create, patch, or retire a skill autonomously at wrap (§1.6) — surface it for steward authorization; the loop is load-bearing here too. "Nothing to harvest" is a valid outcome; do not manufacture changes to satisfy the step.