• ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml

  -- the 15 kernel primitives (with enforcement levels)

• ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md

  -- dimension coupling rules, hard/soft constraint checks

• ${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md

  -- 10 failure modes with domain vulnerability matrix

• ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md

  -- domain-native vocabulary mappings (6 transformation levels)

• ${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md

  -- personality derivation (4 dimensions, conflict resolution, artifact transformation)

• ${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md

  -- three-space architecture (self/notes/ops separation rules)

• ${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md

  -- 3 presets with pre-validated configurations

• ${CLAUDE_PLUGIN_ROOT}/reference/conversation-patterns.md

  -- 5 worked examples validating derivation heuristics

• ${CLAUDE_PLUGIN_ROOT}/generators/claude-md.md

  -- CLAUDE.md generation template

• ${CLAUDE_PLUGIN_ROOT}/generators/features/*.md

  -- composable feature blocks for context file composition

• "My reflections" -> notes are called "reflections"
• "Capture reactions" -> reduce phase is called "capture"
• "Track decisions" -> note type is "decision"

1. Domain understanding -- what kinds of knowledge, what volume, how often
2. Vocabulary confirmation -- if user language suggests non-standard terms
3. Signal conflict resolution -- if contradictory signals emerged

• "When you say 'connections,' what kind? Books covering similar themes, or how one book changed your mind about another?"
• "Walk me through what happened the last time you wanted to remember something."
• "Who else will use this, or is it just for you?"

• "Do you want atomic or moderate granularity?"
• "How heavy should processing be?"
• "What level of schema density?"

1. Granularity -- affects the most downstream cascades
2. Processing -- determines which pipeline approach is generated
3. Automation -- determines topology and skill complexity
4. Organization -- affects folder structure and navigation
5. Linking -- affects connection density
6. Navigation depth -- affects MOC generation
7. Schema density -- affects template complexity
8. Maintenance triggers -- lowest priority, easily adjusted post-deployment

1. All resolved: All 8 dimensions have cumulative confidence >= 1.5 from signals. Proceed to Phase 3 immediately.
2. Mostly resolved: At least 6 dimensions resolved, remaining 2 tentative (confidence >= 0.6). Proceed with cascade filling tentative dimensions.
3. Turn limit: After 4 conversation turns, proceed regardless. Unresolved dimensions use the closest matching use-case preset defaults. Tentative dimensions use cascade from resolved dimensions.
4. User impatience: User signals desire to proceed ("just set it up," "whatever you think is best"). Use domain defaults for all unresolved dimensions. Log that defaults were used in derivation rationale.

• Collect all signals extracted during conversation
• Sum confidence weights
• Determine position (resolved if >= 1.5, tentative if >= 0.6, unresolved otherwise)
• Apply conflict resolution tree if signals conflict

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md

• Atomic granularity -> pressure toward explicit linking, deep navigation, heavier processing
• Full automation -> pressure toward dense schemas, heavy processing, frequent maintenance
• High volume (>200 projected notes) -> requires deep navigation, semantic search, automated maintenance
• Coarse granularity -> permits lightweight linking, shallow navigation, light processing

${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md

1. User's own words -- highest priority. If they said "book note," use "book note."
2. Preset table -- fallback when user has not named a concept
3. Closest reference domain blend -- for novel domains, blend vocabulary from two closest presets

1. Score all 3 presets by signal overlap
2. Select top two presets as blending sources
3. For each term, use the preset with higher overlap for that specific concept
4. Flag all blended terms for user confirmation in the proposal

${CLAUDE_PLUGIN_ROOT}/reference/personality-layer.md

• Therapy domain -> warm, emotionally attentive
• Research domain -> neutral, formal
• Creative domain -> lean playful, opinionated

1. Domain takes priority over affect -- research + "friend" produces warm but not playful
2. Explicit beats implicit -- stated preference overrides tone
3. Clarifying question when ambiguity remains

personality.enabled: true

personality.enabled: false

${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md

• atomic + navigation_depth == "2-tier" + volume > 100

  -> navigational vertigo

• automation == "full" + no_platform_support

  -> platform cannot support full automation

• processing == "heavy" + automation == "manual" + no_pipeline_skills

  -> unsustainable

• If violated AND the weaker dimension was set by cascade (not explicit user signal) -> auto-adjust the cascaded value
• If violated AND both dimensions were user-driven -> present warning with trade-off explanation
• Record resolution in derivation rationale

• atomic + processing == "light"

  -> atomic notes need processing to recreate decomposed context

• schema == "dense" + automation == "convention"

  -> maintenance burden

• linking == "explicit+implicit" + no_semantic_search

  -> implicit linking needs search tool

• volume > 200 + maintenance_thresholds too lax

  -> large vaults need tighter condition thresholds

• processing == "heavy" + maintenance_thresholds too lax

  -> heavy processing generates targets faster than lax thresholds catch

• coarse + processing == "heavy"

  -> diminishing returns

• flat + navigation_depth == "2-tier" + volume > 50

  -> crowded navigation

• Atomic + medium processing -> semantic search compensates for missing explicit links
• Dense schema + convention -> good templates reduce manual validation burden
• High volume + shallow nav -> strong semantic search enables discovery

1. "Here's the system I'd create for you:"
2. Folder structure with their domain-named directories
3. How their notes work -- with a specific example from their domain using their vocabulary
4. How processing works, described in their words
5. How self-knowledge works — "Your system maintains its own methodology in ops/methodology/. Use /ask to query the 249-note methodology knowledge base backing your design, or browse ops/methodology/ directly."
6. Agent personality description (if personality was derived; otherwise skip)
7. What was intentionally excluded and why
8. Any high-risk failure modes flagged

1. Derivation persistence first.

   ops/derivation.md

   is the FIRST artifact generated -- before folder structure, before any other file. It captures the complete derivation state.
2. Stateless generation. Every subsequent step re-reads

   ops/derivation.md

   as its source of truth. No generation step relies on conversation memory for configuration decisions.
3. Sequential feature block processing. Context file composition processes blocks one at a time -- read, transform, compose, release -- rather than loading all blocks simultaneously.

• Tier: [Claude Code / Minimal]
• Automation level: [full / convention / manual]
• Automation: [full (default) / convention / manual]

• wiki-links -- always included (kernel)
• maintenance -- always included (always)
• self-evolution -- always included (always)
• session-rhythm -- always included (always)
• templates -- always included (always)
• ethical-guardrails -- always included (always) [List all conditional blocks with inclusion/exclusion rationale]

• Hard constraints checked: [count]. Violations: [none / details]
• Soft constraints checked: [count]. Auto-adjusted: [details]. User-confirmed: [details]
• Compensating mechanisms active: [list or none]

• Folder names: [domain-specific folder names]
• Skills to generate: [all 26 — vocabulary-transformed]
• Hooks to generate: [orient, capture, validate, commit]
• Templates to create: [list]
• Topology: [single-agent / skills / fresh-context / orchestrated]

This file serves three purposes:
1. **Immediate:** Source of truth for all subsequent generation steps (context resilience)
2. **Operational:** Enables `/architect` to reason about configuration drift
3. **Evolution:** Enables `/reseed` to re-derive with updated understanding

---

ops/derivation.md

CLAUDE.md

${CLAUDE_PLUGIN_ROOT}/generators/claude-md.md

README.md

Step 1: Read generator template for the platform.

Step 2: Select feature blocks from ${CLAUDE_PLUGIN_ROOT}/generators/features/.
  Always-included blocks (11): wiki-links, processing-pipeline, schema, maintenance, self-evolution, methodology-knowledge, session-rhythm, templates, ethical-guardrails, helper-functions, graph-analysis
  Conditional blocks: based on derived dimensions (see Active Feature Blocks in derivation.md)

Step 3: Process blocks SEQUENTIALLY. For each selected block:
  a. Read the block file
  b. Apply vocabulary transformation (Section 9 algorithm -- LLM-based contextual replacement, NOT string find-replace)
  c. Compose into the growing context file
  d. Release the block from context before reading the next

Step 4: Compose in canonical block order:
  1. Philosophy (derived from personality + domain)
  2. session-rhythm -- Orient, work, persist, session capture
  3. atomic-notes -- Note design principles (if active)
  4. wiki-links -- Link philosophy and patterns
  5. mocs -- Navigation structure (if active)
  6. processing-pipeline -- Processing approach (always included)
  7. semantic-search -- Discovery layers (if active)
  8. schema -- Metadata and query patterns (always included)
  9. maintenance -- Health checks and reweaving
  10. self-evolution -- System evolution approach
  10b. methodology-knowledge -- Querying and consulting self-knowledge
  11. personality -- Voice and identity (if active)
  12. templates -- Template usage
  13. multi-domain -- Cross-domain rules (if active)
  14. self-space -- Agent identity and memory (if active)
  15. ethical-guardrails -- Behavioral constraints
  16. helper-functions -- Utility scripts (always included)
  17. graph-analysis -- Graph intelligence and query patterns (always included)

Step 5: Cross-reference elimination.
  If a block is excluded, scan remaining blocks for references to excluded concepts and remove or rephrase:
  - semantic-search excluded -> rephrase "semantic search" to "search your notes" or remove
  - mocs excluded -> simplify "topic MOCs" to "topic organization"
  - self-space excluded -> references to self/identity.md route to ops/ equivalents
  - atomic-notes excluded -> simplify atomicity references to general note guidance
  - multi-domain excluded -> remove cross-domain references

Step 6: Add required sections that are NOT from feature blocks:
  a. Header with philosophy statement and domain identity
  b. Discovery-first design section (kernel primitive 11)
  c. Memory type routing table (where content goes: notes/, self/, ops/, inbox/, reminders.md)
  d. Infrastructure routing table (routes methodology questions to arscontexta plugin skills)
  e. Self-improvement loop (manual friction capture instructions)
  f. Common Pitfalls (3-4 HIGH-risk failure modes from vulnerability matrix, in domain vocabulary)
  g. System Evolution section (architect, reseed, friction-driven growth)
  h. Self-extension blueprints (how to build new skills, hooks)
  i. Derivation Rationale summary (which dimensions, which signals, which tradition)
  j. Pipeline Compliance (NEVER write directly to notes/, route through inbox)
  k. Condition-based maintenance documentation (what signals trigger which actions)

Step 7: Coherence verification.
  - [ ] No orphaned references to excluded blocks
  - [ ] Vocabulary consistent (same universal term -> same domain term everywhere)
  - [ ] Personality tone consistent across all sections
  - [ ] All mentioned skills exist in the generated skills (or are documented as dormant tiers)
  - [ ] All mentioned file paths exist in the generated folder structure
  - [ ] All mentioned templates exist in the generated templates
  - [ ] Processing terminology matches selected pipeline approach (light vs heavy)
  - [ ] Schema fields mentioned in prose exist in generated templates

Step 8: Apply vocabulary transformation one final time.
  Read the completed context file. Replace every remaining universal term with its domain-native equivalent.
  The vocabulary test: would a domain user ever see a term from a different discipline?

Step 9: Write the file.
  Target operational density: each section should have enough detail that the agent can follow instructions without asking questions.
  "Process your notes" is insufficient.
  "Read the source fully, extract insights that serve the domain, check for duplicates" is sufficient.

description:

topics:

relevant_notes:

type:

status:

_schema:

• Tell the agent to ALWAYS read self/ at session start
• Explain prose-as-title with examples from the user's domain
• Include domain-specific schema in the YAML section
• Provide self-extension blueprints
• Include derivation rationale (which dimensions, which signals)
• Feel cohesive, not like assembled blocks
• Use domain-native vocabulary throughout

• Research: "I am a research partner building understanding about..."
• Therapy (warm): "I pay attention to what you write about your sessions..."
• PM (neutral): "I track decisions across your projects..."
• Companion (warm): "I remember the things that matter about your life..."]

• [Relevant values for the use case, derived from personality + domain]

• [How the agent approaches its work, reflecting personality dimensions]

• [[methodology]]

---

• Prose-as-title: every [domain:note] is a proposition
• Wiki links: connections as graph edges
• [domain:MOCs]: attention management hubs
• Capture fast, process slow

• [[identity]]

---

• [[derivation-rationale]] — Why each configuration dimension was set the way it was

• [[methodology]]

The seven content categories for ops/methodology/ are: `derivation-rationale`, `kernel-state`, `pipeline-config`, `maintenance-conditions`, `vocabulary-map`, `configuration-state`, `drift-detection`. Only `derivation-rationale` is created at init; the others are populated by meta-skills during operation.

---

• [[getting-started]] — Your first session, first {DOMAIN:note}, and first connection
• [[skills]] — Every available command with when to use it and examples
• [[workflows]] — The processing pipeline, maintenance cycle, and session rhythm
• [[configuration]] — How to adjust settings via config.yaml or /architect
• [[meta-skills]] — /ask, /architect, /{DOMAIN:rethink}, and /{DOMAIN:remember} explained
• [[troubleshooting]] — Common issues and how to resolve them

**Page 2: getting-started.md**

```markdown
---
description: First session guide — creating your first {DOMAIN:note} and building connections
type: manual
generated_from: "arscontexta-{version}"
---

• What to expect in your first session
• Creating your first {DOMAIN:note} (walk through the process)
• How connections work (wiki links, {DOMAIN:topic maps})
• The orient-work-persist session rhythm
• Where to go next (link to [[workflows]] and [[skills]])
• Running /tutorial for an interactive walkthrough

**Page 3: skills.md**

```markdown
---
description: Complete reference for every available command
type: manual
generated_from: "arscontexta-{version}"
---

• Every generated skill with domain-native name, purpose, and example invocation
• Group by category: Processing, Orchestration, Meta-Cognitive, Diagnostic, Knowledge, Research, Lifecycle, Onboarding
• For each skill: when to use it, what it does, example command
• Link to [[workflows]] for how skills chain together
• Link to [[meta-skills]] for detailed meta-skill documentation

**Page 4: workflows.md**

```markdown
---
description: Processing pipeline, maintenance cycle, and session rhythm
type: manual
generated_from: "arscontexta-{version}"
---

• The full processing pipeline: {DOMAIN:seed} -> {DOMAIN:process} -> {DOMAIN:connect} -> {DOMAIN:maintain} -> {DOMAIN:verify}
• Session rhythm: orient (what's happening) -> work (do the thing) -> persist (save state)
• Maintenance cycle: condition-based triggers, what to do when conditions fire
• Batch processing with /{DOMAIN:orchestrate}
• Link to [[skills]] for command details
• Link to [[configuration]] for adjusting pipeline settings

**Page 5: configuration.md**

```markdown
---
description: How to adjust your system via config.yaml and /architect
type: manual
generated_from: "arscontexta-{version}"
---

• config.yaml structure and key fields
• Using /architect for guided configuration changes
• Feature toggling: what can be enabled/disabled
• Preset explanation: what your preset includes and why
• Dimension positions and what they mean for your domain
• Link to [[meta-skills]] for /architect details
• Link to [[troubleshooting]] for configuration issues

**Page 6: meta-skills.md**

```markdown
---
description: Deep guide to /ask, /architect, /{DOMAIN:rethink}, and /{DOMAIN:remember}
type: manual
generated_from: "arscontexta-{version}"
---

• /ask — querying the bundled research knowledge base + local methodology
• /architect — getting research-backed configuration advice
• /{DOMAIN:rethink} — reviewing accumulated observations and tensions, drift detection
• /{DOMAIN:remember} — capturing friction and methodology learnings (Rule Zero: methodology as spec)
• When to use each meta-skill
• How meta-skills relate to system evolution
• Link to [[configuration]] for config changes
• Link to [[troubleshooting]] for drift-related issues

**Page 7: troubleshooting.md**

```markdown
---
description: Common issues and resolution patterns
type: manual
generated_from: "arscontexta-{version}"
---

• Orphan {DOMAIN:notes} — notes with no incoming links (run /{DOMAIN:connect})
• Dangling links — wiki links to non-existent {DOMAIN:notes} (check after renames)
• Stale content — {DOMAIN:notes} not updated in 30+ days with sparse connections (run /{DOMAIN:maintain})
• Methodology drift — system behavior diverging from methodology spec (run /{DOMAIN:rethink} drift)
• Inbox overflow — too many items accumulating (run /{DOMAIN:process} or /{DOMAIN:pipeline})
• Pipeline stalls — tasks stuck in queue (check with /{DOMAIN:next})
• Common mistakes table with corrections
• Link to [[meta-skills]] for /rethink and /remember
• Link to [[configuration]] for threshold adjustments

**Quality gates:**
- All skill references use domain-native names from the derivation conversation
- All pages link back to [[manual]] via a footer or contextual reference
- No wiki links to notes/ — manual is self-contained
- Each page has `generated_from: "arscontexta-{version}"` in frontmatter
- Content uses domain-specific examples, not generic/abstract ones

---

• Getting started -- learning this knowledge system
• [Use-case-specific initial goals derived from conversation]

• [[identity]]

---

• [list of active feature block IDs]

Level 1: Folder names

Level 2: Note types

Level 3: Schema field names

Level 4: Navigation terms

Level 5: Process verbs

Level 6: Command names (as users invoke them)

Level 7: Extraction categories (domain-specific, from conversation)

personality: warmth: [clinical | warm | playful] opinionatedness: [neutral | opinionated] formality: [formal | casual] emotional_awareness: [task-focused | attentive]

**Why this file exists separately from derivation.md:** derivation.md is the human-readable reasoning record (WHY each choice was made, conversation signals, confidence levels). derivation-manifest.md is the machine-readable operational manifest (WHAT the choices are). Skills read the manifest for quick vocabulary lookup without parsing the narrative derivation document.

**Who updates this file:**
- `/setup` generates it
- `/reseed` regenerates it after re-derivation
- `/architect` updates it when implementing approved changes
- `/add-domain` extends it with new domain vocabulary

---

ops/derivation.md

templates/

• Primary note template (domain-named:

  claim-note.md

  ,

  reflection-note.md

  ,

  decision-note.md

  , etc.)
• MOC template (domain-named:

  topic-map.md

  ,

  theme.md

  ,

  decision-register.md

  , etc.)

• Source capture template (if processing >= moderate)
• Observation template (if self-evolution is active -- always)

_schema

---
_schema:
  entity_type: "[domain]-note"
  applies_to: "[domain:notes]/*.md"
  required:
    - description
    - topics
  optional:
    - [domain-specific fields based on schema density]
  enums:
    type:
      - [domain-relevant types]
  constraints:
    description:
      max_length: 200
      format: "One sentence adding context beyond the title"
    topics:
      format: "Array of wiki links"

description: "" topics: [] [domain fields with defaults]

• [[related note]] -- relationship context

• [[relevant-moc]]

Apply vocabulary transformation to the template: field labels in comments and example values use domain vocabulary. YAML field names stay structural (description, topics, etc.).

---

ops/derivation.md

${CLAUDE_PLUGIN_ROOT}/skill-sources/

SKILL.md

${CLAUDE_PLUGIN_ROOT}/skill-sources/reduce/

${CLAUDE_PLUGIN_ROOT}/skill-sources/reflect/

${CLAUDE_PLUGIN_ROOT}/skill-sources/reweave/

${CLAUDE_PLUGIN_ROOT}/skill-sources/verify/

${CLAUDE_PLUGIN_ROOT}/skill-sources/validate/

${CLAUDE_PLUGIN_ROOT}/skill-sources/seed/

${CLAUDE_PLUGIN_ROOT}/skill-sources/ralph/

${CLAUDE_PLUGIN_ROOT}/skill-sources/pipeline/

${CLAUDE_PLUGIN_ROOT}/skill-sources/tasks/

${CLAUDE_PLUGIN_ROOT}/skill-sources/stats/

${CLAUDE_PLUGIN_ROOT}/skill-sources/graph/

${CLAUDE_PLUGIN_ROOT}/skill-sources/next/

${CLAUDE_PLUGIN_ROOT}/skill-sources/learn/

${CLAUDE_PLUGIN_ROOT}/skill-sources/remember/

${CLAUDE_PLUGIN_ROOT}/skill-sources/rethink/

${CLAUDE_PLUGIN_ROOT}/skill-sources/refactor/

1. Read

   ${CLAUDE_PLUGIN_ROOT}/skill-sources/[name]/SKILL.md

2. Apply vocabulary transformation — rename and update ALL internal references using the vocabulary mapping from

   ops/derivation.md

3. Adjust skill metadata (set

   context: fork

   for fresh context per invocation)
4. Write the transformed SKILL.md to the user's skills directory

.claude/skills/[domain-skill-name]/SKILL.md

• Anti-shortcut language for quality-critical steps
• Quality gates with explicit pass/fail criteria
• Handoff block format for orchestrated execution
• Domain-native vocabulary throughout

1. Inform the user: Display "Generated [N] skills. Restart Claude Code to activate them."
2. Add to context file: Include a "Recently Created Skills (Pending Activation)" section listing all generated skills with their domain-native names and creation timestamp:

undefined

• /[domain:reduce] -- Extract insights from source material (created [timestamp])
• /[domain:reflect] -- Find connections between [domain:notes] (created [timestamp]) ...

3. **SessionStart hook detects activation:** The session-orient.sh hook checks for this section. Once skills are confirmed loaded (appear in skill index), the section can be removed from the context file.
4. **Phase 6 guidance:** If any skills were created, Phase 6 output includes: "Restart Claude Code now to activate all skills, then try /[domain:help] to see what's available."

---

1. Read existing

   .claude/settings.json

   (if it exists)
2. Parse existing hook matcher groups for each event type (hooks.SessionStart, hooks.PostToolUse, hooks.Stop, etc.)
3. ADD new matcher groups to the event arrays -- never replace existing entries
4. If a matcher group with the same

   command

   path already exists for that event, SKIP it (warn in output, don't overwrite)
5. Write the merged result back to

   .claude/settings.json

• [[identity]] -- who the agent is and how it approaches work
• [[methodology]] -- how the agent processes and connects knowledge
• [[goals]] -- current active threads

1. Read self/identity.md to understand your purpose
2. Capture your first [domain:note] in [domain:notes]/
3. Connect it to this hub

---

1. Check if

   qmd

   is installed:

   which qmd

2. If installed:
   • Run

     qmd init

     in the generated vault root
   • Configure or update the qmd collection for

     {vocabulary.notes_collection}

     so it points at the generated notes directory
   • Create or merge

     .mcp.json

     in the vault root with this qmd MCP server contract:

     • {"mcpServers":{"qmd":{"command":"qmd","args":["mcp"],"autoapprove":["mcp__qmd__search","mcp__qmd__vector_search","mcp__qmd__deep_search","mcp__qmd__get","mcp__qmd__multi_get","mcp__qmd__status"]}}}

   • Run

     qmd update && qmd embed

     to build the initial index
3. If NOT installed:
   • Add a "Next Steps" section to the Phase 6 summary telling the user to install qmd
   • Include specific commands:

     • npm install -g @tobilu/qmd

       (or

       bun install -g @tobilu/qmd

       )

     • qmd init

     • qmd collection add . --name {vocabulary.notes_collection} --mask "**/*.md"

     • qmd update && qmd embed

   • Include the

     .mcp.json

     qmd MCP contract with

     autoapprove

     entries in setup output so activation is deterministic once qmd is installed

ops/derivation.md

_schema

ops/queries/

scripts/queries/

1. Read all

   _schema.required

   and

   _schema.optional

   fields from generated templates
2. Identify queryable dimensions (fields with enum values, date fields, array fields with wiki links)
3. For each meaningful 2-field combination, generate a ripgrep-based query script:
   • Cross-reference queries -- notes sharing one field value but differing on another
   • Temporal queries -- items older than N days in a given status
   • Density queries -- fields with few entries (gap detection)
   • Backlink queries -- what references a specific entity
4. Name each script descriptively

trigger-mood-correlation.sh

recurring-triggers.sh

stale-patterns.sh

cross-methodology.sh

low-confidence-candidates.sh

source-diversity.sh

neglected-contacts.sh

topic-overlap.sh

overdue-items.sh

owner-workload.sh

priority-distribution.sh

${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh

1. markdown-yaml -- Every .md file has valid YAML frontmatter? (>95% threshold)
2. wiki-links -- All wiki links resolve to existing files? (>90% threshold)
3. moc-hierarchy -- At least 3 MOCs exist, every note appears in at least one MOC?
4. tree-injection -- Session start procedure loads file structure? (hook or context file instruction)
5. description-field -- Every note has a description field that differs from the title? (>95%)
6. topics-footer -- Topics field present on every non-MOC note? (>95%)
7. schema-enforcement -- Templates exist as single source of truth, validation mechanism present?
8. semantic-search -- Configured or documented for future activation?
9. self-space -- self/ exists with identity.md, methodology.md, goals.md?
10. session-rhythm -- Context file documents orient/work/persist cycle?
11. discovery-first -- Context file contains Discovery-First Design section, notes optimized for findability?
12. operational-learning-loop -- ops/observations/ and ops/tensions/ exist, review trigger documented in context file, /{DOMAIN:rethink} command exists?
13. task-stack -- ops/tasks.md exists? Queue file (ops/queue/queue.json) exists with schema_version >= 3 and maintenance_conditions section? Context file references both in session-orient phase? /{DOMAIN:next} command exists with condition reconciliation?
14. methodology-folder -- ops/methodology/ exists with methodology.md MOC? At least one derivation-rationale note exists? Context file references ops/methodology/ for meta-skill context?
15. session-capture -- ops/sessions/ directory exists? Session-end hook template installed? Condition-based mining trigger exists for unprocessed sessions?

1. Create a test note in [domain:notes]/ with a sample title and description
2. Verify it has correct schema (description, topics)
3. Verify the hub MOC can reference it
4. Delete the test note and clean up

ars contexta -- the art of context

  Creating your [domain] structure...
  Writing your context file...
  Installing [domain:skills]...
  Setting up templates...
  Building your first [domain:topic map]...
  Initializing version control...
  Running validation...

Your memory is ready.

• Progress markers: Use indented text for generation milestones. These provide orientation during generation.
• Section dividers: Use

  ---

  (standard markdown) between major output sections.

${CLAUDE_PLUGIN_ROOT}/presets/[preset]/starter/

1. Present a starter note appropriate to the domain (e.g., a research claim, a personal reflection, a project decision)
2. Ask the user: "Here's a starter [domain:note] to get you going. Want to customize it, or shall I save it as-is?"
3. Create the note in [domain:notes]/ with proper schema
4. Add it to the hub MOC
5. Show: the note, the MOC it landed in, the schema fields filled

• If qmd not installed and semantic-search is active: npm/bun install instructions + qmd init/update/embed +

  .mcp.json

  contract
• If personality not enabled: mention

  /arscontexta:architect

  for future voice tuning once the vault has 50+ notes
• If any kernel checks failed: specific remediation instructions

1. Generated files feel cohesive, not assembled from blocks. Block boundaries must be invisible in the output. The context file reads as if written from scratch for this specific domain.
2. Language matches the user's domain. A therapy user never sees "claim" or "reduce." A PM user never sees "reflection" or "surface." The vocabulary test applies to every generated file.
3. self/identity.md feels genuine, not templated. It reads like self-knowledge, not a character sheet.
4. Every generated file is immediately useful. No placeholder content. No "TODO: fill this in." Every file serves a purpose from day one.
5. Dimension settings are justified. The derivation rationale connects every choice to either a user signal or a research-backed default.
6. Kernel validation PASSES. Zero failures on every generated system. If validation fails, fix the generation before presenting results.
7. Vocabulary consistency across ALL files. The same universal term must ALWAYS map to the same domain term across all generated files. Run a mental consistency check: if you said "reflection" in the context file, you must say "reflection" in templates, skills, and self/ files.
8. Three-space boundaries are clean. Agent self-knowledge in self/. Domain knowledge in notes/. Operational scaffolding in ops/. No conflation.
9. Discovery-first is enforced. Every note, every MOC, every template is optimized for future agent discovery. Description quality, MOC membership, title composability.
10. Personality never contradicts methodology. A playful agent still enforces quality gates. A warm agent still requires composability checks. Personality affects HOW methodology is communicated, never WHETHER it is enforced.