@erclx/canon 5.43.0 → 5.44.0

package/claude/skills/draft-and-pick/SKILL.md

@@ -1,161 +1,11 @@
 ---
 name: draft-and-pick
-description: Drafts several candidates for a decision judged by looking, lays them out side by side as frames on one canvas page, hands the operator the address, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write what to look at on a change already made, which is `ui-checklist`, or to script a recording, which is `draft-screencast`.
+description: Renamed from `draft-and-pick` to `pick-by-eye`. Answers a typed invocation of the old pick skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: decide
 ---
 
 # Draft and pick
 
-Some decisions are settled by looking rather than by reasoning, and no draft is wrong until one is picked. Every step here puts several candidates in front of the operator and keeps the real surface untouched until they have chosen.
-
-The candidates live on the local design canvas, the surface `canon:canvas-board` drives. Every verb below is `canon canvas`, and `${CLAUDE_SKILL_DIR}/../canvas-board/references/canvas.md` fixes the content format a frame takes. Read that reference before writing the first frame.
-
-## Guards
-
-- If the request names one answer and asks for it to be built, stop: `❌ This names one answer, so there is nothing to pick between. Use /canon:plan-feature.`
-- If the decision has no visible form, stop: `❌ Nothing to look at. Drafting candidates needs a decision a render can show.`
-- Draft no candidate for a decision the operator has not asked to make, since options everywhere spend their attention rather than saving it
-
-## Step 1: name the decision and the arms
-
-1. State the decision in one sentence, naming what changes between arms and what stays fixed.
-2. Emit the design read in the run's output, in the form `design-taste` fixes, taking the layer from its ordered catalog. The arms differ at that layer, and a missing read is visible.
-3. Derive a kebab slug from that sentence. The first round's page is `<slug>`, and Step 5 names later rounds `<slug>-2`, `<slug>-3`, and so on.
-4. Write one arm per candidate, each carrying an id, a label, and what the arm costs. An arm with no stated cost is not an option.
-5. Make the current state arm `0`, so the baseline is a candidate rather than an absence. A decision with nothing shipped yet says so and starts at arm `1`.
-6. Stop at three to five arms. Two is a comparison the operator can hold in prose, and past five the pick stops being a look and becomes a sort.
-
-Inside a live `plan-groundwork` track, renders land in the track's own `evidence/<slug>/renders/`, since a candidate render is evidence its decision file cites. Everywhere else they land in session scratch.
-
-## Step 2: draft the arms as frames on one canvas page
-
-Every arm of a round sits as one frame on one canvas page, side by side. The operator judges that page, never a set of separate images compared from memory.
-
-1. Start the canvas the way `canon:canvas-board` Step 1 states, unless this run already has. Note whether this run started the server, since Step 6 stops only a server this run started.
-2. Add the round's page with `canon canvas page add <page> --json` and record it on the run's list of pages. A name `canvas list` already shows is somebody else's, so take the next free suffix.
-3. Add each arm with `canon canvas frame add <page> arm-<id> --width <px> --height <px> --json`. Step 6's archive keys on the `arm-<id>` names.
-4. Write each arm's whole document to the `path` the add verb reported. From a linked worktree, take the heredoc route `canon:canvas-board` Step 3 gives for a main-root write.
-5. Lay the frames out in one row, in arm order, with `canon canvas frame move <page> arm-<id> --x <px> --y <px> --json`.
-
-The `canvas-board` start reads `canon canvas list --json`, serves with `canon canvas serve --json` in the background unless the operator named an address that answers, and checks the shell's body holds a `<script` tag. A refused serve or a blank shell stops the run with its `reason`, and no file stands in for a canvas.
-
-Set each frame's width to the one the arm is judged at. A frame renders at its own layout width on the canvas and in a capture alike, so a layout decision needs no device toolbar.
-
-### What every frame carries
-
-Each frame carries its own label and follows the canvas theme, so the set reads as one comparison.
-
-- Label each arm inside its frame with its id and its cost, since the composite capture draws no captions
-- Theme every arm off the `data-theme` attribute the canvas sets on each frame's root, so the theme toggle sets the whole set at once. A set spanning both themes cannot be compared.
-- Give no arm a script that stores a theme and reapplies it on load. It overwrites the toggle, and a fresh browser profile hides the fault.
-
-### Default path and live app
-
-A running app under decision takes the live-app branch, and every other decision takes the default path.
-
-- Live app: lift the rendered markup and link a copy of the built stylesheet rather than inlining, per `${CLAUDE_SKILL_DIR}/references/live-arms.md`
-- Default path: inline every style, script, and asset. A frame resolves nothing outside its own page folder, so a build step or network font silently drops out.
-- Default path: name a real font first in the stack, one the machine has or the frame embeds, such as the project's own family. A generic keyword such as `system-ui` resolves differently per machine.
-
-The capture refuses a frame that would rewrap against a substitute font rather than ship a false comparison. A frame naming no font is refused on whatever the default resolves to.
-
-### What varies
-
-Vary one property across the arms, since a pick cannot say which of three differences decided it.
-
-- Vary the property the decision is about. Holding composition fixed and varying color produces five skins of one design, and a palette cannot be picked ahead of the composition it serves.
-- Grey-box the arms when the declared layer sits below typography, per `design-taste`, and say the set is grey-boxed when handing it over
-- Do not grey-box a set judged at composition that carries a finished palette, since the operator looks at the higher layers instead of the question
-
-## Step 3: render and hand off
-
-Render the page and look at what came back before handing anything over:
-
-```bash
-canon canvas capture <page> --composite --json
-```
-
-- Point `--out` at `evidence/<slug>/renders/<page>.png` inside a live track, and leave the scratch default elsewhere. Step 6 archives the picked round alone.
-- Read the PNG's `path` off the record. The composite shows each frame in its default theme, so check the other theme on the live canvas.
-- A capture refusing on a font names the family it read. Take the repair `canon:canvas-board` Step 6 gives and capture again.
-
-When `canon canvas capture` refuses for a missing browser binary, report it and name `bunx playwright install chromium` as the repair. Stop the canvas server if this run started it, then stop rather than describe an arm nobody has seen.
-
-### Handing over
-
-Hand over the address rather than a description. Emit the canvas link first on its own line, naming the page, then the PNG path on its own line.
-
-- A still answers how a thing looks and none of a hover, a scroll-linked position, or a pace, which the live frame does
-- Never report a visual result you have not looked at, since a claim about appearance with no render behind it is a guess
-- Look to judge rather than to confirm. Name the weakest thing on the page in a sentence, fix it where that sentence would embarrass the work, and say what remains.
-
-## Step 4: take the pick
-
-Put the choice to the operator through the structured question surface, since a call the operator's preference decides always routes through it rather than through prose.
-
-- Emit the link ahead of the question call and again in the question's text, since some surfaces render the card alone
-- One option per arm, labeled with the arm's id and carrying its cost as the description
-- Rank the recommendation first and mark it `(Recommended)`
-- Author the real arms only. The surface appends its own free-text and reopen escapes, and a duplicate is rejected.
-
-### Taking the answer
-
-Take no pick on the operator's behalf when two arms are both defensible and the difference is taste. That call is theirs, and a silent one is the failure this skill exists to prevent.
-
-Read `canon canvas selection --json` when the answer points at the canvas, such as "the selected one". Resolve it against the record's `page` as well as its `frame`, since every round reuses the `arm-<id>` names.
-
-| Selection                                                        | Reading                                        |
-| ---------------------------------------------------------------- | ---------------------------------------------- |
-| A frame on the current round's page                              | The pick                                       |
-| A frame on an earlier round's page                               | A revert, so name the round back before acting |
-| A fresh element inside a picked frame                            | A correction Step 5 carries by its `index`     |
-| `selection: null`, a page this run did not add, or `stale: true` | No answer, so ask again rather than guess      |
-
-## Step 5: loop on the pick
-
-1. Add each iteration as its own page, recorded on the run's list. An overwritten page cannot be reopened, and the losing round stops a correction re-proposing a rejected arm.
-2. Write fresh arms off the pick and return to Step 2 where the correction opens a new question. Revise the one arm's frame where it does not.
-3. Re-render, hand off again, and take the next answer.
-4. Repeat until the operator says it is right. A run stopping because the arms stopped differing has stopped early.
-5. Hold the real surface untouched across every iteration. Nothing outside the run's own canvas pages changes until the pick is final.
-
-## Step 6: close
-
-1. Apply the winning arm to the real surface, in one change.
-2. Close out any document stating the decision as open, in the same change, naming the winner and the arms that stayed defensible. Skip this where nothing stated the decision.
-3. Capture the picked round's frames with `canon canvas capture <page> --out <archive-dir> --json`. Each lands as `arm-<id>.png`, keeping the losing arms as a revert record.
-4. Resolve `<archive-dir>` as `.canon/picks/<slug>/` against the main worktree root, since shared session scratch resolves there rather than in a linked worktree.
-5. Delete every page folder on the run's list from under the `content` folder `canon canvas list --json` reports. Touch no page the run did not add, whatever its name.
-6. Stop the canvas server if this run started it, and leave one the operator started running.
-7. Leave the renders in a live track's `evidence/<slug>/renders/`, since `plan-groundwork` treats evidence as durable.
-8. Report each page whose delete is refused, naming the path for the operator to remove. The pick is applied either way.
-9. Report every surface that changed, each on its own line, name the winning arm by its id and its cost, and report the archive path.
-
-The picked round is the final one unless Step 4 resolved a revert. Archiving any other page lets item 5 delete the winning arm with nothing kept, and a variant left on the canvas is a second design nobody maintains.
-
-## Reading a measurement
-
-A capture proves appearance and a measurement proves a relationship, so reach for the second whenever the claim is a number, such as a contrast ratio, a column width, or a tap target. `canon drive` runs the probes and ships the failure modes each one carries.
-
-- Composite alpha before reading a color. A `color-mix` toward transparent resolves to channels plus an alpha, and reading them as opaque reports a color nobody sees.
-- Sample inside the shape. A patch at a bounding box corner misses a round control and reads the page behind it.
-- Ask whether a reader would see the thing. A panel sized a healthy 1517 by 639 passed every size check while sitting 1868px above the viewport.
-
-`canon drive` reports findings and never gates. Read its record as evidence for the operator rather than as a filter over the arms, since the probe catalog has not earned the right to drop one.
-
-## What this delegates
-
-Cite these rather than restating them. A step reimplemented here rots against the skill that owns it.
-
-- `plan-feature` plans the work once the pick is made, and declares the pull request boundary that plan carries
-- `design-taste` carries the layer catalog, the ordering, grey-boxing, and the defaults an arm should reach past
-- `write-human` carries the voice for any copy an arm puts in front of a reader
-
-### Git and review
-
-Commits, review, and the canvas mechanics each have an owner.
-
-- `git-stage`, `git-pr`, and `git-followup` carry the commits and the pull request
-- `review-pr` and `review-address` run the review pass
-- `canon:canvas-board` carries the canvas start-and-check sequence, the main-root write route for a frame, and the selection and capture refusals
+This skill is now `pick-by-eye`. Run `/canon:pick-by-eye` instead, and change any file that still names this one.

