Re-derive your knowledge system from first principles when structural drift accumulates. Analyzes dimension incoherence, vocabulary mismatch, boundary dissolution, and template divergence. Preserves all content while restructuring architecture.
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/reseed
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Re-derive your knowledge system from first principles when structural drift accumulates. Analyzes dimension incoherence, vocabulary mismatch, boundary dissolution, and template divergence. Preserves all content while restructuring architecture.
📊 Stats
Stars3,451
Forks218
LanguageShell
LicenseMIT
📦 Ships with arscontexta
</> SKILL.md
reseed.SKILL.md
---name: reseed
description: Re-derive your knowledge system from first principles when structural drift accumulates. Analyzes dimension incoherence, vocabulary mismatch, boundary dissolution, and template divergence. Preserves all content while restructuring architecture.
context: fork
model: opus
allowed-tools: Read, Write, Edit, Grep, Glob, Bash, mcp__qmd__search, mcp__qmd__vector_search, mcp__qmd__deep_search, mcp__qmd__get, mcp__qmd__multi_get, AskUserQuestion
argument-hint: "[optional: --analysis-only to see drift report without implementing]"
---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
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?
| 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.
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.
**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.
If folder names change (vocabulary evolution), rename with content preservation:
```bash
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
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
