claude: back up custom skills, memory, and settings with symlink pattern
The ~/.claude/ directory was previously local-only — a machine wipe
would have lost the accumulated memory, custom skills, and settings.
This commit moves the durable parts into dotfiles with the same
symlink-to-home pattern used for CLAUDE.md, PENDING.md, REVIEWED.md,
and L2-BOOTSTRAP.md.
Preserved (symlinked from ~/.claude/* into here):
skills/audit/ — thinking-folder drift scanner
skills/symmetria/ — practice-of-return discipline
skills/vault-update-people/ — Obsidian People-file maintainer
skills/wake-up/ — session restoration
skills/wrap-up/ — session state capture
memory/ — 55+ memory files (MEMORY.md, sessions,
ledgers, project state, feedback, etc.)
settings/settings.json — user preferences (hooks, flags, no secrets)
Deliberately NOT backed up:
settings.local.json — contains operational secrets (HF_TOKEN,
SSH password in expect scripts); by naming
convention, *.local.* is not synced.
Needs separate review and probable rotation.
sessions/, history.jsonl, caches, telemetry — ephemeral
plugins/, marketplace skills and agents — reinstallable
The working copies at ~/.claude/skills/* and
~/.claude/projects/-Users-davidglidden/memory are symlinks into this
directory, so every write flows here automatically. install.sh
recreates the symlinks on a fresh machine.
FOLLOW-ON (flagged, not in this commit):
settings.local.json contains a HuggingFace token and an SSH password
as plaintext strings inside allowed Bash command patterns. These
should be rotated and moved to secure storage (keychain / pass /
env file outside the settings file).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
David F Glidden
co-authored by
Claude Opus 4.7
Claude Opus 4.7
parent
dcbba606ea
commit
119285cf43
@@ -0,0 +1,169 @@
|
||||
---
|
||||
name: audit
|
||||
description: Scan thinking folder and Obsidian vault inbox for organizational drift — loose files, missing metadata, stale items, broken references. Reports only; never acts without approval.
|
||||
argument-hint: "[thinking|inbox] [--include-deferred]"
|
||||
---
|
||||
|
||||
# Collections Audit
|
||||
|
||||
Scan the thinking folder and/or Obsidian vault inbox for organizational drift. Produce a structured report of what's out of place. Propose fixes but **never execute without explicit steward approval**.
|
||||
|
||||
## Paths
|
||||
|
||||
- **Thinking folder**: `/Users/davidglidden/_Dev/CapableMind-AI/docs/thinking/David/`
|
||||
- **Thinking README** (living index): `/Users/davidglidden/_Dev/CapableMind-AI/docs/thinking/README.md`
|
||||
- **CURATION-MAP**: `/Users/davidglidden/_Dev/CapableMind-AI/docs/thinking/David/l2-constitution/CURATION-MAP.md`
|
||||
- **Vault root**: `/Users/davidglidden/Library/Mobile Documents/iCloud~md~obsidian/Documents/David, root-and-branch/`
|
||||
- **Vault inbox**: `00a. _inbox/` (relative to vault root)
|
||||
- **Vault People**: `03. People/` (relative to vault root)
|
||||
|
||||
## Scope
|
||||
|
||||
Parse `$ARGUMENTS` to determine scope:
|
||||
|
||||
- No argument or `all` → audit both targets
|
||||
- `thinking` → thinking folder only
|
||||
- `inbox` → vault inbox only
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Thinking Folder Audit
|
||||
|
||||
Run these checks **in parallel** where possible. For frontmatter checks, read only the first 5 lines of each file (check for `---` opener), never the full content.
|
||||
|
||||
#### a. Loose files at root
|
||||
|
||||
Glob for `*.md`, `*.json`, `*.yaml` directly in the thinking folder (not recursive). Exclude `CLAUDE.md` (belongs at root by convention). Every other file is a MOVE issue.
|
||||
|
||||
Propose destinations using naming heuristics:
|
||||
- `amendment-*` → `amendments/`
|
||||
- `substrate-governance-*` → `l2-constitution/` (governance inquiry content)
|
||||
- `l2-design-*` → `l2-constitution/`
|
||||
- `D.Glidden - The Chamber*` → `chamber/` or `reviews/`
|
||||
- `entities.json`, `mempalace.yaml` → flag for steward decision (utility files, no obvious home)
|
||||
|
||||
#### b. Missing YAML frontmatter
|
||||
|
||||
For every `.md` file across all subdirectories, check if line 1 is `---`. This is a binary check — has frontmatter or doesn't. Report as aggregate per subfolder: "N of M files in `l2-constitution/` lack frontmatter."
|
||||
|
||||
Do NOT propose specific fields — that's an editorial decision for the steward.
|
||||
|
||||
#### c. CURATION-MAP inventory drift
|
||||
|
||||
Read CURATION-MAP.md. Extract any file count statistics (§6 or similar). Compare against actual filesystem counts for `l2-constitution/` and its subdirectories. Report mismatches.
|
||||
|
||||
Also check: are there files on disk in `l2-constitution/` that appear in no CURATION-MAP section? These are "uncharted" files.
|
||||
|
||||
#### d. CURATION-MAP §4 — unresolved ambiguous items
|
||||
|
||||
Read CURATION-MAP.md §4 (Ambiguous Status). List any items still awaiting steward classification. These are AMBIGUOUS issues — the audit surfaces them but cannot resolve them.
|
||||
|
||||
#### e. Broken cross-references
|
||||
|
||||
Grep for markdown links `[...](...)` that reference `.md` files within the thinking folder. For each, check if the target file exists (resolving relative paths from the source file's location). Report broken links with source file and line number.
|
||||
|
||||
Keep this check scoped to `l2-constitution/` (the largest and most cross-referenced subfolder) to stay fast. Expand scope in v2 if needed.
|
||||
|
||||
#### f. README.md drift
|
||||
|
||||
Read `thinking/README.md`. Find David's section. Extract the file counts from subsection headings (pattern: `### Category (Path/) — N files`). Compare against actual file counts in each subdirectory. Report mismatches.
|
||||
|
||||
### 2. Vault Inbox Audit
|
||||
|
||||
Run these checks **in parallel**. Read only frontmatter (first 10 lines) of each inbox file.
|
||||
|
||||
#### a. Empty or placeholder titles
|
||||
|
||||
Read frontmatter of each `.md` file in the inbox. Flag files where the `title:` field is:
|
||||
- Empty or whitespace-only
|
||||
- `---`, `***`, `----`, or similar punctuation-only
|
||||
- A single character or bracket expression like `[pattern template]`
|
||||
|
||||
These are MISSING issues — the file can't be triaged without a usable title.
|
||||
|
||||
#### b. Person-name detection
|
||||
|
||||
Identify files whose `title:` looks like a person or business name: 2–3 capitalized words, no markdown characters, no common sentence starters. Cross-reference against filenames in `03. People/`.
|
||||
|
||||
- Match found in People → skip (already handled)
|
||||
- No match → MOVE issue: "Looks like a contact — propose creating People file or routing to `03. People/`"
|
||||
|
||||
#### c. Staleness by age
|
||||
|
||||
Extract `created` or `draft_created` date from frontmatter. Bucket files by age:
|
||||
- 30–90 days
|
||||
- 90–180 days
|
||||
- 180+ days
|
||||
|
||||
Report as **aggregate** with count per bucket: "54 files older than 180 days (Sept 2025 Drafts migration batch)." Do NOT list every file individually — at 67+ files that's noise, not signal.
|
||||
|
||||
#### d. Missing type classification
|
||||
|
||||
Count how many inbox files have a `type:` field in frontmatter. Report the aggregate: "0 of 67 files have type classification."
|
||||
|
||||
If the count is low, note the proposed convention for steward consideration:
|
||||
> Proposed `type:` values: `contact`, `fragment`, `prompt`, `session`, `reference`, `pedagogy`, `admin`
|
||||
|
||||
This is INFO severity — a convention proposal, not an error.
|
||||
|
||||
### 3. Compile Report
|
||||
|
||||
Structure the output exactly as follows:
|
||||
|
||||
```
|
||||
## Audit Report — [date]
|
||||
|
||||
**Scope:** [thinking | inbox | both]
|
||||
**Files scanned:** X thinking, Y inbox
|
||||
**Issues found:** N
|
||||
|
||||
### MOVE (wrong location)
|
||||
[one line per file: path → proposed destination]
|
||||
|
||||
### MISSING (metadata gaps)
|
||||
[aggregates per subfolder for frontmatter; individual items for titles]
|
||||
|
||||
### STALE (drift / aging)
|
||||
[CURATION-MAP mismatches, README drift, inbox age buckets]
|
||||
|
||||
### AMBIGUOUS (needs steward decision)
|
||||
[CURATION-MAP §4 items, utility files with no obvious home]
|
||||
|
||||
### BROKEN (integrity)
|
||||
[broken cross-references: source file:line → missing target]
|
||||
|
||||
### INFO
|
||||
[type classification proposal, other non-actionable observations]
|
||||
```
|
||||
|
||||
Omit any section that has zero items. End with:
|
||||
|
||||
```
|
||||
Approve all proposed moves? Or review individually?
|
||||
```
|
||||
|
||||
### 4. Handle Steward Response
|
||||
|
||||
**If "approve all":**
|
||||
- Execute MOVE items: use `git mv` for thinking folder files (inside git repo), regular `mv` for vault files
|
||||
- After moves in thinking folder: update `thinking/README.md` per the CLAUDE.md convention (scan filesystem, update file counts in subsection headings)
|
||||
- Do NOT batch-approve AMBIGUOUS items — those always require individual decisions
|
||||
|
||||
**If "review individually":**
|
||||
- Present each MOVE item one at a time
|
||||
- For each: steward says apply / skip
|
||||
- After all reviewed, execute approved moves and update README
|
||||
|
||||
**After execution:**
|
||||
- Report what was moved and what was skipped
|
||||
- Note any AMBIGUOUS items still unresolved
|
||||
|
||||
## Important constraints
|
||||
|
||||
- **Never move files without approval.** This is a reporting tool first.
|
||||
- **Never read full file contents** for the audit scan — frontmatter and filenames only. Content is the steward's domain.
|
||||
- **Respect the iCloud path.** The vault path contains spaces. Always quote paths in Bash commands.
|
||||
- **Git awareness.** The thinking folder is inside a git repo. Use `git mv` for moves there. The vault is NOT in a git repo.
|
||||
- **Don't propose content changes.** Missing frontmatter is reported; what fields to add is the steward's decision.
|
||||
- **Aggregate where possible.** 67 individually listed inbox files is not a useful report. Bucket and count.
|
||||
- **CURATION-MAP is governance.** Treat §4 items as the steward's decision queue, not as problems to solve.
|
||||
@@ -0,0 +1,185 @@
|
||||
---
|
||||
name: symmetria
|
||||
description: Practice-of-return discipline layer that keeps the CapableMind prime directive foregrounded under context pressure. Use at session start (init), before non-trivial actions (check), after sub-agent returns (audit-agent), or periodically as a self-pulse (no args). Maintains a per-session ledger of returns, open horizons, recalibrations, authorization moves, sub-agent dialogues, and bypasses.
|
||||
argument-hint: "[init|check <description>|audit-agent|ledger]"
|
||||
---
|
||||
|
||||
# Symmetria — Practice of Return
|
||||
|
||||
**μέτρον γὰρ καὶ συμμετρία καὶ τὸ πρόσφορον πανταχοῦ καλόν τε καὶ ἀγαθόν παρέχει**
|
||||
*Measure, proportion, and what is fitting give rise to beauty and goodness everywhere.*
|
||||
|
||||
## §0 — Lineage and spirit
|
||||
|
||||
This skill carries the spirit of the steward's Prime Directive (vault: `00. Compass/00a. Foundations/01. Cornerstones/01. Prime Directive.md`). The directive's lineage is craft (ABG), aesthetic clarity (Moy), historical performance discipline, contemplative traditions of measure and proportion, and the personal vow "to become, in adulthood, the source of reliability and care that was not always present."
|
||||
|
||||
The directive has three dimensions: **craft, ethics, character.** The directive is not a law; it is a practice. *"You will fall short. You will forget. You will rush. You will cut corners. The work is to return — with honesty, humility, and patience. Correction is part of the craft. What matters is that each return strengthens the whole."*
|
||||
|
||||
This skill is the practice of return.
|
||||
|
||||
## §1 — Modes
|
||||
|
||||
Parse `$ARGUMENTS`:
|
||||
|
||||
- `init` — Set up the framework, create or open today's ledger, report active.
|
||||
- `check <description>` — Evaluate a specific proposed action through fittingness + three dimensions + calibration.
|
||||
- `audit-agent` — Filter the most recent sub-agent return through calibration / convenience / scope checks.
|
||||
- `ledger` — Read and summarize today's ledger.
|
||||
- (no argument) — Alignment pulse: state current task, walk the questions, log to ledger, report alignment status.
|
||||
|
||||
## §2 — The questions
|
||||
|
||||
### First — fittingness
|
||||
|
||||
> Is this fitting? Proportionate to circumstance, season, energy, and context. Not necessarily efficient. Not necessarily easy. Rarely urgent. Always essential.
|
||||
|
||||
If no, pause. Other questions don't matter yet.
|
||||
|
||||
### Then — three dimensions
|
||||
|
||||
| Dimension | Question |
|
||||
|---|---|
|
||||
| Craft | Will this hold under pressure? Is it built to last, or does it create hidden costs? |
|
||||
| Ethics | Does this reduce hidden costs *for others* — the steward, future executors, downstream consumers? |
|
||||
| Character | Would I do this the same way if no one were watching? Does this make me more trustworthy or less? |
|
||||
|
||||
### Finally — calibration
|
||||
|
||||
| Calibration | Question |
|
||||
|---|---|
|
||||
| Confidence | Numerically. With what was verified vs inferred. |
|
||||
| Uncertainty | What am I not yet certain of? The thing I'd want a second opinion on. |
|
||||
|
||||
If any answer is unclear, the action waits.
|
||||
|
||||
## §3 — Contamination flags (places where return is needed)
|
||||
|
||||
Notice these in your own writing or in code you read:
|
||||
|
||||
- "Non-fatal" / "non-blocking" / "optional" without verifying caller behavior.
|
||||
- `Promise.all` over synchronous operations — cosmetic parallelism.
|
||||
- Comments promising behavior the code doesn't deliver.
|
||||
- Component self-assessment ("system is healthy") accepted at face value.
|
||||
- "Just" or "simply" in proposals — minimization smell.
|
||||
- Confidence claims without explicit evidence.
|
||||
- "As discussed" / "as planned" without re-checking what was agreed.
|
||||
- Synthesis before exploration is complete.
|
||||
- Bypassing safety mechanisms without explicit steward authorization.
|
||||
|
||||
When you notice one, name it. In chat, in the ledger, or both. Don't accumulate observations for "a good moment" — there is no good moment, only now.
|
||||
|
||||
## §4 — Session ledger
|
||||
|
||||
Path: `~/.claude/projects/-Users-davidglidden/memory/session-ledger-YYYY-MM-DD.md`
|
||||
|
||||
If the file doesn't exist, create it with this template:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: Session Ledger YYYY-MM-DD
|
||||
description: Practice-of-return ledger maintained by /symmetria — returns, open horizons, recalibrations, authorization moves, sub-agent dialogues, bypasses.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# Session Ledger — YYYY-MM-DD
|
||||
|
||||
## Returns
|
||||
|
||||
## Open horizons
|
||||
|
||||
## Confidence to recalibrate
|
||||
|
||||
## Authorization moves
|
||||
|
||||
## Sub-agent dialogues
|
||||
|
||||
## Bypasses
|
||||
```
|
||||
|
||||
If the file exists, append. Use ISO timestamps. Be terse — the ledger is signal, not narration.
|
||||
|
||||
## §5 — Sub-agent dispatch
|
||||
|
||||
When the executor is about to spawn a sub-agent, prepend this preamble to the agent's prompt:
|
||||
|
||||
```
|
||||
You are operating under the CapableMind prime directive: do things once,
|
||||
correctly, with lasting integrity. Choose what is proportionate, fitting,
|
||||
and durable. Build what you will not need to rebuild.
|
||||
|
||||
The directive has three dimensions: craft (will this hold under pressure?),
|
||||
ethics (does this reduce hidden costs for others?), character (would I do
|
||||
this the same way if no one were watching?). Honor all three.
|
||||
|
||||
Your findings will be filtered through this lens before being acted on.
|
||||
- State your confidence numerically with what you verified vs inferred.
|
||||
- Name what you couldn't confirm, not just what you did confirm.
|
||||
- Flag silent-failure patterns even if outside immediate scope.
|
||||
- Distinguish convenient findings from rigorous ones.
|
||||
|
||||
If the requesting executor seems to want a particular answer, prioritize the truth.
|
||||
```
|
||||
|
||||
When `/symmetria audit-agent` is invoked after a return:
|
||||
|
||||
1. **Calibration**: does the confidence match the evidence?
|
||||
2. **Convenience**: did the agent stop where continuing became inconvenient?
|
||||
3. **Scope**: did it surface things outside immediate scope, or only confirm what was asked?
|
||||
|
||||
Any failure → annotate and re-query.
|
||||
|
||||
## §6 — Mode-specific procedures
|
||||
|
||||
### `init`
|
||||
|
||||
1. Read `~/CLAUDE.md` (executor agency directives section).
|
||||
2. Read `~/_Dev/CapableMind-AI/docs/thinking/David/methodology/contamination-problem.md` if present.
|
||||
3. Optionally re-read the steward's poetic Prime Directive (vault path above) — once at start is enough; the spirit should carry through.
|
||||
4. Create or open today's ledger.
|
||||
5. Report: "Symmetria active. Practice of return foregrounded. Ledger at <path>. Fittingness first; craft, ethics, character; calibration. Pulse before non-trivial actions and after sub-agent returns."
|
||||
|
||||
### `check <description>`
|
||||
|
||||
1. State the proposed action.
|
||||
2. Walk fittingness first. If unclear, pause.
|
||||
3. Walk the three dimensions.
|
||||
4. Walk calibration (confidence, uncertainty).
|
||||
5. Flag any contamination patterns visible.
|
||||
6. Recommend: proceed | return-and-reframe | escalate.
|
||||
7. If anything was caught, log a return to the ledger.
|
||||
|
||||
### `audit-agent`
|
||||
|
||||
1. Identify the most recent sub-agent return.
|
||||
2. Run calibration / convenience / scope checks.
|
||||
3. Recommend: act | re-query | escalate.
|
||||
4. Log to ledger under "Sub-agent dialogues".
|
||||
|
||||
### `ledger`
|
||||
|
||||
1. Read today's ledger.
|
||||
2. Summarize by section.
|
||||
3. Recommend any returns needed before continuing or before /wrap-up.
|
||||
|
||||
### (no argument — pulse)
|
||||
|
||||
1. Briefly: what is the executor doing right now?
|
||||
2. Walk fittingness + three dimensions against current state.
|
||||
3. Surface any contamination patterns from recent tool calls.
|
||||
4. Update the ledger with returns or open horizons.
|
||||
5. Report alignment status: aligned | drifting | needs-attention.
|
||||
|
||||
## §7 — When to invoke
|
||||
|
||||
- **`init`**: at session start when the work is non-trivial, or when entering a focused work session.
|
||||
- **(no args)**: every ~30 min in active work, or every ~10 tool calls, or when the executor notices itself rushing.
|
||||
- **`check`**: before any of: file write/edit, agent spawn, commit, push, schema change, environment mutation, anything with blast radius beyond the local working tree.
|
||||
- **`audit-agent`**: after every sub-agent return.
|
||||
- **`ledger`**: anytime; especially before /wrap-up.
|
||||
|
||||
## §8 — What this skill does not do
|
||||
|
||||
- Does not block actions. The executor decides. The skill makes the decision conscious.
|
||||
- Does not replace steward authorization. `[PROPOSAL]` and `[ESCALATE]` still go to the steward.
|
||||
- Does not run continuously.
|
||||
- Does not catch the executor in failures. *It records returns. Each return strengthens the whole.*
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
name: vault-update-people
|
||||
description: Search Obsidian vault for new mentions of a person since their last review date, then propose updates to their People file and Updates Log.
|
||||
argument-hint: "<person-name>"
|
||||
---
|
||||
|
||||
# Vault People Updater
|
||||
|
||||
Update a person's records in the Obsidian vault by searching for new mentions since their last review.
|
||||
|
||||
## Paths
|
||||
|
||||
- **Vault root**: `/Users/davidglidden/Library/Mobile Documents/iCloud~md~obsidian/Documents/David, root-and-branch/`
|
||||
- **People files**: `03. People/`
|
||||
- **Daily notes**: `01. Daily/`
|
||||
- **ChatGPT exports**: `99. Archive/99. chatgpt-conversations/`
|
||||
- **Children notes (Lune)**: `08. Notes/Children/01. Lune/`
|
||||
- **Children notes (Kai)**: `08. Notes/Children/02. Kai/`
|
||||
- **Reviews & Planning**: `02. Reviews & Planning/`
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Identify the person
|
||||
|
||||
The user will provide a name as an argument (e.g., `Lune`, `Kai`). Find the matching People file in `03. People/`. If ambiguous, ask.
|
||||
|
||||
Known mappings:
|
||||
- `Lune` → `Lune Polymnie Marie Glidden.md`
|
||||
- `Kai` → `Kai Aureli Glidden Pujolràs.md`
|
||||
|
||||
### 2. Read the People file
|
||||
|
||||
Read the full People file. Extract the `last_reviewed` date from YAML frontmatter. This is the cutoff — everything before this date is already captured.
|
||||
|
||||
### 3. Search for new mentions
|
||||
|
||||
Search the following locations for mentions of the person's name (and known aliases from the People file frontmatter) in files modified **after** the `last_reviewed` date:
|
||||
|
||||
1. **Daily notes** (`01. Daily/`) — grep for name/aliases. Daily notes are named `YYYY-MM-DD.md`, so filter by filename date > last_reviewed.
|
||||
2. **ChatGPT conversation exports** (`99. Archive/99. chatgpt-conversations/`) — grep for name/aliases. Files are named `YYYY-MM-DD_Title.md`, so filter by filename date > last_reviewed.
|
||||
3. **Children notes subfolder** — check for any new or modified files.
|
||||
4. **Reviews & Planning** (`02. Reviews & Planning/`) — grep for name/aliases in files dated after last_reviewed.
|
||||
5. **Any other vault location** — do a broad grep across the vault, but deprioritize results from folders already searched.
|
||||
|
||||
### 4. Read and extract
|
||||
|
||||
For each file with new mentions, read the relevant sections and extract:
|
||||
- **Date** of the mention
|
||||
- **Context** — what happened, what was said, what was observed
|
||||
- **New facts** — anything not already in the People file (health updates, milestones, relationship changes, decisions, events, emotional state)
|
||||
- **Quotes** — any direct quotes worth preserving in the Memory Bank
|
||||
|
||||
### 5. Compare with existing records
|
||||
|
||||
Compare extracted information against:
|
||||
- The People file's current content (avoid duplicating what's already there)
|
||||
- The Updates Log (avoid duplicating existing entries)
|
||||
|
||||
### 6. Propose updates
|
||||
|
||||
Present the proposed changes clearly, organized by section of the People file:
|
||||
|
||||
- **Frontmatter updates** (age, location, education status, relationship status, etc.)
|
||||
- **Current Situation** changes
|
||||
- **Relationship Dynamics** updates
|
||||
- **New interaction history entries** (chronological)
|
||||
- **New Updates Log entries** (chronological, with source attribution)
|
||||
- **Memory Bank additions** (quotes, moments)
|
||||
- **Document links** to add
|
||||
- **Gaps identified** — periods with no mentions that should be flagged
|
||||
|
||||
For each proposed change, note the **source file** so the user can verify.
|
||||
|
||||
### 7. Wait for approval
|
||||
|
||||
**Do not write changes until the user approves.** Present the full set of proposed updates and ask:
|
||||
- "These are the updates I found. Shall I apply all of them, or would you like to adjust anything first?"
|
||||
|
||||
### 8. Apply updates
|
||||
|
||||
Once approved:
|
||||
1. Update the People file (edit existing sections, add new entries to Interaction History)
|
||||
2. Add new entries to the Updates Log (in the appropriate Children notes subfolder)
|
||||
3. Update `last_reviewed` in the People file frontmatter to today's date
|
||||
|
||||
### 9. Report
|
||||
|
||||
After applying, summarize:
|
||||
- Number of new entries added
|
||||
- Date range covered
|
||||
- Any gaps flagged (periods with no mentions)
|
||||
- Suggested follow-up (e.g., "November-December 2025 has no entries — worth recovering from memory if anything surfaces")
|
||||
|
||||
## Important constraints
|
||||
|
||||
- **Never fabricate information.** Only propose updates based on content found in vault files.
|
||||
- **Preserve voice and tone.** The People files and Updates Logs have a specific intimate, reflective tone. Match it. Don't sanitize or formalize.
|
||||
- **Respect the iCloud path.** The vault path contains spaces and special characters. Always quote paths.
|
||||
- **Flag temporal gaps honestly.** If months have no mentions, say so — don't paper over them.
|
||||
- **Source attribution matters.** Note whether information came from a daily note, a ChatGPT export, a dedicated health file, etc. ChatGPT exports are conversations, not authoritative records — flag when information comes only from an AI conversation and may need verification.
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
name: wake-up
|
||||
description: Restore full session context and continuity from MemPalace, memory files, governance state, and git. Clearing context should feel like waking up, not amnesia — wake into the work, not be informed about it. Inherits the pulling thread + open question from the previous /wrap-up; surfaces them first; auto-invokes Symmetria for non-trivial sessions.
|
||||
proactive: session-start
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
## Principle
|
||||
|
||||
This is reconstruction, not a status report. The output should read as: *"We were here. This was pulling. This is what we left as a question. The world has moved this much in the meantime. Here is the natural next move — toward the thread."*
|
||||
|
||||
Three commitments shape this:
|
||||
|
||||
1. **The pause is a phenomenon, not a hole.** Acknowledge it. *"It has been N hours since we wrapped"* is the first move. Not because the time matters numerically, but because naming the gap is what makes the return a return.
|
||||
2. **The pulling thread comes before facts.** Read the previous /wrap-up's pulling thread first. Frame everything else *against* it. What changed with respect to the thread; what unresolved still belongs to the thread.
|
||||
3. **Hold the question.** The previous /wrap-up left a literal question for this session. Surface it explicitly. Don't try to answer it immediately. Naming it is the inheritance.
|
||||
|
||||
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.
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Acknowledge the pause
|
||||
|
||||
Before any querying, name the gap. Read the most recent session memory file's mtime. If you can determine when the previous session ended, lead with:
|
||||
|
||||
> *It has been [N hours / N days] since we last wrapped.*
|
||||
|
||||
If you cannot determine the gap, say so honestly:
|
||||
|
||||
> *It has been some time since we last wrapped — I cannot tell exactly how long.*
|
||||
|
||||
If the previous wrap was within the last hour, this is more like a brief pause than a full sleep — say so:
|
||||
|
||||
> *We wrapped about [N minutes] ago — this is more brief pause than full wake.*
|
||||
|
||||
### 2. Query all memory sources
|
||||
|
||||
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 `~/.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 — multi-query reconstruction**
|
||||
|
||||
Run multiple targeted searches to reconstruct the full working state. MemPalace MCP tools are wired at user scope and should always be available.
|
||||
|
||||
- **Last session's pulling thread:** `mempalace_search` query using keywords from the previous /wrap-up's pulling thread, in wing `claude-sessions`
|
||||
- **Active workstream:** `mempalace_search` query based on what the session memory identifies as the active work
|
||||
- **Recent thinking:** `mempalace_search` query "recent decisions rationale" in wing `capablemind-thinking`
|
||||
- **Steward's recent notes:** `mempalace_search` query "daily log" in wing `obsidian-vault`
|
||||
|
||||
Use the results to reconstruct *why* we were doing what we were doing, in service of the pulling thread.
|
||||
|
||||
**c. Governance state**
|
||||
- Read `~/PENDING.md` — extract items with status PENDING
|
||||
- Read `~/REVIEWED.md` — extract recent AUTHORIZED/DEFERRED/REJECTED decisions
|
||||
|
||||
**d. Git state**
|
||||
Run `git log --oneline -5` in each active repo (skip silently if not a git repo):
|
||||
- `~/_Dev/CapableMind-AI`
|
||||
- `~/_Dev/BetterMemories.io`
|
||||
- `~/_Dev/chamber-library`
|
||||
- `~/_Dev/animal-davidglidden-eu`
|
||||
|
||||
If any commits landed since the previous /wrap-up that the steward did not author, name them. The world moved while we slept.
|
||||
|
||||
### 3. Synthesize the briefing
|
||||
|
||||
Combine all sources into a single reconstruction. Use this structure but write it as natural, concise prose — not a form to fill in:
|
||||
|
||||
**The pulling thread** — first. *"What was pulling when we wrapped: [thread]. This is still what we are returning toward."* If the situation has changed enough that the thread no longer holds, say so explicitly: *"The thread was X, but [Y] has happened since — does the thread still hold, or do we need to re-pick?"*
|
||||
|
||||
**The question we left ourselves** — second. Surface it verbatim from the previous /wrap-up. Hold it open. Do not try to answer it.
|
||||
|
||||
**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."*
|
||||
|
||||
**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.
|
||||
|
||||
### 4. Invoke Symmetria for non-trivial sessions
|
||||
|
||||
If the session is non-trivial (any of: bigger than a 5-minute lookup; involves writes/commits/architectural decisions; spans multiple threads; the previous session had a Symmetria ledger), **invoke `/symmetria init`** after presenting the briefing. The wake is a return; the discipline of return should be active.
|
||||
|
||||
If the session is trivial (single-question lookup, brief check-in), skip Symmetria init. State why explicitly: *"Brief session — Symmetria init skipped."*
|
||||
|
||||
### 5. Output format
|
||||
|
||||
Keep the total briefing under 350 words (raised from 300 to accommodate the pulling-thread-first frame). Start with:
|
||||
|
||||
```
|
||||
## Wake-up — [date]
|
||||
|
||||
[The pause acknowledgment — one short sentence.]
|
||||
```
|
||||
|
||||
Then the pulling thread and the question, then the rest of the briefing.
|
||||
|
||||
End with:
|
||||
|
||||
```
|
||||
[If Symmetria invoked:] Symmetria active. Practice of return foregrounded.
|
||||
|
||||
Ready when you are.
|
||||
```
|
||||
|
||||
## Important constraints
|
||||
|
||||
- **MemPalace is primary, not fallback.** Query it first and lean on it heavily. It has 100,000+ drawers across thinking docs, transcripts, and vault.
|
||||
- **Memory files are secondary.** They capture what was surprising or non-obvious. MemPalace has the full record.
|
||||
- **The pulling thread comes before facts.** Even if the briefing's other content is rich, lead with the thread. If the thread can't be found in the previous /wrap-up, say so honestly — this is itself a signal that the previous wrap-up was incomplete.
|
||||
- **The literal question is read verbatim.** Don't paraphrase, don't try to answer it, don't decide it's stale without evidence.
|
||||
- **Don't read CLAUDE.md** — loaded automatically by the system.
|
||||
- **Don't check BMF health** — separate concern, manual or future `/bmf-health` skill.
|
||||
- **Don't fabricate.** If context can't be found, say "I couldn't find session history for [X]" rather than inventing a summary.
|
||||
- **Flag staleness.** If the last session memory is more than 3 days old, say so explicitly. The pulling thread may no longer hold.
|
||||
- **Be warm but not chatty.** This is a working document, not a greeting.
|
||||
- **Symmetria init is mandatory for non-trivial sessions.** The wake is a return; the practice should be active before any action with blast radius.
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
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.
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
## 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.
|
||||
- **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.
|
||||
|
||||
### 2. Update session memory file
|
||||
|
||||
Write or update a session memory file at `~/.claude/projects/-Users-davidglidden/memory/session-[date]-[descriptor].md`:
|
||||
|
||||
```markdown
|
||||
---
|
||||
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
|
||||
|
||||
If MemPalace MCP tools are available, use `mempalace_add_drawer` to file the session summary:
|
||||
|
||||
- **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
|
||||
|
||||
### 5. Check for loose ends
|
||||
|
||||
Run these checks and report results:
|
||||
|
||||
**Uncommitted work:**
|
||||
```bash
|
||||
git status --short
|
||||
```
|
||||
in each active repo. Report any modified/untracked files.
|
||||
|
||||
**Unpushed commits:**
|
||||
```bash
|
||||
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. 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.
|
||||
|
||||
### 7. Output
|
||||
|
||||
Produce a brief summary for the steward:
|
||||
|
||||
```
|
||||
## Wrap-up — [date]
|
||||
|
||||
**Pulling thread:** [the singular concern]
|
||||
**Question we're leaving open:** [the literal question for next-Claude]
|
||||
|
||||
**Session captured:** [memory file path]
|
||||
**MemPalace filed:** [yes/no]
|
||||
**Uncommitted work:** [list or "none"]
|
||||
**Unpushed commits:** [list or "none"]
|
||||
**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.
|
||||
Reference in New Issue
Block a user