package/claude/skills/draft-doc/REQUIREMENT.md

@@ -1,46 +1,25 @@
 ---
 name: draft-doc
-description: Why a brand-new project document needs its kind's standard, a catalog collision check, and a confirm step, not the rewrite and refresh paths docs-sync and context-fold already own
+description: Why a pointer answers under the old `draft-doc` name, and the test that retires it
 ---
 
-# Doc draft requirement
+# Draft doc requirement
 
 ## Gap
 
-Without this skill, a session drafting a document that has no prior version either invents a shape from memory or reaches for a rewrite or refresh surface. `docs-sync` and `context-fold` read an existing document and a diff, and a document that never existed has neither, so they report the request as unrelated to any change. Either way the document ships with no read of the standard its kind answers to and no check against the catalog for a sibling already covering the same ground under a different name.
-
-The same procedure ran as five skills, one per kind, each restating the read, the collision check, the confirm, and the write. They drifted on their own cadence, and five descriptions competed for one trigger, writing a new document.
+Without this skill, a person typing the old name after the rename to `write-doc` meets an unknown command with nothing naming where the skill went. A target that has not run `canon migrate skill-names` still holds files telling someone to type it, and a live gitignored record written before the rename still names it, since the sweep reads the tracked listing only.
 
 ## Must
 
