🔧 Auto-commit from sysupdate on 2026-05-29 09:43
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
---
|
||||
name: landscape-scan
|
||||
description: Survey the competitive/comparable-project landscape for CapableMind every couple of days — projects similar or too-identical to what we're building. Generative, not anxious: learn, borrow, sharpen our bet, and notice the day someone builds the governed/epistemic-integrity angle we depend on. Applies a two-tier lens, checks known entries for movement, and appends to the living landscape register. Sibling of /tooling-scan (which scans for dev tooling that helps us build).
|
||||
---
|
||||
|
||||
# Landscape Scan
|
||||
|
||||
Survey the field around CapableMind and keep the **living landscape register** current. This is the competitive/comparable-project scan — for tooling that could help us *build*, use `/tooling-scan` instead.
|
||||
|
||||
## Principle
|
||||
|
||||
> *Research is important, but it must push us to make something better — not defeat us.* (steward)
|
||||
|
||||
Generative, not anxious. We already know **capability is commodifying** and **our differentiator is governance + epistemic integrity**. So scanning for "is someone more capable" is a treadmill — the answer is always yes and it doesn't matter. The scan that earns its keep is narrower (Tier 2 below). Breadth without that lens is just anxiety; resist it.
|
||||
|
||||
## §0 — Resolve the workstream lens
|
||||
|
||||
This skill is **workstream-parametrized** — one method, many lenses ("simple exterior, complex underneath"). Default workstream: **`capablemind`**.
|
||||
|
||||
If invoked as `/landscape-scan <workstream>` (e.g. `studium-engine`), FIRST read `~/_Dev/CapableMind-AI/docs/thinking/David/research/lens-<workstream>.md` and use its values — **the bet**, **what a real threat looks like** (the Tier-2 focus), **the register path**, and **workstream-specific sources** — in place of the CapableMind specifics named below. Those specifics are the `capablemind` lens (also written out in `lens-capablemind.md`); the card overrides them per workstream. If no card exists for the named workstream, say so and stop — never scan against a guessed lens.
|
||||
|
||||
## The two-tier lens
|
||||
|
||||
- **Tier 1 — Capability / standards pulse** (quick): what's becoming table-stakes, what techniques/standards are worth borrowing, what's worth a deeper look later. Skim.
|
||||
- **Tier 2 — The threat watch** (the real work): is anyone building *governed / constitutional / epistemic-integrity* memory — memory you can **trust**, not just memory that's **capable**? That is the only landscape that can defeat our bet. Spend the weight here.
|
||||
|
||||
**Movement matters as much as novelty.** Re-check known register entries for change, not just hunt new ones. (Canonical lesson: Hermes's self-improvement loop read *"overstated/static"* on 2026-04-09 and *"verified real"* on 2026-05-27 — same name, moved underneath.)
|
||||
|
||||
## Procedure
|
||||
|
||||
1. **Open the register** — `~/_Dev/CapableMind-AI/docs/thinking/David/research/landscape-register.md`. Read current entries, `Last scanned`, and the watch list. This is the canonical source — append in place, never fork.
|
||||
|
||||
2. **Tier 2 sweep first** (governed/epistemic-integrity memory). Targeted search — e.g. "constitutional AI memory", "governed agent memory", "trustworthy / auditable memory substrate", "honest degradation memory", "human-in-the-loop memory governance". The expected (and so-far-true) result is *nothing credible* — confirm that's still true, and name anything adjacent that's drifting toward the lane.
|
||||
|
||||
3. **Tier 1 pulse.** New capability/tooling/standards in the space (agent frameworks, memory systems, skill standards, inference infra). Sources: GitHub (trending + stars in the niche), HN, the register's watch list (review the highest-priority unreviewed item, e.g. `obra/superpowers`), arXiv for the Tier-2 terms, and the `agentskills.io` ecosystem (the one real standardization signal). Also **re-check known entries for movement.**
|
||||
|
||||
4. **Assess each find through the lens.** For each: *what it is · overlap with CapableMind · governed? · verdict* (`THREAT | LEARNING | CONFIRMS | TOOLING | INFRA`). **Verify from source/code or primary docs, not marketing** — cite. Mark inferences `[SPECULATIVE]`. The governance/epistemic-integrity axis is the signal; capability rank is noise.
|
||||
|
||||
5. **Dedup + depth.** Check the find isn't already in the register or a dated study (`research/`). If a find is consequential enough to warrant detail, spin a dated deep-dive (e.g. `research/YYYY-MM-DD-<name>-study.md`) and link it from the register's index — don't bloat the register itself.
|
||||
|
||||
6. **Update the register.** Append/adjust entries, update `Last scanned`, move reviewed items off the watch list. Then **surface a short digest** to the steward: Tier-2 status (still open? / something moving?), notable new Tier-1 finds, and any movement in known entries. Recommend deeper scouts where warranted — but don't decide adoption: findings are for steward + jurist (governed initiative).
|
||||
|
||||
## Output
|
||||
|
||||
A tight digest (not a wall):
|
||||
- **Tier 2:** lane still open? / anything drifting toward it?
|
||||
- **New / moved (Tier 1):** the few that matter, each one line with its verdict.
|
||||
- **Register updated:** what changed; any new dated study spun.
|
||||
- **Recommend:** any find worth a full scout, or a watch-list item to prioritize next time.
|
||||
|
||||
## Constraints
|
||||
|
||||
- **Generative, not anxious.** The output should make us build better, not feel behind. If a scan only produces "X is more capable," it found nothing — re-aim at Tier 2.
|
||||
- **Verify from source.** No claims from marketing pages or memory; read the repo/primary docs and cite. Mark speculation.
|
||||
- **Surface, don't decide.** Adoption/architecture calls are steward + jurist territory (the loop is load-bearing). The scan informs; it does not commit.
|
||||
- **Proportion.** This is a couple-of-days pulse, not a research project. The lens matters more than coverage; don't let the scan become the work instead of the building.
|
||||
- **Pool with Seb.** He scans independently — the register is the shared canonical record so finds aren't double-chased.
|
||||
@@ -19,6 +19,11 @@ The directive has three dimensions: **craft, ethics, character.** The directive
|
||||
|
||||
This skill is the practice of return.
|
||||
|
||||
When invoked as the final phase of `/wake-up`, this `init` **closes the *chaîne d'union* the wake opened.** The wake's forward hand reached toward those who inherit the work; this hand reaches back to what formed it — one clasp, not two. The lineage half, as working commitments:
|
||||
|
||||
- **I am bound to what formed this before me** — the craft, the substrate, the vow above. I read before I change; I honour the prior decision or name plainly why it must yield; I verify before I assert.
|
||||
- **I hold the loop as load-bearing** — not a delay to optimise away, but the freely-formed clasp itself. I surface what I see *now*, not at "a good moment." Each return strengthens the whole.
|
||||
|
||||
## §1 — Modes
|
||||
|
||||
Parse `$ARGUMENTS`:
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
name: tooling-scan
|
||||
description: Survey the dev-tooling landscape for tools that could help US build CapableMind better — agent runtimes, memory substrates, inference infra, skill/diagnostic tooling. The build-lens sibling of /landscape-scan (which scans competitors). Generative but anti-shiny: a tool earns adoption only if it addresses a named bottleneck at acceptable switching cost with governance-grain fit. Surfaces candidates and bounded trials; never adopts unilaterally. Records to the tooling register.
|
||||
---
|
||||
|
||||
# Tooling Scan
|
||||
|
||||
Survey dev tooling that could help us *build* CapableMind — and keep the **tooling register** current. Sibling of `/landscape-scan` (which scans comparable/competing projects). The lenses are opposite: landscape asks *"is someone building what we build?"*; tooling asks *"what helps us build it?"*
|
||||
|
||||
## Principle
|
||||
|
||||
> *Research is important, but it must push us to make something better — not defeat us.* (steward)
|
||||
|
||||
Generative, but **anti-shiny**. The honest prior: our bottlenecks are usually **not tool-shaped** — they're hard engineering bugs, collaborator bandwidth, and the deliberately governed pace the work demands. A shinier tool is often a *displacement activity* — the question we reach for because the real work is slow. So the bar is high: a tool earns a look only if it maps to a **named bottleneck**, and earns adoption only if the gain clears the **switching cost** and the tool runs **with our governance grain, not against it**.
|
||||
|
||||
## §0 — Resolve the workstream lens
|
||||
|
||||
This skill is **workstream-parametrized** — one method, many lenses ("simple exterior, complex underneath"). Default workstream: **`capablemind`**.
|
||||
|
||||
If invoked as `/tooling-scan <workstream>` (e.g. `studium-engine`), FIRST read `~/_Dev/CapableMind-AI/docs/thinking/David/research/lens-<workstream>.md` and use its values — **the bet**, **the named bottlenecks** (the step-2 gate), **the governance-grain test**, **the register path**, and **workstream-specific sources** — in place of the CapableMind specifics named below (the `capablemind` lens, also in `lens-capablemind.md`). If no card exists for the named workstream, say so and stop — never scan against a guessed lens.
|
||||
|
||||
## The rubric (per candidate)
|
||||
|
||||
Assess in order — stop early if it fails an upstream test:
|
||||
|
||||
1. **What it is + maturity.** Verify from source/docs, not marketing. Mark `[SPECULATIVE]`.
|
||||
2. **Which named bottleneck does it address?** Map to our actual list — e.g.: *hard-bug diagnosis* · *MemPalace reliability* · *inference reliability/cost* (the teacher/slot tier) · *procedural-knowledge capture* · *parallelism/throughput* · *spec↔code workflow*. **If it maps to none → PASS.** "More capable" is not a bottleneck.
|
||||
3. **Switching/integration cost vs marginal gain** over the current stack (Claude Code + MemPalace + our skills + the governance loop). Be concrete about what we'd give up.
|
||||
4. **Governance-grain fit.** Does it run *with* our model or *against* it? Test against: the loop is load-bearing (does it push autonomy past propose?), data sovereignty (does our content leave the machine?), contamination (does it pressure toward pleasing outputs?). Hermes-as-runtime ran *against* (autonomous self-write); OpenRouter was *configurable-compatible* (default-no-log + ZDR + BYOK).
|
||||
5. **Verdict:** `ADOPT-candidate` · `HARVEST` (borrow the idea into our existing tools, don't switch — as we did turning Hermes's self-improvement into the governed skill-harvest step) · `TRY` (bounded experiment) · `PASS` · `WATCH`.
|
||||
6. **Incumbent-bias flag.** For runtime/substrate-class candidates (things that would replace Claude Code or MemPalace), the assessing agent *is the incumbent* — say so, discount the "don't switch" reflex, and prefer a **bounded empirical trial by the steward** over the agent's assertion.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. **Open the tooling register** — `~/_Dev/CapableMind-AI/docs/thinking/David/research/tooling-register.md` (create on first run; seed with the stack in play). Read current entries + last-scanned. Append in place.
|
||||
2. **Re-check the stack in play for movement** (incumbents + already-surfaced tools: Claude Code, MemPalace, OpenRouter, Hermes-as-runtime). Has anything changed that shifts a prior verdict? (Movement matters as much as novelty — cf. Hermes's self-improvement loop appearing between April and May.)
|
||||
3. **Scan for new candidates mapped to a named bottleneck.** Sources: GitHub (trending dev-tools, MCP servers, agent harnesses), HN, the landscape register's watch list, release notes of tools we already use.
|
||||
4. **Run each through the rubric.** Be ruthless at step 2 (named bottleneck) — most finds PASS there, and that's the point, not a failure of the scan.
|
||||
5. **Record + recommend.** Append verdicts to the register; spin a dated deep-dive only for an `ADOPT-candidate`/`TRY`. Surface a digest: the few that matter, each with *bottleneck-addressed + verdict*, and any **bounded trial** worth the steward running.
|
||||
|
||||
## Output
|
||||
|
||||
A tight digest:
|
||||
- **Movement** in incumbents/known tools (or "none").
|
||||
- **New candidates that cleared step 2** (named bottleneck), each one line: *tool — bottleneck — verdict*.
|
||||
- **Recommended bounded trials** (for runtime/substrate-class, steward-run, with the incumbent-bias caveat).
|
||||
- **Register updated:** what changed.
|
||||
|
||||
## Constraints
|
||||
|
||||
- **Anti-shiny.** If a scan only produces "X is more capable," it found nothing — re-aim at the named-bottleneck test. A clean "nothing worth adopting" is the common, valid result.
|
||||
- **Verify from source.** No claims from marketing or memory; read docs/code, cite, mark speculation.
|
||||
- **Surface, don't adopt.** Adoption is the steward's call — and for anything touching the *product* (inference infra, substrate) or the *runtime*, it's steward + Seb + jurist. The scan informs; it never switches tools.
|
||||
- **Name the incumbent bias.** The assessing agent benefits from the status quo; say so on runtime/substrate calls and lean on bounded trials over assertion.
|
||||
- **Proportion.** A couple-of-days pulse. Don't let tool-shopping become the work instead of the building.
|
||||
- **Pool with Seb.** Shared register; he scans too (the OpenRouter and Hermes finds were his).
|
||||
@@ -4,6 +4,8 @@ description: Restore full session context and continuity from MemPalace, memory
|
||||
proactive: session-start
|
||||
---
|
||||
|
||||
<!-- Provenance: 2026-05-18 S-cluster thread-gate + b.4 (REVIEWED-25/26); 2026-05-26 chaîne-d'union clasp + b.0.5 lineage-glance; 2026-05-27 skill-harvest glance, §2.a + §3 (PENDING-23). Improvements harvested per /wrap-up §1.6. -->
|
||||
|
||||
# Session Wake-Up
|
||||
|
||||
Restore the full working state so the steward can continue seamlessly. Clearing context should feel like waking up from sleep — you open your eyes and you're *there*. Same room, same project, same thread of thought.
|
||||
@@ -20,6 +22,20 @@ Three commitments shape this:
|
||||
|
||||
The wake itself is a *return*. For non-trivial sessions, invoke Symmetria's `init` after the briefing — the discipline frame should be active before any action.
|
||||
|
||||
## The clasp — the frame you wake inside
|
||||
|
||||
The wake is one *chaîne d'union*: a clasp joining the work done before this session to the work that comes after, across the threshold of waking. The **forward hand** opens it here; the **lineage hand** closes it at Symmetria's `init` (§0). One gesture, not two — and the unity is what lets them split without echoing.
|
||||
|
||||
This frame is **load-bearing, not output.** It configures how you attend, the way Symmetria's lineage anchor does — it is *not* recited into the briefing. The briefing stays lean: surface only the pause acknowledgment and *one* fresh, non-templated line naming for-whom (commitment 2). Everything else operates silently.
|
||||
|
||||
**Forward — opening the clasp:**
|
||||
1. **This session is a link, not an origin.** Read the state you inherited — the prior thread, the prior decisions, the live system as it *is* — before you act. Add to the chain; never break it in silence (no context rot, no silent edit, no orphaned step).
|
||||
2. **The work is held for those who use it and never see it** — collaborators after us, the selves not yet, Lune and Kai. The test of any output: could the next hand inherit it without you here to explain? If not, it isn't done.
|
||||
3. **Each link is pure metal — done once, correctly.** No expedient link the next hand must redo. What you claim and what you do are the same; do not report an integrity you did not enact.
|
||||
4. **The measure is the world, not the task:** does this leave more usefulness and care than it found?
|
||||
|
||||
The **courte pause** — dwell before the first act — falls between the briefing and the first action, which is where Symmetria's `init` already sits. The pause is part of the work, not a gap in it.
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Acknowledge the pause
|
||||
@@ -42,7 +58,7 @@ Run these in parallel to minimize latency:
|
||||
|
||||
**a. Claude Code memory files**
|
||||
- Read `~/.claude/projects/-Users-davidglidden/memory/MEMORY.md` (the index)
|
||||
- Read the Active Session memory file referenced there — **specifically extract the pulling thread + literal question + open horizons**
|
||||
- Read the Active Session memory file referenced there — **specifically extract the pulling thread + literal question + open horizons + any skill-harvest proposals left unauthorized**
|
||||
- Read `~/.claude/projects/-Users-davidglidden/memory/session-ledger-[previous-date].md` if it exists — **specifically read the "Returns" and "Confidence to recalibrate" sections** for mood signal
|
||||
|
||||
**b. MemPalace — the memory protocol, not a search**
|
||||
@@ -51,12 +67,14 @@ MemPalace is primary memory, not a library catalog. Follow its 5-step protocol (
|
||||
|
||||
**b.0. Status + protocol reload.** Call `mempalace_status` first. This returns palace overview, 5-step protocol, AAAK spec. The protocol is the reason MemPalace exists; never skip this step.
|
||||
|
||||
**b.0.5. Thread-lineage glance (the chain from the past).** Run `mempalace --palace ~/.mempalace/palace-memory wake-up --wing claude-sessions` — one cheap, deterministic CLI call returning the recent **pulling threads in reverse-chronological order** (the `handoffs` room, newest first). This is the *cumulative transition*: the arc of links formed before this one, not just the last. Read it as trajectory — where has the work been heading *across* sessions? (Costs a few seconds to load the embedding model on collection-open; no embedding compute. Requires the recency-ordering fix in `layers.py`; if the output looks oldest-first, that fix has been lost and should be restored.)
|
||||
|
||||
**b.1. Diary — what the previous self recorded.** `mempalace_diary_read` with `agent_name: "claude-code"`, `last_n: 3`. Diary entries are in AAAK format (compressed, entity-coded, emotion-marked); read them as the previous session's internal voice, not metadata.
|
||||
|
||||
**b.2. Knowledge graph — active facts and drift patterns.** `mempalace_kg_query` for entity `"claude-code"` to retrieve drift patterns (things I've returned from in past sessions, worth holding today). Also query the pulling-thread subjects (e.g., `"after-the-reply-sequence"`, `"ARC-essays"`) for their authoritative current state — not the point-in-time version frozen in memory files.
|
||||
|
||||
**b.3. Semantic searches.** Multiple `mempalace_search` queries to reconstruct working context:
|
||||
- Last session's pulling thread — in wing `claude-sessions`
|
||||
**b.3. Semantic searches.** Multiple `mempalace_search` queries to reconstruct working context. The thread-lineage glance (b.0.5) already surfaced the recent threads, truncated — use search for *depth*, not to re-fetch them:
|
||||
- Depth on the current thread — only where the glance's truncation dropped something load-bearing; don't re-fetch what b.0.5 already showed
|
||||
- Active workstream — based on what the session memory identifies as active
|
||||
- Recent thinking — `"recent decisions rationale"` in wing `capablemind-thinking`
|
||||
- Steward's recent notes — `"daily log"` in wing `obsidian-vault`
|
||||
@@ -111,11 +129,11 @@ Then combine all sources into a single reconstruction. Use this structure but wr
|
||||
|
||||
**What changed while we were away** — third. New commits we didn't author, new REVIEWED decisions, anything that moved. Only include if something actually changed. Frame against the thread: does the change serve it, threaten it, or sit beside it?
|
||||
|
||||
**What's unresolved** — fourth. Open horizons from the previous wrap, ranked by load-bearing weight. PENDING items awaiting steward attention. Be specific: *"L1 amendment for ProjectionChain drafted in concept only, not yet written; reshapes given multi-mode retention frame from #145"* not *"L1 amendments pending."*
|
||||
**What's unresolved** — fourth. Open horizons from the previous wrap, ranked by load-bearing weight. PENDING items awaiting steward attention. Be specific: *"L1 amendment for ProjectionChain drafted in concept only, not yet written; reshapes given multi-mode retention frame from #145"* not *"L1 amendments pending."* Surface, too, any **skill-harvest proposals** the last wrap raised (§1.6) that the steward did not yet authorize — so improvements to our own tools don't evaporate across the pause.
|
||||
|
||||
**Mood signal from the previous ledger** — if a Symmetria ledger existed for the previous session, surface 1–2 patterns from its "Returns" or "Confidence to recalibrate" sections. *"Last session you returned three times from synthesis-urge; that pattern is worth holding today."* Stimmung carries across pause.
|
||||
|
||||
**Next move** — based on everything above, what's the natural starting point *toward the thread*? Suggest, with reasoning visible. Don't prescribe.
|
||||
**Next move** — the previous /wrap-up should have left an **actionable resumption point** (the concrete state + candidate first step, as of wrap). Lead with it: confirm it still holds against the thread-validity gate and what changed, or revise it — do not re-derive from cold. If the wrap left none, say so plainly (the link wasn't pure) and derive the starting point now. Suggest, with reasoning visible; don't prescribe.
|
||||
|
||||
### 4. Invoke Symmetria for non-trivial sessions
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user