@erclx/canon 4.109.0 → 4.111.0

package/claude/skills/migration-claude-md/REQUIREMENT.md

@@ -1,40 +0,0 @@
----
-name: migration-claude-md
-description: Why a bloated CLAUDE.md is rebalanced by proposal rather than by edit, and what the seed baseline settles
----
-
-# Migration claude md requirement
-
-## Gap
-
-Without this skill, a session asked to slim `CLAUDE.md` deletes sections it judges stale and writes the rest into files it creates in the same pass, so a classification the user disagrees with is no longer one command to undo. The file is always-load context, so a wrong move costs every later session rather than one.
-
-Three more failures share a cause. The session has no baseline for what belongs in `CLAUDE.md`, so it reads toolkit-seeded always-load behavior as bloat and proposes moving it, and the next seed sync puts it back. A section carrying a rule and a narrative together gets sorted whole into one bucket, which loses half of it either way. And a target that already exists gets written over, since a proposal blind to the folder cannot tell a create from a collision.
-
-The skill also writes into `canon/context/`, a folder `migration-context` moves files into. A proposal drafted before those moves land cannot see the entries they create, so a move that should have resolved to an append reads as a create.
-
-## Must
-
-- Classify every `##` section against the three tiers in a fixed order, so the same section lands the same way twice
-- Treat a section matching the seed baseline as always-load by definition and propose no move for it
-- Read the existing rules and context folders before resolving a target, so an existing entry resolves to an append and a taken rule slot resolves to a conflict
-- Derive a rule's glob from the scope the section names rather than from the folder it describes
-- Propose and stop, leaving every file write and the `CLAUDE.md` edit to the user
-- Report the already-lean case as a pass rather than manufacturing moves to justify the run
-
-## Must not
-
-- Sort a section holding both a rule and a narrative into either bucket. Flag it for a manual split.
-- Create a rule file, create a context entry, or edit `CLAUDE.md`
-- Propose a move onto an existing rule path. Report it as a conflict and skip it.
-
-## Guards
-
-- No `CLAUDE.md` at the project root stops before any classification runs
-- Fewer than three `##` sections reports the file already lean, since a rebalance needs something to rebalance
-
-## Out of scope
-
-- Relocating `docs/` files, which `migration-context` proposes into this same `canon/context/` folder. Run that skill first when both apply, so Step 3 reads a folder its moves have already populated.
-- Scaffolding the rule files it proposes, which `create-rule` does with the numbering and frontmatter
-- Regenerating `canon/context/index.md`, which `canon indexes regen` does once the user has applied the moves

package/claude/skills/migration-claude-md/SKILL.md