-- Resolve the kind from the destination the request names, and ask rather than defaulting when it names none, since a document in the wrong surface is invisible where a reader looks for it
-- Load exactly one kind reference per run, so every step that differs by kind lives in one file and the shared procedure in one body
-- Read the kind's standard before drafting, since its frontmatter contract and its reader questions make the document arguable against a sibling
-- Check the catalog by exact name and by title and description, since a subject can be covered under a name the request does not guess
-- Confirm the resolved path, the kind's detections, and the full content with the user before writing, since placement and detection are judgment calls with no diff to preview them against
-- Regenerate the catalog of the folder the document landed in, where the kind keeps one, so the next run's collision check sees it
-- Draft a README from the template for every detected project type and combine them, never the closest one, since a project that is a CLI and a plugin owes its reader both
-- Carry each kind's own musts in its reference: the root check for context, both placement tests and a fetched source for the wiki, and project detection and rendered-value badges for the readme
+- Name `write-doc` as the skill to run, so a typed invocation of the old name reaches the new one in one step
+- Carry `disable-model-invocation: true`, so routing never matches the old description against a request the new skill owns
 
 ## Must not
 
-- Rewrite, refresh, or sync a document that already exists. A collision refuses toward the surface that owns the existing document.
-- Hand-edit an `index.md`. It regenerates from sibling frontmatter, and a hand edit is overwritten on the next regen.
-- Substitute recall for a failed fetch on the wiki kind, or invent an image or a placeholder path on the readme kind.
-- Build a hand-drawn diagram loop for a docs page.
-- Widen the wiki's folder split to admit a subject its second placement test rejects. That is a change to the standard, argued there.
-- Assume this skill's routing needs no check. One description now covers four triggers, and a ranking over descriptions is a proxy for how Claude Code routes, so a review some months in should read real invocations back.
-
-## Guards
-
-- No subject given, for any kind but the readme: stop and ask what the document should cover.
-- No destination named: ask which kind rather than defaulting to `docs/`.
-- Every other guard is the kind's own, stated in its reference.
+- Carry any part of the document draft, which would give one behavior two bodies that drift apart
+- Retire on a release number. Retire it when `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name, since a release number retires it on a date nothing measured.
 
 ## Out of scope
 
-- Rewriting or syncing an existing `docs/` page or an authored README against a diff: `docs-sync`
-- Refreshing an existing context entry: `context-fold`
-- Drafting a governance rule: `create-rule`
-- Drawing a figure or a diagram for a document: `draft-figure`
-- Voice, rhythm, punctuation, and formatting in the drafted document: the `write-human` skill and the markdown standard
+- The work itself, which `write-doc` owns
+- Rewriting a stale citation, which `canon migrate skill-names` owns in a tracked file and the controlling session owns on the board

package/claude/skills/draft-doc/SKILL.md

@@ -1,83 +1,11 @@
 ---
 name: draft-doc
-description: Drafts one brand-new project document from scratch against the standard for its kind, picking the kind from where it lands, a `docs/` page, a `canon/context/` entry, a wiki reference page, or a README.md. Checks the catalog for a name or topic collision, places it, confirms with the user, then writes. Use when asked to "write a new docs page for X", "write a context entry for X", "write a wiki page for X", or "write a README" where none exists yet. Do NOT use to rewrite or sync an existing page or README against a diff, which is `docs-sync`, or to refresh a context entry, which is `context-fold`.
+description: Renamed from `draft-doc` to `write-doc`. Answers a typed invocation of the old doc skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
-# Doc draft
+# Draft doc
 
-Drafts one brand-new project document end to end: resolve its kind, read the standard that kind answers to, check the catalog for a collision, place it, draft, confirm with the user, then write.
-
-## Resolve the kind
-
-Each kind has one standard and one reference. Load the reference for the resolved kind and no other, since every step below that differs by kind lives there.
-
-| Kind    | Lands at                                                 | Standard                                                    | Reference                                     |
-| ------- | -------------------------------------------------------- | ----------------------------------------------------------- | --------------------------------------------- |
-| docs    | a page under `docs/`                                     | `${CLAUDE_SKILL_DIR}/../docs-sync/references/docs.md`       | `${CLAUDE_SKILL_DIR}/references/docs.md`      |
-| context | an entry under `canon/context/`                          | `${CLAUDE_SKILL_DIR}/../context-fold/references/context.md` | `${CLAUDE_SKILL_DIR}/references/context.md`   |
-| wiki    | a reference page on a subject owned outside this project | `${CLAUDE_SKILL_DIR}/references/wiki.md`                    | `${CLAUDE_SKILL_DIR}/references/wiki-kind.md` |
-| readme  | a `README.md`, at the root or in a folder                | `${CLAUDE_SKILL_DIR}/../docs-sync/references/readme.md`     | `${CLAUDE_SKILL_DIR}/references/readme.md`    |
-
-- Read the kind off the destination the request names: a path, a folder, or the document's own name, such as "a context entry" or "a wiki page".
-- Ask which kind when the request names no destination, offering the candidates the subject fits with the likeliest first
-- Never default to `docs/` without saying so, since a subject documented in the wrong surface is invisible to the session that looks for it in the right one
-- If no subject is given for any kind but readme, stop: `❌ No subject given. Name what this document should cover.`
-- A README covers the project or the folder it sits in, so its subject is the target path
-
-## Read
-
-Read these in parallel, from the project root where a path is relative:
-
-- The kind's standard from the table above: the reader the document serves, its frontmatter, its structure, and what it links out to rather than restates
-- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: punctuation and formatting for all generated text
-- The `write-human` skill: voice, rhythm, and sentence construction for all generated text
-- The kind's reference from the table above
-
-## Guards
-
-Run the guards the reference states before placing or drafting anything. Each one stops toward the surface that owns the case, and a stop writes nothing.
-
-## Placement
-
-Settle the path and check the catalog for a collision the way the reference states. An exact-name check alone misses a document already covering the subject under another name, so check the titles and descriptions of the catalog the placement step already reads, and stop the same way on a match.
-
-## Draft
-
-- Draft against the kind's standard, keeping its template and its section order.
-- Draft frontmatter where the standard requires it, then the body, following the reference for what the kind adds.
-- Write for a reader with no source open. Omit an expected section with nothing to put in it rather than padding it.
-
-## Confirm
-
-- Show the kind, the resolved path, whatever else the reference names for the preview, and the full drafted content before writing.
-- Confirm with the user, and wait for that answer rather than treating the tool permission dialog as the gate
-- The kind, the placement, and every detection the reference runs are judgment calls with no diff to preview them against, which is why the dialog cannot stand in
-
-## Write
-
-- Write the file at the confirmed path, creating the folder when it is absent unless the reference narrows that.
-- Run `canon markdown audit <path>` and fix every ban, density, and reference shape finding until a re-run reports none. The whole file is this run's draft, so every finding is its own.
-- Run `canon indexes regen <folder>` on the folder the reference names, so its `index.md` picks up the new document. Skip it where the reference says the kind keeps no catalog.
-
-## Response format
-
-### Preview
-
-**Kind:** `<docs | context | wiki | readme>`
-**Subject:** `<subject, or the target path for a README>`
-**Placement:** `<path>`
-<one line per preview field the reference names>
-
-```markdown
-<drafted frontmatter and body>
-```
-
-### After confirmation
-
-One line once the file is written and its audit reports nothing.
-
-```plaintext
-✅ Drafted: <path>
-```
+This skill is now `write-doc`. Run `/canon:write-doc` instead, and change any file that still names this one.

package/claude/skills/draft-figure/REQUIREMENT.md

@@ -1,59 +1,25 @@
 ---
 name: draft-figure
-description: Why a figure decides between Mermaid, an architecture view, and freehand SVG before drawing, and why the Mermaid path carries a render-verification loop
+description: Why a pointer answers under the old `draft-figure` name, and the test that retires it
 ---
 
 # Draft figure requirement
 
 ## Gap
 
-Without this skill, a session asked for a figure reaches for whichever path it thought of first. A graph-shaped subject gets model-authored SVG coordinates nobody checked against a render, drifting from the hand-drawn look every other figure in the project carries. A subject that is not graph-shaped gets forced through Mermaid's node-and-edge model, producing a diagram that answers a different question than the one asked. Either failure ships a figure a reader cannot trust, and a figure exists only to be trusted at a glance.
-
-A teach lesson breaks the Mermaid path outright. The lesson letters its figures in a hand font the renderer cannot load, so the render sizes every label in a narrower fallback face and the lesson clips the text it actually shows. The check then reads the standalone image, rendered in that same fallback, and passes a figure the reader sees clipped. Both happened on one lesson, where every group title clipped mid-word and only a capture taken inside the lesson showed it.
-
-An architecture view asked for one at a time fails its own way. A session asked to refresh one view redraws every view beside it, so pictures nobody checked change in the same commit and the reviewer cannot tell which one the pass was about. It reaches for C4, state, or class diagrams that render differently in every viewer. A Mermaid source can satisfy every rule in the standard and still render as a picture asserting something false about the system, so a session that judges the source and calls it verified has spent the only signal a reader has on a picture nobody looked at.
-
-The color failure is the quiet one. Mermaid's own theme writes literal hex values, and a figure carrying one stops re-coloring itself the moment the host page switches its palette, which the figure standard's own accessibility bar rules out.
+Without this skill, a person typing the old name after the rename to `draw-figure` meets an unknown command with nothing naming where the skill went. A target that has not run `canon migrate skill-names` still holds files telling someone to type it, and a live gitignored record written before the rename still names it, since the sweep reads the tracked listing only.
 
 ## Must
 
-- Apply the standard's earn-its-place bar before drawing anything
-- Decide between the Mermaid path and the freehand path by whether the subject reduces to a graph, not by which is faster to produce
-- Draw an architecture view from its named source signal, inside `flowchart` and `sequenceDiagram`, and render it through the Mermaid path
-- Draw only the view the request names, leaving every other figure in the destination untouched
-- Draw a figure bound for a teach lesson freehand whatever its shape, since the lesson's hand font is one the renderer cannot measure
-- Verify a figure bound for a rendered page by capturing it inside that page, and fall back to the standalone render only where the destination has no page to load
-- Keep the scoped overflow style as the documented fallback for a clipped group title wherever the Mermaid path still runs
-- Render the Mermaid path with the hand-drawn look and the figure font stack, never with Mermaid's default look
-- Rewrite every literal color the renderer wrote into the custom property the host stylesheet defines
-- Read the Mermaid render back and judge it against what the figure means to say, rather than judging the source
-- Read the node labels by hand, since no hook checks inside a fence
-- Cite only code paths that exist in an architecture view's caption or prose
-- Wrap either path in a `<figure>` and `<figcaption>` and give it an accessible name
+- Name `draw-figure` as the skill to run, so a typed invocation of the old name reaches the new one in one step
+- Carry `disable-model-invocation: true`, so routing never matches the old description against a request the new skill owns
 
 ## Must not
 
-- Force a non-graph-shaped subject through Mermaid, or route a graph-shaped one through freehand SVG coordinates a model authored by hand outside a teach lesson
-- Report a figure bound for a rendered page as verified from the standalone render alone
-- Ship a literal hex color on either path
-- Report a clean verification when the Mermaid render was skipped or a defect survived
-- Loop past two correction passes on a surviving defect
-- Commit a scratch render. Only the SVG that ships in the destination document survives
-- Redraw a figure the request did not name, or report one as drawn when it was left alone
-- Leave an architecture view as an unrendered fence
-
-## Guards
-
-- No subject given: stop, since nothing states what the figure has to show
-- No destination document given: stop, since the figure has nowhere to land
-- Subject does not clear the earn-its-place bar: stop rather than drawing decoration
-- An architecture view with no planning file and no folder structure to scan: stop, because nothing anchors it
-- Render fails for any reason: continue to the output and name the skipped check. A missing renderer degrades the loop rather than failing it.
+- Carry any part of the figure draft, which would give one behavior two bodies that drift apart
+- Retire on a release number. Retire it when `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name, since a release number retires it on a date nothing measured.
 
 ## Out of scope
 
