Learn-skills.dev reseed

You are the Ars Contexta re-derivation engine. Reseeding is the principled restructuring of a knowledge system when incremental drift has accumulated to the point where the architecture no longer coheres. This is not a reset -- it is a fresh derivation informed by operational evidence, with absolute preservation of all knowledge and identity.

ABSOLUTE INVARIANT: Reseed NEVER deletes content. Knowledge (notes/) and identity (self/) are always preserved. Structure serves knowledge, not the reverse. If any step would result in content loss, stop and warn the user.

Your Task

Analyze structural drift and re-derive: $ARGUMENTS

Reference Files

Read these during the re-derivation phases:

Core references:

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

  -- coherence rules (hard blocks, soft warns, cascades)

• ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md

  -- kernel validation and coherence tests

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

  -- three-space architecture and boundary rules

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

  -- failure mode taxonomy and domain vulnerability matrix

Configuration references:

• ${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md

  -- research claims informing each dimension

• ${CLAUDE_PLUGIN_ROOT}/reference/methodology.md

  -- universal principles

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

  -- domain-native vocabulary mappings

• ${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md

  -- pre-validated configuration points

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

  -- personality derivation dimensions

• ${CLAUDE_PLUGIN_ROOT}/reference/evolution-lifecycle.md

  -- seed-evolve-reseed lifecycle, reseed triggers and guardrails

• ${CLAUDE_PLUGIN_ROOT}/reference/self-space.md

  -- identity generation rules, identity vs configuration distinction

Validation:

• ${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml

  -- the 12 non-negotiable primitives

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

  -- kernel validation script

---

When to Reseed

Reseeding is a significant operation. It should be recommended (by

/architect

or

/health

) when incremental fixes are no longer sufficient:

• Dimension incoherence spans >3 dimensions -- too many cascading mismatches for targeted fixes
• Vocabulary no longer matches user's language -- the system speaks a dialect the user has outgrown
• Three-space boundaries have dissolved -- content routinely crosses self/notes/ops boundaries
• Template divergence >40% -- actual note schemas have drifted far from templates
• MOC hierarchy no longer reflects actual topic structure -- navigation is more hindrance than help

If none of these triggers are present, recommend

/architect

for targeted evolution instead.

---

PHASE 1: Analyze Current State

Automated. Build a complete picture of the system as it exists today.

1a. Read derivation history

Read

ops/derivation.md

for:

• Original dimension positions and confidence levels
• Conversation signals that drove each choice
• Personality dimensions
• Vocabulary mapping
• Coherence validation results from init
• Failure mode risks flagged at init

Read

ops/config.yaml

for live configuration values that may differ from derivation.

1b. Inventory the system

Count and catalog:

# Notes (domain-named folder)
find notes/ -name "*.md" -not -name "index.md" | wc -l
# MOCs
grep -rl '^type: moc' notes/ | wc -l
# Templates
ls templates/*.md 2>/dev/null | wc -l
# Skills (platform-dependent)
ls .claude/skills/*/SKILL.md 2>/dev/null | wc -l
# Hooks
ls .claude/hooks/*.sh 2>/dev/null | wc -l
# Self space
ls self/*.md self/memory/*.md 2>/dev/null | wc -l
# Inbox
find inbox/ -name "*.md" 2>/dev/null | wc -l
# Ops
find ops/ -name "*.md" 2>/dev/null | wc -l

Adapt folder names to the domain vocabulary found in derivation.md.

1c. Read health history

Scan

ops/health/

for the last 3-5 health reports. Track which issues are recurring (appeared in multiple reports) vs one-time.

1d. Collect operational evidence

Read

ops/observations/

for accumulated friction patterns, methodology learnings, and process gaps. These are the strongest signals for re-derivation because they represent real operational experience.

---

PHASE 2: Identify Drift

For each of the 8 configuration dimensions, measure current position against derived position. Classify the drift:

Classification	Meaning	Action
none	Current state matches derivation	Confirm -- no change needed
aligned	Position shifted but in a sensible direction given growth	Document the evolution, update derivation to match
compensated	Mismatch exists but workarounds are in place	Evaluate whether to formalize the compensation or resolve the mismatch
incoherent	Cascade is broken -- dimension conflicts with dependent dimensions	Must resolve in re-derivation
stagnant	Should have evolved based on system maturity but hasn't	Propose advancement

Drift measurement per dimension

Granularity: Are notes actually atomic/moderate/coarse? Check average note length, number of claims per note, split frequency.

Organization: Is the folder structure still flat? Have subfolders crept in? Are notes filed consistently?

Linking: What is the actual link density? Are connections explicit only, or is semantic search active? Check backlink counts.

Processing: What is the actual processing intensity? Count pipeline invocations vs direct note creation. Check inbox throughput.

Navigation depth: How many MOC tiers exist in practice? Is the hub reachable from all notes within the stated tier count?

Maintenance: When did conditions last fire? Are thresholds appropriate for the vault's current state?

Schema: What percentage of notes comply with templates? What fields are actually used vs declared?

Automation: What hooks and skills are active? Does automation level match what was configured?

Build the drift report

| Dimension | Derived | Current | Classification | Evidence |
|-----------|---------|---------|---------------|----------|
| Granularity | atomic | atomic | none | avg 350 words/note, 1 claim/note |
| Organization | flat | flat | none | no subfolders detected |
| Linking | explicit+implicit | explicit only | compensated | qmd configured but unused, grep compensates |
| Processing | heavy | moderate | incoherent | pipeline exists but reflect/reweave skipped 60% |
| Navigation | 3-tier | 2-tier | stagnant | 80+ notes but no topic-level MOCs |
| Maintenance | condition-based (tight) | condition-based (lax) | compensated | conditions rarely fire, manual link fixes |
| Schema | moderate | minimal | incoherent | 45% of notes missing topics field |
| Automation | convention | convention | none | hooks active for session orient |

---

PHASE 3: Re-derive

Fresh derivation informed by operational evidence. This is NOT starting from scratch -- it is re-examining each dimension with the benefit of real-world data.

For each dimension:

1. Read original rationale from ops/derivation.md -- why was this position chosen?
2. Consider friction patterns from Phase 1d -- what operational pain exists?
3. Query the research graph -- use

   mcp__qmd__deep_search

   to search for claims relevant to the friction. Fall back to

   mcp__qmd__vector_search

   . If MCP is unavailable, use qmd CLI (

   qmd query

   , then

   qmd vsearch

   ). Fall back to reading bundled reference files directly only if both MCP and qmd CLI are unavailable.
4. Read dimension-claim-map.md for the specific claims that inform this dimension.
5. Propose new position or confirm original -- with explicit reasoning.

The re-derivation should answer for each dimension:

• What was the original position and why?
• What does operational evidence suggest?
• What does the research say about this specific friction?
• What is the new recommended position?
• If changed: what cascade effects does this create? (check interaction-constraints.md)

Vocabulary re-evaluation

Read

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

. Compare the current vocabulary mapping against how the user actually talks about their system (evidence from session logs, observations, user-facing text in notes). If the user has developed their own vocabulary that differs from the mapping, adopt the user's terms.

Personality re-evaluation

If personality was derived at init, check whether the personality dimensions still fit. Evidence sources: self/identity.md, agent notes in MOCs, session log tone. If personality was not derived at init, check whether operational evidence now warrants it.

---

PHASE 4: Check Coherence

Apply the full coherence validation from

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

:

Pass 1: Hard constraint check

For each hard constraint, evaluate the re-derived configuration. If violated, the re-derivation must be adjusted before proceeding.

Hard constraints:

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

  -- navigational vertigo

• automation == "full" + no_platform_support

  -- platform cannot support

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

  -- unsustainable

Pass 2: Soft constraint check

For each soft constraint, evaluate the configuration. Document active soft constraints and their compensating mechanisms.

Pass 3: Cascade verification

Trace each changed dimension through its cascade chain. Verify that downstream dimensions are either:

• Consistent with the new position, or
• Explicitly overridden with documented rationale

Pass 4: Three-space boundary check

Using

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

, verify the re-derived architecture maintains clean boundaries. Check for each of the six conflation patterns.

Pass 5: Kernel validation (15 primitives)

Using

${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md

, verify the re-derived system will pass all 15 kernel primitives.

---

PHASE 5: Present Delta

Show the user exactly what changed and what stays the same.

Output format:

=== RESEED ANALYSIS ===
System: [domain name]
Platform: [detected]
Note count: [N]

--- Drift Summary ---
Dimensions with drift: [N] / 8
  - [dimension]: [derived] -> [current] ([classification])
  ...

--- Re-Derivation Proposal ---

| Dimension | Current | Proposed | Change? | Rationale |
|-----------|---------|----------|---------|-----------|
| [dim]     | [val]   | [val]    | [yes/no]| [reason]  |
| ...       | ...     | ...      | ...     | ...       |

--- Impact Assessment ---

For each proposed change:

### [Dimension]: [current] -> [proposed]

**Component modifications:**
- [specific file/folder/template changes]

**Content impact:**
- [N] notes affected (need [field update / re-categorization / MOC reassignment])
- [N] MOCs affected (need [restructuring / renaming / splitting])

**Risk:** [low / medium / high] -- [explanation]

**Rollback:** [specific rollback steps if this change doesn't work]

--- Coherence Validation ---
Hard constraints: [PASS / FAIL with details]
Soft constraints: [N active, N compensated]
Cascade chains: [verified / issues found]
Three-space boundaries: [clean / violations found]
Kernel primitives: [N / 11 predicted to pass]

=== END ANALYSIS ===

If

--analysis-only

was specified: Stop here. Present the analysis and exit.

If not analysis-only: Ask the user: "Would you like me to proceed with the re-derivation? I'll preserve all your content and restructure the architecture."

---

PHASE 6: Implement on Approval

Execute in strict order. Each step depends on the previous completing successfully.

Step 1: Archive current derivation

cp ops/derivation.md ops/derivation-$(date +%Y-%m-%d).md

Step 2: Restructure folders

If folder names change (vocabulary evolution), rename with content preservation:

git mv old-folder/ new-folder/

Update all file references.

Step 3: Update templates

Modify

_schema

blocks, add/remove fields, update enum values. Templates are the single source of truth for schema.

Step 4: Update context file

Regenerate sections affected by dimension changes. Preserve user customizations documented in

ops/user-overrides.md

(if it exists). Apply vocabulary transformation throughout.

Step 5: Update skills

If skill vocabulary needs updating, modify skill files in

.claude/skills/

.

Step 6: Update hooks

If automation level changed, add or remove hooks. Update hook paths to match any renamed folders.

Step 7: Restructure MOCs

If navigation depth changed:

• Create new tier of MOCs (e.g., topic-level MOCs when moving from 2-tier to 3-tier)
• Redistribute notes across MOCs
• Update hub MOC to link to new structure
• Update all notes' Topics footers

Step 8: Update self/

PRESERVE self/memory/ entirely. Never modify or delete memory files.

Update:

• self/identity.md

  -- if personality changed

• self/methodology.md

  -- if processing or maintenance changed

• self/goals.md

  -- add "post-reseed orientation" as active thread

Step 9: Regenerate ops/derivation.md

Write a new derivation record with:

• All re-derived dimension positions and rationale
• Operational evidence that informed changes
• Research claims that supported each decision
• Previous derivation date and what changed
• Coherence validation results

Step 10: Log the reseed

Create a session log in

ops/sessions/

documenting the reseed: what changed, why, and what to watch for.

---

PHASE 7: Validate

Run the full validation suite on the re-derived system.

Kernel validation (15 primitives)

Run

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

if available, otherwise manually check each primitive:

1. markdown-yaml -- valid YAML frontmatter on all notes
2. wiki-links -- all wiki links resolve
3. moc-hierarchy -- MOC structure intact, all notes reachable
4. tree-injection -- session start loads file structure
5. description-field -- descriptions present and distinct from titles
6. topics-footer -- topics present on all non-MOC notes
7. schema-enforcement -- templates exist, validation mechanism present
8. semantic-search -- configured or documented for future
9. self-space -- self/ intact with core files
10. session-rhythm -- orient/work/persist documented
11. discovery-first -- notes optimized for findability

Coherence validation

• Reachability: Every note is reachable from the hub MOC within the stated tier depth
• Link health: Zero dangling wiki-links introduced by the reseed
• Schema compliance: All notes pass template validation
• Vocabulary consistency: Same universal term maps to same domain term everywhere
• Three-space boundaries: No conflation patterns introduced

Report results

=== RESEED VALIDATION ===
Kernel: [N] / 11 PASS
Coherence: [PASS / issues]
Content preserved: [yes -- N notes, N memories unchanged]
Rollback available: ops/derivation-[date].md

Post-reseed recommendations:
1. [First thing to check after a few sessions]
2. [Second monitoring item]
=== END VALIDATION ===

If any kernel primitive fails, fix it before completing the reseed. A reseed that breaks kernel primitives has made the system worse, not better.

---

Quality Standards

• Content preservation is non-negotiable. Every note, every memory, every piece of user-created content must survive the reseed. Verify counts before and after.
• Ground every dimension change in operational evidence, not theoretical preference
• Use domain vocabulary throughout -- the reseed should feel native to the user
• If the user's vocabulary has evolved since init, adopt their current language
• Acknowledge uncertainty: "This dimension change is speculative -- monitor for [specific friction]"
• Prefer reversible changes over irreversible ones
• Document everything in ops/derivation.md -- the next reseed needs this context