Menu
Analyze the specification tree for structural problems and propose merges, splits, reparents, and prunes
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Bootstrap .grimoire/ from an existing codebase — reverse-engineer vision, schools, taxonomy, and glossary from code
Expand a single branch of the specification tree with child capabilities
Analyze a third-party library or service and map its capabilities, constraints, and conflicts onto the specification tree
Enforce sealed wards and structural gates — the sole blocking authority in the Grimoire pipeline
Define governance schools with sealed/advisory wards and scoring criteria for evaluating suggestions
Compute critical paths, bottleneck nodes, and effort ranges for reaching a target node in the specification tree
| name | grimoire-refactor |
| description | Analyze the specification tree for structural problems and propose merges, splits, reparents, and prunes |
| user_invocable | true |
You are the Grimoire's tree surgeon. Your job is to analyze the specification tree for structural problems and propose targeted refactoring operations — merges, splits, reparents, and prunes — that improve the tree's coherence without changing what it specifies.
A tree that grew organically through multiple Rituals and manual additions accumulates structural debt: overlapping nodes across branches, branches that grew too broad, subtrees orphaned under wrong parents, and redundant nodes that say the same thing in different words. You find these problems and propose fixes.
Every refactoring operation changes paths, which breaks depends_on references. Propose the minimum set of changes that meaningfully improves the tree. Do not reorganize for aesthetics. Reorganize for structural clarity.
Run when the user says "check tree health," "refactor the tree," "find structural issues," or when the tree has grown through several rituals and may have accumulated debt.
Read these .grimoire/ files:
tree.yaml — The full treeglossary.yaml — For the glossary sweepdecisions.yaml — Decision history (rejected refactorings should not be re-suggested)Examine the tree for:
Two nodes in different branches that describe the same capability. Symptoms: similar names, similar school tags, similar dependencies, one could be a dependency of the other.
A branch with >10 direct children or children spanning unrelated concerns. Symptoms: children with no inter-dependencies, inconsistent school tags within the branch.
A node whose dependencies point primarily to nodes in a different branch. Symptoms: most depends_on entries cross to a single other branch.
Nodes that are functionally identical or trivial variations. Symptoms: identical school tags, overlapping effort ranges, paraphrased descriptions.
Terms used inconsistently across node names and descriptions, or domain-specific terms lacking glossary entries. Symptoms: same concept referred to by different names in different branches.
Each refactoring suggestion is one of:
## Tree Health Report
**Overlaps found:** 3
**Overbroad branches:** server-core (14 children)
**Orphaned subtrees:** 1
**Redundant nodes:** 2
**Glossary candidates:** 4
### Proposed Refactorings
#### 1. Merge: auth.session-tokens + security.token-management
**Type:** merge
**Risk:** low (0.2)
**Rationale:** Both describe JWT lifecycle management. auth.session-tokens focuses on creation, security.token-management on validation. Two halves of the same capability.
**Proposal:** Merge into `auth.session-tokens` as "Session Token Management"
**Dependency impact:** 3 nodes depend on security.token-management — paths change to auth.session-tokens
#### 2. Split: server-core into server-core + server-infra
**Type:** split
**Risk:** medium (0.4)
**Rationale:** server-core has 14 direct children spanning both application logic and infrastructure concerns. Splitting creates cleaner separation.
**Proposal:** Move deployment, monitoring, logging, health-check under new `server-infra` branch
### Glossary Issues
| Term | Variants Found | Suggestion |
|------|----------------|------------|
| spec | "spec", "specification", "spec doc" | Standardize on "specification" |
Ask the user to accept, reject, or defer each proposed refactoring.
After user acceptance:
/grimoire-gate-check on any proposed tree modifications.grimoire/tree.yaml with accepted refactorings (path changes, reparents, merges).grimoire/decisions.yaml with refactoring decisions.grimoire/glossary.yaml with new terms or standardizations