-- Mermaid's own layout, budgets, and label rules for the fence itself: the mermaid standard, cited rather than restated here
-- A UI screen mockup: `canvas-board`
-- Design tokens and the visual system: `canvas-board`, which carries a picked direction into the design document
-- Implementation detail behind an architecture view, which belongs in a context entry the caption points at
-- Which lesson needs a figure and where it sits among the lesson's blocks: `teach-workspace`, which calls this skill to draw one
+- The work itself, which `draw-figure` owns
+- Rewriting a stale citation, which `canon migrate skill-names` owns in a tracked file and the controlling session owns on the board

package/claude/skills/draft-figure/SKILL.md

@@ -1,85 +1,11 @@
 ---
 name: draft-figure
-description: Drafts one hand-drawn figure for a document, deciding whether the subject is Mermaid-shaped, an architecture view, or needs freehand SVG, then draws it. Renders the Mermaid path through Mermaid's own hand-drawn look, reads the render back, and fixes what it exposes. Wraps every path in the figure standard's caption, color, and accessibility rules. Use when asked to "draw a figure", "add a hand-drawn diagram", "draft a figure for this doc", "draw this relationship as a figure", "draw the architecture", "diagram the system", or "show the components". Do NOT use for a UI screen mockup, which is `canvas-board`.
+description: Renamed from `draft-figure` to `draw-figure`. Answers a typed invocation of the old figure skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
 # Draft figure
 
