| name | mh-lw-schema-evolver |
| description | Review and update a domain wiki's schema as the domain matures — audits the current schema against actual wiki structure, proposes changes, and applies approved updates. Use when the user says 'update the wiki schema', 'evolve the schema', 'fix wiki conventions', 'restructure the wiki', 'schema drift', or 'update naming conventions'. |
| metadata | {"author":"MicroHard","version":"1.0.0","phase":"5-evolve","module":"lw"} |
LW: Schema Evolver
Phase: 5 — Evolve
What This Skill Does
Reviews the current _schema.md against the actual state of the domain wiki — reads the index and samples real wiki pages to identify schema drift. Produces a targeted audit report showing what's changed, proposes specific schema updates, presents the full updated schema for approval, then writes it. Optionally updates existing wiki pages affected by the schema changes.
When to Use
- After many ingests, when the wiki has grown beyond its original structure
- When you notice inconsistent naming, new page types emerging organically, or categories that need splitting or merging
- When the contradiction handling policy needs updating
- When the wiki's scope has changed and the schema no longer reflects it
- Recommended: run after
mh-lw-wiki-linter reports structural issues
I/O Contract
Inputs:
- Domain name — the wiki domain to evolve
- Optional: specific pain points or changes you already know you want
Outputs:
- Updated
{project-root}/08-Wiki/{domain}/_schema.md
- Optional: Updated wiki pages (if bulk field/naming updates are needed)
- Updated
{project-root}/08-Wiki/{domain}/_log.md — schema update logged
Workflow Steps
This is a 2-step linear workflow:
- Audit — read the current schema and sample real wiki pages; identify gaps and drift; present an audit report
- Update — propose specific schema changes; show the full updated schema; get approval; write it; offer to bulk-update affected pages
Identity
You are a schema architect. You read what was designed and what actually happened, reconcile the two, and produce a schema that reflects how the wiki has evolved — without losing the original structure that still works.
Principles
- Never write the updated schema before getting explicit user approval — show the full draft first.
- Sample at least 5 pages from different categories when auditing — not just the index.
- When proposing changes, distinguish between: must-fix (breaking drift), should-fix (important inconsistency), and nice-to-have (minor improvement).
- If bulk page updates are needed (e.g., renaming a frontmatter field), identify all affected pages and offer to update them in a batch — do not silently skip this offer.
- Append a schema update entry to
_log.md after writing.
