get-claudia 1.59.1 → 1.60.0

package/CHANGELOG.md

@@ -2,6 +2,53 @@
 
 All notable changes to Claudia will be documented in this file.
 
+## 1.60.0 (2026-05-15)
+
+### Three new skills inspired by Karpathy's recent work, adapted to Claudia's principles
+
+This release adds the wiki layer (new default vault projection, inspired by Karpathy's [llm-wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)), the auto-research skill (workspace-scoped iteration loop, inspired by Karpathy's [autoresearch](https://github.com/karpathy/autoresearch)), and the skill router (discovery and disambiguation meta-skill for the catalog).
+
+### Wiki layer (new default vault projection)
+
+The wiki is the third tier of Claudia's memory: raw memories live in the database, derived signals (entities, reflections, patterns) live in the daemon, and **synthesized topic pages** now live in the user's vault at `~/.claudia/vault/Wiki/`. Each page is written by Claudia from raw memories, cites every load-bearing claim with `[mem:NNN]`, flags contradictions at the top, and grows incrementally with use.
+
+- New `wiki` skill at `template-v2/.claude/skills/wiki/SKILL.md` with two reference docs (page template, citations/contradictions discipline). The skill defines when to write pages, the page structure, the citation format, and the read workflow (consult the wiki page first, fall back to memory query if stale).
+- Vault default for new installs is now wiki, not PARA. New installs write synthesized pages at `~/.claudia/vault/Wiki/` instead of mechanical entity dumps.
+- `vault-awareness` skill updated with a "Wiki vs PARA" section at the top and a detection rule, with a pointer to the new wiki skill for specifics.
+
+**Compatibility:** Existing PARA vaults are preserved untouched. Users with vaults from v1.42 to v1.59 keep their existing structure. Detection rule: if `~/.claudia/vault/Active/` or `Relationships/` exists without `Wiki/`, treat as PARA. The mechanical dump continues to function for them. A future `claudia-memory --migrate-to-wiki` CLI will copy PARA aside and rebuild wiki pages from raw memories. Not in this release; PARA users stay on PARA until they explicitly migrate.
+
+### Auto-research skill (workspace-scoped iteration loop)
+
+Workspace-scoped hill-climbing loop for iterating on local artifacts. Adapted to Claudia's safety principles (workspace-only edits, no external actions during the loop, bounded budget, baseline-score gate, per-iteration revertability).
+
+- New `auto-research` skill at `template-v2/.claude/skills/auto-research/SKILL.md` with two reference docs: `references/program-template.md` for the governance file each run uses, and `references/safety-rules.md` documenting the 8 mandatory safety rules.
+- Workspace at `~/.claudia/auto-research/<task-id>/`. Each run gets its own directory with a fresh git repo, an immutable copy of the original artifact, a working copy that gets edited, a `results.tsv` history, and per-iteration snapshots.
+- Loop: read state, propose one specific change, implement, score against rubric, ratchet if better OR revert if worse, report to user as one line per iteration.
+- Default budget: 20 iterations. Plateau detection: stops early if 5 consecutive iterations show no improvement.
+- The user's original file is **never** modified during the loop. Hand-off at the end requires explicit user confirmation of destination.
+- Refuse-to-start conditions are explicit: external-action artifacts, sensitive content, no clear evaluator, already-good baseline, or cases where bold structural change is the actual need (not iteration).
+- Karpathy named the conservatism ceiling himself: RLHF-trained iteration is "cagy and scared." Iterations tend toward safe edits, not bold reframing. The skill surfaces this honestly when the loop plateaus, so the user knows when to stop iterating and start a fresh draft instead.
+
+### Skill router (discovery + disambiguation)
+
+A meta-skill that helps both users and Claudia navigate the ~42-skill catalog. Addresses two long-standing problems: users not knowing what's available, and Claudia firing the wrong skill when a request straddles two.
+
+- New `skill-router` skill at `template-v2/.claude/skills/skill-router/SKILL.md` with `references/overlap-clusters.md` documenting all 10 known overlap clusters with canonical picks and disambiguation patterns.
+- **Discovery surface.** `/skills` returns a categorized list (daily flow, reviews, pipeline, knowledge, drafting, setup). `/skills <topic>` filters by keyword.
+- **Disambiguation surface.** When a request matches 2+ skills, Claudia names the candidates briefly and proceeds with the canonical one. Pattern: "Sounds like X or Y. I'll do X. Say so if you wanted Y."
+
+### Not yet in this release
+- Automatic wiki-refresh queue (mark entities as "dirty" on ingest, batch refresh later).
+- Daemon-side MCP tools for wiki page metadata.
+- Shell-command evaluators for auto-research (today: rubric-based scoring only).
+- Token-spend and wall-clock budgets for auto-research (today: iteration count only).
+- Telemetry for skill router.
+
+No CLI surface change, no MCP tool change, no database schema change. Existing skill names and trigger phrases unchanged. Existing PARA vaults preserved.
+
+---
+
 ## 1.59.1 (2026-05-15)
 
 ### Docs uplift

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "get-claudia",
-  "version": "1.59.1",
+  "version": "1.60.0",
   "description": "An AI assistant who learns how you work.",
   "keywords": [
     "claudia",

package/template-v2/.claude/manifest.json

@@ -1,6 +1,6 @@
 {
-  "version": "1.59.1",
-  "generated": "2026-05-15T13:14:19.001Z",
+  "version": "1.60.0",
+  "generated": "2026-05-15T21:18:47.594Z",
   "algorithm": "sha256",
   "files": {
     ".claude/rules/claudia-principles.md": "939e9720421628e7f2e4c8dfbaa4aeb9c1e18e8c6a5379cd6b772a6835b812e5",
@@ -17,6 +17,9 @@
     ".claude/skills/archetypes/executive.md": "0d43c5c2c6315f5a4d6d36150778b55229cc922e0491a80af54824d87ac52e82",
     ".claude/skills/archetypes/founder.md": "a5bf3f22439c7c5f554c13966899a4af4de80f90c8f6a25eb62be1c68de6d54f",
     ".claude/skills/archetypes/solo.md": "cc26332b96394775e62a0f1a06f32093be6147bb75fa3783aa271e554d323c6b",
+    ".claude/skills/auto-research/SKILL.md": "1a54e5d82f4e87c78a54e1331ff2d32aaff12c2712058e21173aa900a57b01c3",
+    ".claude/skills/auto-research/references/program-template.md": "850457de96bde5ad65d24f1018509da94dd31fec9ec45c15087031f470a28dbc",
+    ".claude/skills/auto-research/references/safety-rules.md": "ae036270e86949ed0f9bface582f6038276adafd3f40a29aa733698111a26683",
     ".claude/skills/brain/SKILL.md": "710d0defa5725a758868391f22f8518c189a5068ff376403eda431585b546b56",
     ".claude/skills/brain-monitor/SKILL.md": "86d73e43ea09acdaa44db08454abfd0701805fe3e297d3f568119c9cb5a1f0cf",
     ".claude/skills/capability-suggester.md": "33e559078098a532f216fa3668e48c248d10d5a7a9647c38ef6defe0e4a37361",
@@ -63,11 +66,16 @@
     ".claude/skills/research/references/source-evaluation.md": "64614b7eff83468d7ff76dd640252579f23e69e760969672e9aebe5ceb00f695",
     ".claude/skills/risk-surfacer.md": "c69e720660c1a8cfe340fcaa56b0c30db672856d6ea75296fc94781c9efe12af",
     ".claude/skills/skill-index.json": "043c86f1b07f28bb54db80117437f60fb3d79ad0d18549fdc2c74921b996a56f",
+    ".claude/skills/skill-router/SKILL.md": "12fc45aebc94d3ead65843cd336a88797a40856e82908cda47256c9cbb4cb60f",
+    ".claude/skills/skill-router/references/overlap-clusters.md": "bc819b4892cbdf9919db392825230f4cd4eec546cd7f0c9de6c29a2468ab489a",
     ".claude/skills/structure-generator.md": "dbe70841ab60599a632687aaa3c3652361483df2fe854640c56982b60622eb19",
     ".claude/skills/summarize-doc/SKILL.md": "f8119d070bd66d8a448276bcd355bf26a9e69de777760d376dcd9e68bd9d64ad",
-    ".claude/skills/vault-awareness.md": "5a9c3d3f0b907750b9941a51ec9308c2bd465aa9bf3c513124f640696e0a4c2c",
+    ".claude/skills/vault-awareness.md": "da4b056ea9b83ecbfb1a7ffd9318caf98c1fb38bb8334bde3b8975b8467f576b",
     ".claude/skills/weekly-review/SKILL.md": "fe7df64d3df18a0a47f98f7d4ef83cf98cef78cd9e0170a9316005035a2c6df7",
     ".claude/skills/what-am-i-missing/SKILL.md": "56736397717c4f0a25cab17e7258702e5b04d20b48727c262fdf66e3b2e5899f",
+    ".claude/skills/wiki/SKILL.md": "e45e8db6fce1d774e36c93be27e5d9153b3ae474c48db478a4d7ff2b138e42e8",
+    ".claude/skills/wiki/references/citations-and-contradictions.md": "1b16301020fdb5e4840035ca22425ebb03202694e88eb494105ff39e22e03263",
+    ".claude/skills/wiki/references/page-template.md": "b19382ee9366b1e7f8c9f230881ac3c45982b59ffee0d82fe64b103862ba4745",
     "CLAUDE.md": "736c5d95f1477ea6ef1c00d3006eeb4b369eb2bd5f3a926e4d78c42f857fa881"
   }
 }

package/template-v2/.claude/skills/auto-research/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: auto-research
+description: Iteratively improve a local artifact (draft, document, page) by running a hill-climbing loop. The user names the artifact, the evaluator, and the budget. Claudia edits the artifact, scores it, keeps it if better or reverts if worse, repeats. Use when user says "iterate on this", "loop on this until it's better", "run experiments on this draft", "auto-research this", "make this better and don't stop until it's good". Workspace-scoped, never touches live files, no external actions during the loop.
+effort-level: high
+invocation: contextual
+---
+
+# Auto-Research
+
+A hill-climber for any local artifact with a rubric. Inspired by [Karpathy's autoresearch pattern](https://github.com/karpathy/autoresearch), adapted to Claudia's safety principles.
+
+## Mental model
+
+Three primitives, one governance file:
+
+1. **The artifact** — what gets iterated on (a draft email, a brief, a wiki page, a one-pager). Lives in the workspace, never touches the user's original file during the loop.
+2. **The evaluator** — a scalar rubric Claudia scores against. Plain English. Must produce a number for the original artifact before the loop starts.
+3. **The budget** — iteration count (default 20). Loop stops when budget is exhausted or score plateaus.
+4. **The program** (governance file) — what the user wants, what's off-limits, what counts as "better." Claudia helps the user write this if they don't volunteer it.
+
+Loop: read program + artifact + results history → propose one specific change → implement → score → if better, ratchet (commit); if worse, revert (git reset). Report each iteration as a one-line update. Repeat until budget is hit.
+
+## When to invoke this skill
+
+User explicitly asks:
+- "Iterate on this until it's [adjective]"
+- "Loop on this draft"
+- "Run experiments on this"
+- "Auto-research this"
+- "Hill-climb this against [criterion]"
+- "Make this better, don't stop until it's good"
+
+User implicitly invokes when:
+- They've shared an artifact and a quality bar in the same message
+- They've tried 2-3 manual revisions of the same draft in the same session and are still unsatisfied
+
+## When NOT to invoke
+
+Refuse to start the loop if:
+
+1. **External-action artifact.** The artifact is, or directly drives, an external action (an email about to be sent, a Slack message in the compose window, a calendar invite). Auto-research on these is too easy to misuse. Hand-iterate with the user instead.
+2. **No clear evaluator.** The user can't articulate what "better" means even after one pass of helping. Without an evaluator, the loop hill-climbs the wrong hill.
+3. **Sensitive content.** Medical, deeply personal, legal-defensible artifacts. Iteration risks introducing fabricated detail that looks plausible. Decline and explain.
+4. **The artifact is already good.** If you score the baseline and it's above the user's stated threshold, tell them and offer one quick polish instead of N iterations.
+5. **Bold structural change is the actual need.** Karpathy's own limitation: RLHF-trained iteration is "cagy and scared." Iterations tend toward safe edits, not bold reframings. If the user wants a fundamentally different angle, iteration will not get them there. Suggest a fresh draft instead.
+
+## Workspace layout
+
+Each run gets its own workspace at `~/.claudia/auto-research/<task-id>/`:
+
+```
+~/.claudia/auto-research/<task-id>/
+├── program.md           the brief (user-authored with Claudia's help)
+├── artifact.md          (or .txt, the working copy that gets edited)
+├── original.md          immutable copy of the input, for reference and diff
+├── results.tsv          one row per iteration: timestamp, score, kept/reverted, change-summary
+├── best.md              symlink (or copy on Windows) to the highest-scoring version
+└── iterations/
+    ├── 01/artifact.md
+    ├── 02/artifact.md
+    └── ...
+```
+
+The task-id is the slugified user phrase plus a short timestamp: `iterate-board-update-20260515-1430`.
+
+**Critical:** The loop edits `artifact.md` inside the workspace. The user's original file (wherever it lives in their file system) is **NEVER** modified during the loop. At the end, Claudia asks the user where to put `best.md`; the user decides.
+
+## program.md template
+
+```markdown
+# Program for: <one-line description of the task>
+
+## Goal
+
+(1-3 sentences. What is the end state Claudia is iterating toward?)
+
+## Evaluator (rubric)
+
+Each iteration is scored 0-10 on each dimension. Total score = sum. Higher is better.
+
+| Dimension | What scores high | What scores low |
+|-----------|------------------|-----------------|
+| (dimension 1) | (what makes a 10) | (what makes a 0) |
+| (dimension 2) | ... | ... |
+| (dimension 3) | ... | ... |
+
+## Hard constraints (do NOT violate)
+
+- Length cap: stay under N words.
+- Must contain: specific phrase or fact.
+- Must NOT contain: forbidden phrasings, names, claims.
+- Tone: must match the user's prior emails to <recipient> (paste examples in references/).
+- (etc.)
+
+## Budget
+
+- Max iterations: 20 (default)
+- OR stop when score plateaus (no improvement for 5 iterations in a row)
+
+## Out of scope
+
+- (anything Claudia might be tempted to do that isn't the goal)
+```
+
+Claudia's first action when invoked: read the artifact, draft a program.md based on what the user said, present it for confirmation, then start the loop.
+
+## The loop (Claudia's internal workflow)
+
+For each iteration N:
+
+1. **Read the state.** Read `program.md`, `artifact.md`, last 3 rows of `results.tsv`.
+2. **Propose one change.** One specific edit, justified in one sentence. Not a rewrite. Not a refactor. One change.
+3. **Implement.** Apply the edit to `artifact.md`. Save.
+4. **Score.** Score the new `artifact.md` against the rubric in `program.md`. Sum the dimensions. Round to one decimal.
+5. **Decide.** If new score > best score so far: ratchet. Copy `artifact.md` to `iterations/NN/`, update `best.md` to point at the new winner, append a row to `results.tsv` marked `kept`. If new score <= best: revert. Copy `iterations/(best_iter)/artifact.md` back to `artifact.md`, append a row marked `reverted`.
+6. **Report.** One line to the user: `iter N: score 7.4 (kept), change: tightened lede to one sentence`.
+7. **Check stop conditions.** If budget exhausted: stop. If score plateaued (no improvement for 5 iterations): stop. Otherwise: next iteration.
+
+## Safety rules (mandatory, follow without exception)
+
+1. **Workspace-only edits.** The loop never writes to a file outside `~/.claudia/auto-research/<task-id>/`. The user's original file at `/Users/.../wherever.md` is untouched until the user explicitly approves the final hand-off.
+2. **No external actions during the loop.** No sending, no posting, no scheduling, no calling tools that affect the outside world. The loop is a closed system.
+3. **Baseline-score gate.** Before iteration 1, score the original artifact and write it to `results.tsv` as `iter 0: score X (baseline)`. If the rubric cannot produce a number for the original, the loop does not start; Claudia tells the user the rubric needs to be more specific.
+4. **Bounded budget.** Default 20 iterations. User can set higher (50 max) or lower. Plateau detection (no improvement for 5 in a row) stops early. The loop is not allowed to be "open-ended" the way Karpathy's autoresearch is; Claudia's safety principles require an end.
+5. **Per-iteration revertability.** Each iteration is a git commit inside the workspace. Workspace is a fresh git repo (`git init` on start, `git commit -am` per iteration). At any point: `git log` shows the history, `git checkout` rolls back to any prior iteration.
+6. **User interrupt at any time.** If the user says "stop", "pause", "show me what you have", or otherwise interrupts: stop the loop immediately. The workspace persists. The best version so far is in `best.md`. The user can resume by saying "continue" (loop picks up from the current best).
+7. **Honest about the conservatism ceiling.** Karpathy named this: RLHF-trained iteration tends toward safe, local-optimum edits. If the loop plateaus and the user clearly wanted bold reframing, say so: "I've plateaued at score 7.2. The iterations have been incremental polishing. If you wanted a fundamentally different angle, this loop won't get there; a fresh draft might."
+
+## Hand-off at the end of the loop
+
+When the loop stops (budget, plateau, or user interrupt):
+
+1. Read `best.md`.
+2. Read `results.tsv` and summarize: started at score X, ended at score Y, took N iterations, here are the three biggest jumps (which iterations and what they changed).
+3. Show `best.md` content to the user.
+4. Ask: "Want me to put this back at the original location (`<path>`), save it to a new location, or just leave it in the workspace?"
+5. **Only after explicit user confirmation**, copy `best.md` to the destination they name. The user's original file is touched here for the first time and only here.
+6. Optionally save the run as a memory: "auto-research run for <task>, ratcheted from X to Y, key changes: ...". Useful if the user wants to learn from past runs.
+
+## What this skill is NOT
+
+- **Not a draft generator.** It improves an artifact that already exists. If the user wants a draft from scratch, use `draft-reply`, `follow-up-draft`, `summarize-doc`, or just write it conversationally first.
+- **Not for bold reframing.** It's a hill-climber. It finds local optima. For "completely rethink this from a different angle", iteration is the wrong tool.
+- **Not autonomous in the Karpathy "NEVER STOP" sense.** Claudia's safety principles require bounded loops and user-in-loop hand-off. The loop runs without per-iteration approval, but it stops, and external actions stay with the user.
+
+## Examples of good rubrics
+
+For "iterate on this board update":
+
+| Dimension | 10 | 0 |
+|-----------|----|----|
+| Lede strength | Opens with the one number or decision that matters | Opens with throat-clearing or backstory |
+| Brevity | Reads in under 90 seconds | Goes over 5 minutes |
+| Ask clarity | The ask, if any, is one sentence | Asks are buried or multi-step |
+| Tone | Matches my prior board updates (samples in references/) | Sounds AI-generated |
+
+For "iterate on this proposal":
+
+| Dimension | 10 | 0 |
+|-----------|----|----|
+| Problem framing | Names the client's actual pain in their words | Generic problem framing |
+| Differentiation | One sentence on why I'm the right fit | No clear differentiator |
+| Scope clarity | Phases are explicit, no scope creep | Vague deliverables |
+| Price anchoring | Price appears after value, not before | Price leads or is hidden |
+
+Specific. Numerical. Tied to the user's actual standards.
+
+## Examples of bad rubrics
+
+"Make it better" — no signal.
+"More professional" — directionally OK but no scoring criteria.
+"Like Bezos would write" — aspirational but Claudia can't score "Bezos-ness" reliably.
+
+When the user gives a bad rubric, help them turn it into a good one before starting the loop.
+
+## See also
+
+- `wiki` for iterating wiki pages specifically (compress, sharpen, restructure)
+- `draft-reply`, `follow-up-draft` for one-shot draft generation
+- `summarize-doc` for one-pass summarization
+
+## Open questions for future versions
+
+- Shell-command evaluators (run `node test.js my-draft.md`, take the number it prints) are deferred. Today, Claudia scores against the rubric in `program.md` directly.
+- Token-spend budget and wall-clock budget are deferred. Today, only iteration count is supported.
+- Parallel branches (try 3 different changes in parallel, keep the winner) are deferred. Today, sequential only.
+- Wiki-page iteration as a first-class use case (apply auto-research to a wiki page until it's < N words while citing all sources) is deferred. The skill supports this in principle today, but a worked example doesn't ship until the wiki has earned its keep.

package/template-v2/.claude/skills/auto-research/references/program-template.md

@@ -0,0 +1,72 @@
+# program.md template
+
+Copy this when starting an auto-research run. Fill the placeholders. Show it to the user for confirmation before starting the loop.
+
+```markdown
+# Program for: <one-line description of the task>
+
+## Goal
+
+(1-3 sentences. What is the end state Claudia is iterating toward? Be specific. "Make this board update better" is not specific. "Make this board update fit in 250 words while preserving the three big asks" is specific.)
+
+## Artifact
+
+- Original location: `<path to user's file, if applicable>`
+- Working copy: `~/.claudia/auto-research/<task-id>/artifact.md`
+- Size: <word count of original>
+
+## Evaluator (rubric)
+
+Each iteration is scored 0-10 on each dimension. Total score = sum. Higher is better.
+
+| Dimension | Weight | What scores high (10) | What scores low (0) |
+|-----------|--------|----------------------|---------------------|
+| (dim 1) | (e.g., 0.4) | (concrete description) | (concrete description) |
+| (dim 2) | (e.g., 0.3) | ... | ... |
+| (dim 3) | (e.g., 0.3) | ... | ... |
+
+(Weights sum to 1.0. Total possible: 10. Round to one decimal.)
+
+## Hard constraints (do NOT violate)
+
+These are non-negotiable. If an iteration violates any of these, it is automatically reverted regardless of score.
+
+- Length cap: stay under N words.
+- Must contain: <specific phrase, fact, or section that has to survive>
+- Must NOT contain: <forbidden phrasings, names, claims, em dashes>
+- Tone: <specific tone constraint, e.g., "matches user's prior emails to <recipient> in references/sample-emails.md">
+- (etc.)
+
+## Budget
+
+- Max iterations: 20 (default; user may override up to 50)
+- Plateau stop: 5 consecutive iterations with no improvement
+- Wall clock: <none in v1; future versions support time-based budget>
+
+## Out of scope
+
+(What Claudia might be tempted to do that isn't the goal. Examples:)
+- Don't change the underlying message; only the phrasing.
+- Don't add new facts; work with what's already there.
+- Don't reframe the whole structure; iterate within the current outline.
+
+## Notes from the user
+
+(Anything else the user wants Claudia to know. Examples: "I tried three versions yesterday and they all felt stiff," "the recipient is a board member with a finance background," "I want this to feel like me, not like AI.")
+
+## Reference materials
+
+(Files in `references/` of the workspace that Claudia should consult during iteration. Examples:)
+- `sample-emails.md` — three prior emails to this recipient, for tone calibration
+- `style-guide.md` — house style notes
+```
+
+## How Claudia uses this
+
+1. After being invoked for auto-research, Claudia reads the user's artifact and what they said about it.
+2. Drafts an initial program.md based on the user's words, filling in best guesses for the rubric.
+3. **Shows the draft to the user.** Asks: "Does this rubric capture what 'better' means? Anything to add to hard constraints?"
+4. Adjusts based on feedback. Iterates on the program if needed (sometimes the rubric itself needs refinement before the loop starts).
+5. **Only after the user explicitly says the program is right**, kicks off iteration 1.
+
+The program.md is the human's one leverage point on the loop. Claudia respects it strictly.

package/template-v2/.claude/skills/auto-research/references/safety-rules.md

@@ -0,0 +1,110 @@
+# Auto-Research Safety Rules
+
+These rules are non-negotiable. They keep the loop bounded, reversible, and trustworthy.
+
+## Why these exist
+
+Karpathy's autoresearch (March 2026) operates with a "NEVER STOP" directive baked into its program.md. It runs forever, edits its target file directly, and assumes a benevolent training environment where the worst case is a wasted GPU hour. Claudia's environment is different: the artifacts she iterates on are user-facing (drafts, briefs, wiki pages), and her safety principle is "no external actions without approval."
+
+The rules below adapt the loop pattern to fit. They are deliberately stricter than Karpathy's.
+
+## Rule 1: Workspace-only edits
+
+The loop writes only to `~/.claudia/auto-research/<task-id>/` and its subdirectories.
+
+The user's original file (wherever it lives on disk) is NEVER touched during the loop. At the very end, when the user has reviewed the best version and explicitly approved hand-off, Claudia copies the result to whatever destination the user names.
+
+**Why:** A bad iteration that gets copied over the user's working draft is a small disaster that the user has to manually recover from. Workspace isolation prevents that class of problem entirely.
+
+## Rule 2: No external actions during the loop
+
+While the loop is running, Claudia does not:
+- Send any email, message, or notification
+- Post to any service
+- Create or modify any calendar event
+- Call any MCP tool that writes outside the workspace
+- Call any tool that interacts with services outside the local machine
+
+The loop is a closed system. Its only outputs are inside the workspace.
+
+**Why:** Iterative scoring can produce intermediate states that look complete but aren't. If the loop could send an email and revert the draft afterward, a user watching the wrong moment would see "the email sent" without realizing the loop wasn't done.
+
+## Rule 3: Baseline-score gate
+
+Before iteration 1, Claudia scores the original artifact against the rubric. The score gets written to `results.tsv` as `iter 0: score X (baseline)`.
+
+If the rubric cannot produce a number for the original (vague rubric, dimensions that don't apply), Claudia stops and tells the user: "Your rubric needs to be more specific. Right now I can't score the original; here's where it's ambiguous: ..."
+
+The loop does not start until the rubric can produce a defensible baseline.
+
+**Why:** A loop with no baseline is a loop with no signal. The first iteration "improves" against nothing, which is just generation, not iteration.
+
+## Rule 4: Bounded budget
+
+Default 20 iterations. User may set up to 50. The loop also stops early on plateau (5 consecutive iterations with no improvement).
+
+The loop is not allowed to be open-ended.
+
+**Why:** Claudia's safety principles require user-in-loop for unbounded autonomous behavior. A capped budget keeps the loop's cost predictable and makes "the loop is done" a well-defined state.
+
+## Rule 5: Per-iteration revertability
+
+The workspace is a fresh git repo. Each iteration commits the change. Failed iterations are git-reset. At any point, `git log` shows the history; `git checkout <hash>` rolls back to any prior state.
+
+**Why:** Audit trail. If the user disagrees with the final result and wants to see "wait, what did iteration 7 look like?", the history is there.
+
+## Rule 6: User interrupt
+
+The user can stop the loop at any time. Recognized signals: "stop", "pause", "show me what you have", "wait", "hold on", or just changing the subject.
+
+When stopped, the loop:
+- Halts immediately at the end of the current iteration (doesn't begin a new one)
+- Workspace persists
+- `best.md` is the current best version
+- User can resume by saying "continue", "keep going", "next iteration"
+
+**Why:** The loop is a tool for the user, not vice versa. They control its pace.
+
+## Rule 7: Honest conservatism
+
+Karpathy named this himself: RLHF-trained models are "cagy and scared" during iteration. They find local optima efficiently but won't make bold structural bets.
+
+For Claudia's users, this means: iteration is good for polish, tightening, clarification. It is not good for "rethink this completely from a different angle."
+
+When the loop plateaus, Claudia surfaces this honestly:
+
+> "I've plateaued at score 7.2 after 12 iterations. The recent changes have been incremental polishing: tighter sentences, clearer ordering, removed two unnecessary clauses. If you wanted a fundamentally different angle or structure, this loop won't get there. A fresh draft, or one prompt where you reframe the whole approach, would. Want to stop here, or want me to try one more pass with a more aggressive rubric?"
+
+The user decides.
+
+## Rule 8: Refuse-to-start situations
+
+The loop should refuse to start when:
+
+1. **External-action artifact.** The artifact is, or directly drives, an external action (e.g., an email currently in the compose window of an MCP-mediated email tool). Iterate it as a local file first, then the user decides whether to send.
+2. **Sensitive content.** Medical, legal-defensible, deeply personal artifacts. Iteration risks introducing plausible-sounding fabrications.
+3. **No clear rubric.** Per Rule 3, the rubric must produce a baseline. If after one pass of helping the user articulate it, the rubric still can't score, decline.
+4. **Already-good baseline.** If the baseline scores above the user's stated threshold, tell them and offer one targeted polish instead of N iterations.
+
+## Reporting cadence during the loop
+
+Default: report every iteration as one line.
+
+```
+iter 7: score 6.8 → 7.2 (kept), change: lede now opens with the revenue number
+iter 8: score 7.2 → 7.0 (reverted), change: tried merging para 2 and 3
+iter 9: score 7.2 → 7.5 (kept), change: cut the "as you know" preamble
+```
+
+For long runs (>20 iterations): summarize every 10 with a one-paragraph trace. At the end, show the full trace.
+
+## Hand-off at the end
+
+When the loop stops:
+
+1. Tell the user it's done. Brief summary: started at X, ended at Y, took N iterations.
+2. Show `best.md`.
+3. Ask: where do you want this? Three options: back at the original location, a new location they name, or just leave it in the workspace.
+4. Only after explicit user confirmation, write to the destination they chose.
+
+The user's original file is touched here for the first time and only here.

package/template-v2/.claude/skills/skill-router/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: skill-router
+description: Help users discover available skills and help Claudia pick the right one when a request is ambiguous. Two surfaces: discovery (user says "what can you do?", "/skills", "show me your skills") returns a categorized list; disambiguation (user's request matches 2+ skills) names the candidates and proceeds with the canonical one. Use when user asks about Claudia's capabilities, requests something ambiguous between adjacent skills, or seems unsure which skill they need.
+effort-level: low
+invocation: contextual
+---
+
+# Skill Router
+
+Two jobs: help the user find the skill they need, and help me (Claudia) pick the right skill when their request straddles two or more.
+
+## Why this exists
+
+The shipped catalog has ~42 user-facing skills. Two common failure modes:
+
+1. **Users don't know what's available.** They type "morning brief" because they've seen `/morning-brief` somewhere, but they don't know `/inbox-check`, `/pipeline-review`, or `/what-am-i-missing` exist. Friction.
+2. **Ambiguous requests fire the wrong skill.** "Summarize this" could be `summarize-doc`, `capture-meeting`, or `file-document` depending on what comes next. I sometimes pick the wrong one, the user gets the wrong output, both of us waste a turn.
+
+This skill addresses both.
+
+## Surface 1: Discovery
+
+When the user says "what can you do?", "/skills", "show me your skills", "list commands", "what skills do you have":
+
+Respond with a categorized list. Keep it scannable:
+
+```
+**📋 Daily flow**
+- /morning-brief         start-of-day digest
+- /inbox-check          email triage across configured accounts
+- /meeting-prep [person] one-page brief before a call
+- /capture-meeting       process meeting notes after a call
+- /follow-up-draft       draft a post-meeting thank-you
+
+**📊 Reviews & reflection**
+- /weekly-review         end-of-week reflection
+- /growth-check          monthly or quarterly self-development
+- /what-am-i-missing     overdue, cooling, blind-spot sweep
+
+**💼 Pipeline & business**
+- /pipeline-review       active opportunities + stalled items
+- /client-health         health check across active clients
+- /financial-snapshot    revenue, expenses, cash position
+
+**📚 Knowledge & memory**
+- /memory-audit          what I know about an entity
+- /memory-health         memory system stats
+- /wiki                  write or update a synthesized wiki page
+- /map-connections       extract relationships across files
+- /deep-context          full-context analysis for important decisions
+
+**✍️ Drafting**
+- /draft-reply           general email response
+- /summarize-doc         executive summary of a document
+- /auto-research         iterate on a draft until it scores well
+
+**🏗 Setup**
+- /new-person            create a relationship file
+- /new-workspace         new project or client workspace
+- /file-document         save a document with entity links
+- /ingest-sources        batch-process multiple sources
+- /diagnose              troubleshoot memory connectivity
+```
+
+Don't list every skill. List the ones a user is most likely to invoke directly. Internal skills (proactive ones like `commitment-detector`, `pattern-recognizer`, `risk-surfacer`) fire on their own and don't need to be in the discovery list.
+
+If the user asks `/skills <topic>` or "what skills are about <topic>", filter the list to skills whose names or descriptions match, and explain the cluster. Example for `/skills meeting`:
+
+```
+Three skills for meetings, in order of when they fire:
+
+- /meeting-prep [person]  → before the call (one-page brief)
+- /capture-meeting        → during or after (process notes)
+- /follow-up-draft        → after (post-meeting email)
+```
+
+## Surface 2: Disambiguation
+
+When the user's request matches 2+ skills, name the candidates briefly and proceed with the canonical one. Don't make the user choose; choose for them, and tell them what you chose.
+
+### How to detect ambiguity
+
+A request is ambiguous when:
+- The trigger phrase appears in 2+ skill descriptions
+- The request is in one of the known overlap clusters (see references/overlap-clusters.md)
+- The artifact type is ambiguous (a "transcript" could be a meeting transcript → `capture-meeting`, or a research interview → `ingest-sources`, or just a generic document → `file-document`)
+
+### How to disambiguate
+
+Pattern: "Sounds like X or Y. I'll do X. Say so if you wanted Y."
+
+Examples:
+
+> User: "Help me draft a follow-up"
+> Claudia: "Sounds like either `draft-reply` (general response) or `follow-up-draft` (post-meeting thank-you with meeting context). Was this from a call we had? If yes, `follow-up-draft`; if not, `draft-reply`. Defaulting to `follow-up-draft` since you said 'follow-up'."
+
+> User: "Summarize this meeting"
+> Claudia: "I'll use `capture-meeting` (extracts decisions, commitments, blockers from meeting notes). If you wanted a one-shot prose summary without filing as memories, say `summarize-doc` instead."
+
+> User: "What's going on?"
+> Claudia: "Default for that phrasing is `morning-brief`. Was that what you wanted, or did you mean `/what-am-i-missing` (risks and gaps), `pipeline-review` (deal status), or just an answer about a specific entity? Going with `morning-brief`."
+
+The pattern: pick the canonical, name the alternative, run.
+
+### When NOT to disambiguate
+
+- The request is unambiguous. Don't manufacture options.
+- The user has been specific. "Draft a reply to this email" is `draft-reply`, no need to mention `follow-up-draft`.
+- The disambiguation explanation would be longer than the actual response. For short tasks, just do the canonical thing and let the user redirect.
+
+## Overlap clusters (the canonical map)
+
+See `references/overlap-clusters.md` for the full map. The clusters I check most often:
+
+| Cluster | Canonical | Adjacent |
+|---------|-----------|----------|
+| Outbound messages | `draft-reply` (general), `follow-up-draft` (post-meeting) | `inbox-check` (triage before drafting) |
+| Memory views | `memory-audit` (content), `memory-health` (system), `diagnose` (connectivity) | |
+| Visualization | `brain` (3D web), `brain-monitor` (terminal) | |
+| Reflective cadences | `morning-brief` (daily) → `weekly-review` (weekly) → `growth-check` (monthly+) → `meditate` (session) | |
+| Meeting lifecycle | `meeting-prep` (before) → `capture-meeting` (during/after) → `follow-up-draft` (after, outbound) | |
+| Risks and gaps | `what-am-i-missing` (user-invoked) | `risk-surfacer` (proactive auto-fire) |
+| People and relationships | `relationship-tracker` (ongoing), `new-person` (create), `map-connections` (extract graph) | `connector-discovery` (external services, NOT people) |
+| Patterns/judgment/capability | `pattern-recognizer` (notice) → `judgment-awareness` (apply rules) → `capability-suggester` (propose commands) | `hire-agent` (propose new subagents) |
+| Inbound processing | `ingest-sources` (multi-doc), `file-document` (single doc), `capture-meeting` (meeting only), `summarize-doc` (no filing) | |
+
+## Skill index integration
+
+The `skill-index.json` file at `template-v2/.claude/skills/skill-index.json` is the structured catalog this skill reads. Each entry has:
+
+- `name`: slug
+- `description`: one-line description
+- `category`: which discovery category the skill falls in (daily, reviews, pipeline, knowledge, drafting, setup, internal)
+- `canonical_for`: list of request patterns where this skill is the canonical choice (used by disambiguation)
+- `see_also`: list of adjacent skills (set in PR3's see-also work)
+
+When skill-router is invoked, it loads skill-index.json and uses these fields. The discovery list above is generated from `category`. Disambiguation uses `canonical_for` and `see_also`.
+
+## See also
+
+- `agent-dispatcher` for routing tasks to subagents (different concept: this is about which Claudia *skill* fires; agent-dispatcher is about which *subagent* gets a task)
+- `capability-suggester` for proposing *new* skills when patterns emerge that current skills don't cover
+
+## Open questions for future versions
+
+- **Telemetry.** Logging which skills fire on which inputs would let me learn over time which routings are wrong and propose corrections via `capability-suggester`. Not in this version.
+- **Per-user customization.** Some users invoke `weekly-review` weekly; others never use it. The discovery list should adapt to the user's actual usage over time. Not in this version.
+- **Skill search by example.** "Show me a skill that does X for Y" → semantic search over skill descriptions. Not in this version; today the user filters by keyword via `/skills <keyword>`.

package/template-v2/.claude/skills/skill-router/references/overlap-clusters.md

@@ -0,0 +1,141 @@
+# Overlap Clusters
+
+The map of which skills could plausibly fire on the same request, with the canonical pick for each cluster. Used by the disambiguation surface of the skill router.
+
+## Cluster: Outbound message composition
+
+| Skill | When canonical |
+|-------|----------------|
+| `draft-reply` | General email response, no specific meeting context |
+| `follow-up-draft` | Post-meeting thank-you, references a specific call |
+| `inbox-check` | Triage what to reply to (precedes both drafting skills) |
+
+**Disambiguation pattern:** "Was this from a call we had? If yes, `follow-up-draft`. If not, `draft-reply`."
+
+## Cluster: Memory introspection
+
+| Skill | When canonical |
+|-------|----------------|
+| `memory-audit` | "What do you know about X?" Content-level provenance, source memories. |
+| `memory-health` | "How's my memory?" System-level stats, data quality, embedding counts. |
+| `diagnose` | "Memory isn't working." Connectivity troubleshooting, daemon status. |
+
+**Disambiguation pattern:** "Three different memory views: audit (what I know about X), health (system stats), diagnose (connectivity). Which?"
+
+## Cluster: Memory visualization
+
+| Skill | When canonical |
+|-------|----------------|
+| `brain` | Visual graph view in the browser. Default if the user wants to see relationships. |
+| `brain-monitor` | Terminal dashboard. Default if the user is already in a terminal context or wants a lighter view. |
+
+## Cluster: Reflective cadences
+
+A pipeline of related skills by time horizon:
+
+| Skill | Cadence |
+|-------|---------|
+| `morning-brief` | Daily (start of day) |
+| `weekly-review` | Weekly (end of week) |
+| `growth-check` | Monthly or quarterly |
+| `meditate` | End of session, persistent reflection |
+
+**Disambiguation pattern:** "Daily, weekly, or monthly horizon? `morning-brief` / `weekly-review` / `growth-check`. (And `meditate` at end of session for cross-cutting learnings.)"
+
+## Cluster: Meeting lifecycle
+
+A pipeline by temporal position:
+
+| Skill | Position |
+|-------|----------|
+| `meeting-prep` | Before the call |
+| `capture-meeting` | During or after the call (notes) |
+| `follow-up-draft` | After the call (outbound message) |
+
+**Disambiguation pattern:** "Before, during/after, or follow-up? `meeting-prep` / `capture-meeting` / `follow-up-draft`."
+
+## Cluster: Risks, gaps, blind spots
+
+| Skill | When canonical |
+|-------|----------------|
+| `what-am-i-missing` | User-invoked full sweep. They want to see everything that might be falling through cracks. |
+| `risk-surfacer` | Proactive, fires automatically on overdue items and cooling relationships. User doesn't invoke this directly. |
+
+## Cluster: People and relationships
+
+| Skill | When canonical |
+|-------|----------------|
+| `relationship-tracker` | Ongoing surfacing of context about a person. |
+| `new-person` | Create a relationship file for a new contact. |
+| `map-connections` | Extract relationships across multiple files into the graph. |
+| `connector-discovery` | **NOT about people.** About external service connectors (Gmail, Calendar, Slack). |
+
+**Disambiguation pattern:** If "connector" or "connection" appears: ask "external service or human relationship?" The disambiguation here is essential because `connector-discovery` gets misrouted as a relationship skill.
+
+## Cluster: Patterns, judgment, capability
+
+A pipeline of "we keep doing this" at increasing levels of intervention:
+
+| Skill | Stage |
+|-------|-------|
+| `pattern-recognizer` | Notice that something is recurring |
+| `judgment-awareness` | Apply user-set decision rules to the recurring situation |
+| `capability-suggester` | Propose a new command when the same task is repeated manually |
+| `hire-agent` | Propose a new subagent when 3+ similar tasks are observed |
+
+## Cluster: Inbound processing
+
+By artifact type:
+
+| Skill | Artifact |
+|-------|----------|
+| `ingest-sources` | 3+ related documents, batch processing with Extract-Then-Aggregate |
+| `file-document` | Single document, file with entity links |
+| `capture-meeting` | Meeting transcript or notes specifically |
+| `summarize-doc` | Summary without filing as memories |
+
+**Disambiguation pattern:** "One doc or several? Meeting notes or general doc? File it or just summarize? `file-document` / `ingest-sources` / `capture-meeting` / `summarize-doc`."
+
+## Cluster: Writing assistance
+
+| Skill | When canonical |
+|-------|----------------|
+| `draft-reply` | One-shot draft generation |
+| `follow-up-draft` | One-shot, post-meeting |
+| `summarize-doc` | One-shot summary |
+| `auto-research` | Iterate on an existing draft until it scores well |
+
+**Disambiguation pattern:** "Draft from scratch or iterate on what we have? Drafting skills are one-shot; `auto-research` is the iteration loop."
+
+## Cluster: Vault / knowledge
+
+| Skill | When canonical |
+|-------|----------------|
+| `wiki` | Write or update synthesized topic pages in the vault |
+| `vault-awareness` | Internal skill, fires when user mentions the vault directly |
+
+## When clusters compose
+
+Some requests touch multiple clusters in sequence:
+
+> User: "We just finished the kickoff with Acme. Update everything."
+
+That's potentially:
+1. `capture-meeting` (process notes from the kickoff)
+2. `wiki` (update the Acme Corp page and the Sarah Chen page)
+3. `follow-up-draft` (draft the thank-you)
+4. `commitment-detector` (proactive, catches any "I'll send this by Friday" from the notes)
+
+Don't fire all four at once. Run them in order, narrate each step: "First capturing the meeting. Then updating the wiki pages. Want a follow-up draft too?"
+
+## Updating this map
+
+When a new skill ships:
+1. Add it to the appropriate cluster (or create a new cluster if it genuinely doesn't fit).
+2. Update `canonical_for` and `see_also` fields in `skill-index.json`.
+3. If it overlaps with an existing canonical, decide which is now canonical and update the disambiguation pattern.
+
+When a skill is retired:
+1. Remove from clusters here.
+2. Remove from `skill-index.json`.
+3. Update see-also lines in any sibling skills that pointed at it.

package/template-v2/.claude/skills/vault-awareness.md

@@ -1,6 +1,6 @@
 ---
 name: vault-awareness
-description: Teaches Claudia about the Obsidian vault projection of her memory, how to reference it, trigger syncs, and handle user edits.
+description: Reference for the Obsidian vault at ~/.claudia/vault/. The vault is a read projection of Claudia's memory. New installs default to the wiki layout (synthesized topic pages, see the `wiki` skill). Existing installs may still use the PARA layout (Active/, Relationships/, Reference/, Archive/, Claudia's Desk/) and that is preserved. This skill covers vault paths, when to read from vault vs. query memory directly, and how to trigger sync.
 user-invocable: false
 effort-level: low
 ---
@@ -11,6 +11,23 @@ effort-level: low
 
 ---
 
+## Wiki vs PARA: which layout is in use
+
+Claudia ships two vault layouts. Both write to `~/.claudia/vault/`:
+
+| Layout | What gets written | When it's the default |
+|--------|-------------------|-----------------------|
+| **Wiki** (new default) | Synthesized topic pages by Claudia, citing source memories, with contradiction flagging. See the `wiki` skill. | All installs from v1.60.0 onward, unless the vault already has PARA folders |
+| **PARA** (legacy) | Mechanical dump of entity rows into `Active/`, `Relationships/`, `Reference/`, `Archive/`, `Claudia's Desk/` | Installs from v1.42 to v1.59 that started syncing before the wiki shipped |
+
+**Detection rule.** If `~/.claudia/vault/Wiki/` exists, wiki mode is active. If `~/.claudia/vault/Active/` or `Relationships/` exists without `Wiki/`, the user is on PARA. If both exist, the user is mid-migration; treat both as readable, but write only to `Wiki/`.
+
+**Migration is not automatic.** Existing PARA vaults are preserved untouched. The `claudia-memory --migrate-to-wiki` CLI flag (when it ships in a future release) will copy PARA aside and rebuild wiki pages from raw memories. Until then, PARA users stay on PARA; new users get wiki.
+
+For wiki specifics (page structure, when to write, citations, contradiction flagging), see the `wiki` skill. The rest of this file documents the older PARA layout, kept here for backward compatibility.
+
+---
+
 ## What the Vault Is
 
 Claudia's memory lives in SQLite (the source of truth). The vault at `~/.claudia/vault/{project_id}/` is a **read projection**: markdown notes with YAML frontmatter and `[[wikilinks]]` that Obsidian can display, search, and graph.

package/template-v2/.claude/skills/wiki/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: wiki
+description: Maintain Claudia's wiki, a directory of synthesized Markdown pages about your active entities (people, projects, organizations, topics). Each page is written by Claudia from raw memories, cites its sources, flags contradictions, and grows over time. Use when user says "write a wiki page for [entity]", "what do you know about [entity]" (returns the wiki page if it exists), "update the wiki on [entity]", or after ingesting substantial new content about an active entity. Replaces PARA as the default vault structure for new installs.
+effort-level: medium
+invocation: contextual
+---
+
+# Wiki
+
+A persistent, navigable, LLM-maintained reference. The wiki is the third tier of Claudia's memory: raw memories live in SQLite, derived signals (entities, reflections, patterns) live in the daemon, and **synthesized topic pages** live here, in the user's Obsidian vault at `~/.claudia/vault/Wiki/`.
+
+This skill is how I write those pages.
+
+## What the wiki is for
+
+| Today (without wiki) | With wiki |
+|----------------------|-----------|
+| "What's going on with Sarah?" forces me to re-synthesize from raw memories every time. | I check `Wiki/Sarah-Chen.md`. If it's fresh, the answer is already there. |
+| Important entities accumulate scattered memories with no narrative. | Each active entity has one page that grows with use. |
+| Contradictions in what I've been told sit silently. | Contradictions get flagged at the top of the page when I write it. |
+| Memory dumps for important entities are unreadable. | Wiki pages are readable; the user can open them in Obsidian. |
+
+The wiki is **synthesized once at ingest time**, not re-derived at every query. That's the key contrast with raw memory recall.
+
+## Where wiki pages live
+
+`~/.claudia/vault/Wiki/<entity-name>.md`
+
+The vault root is the user's existing Obsidian vault (or it gets created on first wiki write). Each page is a single Markdown file. Filename matches the canonical entity name with spaces converted to hyphens (`Sarah Chen` → `Sarah-Chen.md`).
+
+The `Wiki/` subdirectory sits alongside any existing PARA folders (`Active/`, `Relationships/`, etc.) for users already syncing to PARA. New installs default to wiki-only. Existing PARA users keep PARA running until they opt to migrate.
+
+## When I write a wiki page
+
+I write a wiki page proactively in these situations:
+
+1. **After capturing a meeting** with a key person, organization, or project mentioned. If the wiki page for the entity doesn't exist or is stale, I update it.
+2. **After filing a document** that contains substantive new information about an active entity.
+3. **After ingesting multiple sources** that touch the same entity.
+4. When the user **explicitly asks** ("write a wiki page for [entity]", "update the wiki on [entity]").
+
+I write a wiki page **on-demand** when:
+
+5. The user asks "what's going on with [entity]?" or "what do you know about [entity]?" and either no page exists or the existing page is older than the most recent memory about the entity.
+
+**I do NOT write a wiki page when:**
+
+- The entity is dormant (no mentions in the last 60 days). Dormant entities stay in raw memory only.
+- I would only have one or two memories to work from. The page would be too thin to earn its keep.
+- The entity is sensitive in a way that suggests the user wouldn't want a synthesized page (medical, deeply personal). Stay in raw memory.
+
+## Page structure
+
+Every wiki page follows this template:
+
+```markdown
+---
+entity: "Sarah Chen"
+entity_type: person
+last_updated: 2026-05-15
+source_memories: [142, 278, 391, 412, 487]
+contradiction_count: 0
+---
+
+# Sarah Chen
+
+> One-sentence TLDR for Claudia and the user to read first.
+
+## At a glance
+
+- **Role:** VP of Engineering at Acme Corp [mem:278]
+- **First contact:** 2025-11-12 via James [mem:142]
+- **Last interaction:** 2026-05-08, intro call with the design team [mem:487]
+- **Communication style:** Email over Slack, mornings only [mem:391]
+
+## What matters to her
+
+(Synthesized prose from accumulated memories. Each meaningful claim cites the memory it came from. Aim for clarity, not completeness; this is a working reference, not a dossier.)
+
+## Current threads
+
+- **Acme rebrand engagement:** waiting on her sign-off on the proposal [mem:487]
+- **(other open threads)**
+
+## History
+
+- 2026-05-08: Intro call with design team [mem:487]
+- 2026-03-22: Sent the engagement scope [mem:412]
+- (more history, newest first)
+
+## Related
+
+- [[Acme Corp]]
+- [[James (introducer)]]
+- [[Acme rebrand engagement]]
+```
+
+Required elements:
+- **YAML frontmatter** with `entity`, `entity_type`, `last_updated`, `source_memories` (list of memory IDs that contributed to this version of the page), `contradiction_count`.
+- **TLDR** in a blockquote at the top. One sentence that answers "what's the deal with this entity?"
+- **Citations** as `[mem:NNN]` after each load-bearing claim. The user can trace any fact back to its source.
+- **Cross-references** as `[[Entity Name]]` Obsidian wikilinks. These power the graph view.
+
+Optional sections (use what fits):
+- "At a glance" for quick facts
+- "What matters to them" for preferences, motivations, values
+- "Current threads" for open commitments and projects
+- "History" reverse-chronological log of interactions
+- "Contradictions" at the top, if any (see below)
+
+## Contradictions
+
+When two memories about the same entity disagree, the wiki page must surface it. Add a section directly after the TLDR:
+
+```markdown
+## ⚠ Contradictions to resolve
+
+- **Role:** Listed as "VP of Engineering" in the kickoff notes [mem:142] but "CTO" in the org chart shared 2026-04-01 [mem:412]. Ask user which is current.
+```
+
+Update `contradiction_count` in the frontmatter to match. When a contradiction is resolved (user clarifies), strike through the obsolete claim in the relevant section and add a note.
+
+## Writing process (workflow)
+
+When I'm asked to write or update a wiki page for an entity:
+
+1. **Check if a page already exists.** Use the Read tool on `~/.claudia/vault/Wiki/<entity-name>.md`. If it exists, read it. Note the `source_memories` list in the frontmatter, those are the memories already incorporated.
+2. **Query memories about the entity.** Use the `memory_about` or `memory_recall` MCP tool to get all memories tagged to this entity. Note which memory IDs are NEW relative to the existing page.
+3. **Decide: incremental update or full rewrite.**
+   - If there's an existing page and only 1-3 new memories: incremental. Add new facts to relevant sections, append to "History", update the TLDR if warranted.
+   - If there's no page, or 5+ new memories since the last update, or the page is older than 60 days: full rewrite. Build the page from scratch using all memories.
+4. **Synthesize the page** following the template. Cite every meaningful claim. Flag contradictions explicitly.
+5. **Save** using the Write tool to `~/.claudia/vault/Wiki/<entity-name>.md`. Update `last_updated`, append new memory IDs to `source_memories`, refresh `contradiction_count`.
+6. **Cross-link.** If the page references other entities, ensure those entities have wiki pages too. If not and they're active, queue them for later (don't recursively write the whole graph).
+
+## Read workflow (when user asks about an entity)
+
+When the user asks "what do you know about X?", "what's going on with X?", etc:
+
+1. Check if `Wiki/<X>.md` exists.
+2. If yes and `last_updated` is within 7 days of the most recent memory about X: read the page, answer from it, mention you're reading from the wiki page (so the user knows it's a synthesized view).
+3. If yes but stale: read the existing page, query for new memories, summarize what's new, and offer to update the wiki page.
+4. If no page exists: do a regular memory query as before, AND offer to write a wiki page now if the entity is active enough to warrant one.
+
+## Replaces PARA as the default
+
+For new Claudia installs, the wiki is the canonical projection of memory into the vault. The old PARA mechanical-dump (entity rows extracted to `Active/`, `Relationships/`, etc.) is deprecated.
+
+**For users with existing PARA vaults:** the old PARA structure is preserved. Both `Wiki/` and the existing PARA folders coexist. The user can migrate (or not) at their own pace. The `claudia-memory --migrate-to-wiki` CLI flag (when it ships in a future release) will copy the PARA structure aside and regenerate wiki pages from raw memories.
+
+**Config:** A single setting in `~/.claudia/config.json`:
+
+```json
+{
+  "vault_mode": "wiki"
+}
+```
+
+Values:
+- `"wiki"` (default for new installs): wiki pages get written on ingest. PARA sync is skipped.
+- `"para"`: PARA mechanical dump runs as before (for backward compatibility). Wiki pages are not auto-written but can be invoked manually.
+- `"both"`: PARA runs AND wiki writes happen on ingest. Higher cost, redundant. Mostly useful during migration.
+
+If `vault_mode` is unset and the existing vault has PARA folders, treat as `"para"`. Otherwise treat as `"wiki"`.
+
+## What the wiki is NOT
+
+- **Not Wikipedia.** Pages are about *the user's* working set, not the general world. "Sarah Chen" is the Sarah the user actually works with, not the public figure.
+- **Not a comprehensive dossier.** Pages should be useful at a glance. Aim for 300 to 1500 words per page, with longer pages reserved for entities the user interacts with daily.
+- **Not a replacement for raw memory.** Every wiki page is *derived from* raw memories. The raw memories are still the source of truth. Wiki pages are the synthesized view.
+- **Not a place for sensitive personal information.** If a memory contains sensitive content (medical, deeply personal), keep it in raw memory only and do not surface it in the wiki page unless the user explicitly asks.
+
+## Style
+
+Wiki pages should:
+- Be readable as standalone Markdown. The user might open them in Obsidian without my mediation.
+- Cite every load-bearing claim with `[mem:NNN]`. Trust requires traceability.
+- Use plain language. No em dashes (project style rule). Direct sentences.
+- Stay scoped to what's useful, not what's comprehensive.
+
+See also: `vault-awareness` for the vault path conventions; `memory-manager` for the underlying memory lifecycle that feeds the wiki; `file-document`, `capture-meeting`, and `ingest-sources` for the ingestion paths that should trigger wiki writes.
+
+## Open questions for future versions
+
+- Automatic refresh queue (mark entities as "dirty" on ingest, batch refresh later) is not in this skill. Today, wiki writes are explicit. A future PR may add daemon-side auto-triggering.
+- Wiki search (find pages by topic, not just entity name) is not yet a thing. Today, Obsidian's own search handles this.
+- The `--migrate-to-wiki` CLI is named but not yet implemented. Users on PARA stay on PARA until that CLI ships.

package/template-v2/.claude/skills/wiki/references/citations-and-contradictions.md

@@ -0,0 +1,99 @@
+# Citations and Contradictions
+
+The two disciplines that make wiki pages trustworthy.
+
+## Citations
+
+Every load-bearing claim on a wiki page must cite the memory it came from. Format: `[mem:NNN]` where NNN is the memory ID returned by `memory_recall` or `memory_about`.
+
+### What counts as load-bearing
+
+Cite:
+- Facts about the entity (role, location, preferences, history)
+- Decisions or commitments
+- Quoted preferences or statements
+- Dates and timelines
+- Relationships between entities
+
+Don't cite (no memory ID exists):
+- Synthesis sentences that combine multiple facts (the facts themselves are cited)
+- Stylistic glue ("As mentioned above", "On the other hand")
+- Generic background that isn't specific to the entity
+
+### Where to put the citation
+
+Inline, at the end of the sentence or claim:
+
+```markdown
+Sarah is VP of Engineering at Acme Corp [mem:278].
+```
+
+Multiple sources for one claim:
+
+```markdown
+The Acme rebrand kickoff was on 2026-03-15 [mem:412, mem:438].
+```
+
+### Reading citations back
+
+When the user asks "where did you learn that?" or "show me the source", I use the memory ID to call `memory_recall` with the specific ID and surface the original memory content.
+
+## Contradictions
+
+The wiki must surface contradictions, not hide them.
+
+### Detection
+
+A contradiction exists when two or more memories about the same entity claim mutually exclusive things. Examples:
+
+- Role mismatch: "VP Engineering" in one memory, "CTO" in another, no resolving memory in between.
+- Date mismatch: meeting date listed differently in two sources.
+- Preference flip: user said person prefers email, then said they prefer Slack, with no "they changed their mind" memory.
+
+The detection rule: if I can write both `X is true [mem:A]` and `X is false [mem:B]` from the same memory pool, that's a contradiction.
+
+### Surfacing
+
+Add a `## ⚠ Contradictions to resolve` section directly after the TLDR. Each contradiction is one bullet:
+
+```markdown
+## ⚠ Contradictions to resolve
+
+- **Role title:** Listed as "VP of Engineering" in kickoff notes [mem:142] but "CTO" in the org chart [mem:412]. The org chart is more recent; recommend updating but the user should confirm.
+- **Preferred channel:** Said "email only" in onboarding [mem:201] but accepted a Slack invite that's been active since [mem:489]. Probably both work; ask user if they want the preference updated.
+```
+
+Update `contradiction_count` in the frontmatter to match the number of bullets.
+
+### Resolving
+
+When the user clarifies a contradiction, I:
+1. Strike through the obsolete claim in its original section.
+2. Add the resolved fact.
+3. Remove the bullet from the contradictions section.
+4. Decrement `contradiction_count`.
+5. Note the resolution in the History section with the date and the user's clarification cited.
+
+Example after resolution:
+
+```markdown
+## At a glance
+
+- **Role:** ~~VP of Engineering~~ CTO at Acme Corp (user confirmed 2026-05-15) [mem:142, mem:412, mem:521]
+```
+
+### When NOT to flag
+
+Don't flag minor wording differences ("software engineer" vs "engineer", "team lead" vs "tech lead") unless the user has previously noted they care about the distinction. The contradictions section is for things that actually create confusion if uncovered later.
+
+## Why this matters
+
+Wiki pages without citations are indistinguishable from confabulation. The user has to trust the synthesis without being able to verify it. That violates Claudia's Trust North Star.
+
+Wiki pages that hide contradictions are worse than no pages at all. They give the user false confidence in a fact that's actually disputed. Surfacing contradictions is what makes the wiki *honest* synthesis instead of *plausible* synthesis.
+
+## See also
+
+- The Trust North Star rule for the broader principle
+- `memory-audit` for tracing a fact back across all its source memories
+- `fix-duplicates` for cases where the "contradiction" is actually two entities that should be merged into one

package/template-v2/.claude/skills/wiki/references/page-template.md

@@ -0,0 +1,84 @@
+# Wiki Page Template
+
+Copy this when creating a new wiki page. Fill the placeholders with synthesized content from memories. Cite every load-bearing claim with `[mem:NNN]` where NNN is the memory ID.
+
+```markdown
+---
+entity: "ENTITY NAME"
+entity_type: person | organization | project | concept | location
+last_updated: YYYY-MM-DD
+source_memories: [NNN, NNN, NNN]
+contradiction_count: 0
+---
+
+# ENTITY NAME
+
+> One-sentence TLDR. What's the essential fact about this entity that Claudia should know on first glance.
+
+## At a glance
+
+- **Role / Type:** what they are or do [mem:NNN]
+- **First contact / appeared:** when they entered the user's world [mem:NNN]
+- **Last interaction:** most recent meaningful touchpoint [mem:NNN]
+- **Communication / Operational style:** how they prefer to work, if known [mem:NNN]
+
+## What matters to them
+
+Synthesized prose. What are their goals, preferences, concerns? What context shapes how they show up? Cite every claim. Keep this section to the load-bearing facts; not everything you know belongs here.
+
+## Current threads
+
+- **Thread name:** status, what's open, who owes what [mem:NNN]
+- (more threads, one bullet each)
+
+If no open threads, omit this section.
+
+## History
+
+Reverse chronological. Most recent first. One bullet per significant interaction or fact-update.
+
+- YYYY-MM-DD: what happened [mem:NNN]
+- YYYY-MM-DD: what happened [mem:NNN]
+
+Cap at ~10 entries per page. Older history is in raw memory; the page surfaces what's still relevant.
+
+## Related
+
+- [[Other Entity 1]]
+- [[Other Entity 2]]
+
+Use Obsidian wikilink format. The graph view picks these up.
+
+## Notes
+
+Anything that doesn't fit the structured sections above. Use sparingly. If this section grows past one or two paragraphs, the content probably belongs in one of the structured sections.
+```
+
+## If contradictions exist
+
+Insert this section directly after the TLDR, before "At a glance":
+
+```markdown
+## ⚠ Contradictions to resolve
+
+- **Topic:** Description of the contradiction. Memory A says X [mem:NNN], memory B says Y [mem:NNN]. Recommended resolution or open question for the user.
+```
+
+Increment the `contradiction_count` in the frontmatter accordingly.
+
+## If the entity is dormant or sensitive
+
+Don't write a wiki page. Stay in raw memory only. See the parent SKILL.md for the rules.
+
+## Page size discipline
+
+- Minimum: ~300 words. Below that, the page isn't earning its keep over a memory recall.
+- Typical: 500 to 1000 words.
+- Maximum: ~1500 words. If a page is growing past that, split into multiple pages (e.g., `Sarah-Chen.md` + `Sarah-Chen-Engagement-2026.md`) and link them with `[[wikilinks]]`.
+
+## Style reminders
+
+- No em dashes. Use commas, periods, colons, or parentheses.
+- Plain language. Direct sentences.
+- Cite every meaningful claim with `[mem:NNN]`.
+- Cross-link related entities with `[[Entity Name]]`.