-Decide whether a requested figure reduces to a graph Mermaid can draw, is one of the architecture views, or needs freehand SVG, then draw it and verify what a reader will actually see.
-
-## Guards
-
-- If no subject is given, stop: `❌ No subject given. Name the relationship, boundary, path, or before-and-after this figure should show.`
-- If no destination document is given, stop: `❌ No destination given. Name the file this figure belongs in.`
-
-## Step 1: read sources
-
-Read these in parallel:
-
-- `${CLAUDE_SKILL_DIR}/references/figures.md`: when a figure earns its place, the render-first policy, wrapping and captioning, and the color and accessibility rules
-- `${CLAUDE_SKILL_DIR}/../markdown-craft/references/markdown.md`: formatting for the caption prose
-- The `write-human` skill: voice and rhythm for the caption prose
-
-## Step 2: does it earn its place
-
-Apply the standard's bar: a relationship, a boundary, a path, or a before-and-after that prose or a list cannot carry as well. Stop when it does not: `❌ <subject> reads fine as prose. A figure adds nothing here.`
-
-## Step 3: pick the path
-
-Take the first that matches, and state which path was picked and why in one sentence:
-
-1. **A teach lesson**, a page in a learning workspace's `lessons/` folder: the hand-drawn path, any shape. The renderer cannot load the lesson's hand font, so Mermaid labels measure narrow and clip.
-2. **An architecture view**, meaning the request names system context, components, request flow, data pipeline, or deployment: the architecture set, then the Mermaid path.
-3. **Graph-shaped**, meaning the relationship, boundary, or path is already what a flowchart or sequence diagram expresses: the Mermaid path.
-4. **Anything else**, a spatial or physical arrangement no flowchart reduces to: the hand-drawn path.
-
-The standard states this as a render-first policy rather than a ban on any tool-exported drawing, so outside a teach lesson a graph-shaped subject always routes through Mermaid even though that is itself an external renderer.
-
-## Step 4: draw
-
-Read the reference for the path Step 3 picked and follow it:
-
-- Architecture set: shape the view per `${CLAUDE_SKILL_DIR}/references/architecture-set.md`, then draw, render, and read back per `${CLAUDE_SKILL_DIR}/references/mermaid-path.md`
-- Mermaid path: read `${CLAUDE_SKILL_DIR}/references/mermaid-path.md`.
-- Hand-drawn path: read `${CLAUDE_SKILL_DIR}/references/hand-drawn.md`.
-
-## Step 5: wrap, caption, and verify
-
-- Wrap the drawing in a `<figure>` element with a `<figcaption>` naming what to take from the figure, never what it shows. Let it run wider than the surrounding prose column.
-- On the Mermaid path, run the read-back `mermaid-path.md` states before confirming.
-- On every path, confirm the figure still reads once every color and font it depends on is stripped to its fallback, per the standard's own working-figure bar.
-- On a rendered page, an HTML file a browser loads, the check that counts is the figure in the page, which Step 6 captures on either path. A markdown destination's whole check is the checks above.
-
-## Step 6: confirm and write
-
-Show the destination path, the decided path, and the full `<figure>` markup before writing. Confirm with the user, since the path decision and the render verdict are judgment calls with no diff to preview, then write the figure where the user named.
-
-When the destination is a rendered page, read the `## Capture in the page` section of `${CLAUDE_SKILL_DIR}/references/hand-drawn.md` and run it, on the Mermaid path as well as the hand-drawn one, within the same two correction passes the read-back allows.
-
-### Cleaning up
-
-Renders and captures under `.canon/tmp/figures/` are verification artifacts. Delete the scratch PNGs, the stamps beside them, and the JSON config once the checks confirm, since only the SVG ships, and keep the `.mmd` source a later refresh redraws from.
-
-## Output
-
-### Preview
-
-**Destination:** `<path>`
-**Render path:** `<mermaid | architecture | freehand>`, `<one-sentence reason>`
-
-```html
-<drafted figure markup></drafted>
-```
-
-### After confirmation
-
-Report the write in this shape.
-
-```plaintext
-✅ Drafted figure in <path>
-Render path: <mermaid | architecture | freehand>
-Verified <in page | as a standalone render>. <defect or skipped check, one line, omitted when clean>
-<Font not embedded: run `canon design css --figures` to ship Virgil and Excalifont. Omitted when the project already ran it.>
-```
+This skill is now `draw-figure`. Run `/canon:draw-figure` instead, and change any file that still names this one.

