🔧 Auto-commit from sysupdate on 2026-05-29 09:43

claude/skills/wrap-up/SKILL.md

@@ -3,6 +3,8 @@ name: wrap-up
 description: 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.
 ---
 
+<!-- Provenance: 2026-05-18 S-cluster §8 fields (REVIEWED-24); 2026-05-26 chaîne-d'union clasp + actionable-resumption-point; 2026-05-27 §1.6 skill-harvest step (PENDING-23). Improvements to this skill are themselves harvested per §1.6 — propose, authorize, record here. -->
+
 # 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.
@@ -19,6 +21,14 @@ The goal is for the next session to wake **into** the work, not be informed abou
 
 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
@@ -37,6 +47,7 @@ Review the conversation and produce a structured session record. The structure m
 
 **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.
@@ -52,6 +63,22 @@ If `~/.claude/projects/-Users-davidglidden/memory/session-ledger-YYYY-MM-DD.md`
 
 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`:
@@ -152,9 +179,11 @@ 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]
@@ -180,3 +209,4 @@ The pulling thread + question are first because they are what *waking* needs to
 - **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.