@@ -1,79 +0,0 @@
----
-name: migration-claude-md
-description: Classifies each section of a target project's bloated `CLAUDE.md` into the three-tier context model and proposes moves to path-scoped rules or context entries, keeping only always-load behavior in `CLAUDE.md`. Use when asked to "slim CLAUDE.md", "migrate CLAUDE.md to rules", "rebalance CLAUDE.md", or when a project's `CLAUDE.md` has grown large. Do NOT move `docs/` files (that is `migration-context`) and do NOT auto-execute. Proposal only.
----
-
-# Claude md migrate
-
-Rebalance a large `CLAUDE.md` so only always-load behavior stays in it, path-scoped behavior becomes a rule, and domain narrative becomes a context entry. Every move is a proposal the user applies by hand.
-
-Run `migration-context` first when both apply. Its moves populate `canon/context/`, and Step 3 has to read the folder those moves left so an existing entry resolves to an append rather than blocking the move that should have created it.
-
-A project the surface move has not reached keeps its context folder under `.claude/` rather than `canon/`. Read and propose entries into whichever root already carries the folder, and propose `canon/` only when neither does, since a new `canon/` folder would hide every entry the old one holds.
-
-## Guards
-
-- If no `CLAUDE.md` exists at `pwd`, stop: `❌ No CLAUDE.md found at the project root.`
-- If `CLAUDE.md` has fewer than three `##` sections, stop: `✅ CLAUDE.md is already lean. Nothing to rebalance.`
-
-## Step 1: discover
-
-Run these in parallel from `pwd`:
-
-- Read `CLAUDE.md`
-- `ls .claude/rules/ 2>/dev/null`: existing rule subdirs and numbers for placement
-- `ls canon/context/ 2>/dev/null`: existing context entries for conflict checks
-- `canon claude seeds list --json 2>/dev/null`: the base seed set. Read the `CLAUDE.md` entry's `content` as the always-load baseline. Skip this input when `canon` is not installed.
-
-## Step 2: classify each section
-
-Split `CLAUDE.md` by `##` heading. Score each section against this order:
-
-1. **Always-load.** Stays in `CLAUDE.md`. Signals: cross-cutting behavior that applies every session, output and formatting rules, project-wide invariants, conventions with no file scope. A section that matches the seed baseline is always-load by definition. Keep it and propose no move.
-2. **Path-scoped.** Propose a rule. Signals: behavior that only applies when working in a folder (`frontend/`, `backend/`) or on a file type, framework-specific conventions, "when editing X do Y" phrasing. Derive the glob from the named scope.
-3. **Domain narrative.** Propose a context entry. Signals: prose describing how a system or domain is built, decisions, gotchas, structure. Not do-or-do-not rules.
-4. **Mixed.** Both rule and narrative in one section. Flag as "needs manual split". Do not propose a single target.
-
-## Step 3: resolve targets
-
-For each section proposed for a move:
-
-- Path-scoped: propose `.claude/rules/<subdir>/<n>-<slug>.md` with a `paths:` glob. Pick the subdir and a free number the way `create-rule` does. If `.claude/rules/<subdir>/` already holds a rule on the topic, mark as "conflict" and skip.
-- Domain narrative: propose `canon/context/<domain>.md`. If the entry already exists, flat or as a same-named `canon/context/<domain>/` folder, propose appending to the file that owns it rather than creating a duplicate flat entry beside a domain already split.
-
-## Step 4: output
-
-Print one grouped proposal block. Omit empty groups.
-
-```markdown
-## Keep in CLAUDE.md
-
-- `## <heading>` (<one-line reason: always-load behavior>)
-
-## Extract to a path-scoped rule
-
-- `## <heading>` → `.claude/rules/<subdir>/<n>-<slug>.md`, paths `<glob>` (<reason>)
-
-## Extract to a context entry
-
-- `## <heading>` → `canon/context/<domain>.md` (<reason>)
-- `## <heading>` → `canon/context/<domain>/<sub-area>.md`, appending to the domain's existing sibling file (<reason>)
-
-## Needs manual split
-
-- `## <heading>` (rule and narrative mixed)
-
-## Conflicts
-
-- `## <heading>` → `.claude/rules/<subdir>/<n>-<slug>.md` already exists. Skipping.
-
-## Reminder
-
-Scaffold each rule with create-rule, which carries the rule standard.
-Follow the context standard for each new context entry.
-Run canon indexes regen after adding context entries.
-```
-
-If every section classified as always-load, output: `✅ CLAUDE.md holds only always-load behavior. No moves proposed.`
-
-Do not edit `CLAUDE.md`, and do not create the rule or context files. The user reviews the proposal, then applies each move by hand.

package/claude/skills/migration-context/REQUIREMENT.md

@@ -1,36 +0,0 @@
----
-name: migration-context
-description: Scope boundary for the docs audience split and its ordering against the other two migrations
----
-
-# Migration context requirement
-
-## Gap
-
-Without this skill, a session judges a `docs/` file agent-facing, moves it, and rewrites the inbound links in the same pass, so a classification the user rejects is no longer one command to undo.
-
-Three more failures share a cause. The skill reads a folder two other surfaces also write, and a proposal blind to them destroys work.
-
-A seed-derived `development.md` moved out of `docs/` comes back on the next seed sync. A move onto an existing `canon/context/` filename overwrites the entry sitting there. A proposal drafted while `migration-claude-md` is proposing entries into the same folder cannot see those targets, and running the two in the wrong order turns a legitimate move into a skipped conflict.
-
-## Must
-
-- Classify by audience signal in the file rather than by its name or its folder position
-- Propose and stop. The `git mv` commands and the link fixes stay the user's to run.
-- Report every inbound reference to a moved path as a TODO line, leaving the reference itself untouched
-- Defer a seed-derived file to the seed sync path rather than proposing a move for it
-- Skip a move whose destination already exists and report it as a conflict
-
-## Must not
-
-- Sort a file carrying both audiences into either bucket. Flag it for a manual split, since a whole-file move and a silent split are both wrong.
-- Descend into `docs/` subfolders. List them for manual review and leave them alone.
-
-## Guards
-
-- A missing `docs/` directory, or one holding no top-level markdown, stops before any classification runs
-
-## Out of scope
-
-- Classifying `CLAUDE.md` sections, which `migration-claude-md` proposes into this same `canon/context/` folder. Run this skill first when both apply, so that skill's append-or-create check reads a folder the moves have already populated.
-- Regenerating `canon/context/index.md`, which `canon indexes regen` does once the user has applied the moves

package/claude/skills/migration-context/SKILL.md

@@ -1,97 +0,0 @@
----
-name: migration-context
-description: Classifies markdown files in a target project's `docs/` folder and proposes `git mv` commands to relocate agent-flavored content to `canon/context/`. Use when asked to "migrate docs to context", "move docs to context", "split docs", or to align an existing project with the three-tier context model. Do NOT auto-execute moves or rewrite inbound links. Proposal only.
----
-
-# Claude context migrate
-
-Run this skill before `migration-claude-md` when both apply. That skill proposes entries into the same `canon/context/` folder, and an entry landing there first makes the corresponding move here read as a conflict and get skipped, which loses the richer `docs/` file.
-
-A project the surface move has not reached keeps its context folder under `.claude/` rather than `canon/`. Read and propose moves into whichever root already carries the folder, and propose `canon/` only when neither does, since a new `canon/` folder would hide every entry the old one holds.
-
-## Guards
-
-- If no `docs/` directory exists at `pwd`, stop: `❌ No docs/ directory found.`
-- If `docs/` contains no `.md` files at the top level, stop: `❌ No markdown files in docs/.`
-- This skill operates on flat `docs/*.md` only. Subfolders under `docs/` are listed in the output as "manual review needed" and skipped.
-
-## Step 1: discover
-
-Run these in parallel from `pwd`:
-
-- `ls docs/*.md 2>/dev/null`: list flat markdown files
-- `ls docs/*/ 2>/dev/null`: detect subfolders for the manual-review note
-- `ls canon/context/ 2>/dev/null`: detect already-migrated content for conflict checks
-- `canon claude seeds list --json 2>/dev/null`: get the canonical seed list to identify seed-derived files
-
-Read each discovered `docs/*.md` file in parallel.
-
-## Step 2: classify
-
-For each file, score against this rule order:
-
-1. **Seed-derived.** Filename matches `development.md` or `ci.md` and content shape resembles the toolkit's base seed (frontmatter plus a Setup or Triggers section plus tables for scripts or checks). These belong to the seed-migration path. Do not propose a move here.
-2. **Agent-flavored.** Score the following signals. Classify as agent-flavored when two or more match:
-   - Dense file paths in code fences
-   - Sections titled "Anti-patterns", "Layer responsibilities", "Conventions", or "Commands"
-   - Tables of CLI commands
-   - Explicit "do not" rules
-3. **Human-only.** Default fallback when no agent signals match. Typical signals:
-   - Tutorial prose
-   - Sections titled "Welcome", "Getting started", "Contributing", or "Installation"
-   - Second-person narrative aimed at new contributors
-4. **Mixed.** Both agent and human signals present. Flag as "needs manual split". Do not propose a move.
-
-## Step 3: check conflicts and inbound links
-
-For every file proposed for a move:
-
-- If `canon/context/<filename>` already exists, or a same-named folder exists at `canon/context/` with `<filename>`'s `.md` extension dropped, mark as "conflict" and skip the move. A folder of the same name is still a collision, since the domain already lives there split into siblings.
-- Run `git grep -n "docs/<filename>"` (or grep equivalent) to list inbound references in `CLAUDE.md`, `README.md`, and other markdown. Report each as a TODO line. Do not rewrite.
-
-## Step 4: output
-
-Print one grouped proposal block. Omit empty groups.
-
-```markdown
-## Move to canon/context/
-
-- docs/<file>.md → canon/context/<file>.md (<one-line reason>)
-
-## Keep in docs/
-
-- docs/<file>.md (<one-line reason>)
-
-## Defer to seed-sync
-
-- docs/<file>.md (matches toolkit base seed)
-
-## Needs manual split
-
-- docs/<file>.md (mixed agent and human signals)
-
-## Conflicts
-
-- docs/<file>.md → canon/context/<file>.md already exists. Skipping.
-
-## Subfolders (manual review)
-
-- docs/<subfolder>/
-
-## Suggested git mv commands
-
-git mv docs/<file>.md canon/context/<file>.md
-
-## Inbound links to fix after moves
-
-- CLAUDE.md:42 references docs/<file>.md
-- README.md:17 references docs/<file>.md
-
-## Reminder
-
-Run canon indexes regen to update canon/context/index.md.
-```
-
-If every file classified as "Keep in docs/", output: `✅ All docs/ content is human-facing. No moves proposed.`
-
-Do not execute the `git mv` commands. Do not edit `CLAUDE.md` or `README.md`. The user runs the commands and fixes the links manually after reviewing.

package/claude/skills/migration-standards-drop/REQUIREMENT.md

@@ -1,55 +0,0 @@
----
-name: migration-standards-drop
-description: Why the standards-tree drop ships as an ordered proposal, what the two pre-delete reads catch, and why one citation form serves every surface inside a target
----
-
-# Migration standards drop requirement
-
-## Gap
-
-Without this skill, nothing names the tree. The sync engine registers governance alone and the unmigrated scan carries an empty root-layout set, both by decision rather than by omission, so a target holding 21 installed standards files reports clean and the drop runs off whoever remembers to look. The census that found the population walked one folder on one machine and moved the count from four to seven.
-
-The order is the second failure and it has two halves. A session that deletes before syncing lands the installed rules citing a path it removed, and one that sweeps before syncing repoints citations the sync then rewrites.
-
-The delete otherwise runs blind in two directions. Two of the five targets measured on 2026-08-28 carried a runtime reader, one a hook hand-parsing a standard for its banned-word set, and a hook whose input is gone audits nothing while reporting a clean run. In the other direction, nothing separates a file the project wrote from a toolkit copy by name, and the corpus had moved on from all 20 files at one target, so a content diff sorts every file as changed and a session reading that diff either keeps everything or loses the one file no corpus carries.
-
-The repoint form is the fourth. A session applying the citation rule it knows from a shipped skill writes `${CLAUDE_SKILL_DIR}/../../standards/<name>.md`, which from a project-local skill at `.claude/skills/<name>/` resolves back into the tree the same pass deleted, and reports the sweep finished.
-
-The last is the name map. `prose` split into `markdown.md` plus the `write-human` skill and resolves as no standard, so a mechanical one-to-one repoint produces a citation to nothing and every check on it passes.
-
-## Must
-
-- Detect from a read of `.claude/standards/` itself, since no report names the tree and a session waiting for one waits forever
-- Report the state a binary behind the published version puts the sync in, before naming a sync a stale binary would run
-- Split the tree against `canon standards list --json` three ways, separating an unchanged toolkit copy from a drifted one and from a name that resolves to no standard
-- Name every runtime reader ahead of any delete, splitting a reader from a citation by whether the file is markdown, and say when the search could not run
-- Give every citation inside a target one target form, `canon standards <name>`, and say why the plugin-root form fails there
-- Order the proposal sync, drop, sweep, and state that the sweep re-reads after the sync rather than before it
-- Report an unmatched name as the user's to place, naming the `prose` split as the recorded instance
-- Report the measured empty case as a pass, since the guard is what proves the read ran
-
-## Must not
-
-- Run the sync, delete or move a file under the tree, or rewrite a citation
-- Sort a drifted file as project-authored or as toolkit-owned on a content diff alone
-- Propose the plugin-root citation form for a surface inside a target
-- Relocate the install stamp. One visit per target is cheaper than two and a skill is not a visit, so the stamp rides with whatever else reaches the target.
-- Stay in the catalog on the author typing its name alone. Nothing can answer that before the skill has run, so read the census back once it has and retire it if the answer is nobody.
-
-## Guards
-
-- A directory with no `.claude/` stops, since nothing there installed a tree
-- A `.claude/standards/` holding no markdown is the pass rather than a refusal
-- No `canon` on `PATH` stops, since every citation this move writes names a verb the target has to run
-
-## Out of scope
-
-- Classifying `CLAUDE.md` sections into the three-tier model: `migration-claude-md`
-- Relocating `docs/` files by audience: `migration-context`
-- Splitting a retired `.claude/` file into the folder that replaced it, which pairs one file against one folder rather than dropping a corpus: `migration-superseded`
-- Reconciling a seed file against its source section by section: `seed-sync`
-- Applying the drop and the sweep, which the user does after reviewing
-
-## Why it ships while its consumer row is parked
-
-The one task performing this move is parked on the operator declining outside-repository work, so the skill arrives with three known consumers and no live instance. It ships anyway, because the parked row is about who is authorized to visit a target rather than about the move being wrong, and the skill is what makes the move repeatable by whoever is authorized. The evidence behind it comes from the census rather than from a run, which is the weaker of the two and is recorded here as such.

package/claude/skills/migration-standards-drop/SKILL.md

@@ -1,113 +0,0 @@
----
-name: migration-standards-drop
-description: Proposes the ordered drop of an installed `.claude/standards/` tree and the repoint of every citation at `canon standards <name>`, separating a toolkit copy from a file the project wrote and naming any runtime reader before a delete is proposed. Use when asked to "drop the standards tree", "repoint the standards citations", "my project still has .claude/standards/", or when a toolkit update leaves an installed standards copy no command refreshes. Do NOT delete the tree, run the sync, or rewrite a citation. Proposal only.
----
-
-# Migration standards drop
-
-## Guards
-
-- If `.claude/` does not exist at `pwd`, stop: `❌ No .claude/ directory. Nothing here installed a standards tree.`
-- If `.claude/standards/` holds no markdown, that is the pass: `✅ No installed standards tree. Nothing to drop.`
-- If `canon` is not on `PATH`, stop: `❌ canon is not on PATH. Every citation this move writes names a verb the target has to run.`
-
-Detection is the directory read above and nothing else. No report names this tree, since the sync engine registers governance alone and the unmigrated scan covers a root layout an older toolkit wrote rather than a copy under `.claude/`. A session waiting for a command to raise the tree waits forever.
-
-## Step 1: read the version the sync would run from
-
-Run `canon sync --check . --json` and read its `skew` object. The sync in Step 5 installs the rules the running binary carries, so a binary predating the citation change installs rules naming the path this move removes, and the sweep then has more to fix than it started with.
-
-- `state` is `behind`: stop. `❌ The canon on PATH is <installed> against <latest> published. A gov sync from it installs rules citing the standards path. Update, then re-run.`
-- `state` is `unknown`: report the reason and continue. A version that could not be read is unread rather than stale.
-- `state` is `current`: continue.
-
-## Step 2: split the tree three ways
-
-Run `canon standards list --json`. Each entry carries `name` and `content`, so the comparison needs no second read. Match every `.claude/standards/<stem>.md` against `name`:
-
-- **Matched, content identical.** A toolkit copy the corpus still carries unchanged. The drop loses nothing.
-- **Matched, content differs.** A toolkit copy that has drifted, and the diff cannot say which side moved. Report it as a read the user owes rather than sorting it either way. All 20 files measured at one target on 2026-08-28 read as changed, because the corpus had moved on since the install, and none of them was project-authored.
-- **Unmatched.** No standard resolves under that name. Either the project wrote the file or the toolkit retired the name, and the catalog cannot separate the two.
-
-Report a project-authored file as one this move keeps. Its destination is `standards/<name>.md` at the project root, which `canon standards <name>` resolves ahead of the package corpus, so the citation form Step 4 gives every other file serves it too.
-
-`prose` is the recorded retirement. It split into `markdown.md` plus the `write-human` skill and resolves as no standard at all, so a citation repointed one-to-one from it names nothing. Report an unmatched name as the user's to place and name that split as the instance.
-
-## Step 3: name every runtime reader before naming a delete
-
-Run both from the project root, in parallel:
-
-- `git grep -ln 'claude/standards' -- '*.md'`: the citations Step 4 repoints
-- `git grep -ln 'claude/standards' -- . ':!*.md'`: the readers
-
-The extension is the split. Markdown cites the tree and a session reads the citation. A hook, a script, or a config opens a file under it at run time, and dropping the tree under one leaves a check whose input is gone reporting success. Two of the five targets in the 2026-08-28 census carried a reader, one of them a hook hand-parsing a standard for a banned-word set.
-
-Report each reader with what replaces it. A reader parsing a standard for a list the CLI now ships reads that list through the verb instead, which is `canon markdown audit <file> --json` for the banned-word case.
-
-When `pwd` is not a git work tree, say the reader search did not run rather than reporting no reader.
-
-## Step 4: give every citation one target
-
-Every citation repoints to `canon standards <name>`, whatever surface it sits on. One form rather than a choice per surface, which is the part a session gets wrong:
-
-- A rule under `.claude/rules/` is markdown a glob match loads, so `${CLAUDE_SKILL_DIR}` expands to nothing there
-- A project-local skill under `.claude/skills/<name>/` expands that variable to its own folder, so `${CLAUDE_SKILL_DIR}/../../standards/` resolves back into the tree being dropped
-- `CLAUDE.md` and a context entry expand no variable at all
-
-The plugin-root form belongs to a skill the toolkit ships beside its own corpus. Proposing it inside a target writes a path that resolves to the deleted tree.
-
-A citation naming a name Step 2 left unmatched carries no target. Report it under what the user supplies.
-
-## Step 5: output the ordered proposal
-
-The order is fixed and the reverse is the failure. Deleting before the sync lands the installed rules citing a path that is gone, and sweeping before the sync repoints citations the sync then rewrites. The sweep re-reads after the sync for that reason, since the sync fixes the rules it installed and leaves a project's own rules and prose alone.
-
-Take the drop command from whether the tree is tracked, read with `git ls-files .claude/standards`. A tracked tree goes out through `git rm -r` so the index moves with the files, and an untracked one through `rm -rf`. A tree holding both needs both commands, since `git rm -r` takes the tracked files, exits zero, and leaves every untracked one where it was.
-
-Print the blocks below, omitting any that is empty.
-
-````markdown
-## Drop
-
-`.claude/standards/` holds <n> files: <n> unchanged toolkit copies, <n> drifted, <n> matching no standard.
-
-## Read before dropping
-
-- `.claude/standards/<name>.md` drifted from the corpus copy. Confirm the project did not edit it.
-
-## Keep
-
-- `.claude/standards/<name>.md` matches no standard. Move it to `standards/<name>.md` at the project root, which `canon standards <name>` resolves first.
-
-## Runtime readers
-
-- `.claude/hooks/<file>.sh` parses a standard at run time. Route it through `canon markdown audit <file> --json` before the drop, or it reports a clean run having read nothing.
-
-## Citations to repoint
-
-- `CLAUDE.md:42` → `canon standards markdown`
-- `.claude/rules/canon/core/<n>-<slug>.md:8` → `canon standards skill`
-
-## You supply
-
-- The destination for the `prose` citations. It split into `markdown.md` plus the `write-human` skill, so no single name replaces it.
-
-## Run in this order
-
-```bash
-canon gov sync
-git rm -r .claude/standards
-```
-
-Then re-read the citations and repoint what the sync left.
-
-## Confirm
-
-Run `canon standards <name>` from inside this project for every name the repointed citations carry, and confirm each resolves.
-
-## Reminder
-
-Nothing above was written or run. The tree holds files a delete cannot recover, so the drop and the sweep are yours to apply.
-````
-
-Run nothing and write nothing: not the sync, not a delete or a move under `.claude/standards/`, not a citation rewrite. The install stamp is out of scope too, and travels with whatever else reaches this target. The user applies the move after reviewing it.

package/claude/skills/migration-superseded/REQUIREMENT.md

@@ -1,44 +0,0 @@
----
-name: migration-superseded
-description: Why a retired file's split ships as a proposal read from the destination standard, and why detection stops rather than falling back to a listing
----
-
-# Migration superseded requirement
-
-## Gap
-
-Without this skill, a target holding a retired `.claude/` file is told what replaced it and nothing else. The drift report names both halves and no command touches either, so the user hand-splits one file into a folder answering to a standard they have not read. The destination files land with frontmatter fields missing and filenames that sort out of order, which is the step the toolkit exists to remove.
-
-A second failure comes from the ordering nobody gets right unaided. A retired file committed before its ignore entry was written is tracked and ignored at once, and removing the entry first leaves the file tracked with nothing naming it. No report catches that state, so the mistake is discovered by whoever next wonders why a gitignored path keeps appearing in diffs.
-
-Two more follow from where a session looks when the report is thin. An uppercase stem under `.claude/` is not the test for a superseded file, so a session substituting a folder listing reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, and `DESIGN.md`, each a single file the layout intends to stay one, and proposes shredding three documents. A session falling back to the plugin's own copy of the destination standard proposes a shape the project never adopted, against content only the user can place.
-
-The last is the two-speed release skew arriving as a confident wrong answer. `superseded` reached a release in `0.46.0`, and an older CLI exits zero with a well-formed report that never mentions the field. A session reading that absent key as an empty array reports a clean layout to exactly the population holding the retired files.
-
-## Must
-
-- Take detection from the report's `superseded` array alone, and stop when the key is absent rather than treating it as empty
-- Resolve the governing standard by matching the replacement folder against the `appliesTo` the standards catalog declares, so a seed folder added later resolves without an edit to the body
-- Read the destination shape with `canon standards <name>`, report the root it answered from, and propose nothing for a folder the catalog names no standard for
-- Separate a folder no standard governs from one whose governing standard could not be read, since the catalog derives `appliesTo` from prose and answers an unparsed scope statement with an empty array
-- Name the untrack command ahead of the ignore entry whenever a retired file is both tracked and ignored, and say when the check could not run
-- Report what the destination standard leaves open, such as a phase label the retired file never recorded, rather than supplying a value for it
-- Report the measured empty case as a pass, since the guard is what proves the section ran
-
-## Must not
-
-- Write, move, or delete the retired file or its replacement, or create the destination folder
-- Run `git rm --cached` or edit the file carrying the ignore entry
-- Substitute a folder listing for the `superseded` array
-- Read the plugin's own copy of the destination standard when the target lacks that file
-
-## Guards
-
-- A directory with no `.claude/` stops, since nothing there was superseded and the report's sections would not be measured
-
-## Out of scope
-
-- Classifying `CLAUDE.md` sections into the three-tier model: `migration-claude-md`
-- Relocating `docs/` files by audience: `migration-context`
-- Reconciling a seed file against its source section by section, which diffs two files rather than splitting one into a folder: `seed-sync`
-- Applying the split and running the untrack, which the user does after reviewing

package/claude/skills/migration-superseded/SKILL.md

@@ -1,115 +0,0 @@
----
-name: migration-superseded
-description: Proposes how to split a retired `.claude/` file into the folder that replaced it, reading the destination shape from the standard that folder answers to. Use when asked to "split TASKS.md", "my .claude/DIAGRAMS.md was replaced by a folder", "migrate the superseded file", or after a drift report names a superseded artifact. Do NOT write to the retired file or to its replacement, and do NOT run the untrack command. Proposal only.
----
-
-# Migration superseded
-
-## Guards
-
-- If `.claude/` does not exist at `pwd`, stop: `❌ No .claude/ directory. Nothing here was superseded.`
-
-The guard is also what makes the report's `superseded` section measured. Every section is gated on the target being toolkit-managed, and a `.claude/` directory satisfies that gate, so the empty case below is a measured empty rather than a section that never ran.
-
-## Step 1: read the report
-
-Run `canon sync --check . --json` from the project root. Its `superseded` array is the detection. Each entry carries `rel`, the retired file, and `replacedBy`, the folder that took its job.
-
-An empty array is the pass: `✅ No superseded artifact. Every .claude/ file the seeds replaced is already a folder.`
-
-### When the report is unavailable
-
-Stop on any of three conditions, naming which one fired:
-
-- `canon` is not on `PATH`: `❌ canon is not on PATH. The superseded section is the only detection this skill has.`
-- The command exits non-zero: `❌ canon sync --check failed. Fix the report before proposing a split.`
-- The report parses and carries no `superseded` key at all: `❌ This canon predates the superseded field, which reached a release in 0.46.0. Upgrade, then re-run.`
-
-Test for the key rather than for emptiness. A current CLI reporting `"superseded": []` has looked and found nothing, which is the pass above, and reading an absent key as an empty answer reports a clean layout to the projects this skill exists for.
-
-No listing substitutes for the field. The pairing runs against the seed folder names the toolkit ships, and an uppercase stem is not the test, so a listing of `.claude/*.md` also reaches `ARCHITECTURE.md`, `REQUIREMENTS.md`, and `DESIGN.md`. Each of those is a single file the layout intends to stay one. A fallback that proposed splitting them would shred three documents to avoid reporting a stale CLI, which is why this skill stops where its siblings degrade.
-
-## Step 2: resolve the destination standard
-
-### Match the folder against the catalog
-
-Run `canon standards list --json` and match each entry's `replacedBy` against the `appliesTo` array the catalog declares. Resolve from the catalog rather than from the folder stem, so a seed folder the toolkit adds later resolves without an edit here.
-
-Compare on the folder rather than on the exact string. An `appliesTo` value matches when it equals `replacedBy` or begins with `replacedBy` followed by a slash. The report spells the folder `.canon/tasks` and the catalog spells it `.canon/tasks/`, and `memory` declares a filename pattern beneath its folder rather than the folder itself, so string equality matches nothing the catalog actually carries and sends every entry to a decline below.
-
-### Read the standard through the verb
-
-A match resolves to that standard's `name`. Read it with `canon standards <name>`, which writes the document to stdout and the root it answered from to stderr.
-
-The verb is the one route. It resolves `standards/<name>.md` at the project root first, which is where a project that authors standards of its own keeps them, and falls back to the corpus inside the canon package. No toolkit standard installs into a project, so there is no third path to test and no case where the shape is unreachable while the catalog names it.
-
-Report the root the frame named beside the proposal. A shape read from the project's own `standards/` is the project's stated agreement, and one read from the package is the toolkit's default, which is a difference the user weighs rather than a reason to refuse.
-
-### The states that end an entry
-
-Four states end an entry with no proposal. Name whichever one fired rather than collapsing them, because two of them are unmeasured and two are answers:
-
-- The catalog carries no `appliesTo` key: `⚠️ This canon emits no appliesTo, so which standard governs <replacedBy> is unread.`
-- No value covers `replacedBy` and some entry carries an empty `appliesTo`: an empty array is a scope statement that did not parse, so a no-match verdict is unread rather than negative. Name the standards that did not parse.
-- No value covers `replacedBy` and every array is populated: `⚠️ The toolkit ships no standard for <replacedBy>. Nothing states the destination shape.` No command fixes it, so name none.
-- The standard resolved in the catalog and `canon standards <name>` exits non-zero: name the standard and the exit, since the catalog and the read disagree and only one of them can be right.
-
-## Step 3: read the shape and map the file onto it
-
-Read the resolved standard and take four things from it: the filename convention, the required frontmatter, the required sections, and anything the folder holds that is not an item, such as a generated `index.md` no proposal may claim.
-
-Then read the retired file and split it at the boundary the standard implies, one destination file per item. Propose a filename per item from the convention, and name the frontmatter and sections each destination file owes.
-
-Report what the standard leaves open rather than inventing a value for it. A convention carrying a field the retired file never recorded, such as a phase label or a verified SHA, is the user's to supply, and a proposal that fills one in reads as a decision the split already made.
-
-## Step 4: check the ignore ordering
-
-Run both against each `rel`, in parallel:
-
-- `git ls-files --error-unmatch <rel> 2>/dev/null`: whether the file is tracked
-- `git check-ignore -v --no-index <rel> 2>/dev/null`: whether it is ignored, and which file and line names it
-
-`--no-index` is what makes the second read answer the question. `git check-ignore` consults the index by default and reports a tracked path as not ignored, so the flagless form returns nothing in exactly the tracked-while-ignored state this step exists to find, and the run reads a clean result off the one case that is not clean.
-
-A file that is both tracked and ignored carries an ignore entry added after the commit. Take it out of the index first, then remove the entry `check-ignore` named:
-
-```bash
-git rm --cached <rel>
-```
-
-Reversing the two leaves the file tracked with nothing naming it, and no report catches that state. Name both steps in that order and run neither. `git rm --cached` writes the index, which is a change to the project's own history even though no content moves.
-
-When `pwd` is not a git work tree, say the tracked check did not run rather than reporting the ordering as clear.
-
-## Step 5: output
-
-Print one block per superseded entry, then the shared reminder. Omit empty groups.
-
-```markdown
-## Split
-
-`.claude/TASKS.md` → `.canon/tasks/`, shaped by `canon standards tasks`
-
-## Proposed files
-
-- `.canon/tasks/vXX.Y-<slug>.md` ← the "<heading>" section
-- `.canon/tasks/vXX.Y-<slug>.md` ← the "<heading>" section
-
-Each carries `title` and `description` frontmatter, an `## Outcomes` heading, and a `## Findings` heading.
-
-## You supply
-
-- The phase label on each filename. The retired file records no version.
-
-## Untrack before editing the ignore entry
-
-git rm --cached .claude/TASKS.md
-
-Then remove the `.claude/TASKS.md` line from `.gitignore:12`.
-
-## Reminder
-
-Nothing above was written or run. The retired file holds content the project authored, so the split is yours to apply and the destination folder shape is what this proposal supplies.
-```
-
-Do not create the destination folder. Do not write, move, or delete the retired file. Do not run `git rm --cached`. The user applies the split after reviewing it.