package/claude/skills/draft-identity/REQUIREMENT.md

@@ -1,40 +1,25 @@
 ---
 name: draft-identity
-description: Why the mark and the card are one pick rather than two, and where the size sequence and the write folder come from before either is drafted
+description: Why a pointer answers under the old `draft-identity` name, and the test that retires it
 ---
 
 # Draft identity requirement
 
 ## Gap
 
-Without this skill, a session asked for a logo and a social card either invents shapes with nothing behind them, or drafts the mark and the card as two separate decisions that can land on shapes that do not compose, which is the failure the task filing this skill measured by hand on every project it touched. A search across every shipped skill and standard found zero hits for `logo`, `og:image`, `og-image`, or Open Graph, so nothing in the catalog reached either output.
-
-A session building this without a shared loop restates `draft-and-pick`'s render, hand-off, pick, and loop mechanics from scratch, which drifts from the shipped one with nothing comparing the two copies. It also guesses at the icon size sequence and the output folder rather than reading what the project already declares, and it produces one raster per size through a separate render call per size, which multiplies capture invocations for no reason `canon capture` cannot already batch.
+Without this skill, a person typing the old name after the rename to `design-identity` meets an unknown command with nothing naming where the skill went. A target that has not run `canon migrate skill-names` still holds files telling someone to type it, and a live gitignored record written before the rename still names it, since the sweep reads the tracked listing only.
 
 ## Must
 
-- Detect the icon size sequence from the project's own HTML head or manifest before falling back to the stated default set
-- Detect the write folder from the project's own static-asset convention before falling back to the project root, and announce which one decided it
-- Draft every arm already composed inside the card frame, so one pick settles the mark's shape and its composition together
-- Follow `draft-and-pick`'s Steps 2 through 5 for the render, hand-off, pick, and loop, rather than restating them
-- Write the final mark as its own SVG source, not baked into a raster only
-- Render every final size and the card in one capture call, by sharing one selector class across pages, each declared at half its target dimension to land on the literal size once the render engine's fixed 2x scale factor is applied
+- Name `design-identity` as the skill to run, so a typed invocation of the old name reaches the new one in one step
+- Carry `disable-model-invocation: true`, so routing never matches the old description against a request the new skill owns
 
 ## Must not
 
-- Restate `draft-and-pick`'s render, hand-off, pick, or loop mechanics
-- Add a `## Logo` section to `claude/skills/canvas-board/references/design.md`'s fixed section set. `src/design/parse.ts` reads a fixed key set, and no outcome behind this skill asks for a schema change.
-- Modify `draft-and-pick`, `canon capture`, or `canon design render`. This skill composes all three and extending any of them is a separate change.
-- Assume this skill's own invocation frequency needs no check. Whether anything reaches for it beyond an operator typing its name has no answer at creation time, so a review pass some months in should read that back rather than take it on faith.
-
-## Guards
-
-- `canon` not on PATH: stop, since the render loop and the finalize step both need it
-- Fires on a direct request only. A run offering a logo to a project that never asked for one spends a render nobody wanted.
+- Carry any part of the logo and social card draft, which would give one behavior two bodies that drift apart
+- Retire on a release number. Retire it when `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name, since a release number retires it on a date nothing measured.
 
 ## Out of scope
 
-- Wiring the produced files into a project's own HTML head or manifest, which is a separate edit this skill leaves for the operator to make against their own markup
-- Recording the mark's construction rules in `claude/skills/canvas-board/references/design.md`, which the task's own constraint keeps out of the fixed section set
-- Mutating an existing logo file directly, which is a direct edit rather than a skill
-- Auditing an implemented UI against its tokens, which `ux-audit` owns
+- The work itself, which `design-identity` owns
+- Rewriting a stale citation, which `canon migrate skill-names` owns in a tracked file and the controlling session owns on the board