@erclx/canon 5.42.0 → 5.44.0

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

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

@@ -1,138 +1,11 @@
 ---
 name: draft-identity
-description: Drafts a project's logo mark through draft-and-pick's render-and-pick loop, then composes the picked mark into an icon sequence and a 1200x630 social card. Use when asked to "make a logo", "design a logo mark", "create a favicon", "build the icon set", "generate a social card", "make an og:image", or "draft the logo and social card together". Do NOT use to mutate an existing logo file directly, which is a plain edit, or to record the mark's construction rules in DESIGN.md, which is out of scope.
+description: Renamed from `draft-identity` to `design-identity`. Answers a typed invocation of the old identity skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
 # Draft identity
 
-One identity rendered twice: the same mark sized down to an icon sequence and composed with type into the social card sized up. Drafting both from one pick keeps the mark and its card composition from settling on shapes that do not match.
-
-## Guards
-
-- If `canon` is not on PATH, stop: `❌ canon CLI not found.`
-- Draft no candidate for a mark the operator has not asked to make. This skill fires on a direct request, never on the model's own read that a project could use one.
-
-## Step 1: read signal
-
-Read these in parallel, skipping any that do not exist:
-
-- `canon/DESIGN.md`: the `## Overview` paragraph and the role intents under `## Colors` and `## Typography`, read as `## Personality` and `## Color` in an older record
-- The stylesheet `canon/DESIGN.md`'s lead names: the color and type values behind those roles
-- `canon/REQUIREMENTS.md`: the `## Personality` paragraph, when `canon/DESIGN.md` carries none
-- `CLAUDE.md`: the project's stated voice, when neither file above carries a personality signal
-
-No signal from any of these is not a stop. Draft against a neutral default, and mark each guessed color and type value with a `/* ? verify */` comment beside its declaration in the `.mark` and `.card` markup, since the design document carries no value to tag.
-
-## Step 2: detect the icon size sequence
-
-Check the project's HTML entry points (`index.html`, `public/index.html`, `src/index.html`) for a `<link rel="icon">` or `<link rel="apple-touch-icon">` tag carrying a `sizes` attribute, and any `manifest.json` or `site.webmanifest` for an `icons` array. Take the union of every size found.
-
-Fall back to the stated default when nothing is detected, since no `tooling/` stack scaffolds a `public/` folder, a favicon reference, or an `og:image` meta tag:
-
-- `16x16`, `32x32`, `48x48`
-- `180x180`
-- `192x192`, `512x512`
-
-This default set is raster-only, and Step 6 writes the vector source at `favicon.svg` on either branch. Announce which of the two decided the sequence.
-
-## Step 3: detect the write folder
-
-A root-only check misses a site kept in a subfolder, and a Next project keeps its favicon under the App Router with no `public/` at all. Both would fall through to the root while the announcement reads as detected, so walk one level down and know that convention.
-
-Read both, from the project root:
-
-```bash
-find . -maxdepth 3 \( -name node_modules -o -name .git -o -name dist -o -name .astro \) -prune -o -type d \( -name public -o -name static \) -print | sort
-find . -maxdepth 4 \( -name node_modules -o -name .git \) -prune -o -type d -path '*/src/app' -print | sort
-```
-
-Take the first tier that answers:
-
-1. A root `public/` or `static/`.
-2. A `public/` or `static/` one level down, such as `web/public/`. Of several, take the shallowest, then the one whose parent holds the project's framework config.
-3. A `src/app/` folder, at the root or one level down, which is the Next App Router convention. Take the folder itself, not a `public/` beside it.
-4. A stack-declared asset folder, where the project's own config names one.
-5. The project root, which is the fallback rather than a detection.
-
-Announce which tier decided, naming the tier rather than the path alone, so the operator can move the files where the project's convention differs. On tier 5 say the detection found nothing and the root is a fallback.
-
-## Step 4: name the decision and the arms
-
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Step 1, with the decision fixed rather than derived: "the project's logo mark and its composition into the social card." Vary the mark's shape or style across arms, keeping the card's type and layout fixed, per that skill's one-property rule.
-
-- Draft each arm inside the full 1200x630 card frame, mark and type together, and add its canvas frame at `--width 1200 --height 630`, so one pick settles shape and composition
-- Arm 0 is the current mark when the Step 3 folder already holds a logo file (`favicon.svg`, `favicon.ico`, `logo.svg`, or similar). Arms start at 1 otherwise.
-- Structure every arm as a `.mark` element, the inline SVG alone, nested inside a `.card` element, the full composition, so Step 6 can address either
-
-## Step 5: draft, render, pick, and loop
-
-Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Steps 2 through 5 against the arms from Step 4: draft the arms as frames on a canvas page, render and hand off, take the pick, and loop on it.
-
-The final icon and card renders below are not arms, so they stay off the canvas. Call the folder they render from `<dest>`, being `.canon/tmp/<slug>/` under the slug `draft-and-pick` Step 1 derived, which is where this project puts every temporary write.
-
-## Step 6: finalize the mark and the icons
-
-This step and Step 7 replace `draft-and-pick`'s own Step 6 items 1 and 2, since the pick here produces several final files rather than one applied surface. Its archive capture, its page delete, and its server stop still run, after Step 7.
-
-1. Extract the picked arm's `.mark` markup as the final vector source. Write it to `<write-folder>/favicon.svg`.
-2. Under `<dest>/render/`, write one `icon-<w>x<h>.html` page per Step 2 size, carrying the picked `.mark` markup in an element with the shared class `.render`.
-3. Declare each `.render` element at `<w>/2` by `<h>/2`, since `canon capture` screenshots at a fixed 2x scale and the PNG then lands on the target size.
-4. Declare no font on them. Each holds the mark alone, and `canon capture` skips the font check on an element with no text, where `system-ui` would be refused.
-5. Render the batch:
-
-   ```bash
-   canon capture <dest>/render --selector .render --out <write-folder>
-   ```
-
-6. Report each written file's path and the dimensions `canon capture` printed, confirming each equals its Step 2 target rather than half of it.
-
-The card leaves this batch and takes Step 7 instead. An icon is the mark alone and a scratch page renders it faithfully, where the card composes the mark with the project's own type and color, which a scratch page can only copy.
-
-## Step 7: write the card as a route and capture it through the server
-
-A card captured from a page this run deletes leaves a PNG and nothing that produced it, so renaming the project means another pick loop to move one string. Write the composition into a route the project keeps, and capture it through a running server so it reads the real stylesheet, tokens, and fonts.
-
-This is Astro-shaped for now, because Astro is the one web stack whose config gives a route a structural build exclusion. A project already holding the card route scaffold takes the route path, and everything else takes the page path. Say which one decided, since the two leave the project different things.
-
-### The route path
-
-Read `${CLAUDE_SKILL_DIR}/references/card-route.md` on reaching this path, for the scaffold check, the message to give when it is missing, and the write, serve, and capture sequence. A project with no scaffold skips it.
-
-### The page path
-
-Where the project holds no route to write into, write `og-image.html` into `<dest>/render/` with its `.render` wrapper sized 600x315, then capture that one page:
-
-```bash
-canon capture <dest>/render/og-image.html --selector .render --out <write-folder>
-```
-
-It takes its own call because Step 6's batch is already captured by the time this step picks a path. Say that the card shipped as a PNG with no source, and that the project gains one when it grows a route to hold the composition.
-
-### Closing the scratch folder and the canvas
-
-Delete `<dest>` once both captures land, then close the canvas through `draft-and-pick` Step 6 items 3 to 8, which archive every arm and delete the pages the run added. The route is not a leftover variant, since it holds the arm the operator picked.
-
-A project whose card was generated before this route existed keeps its PNG. Say so rather than regenerating it, since the pick loop spends attention on a file nobody complained about, and the next real edit picks up the route.
-
-## Response format
-
-```plaintext
-📝 Wrote <write-folder>/favicon.svg
-📝 Wrote <write-folder>/icon-16x16.png (16x16)
-📝 Wrote card-src/pages/og-card.astro (route path only)
-📝 Wrote <write-folder>/og-image.png (1200x630)
-
-Write folder: <tier that decided>. Move the files if this project's own convention differs.
-Card source: <the route, captured through the card server|a scratch page, since this project holds no card route>.
-```
-
-## What this delegates
-
-Cite these rather than restating them.
-
-- `draft-and-pick` owns Steps 1 through 5 of the render-and-pick loop, cited above
-- `canon:canvas-board` carries a picked direction into `canon/DESIGN.md`. This skill only reads it.
-- `canon capture` owns the render mechanics, its font refusal, its fixed 2x scale, and its reported dimensions. It reads an `http(s)://` source, where `--out` names the PNG.
-- The `astro` tooling stack owns the card route's scaffold, its second config, and the exclusion check, read with `canon tooling reference astro`. This skill writes into the route and never reshapes it.
+This skill is now `design-identity`. Run `/canon:design-identity` instead, and change any file that still names this one.

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

@@ -1,54 +1,25 @@
 ---
 name: draft-ready
-description: Why writing a ready folder, its overview, the thin plan, and the task row is one invocation rather than four hand writes, and where the boundary against the planning and shipping skills falls
+description: Why a pointer answers under the old `draft-ready` name, and the test that retires it
 ---
 
 # Draft ready requirement
 
 ## Gap
 
-Without this skill, a session holding finished files that hands them to a worker:
-
-- Writes the folder, the overview, the plan, and the task row as four separate hand writes, and the four drift from each other because nothing compares them.
-- Lists a destination in the overview that the plan's `**Files to touch:**` omits, or the reverse. The omitted path is invisible to `plan-reach`, so a second track writes the same file and neither side finds out.
-- Picks the next ordinal by reading only the live folder, and reuses a number an archived folder already spent, which the pull request that shipped it cites by name.
-- Picks a phase label by scanning the live board alone, which is the scan that let two sessions hand out one label within minutes of each other.
-- Reads the label bare, which reserves nothing and returns one a live claim already holds until that claim's task file lands.
-- Leaves the plan's `**Constraints:**` without a line naming the folder as the verbatim source, so the worker reads the files as inspiration and writes its own version.
-- Leaves a note, an alternate, or a draft passage in the folder beside the real files, so the worker guesses which one is the source.
-- Writes into the main worktree root from a linked worktree with `Edit` or `Write`, which the isolation guard refuses, and takes the refusal's redirect into a second gitignored copy no later session reads.
-- Reports the handoff as done while the archive move at the end, which no verb performs, is left for someone to remember.
+Without this skill, a person typing the old name after the rename to `plan-ready` 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
 
-- Refuse before writing when the operator has named no finished file, since a folder assembled from a description is a plan with extra steps.
-- Read the ordinal from the live folder and its archive together, so a spent number is never reused.
-- Take the phase label from `canon tasks next-label --claim` rather than from a scan of its own or a bare read, and stop on a binary that predates the flag rather than falling back.
-- Derive the overview's `destinations` and the plan's `**Files to touch:**` from one list, and compare the two before reporting, so neither can name a path the other lacks.
-- Write the plan's `**Constraints:**` line naming the folder as the verbatim source.
-- Copy each finished file whole to its destination path inside the folder, and carry nothing else into it.
-- Write the plan and the task through `canon tasks plan-link`, `canon records validate plans`, and `canon markdown audit` rather than by restating what those verbs check.
-- Place the task's row by the three branches `task-board` Step 4 states, so a solo project never ends with a task file on no surface.
-- Route a write at the main root from a linked worktree through `Bash`, the way `session-worktree` routes it.
-- Name the archive move in the closing report, since the skill writes a folder that stays live until someone moves it.
+- Name `plan-ready` 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
 
-- Edit a finished file. The worker copies verbatim, so a change made here is a change the warm session should have made before invoking the skill.
-- Hardcode a branch type, which `branch.md` owns, or restate the folder shape, which `ready.md` owns.
-- Write `priority.md` or `backlog.md` where an orchestrator is on the roster or the session is a worker or planner, since one board writer at a time is what keeps a gitignored board safe. Those two cases report the row instead.
-- Automate the archive move. No verb owns the relocation, and a skill doing it by hand would be the second copy of a step the standard already states.
-- Dispatch or start the worker, which belongs to whoever runs the board.
-
-## Guards
-
-- No finished file named, stop: `❌ No finished file named. A ready folder carries text that already exists, so write the files first or use /canon:plan-feature.`
-- A named file that does not resolve, stop: `❌ <path> does not exist. Name a file that is already written.`
+- Carry any part of the ready folder packaging, 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
 
-- `plan-feature` writes a plan describing a change nobody has written yet. This begins from text already written and writes a plan thin enough to point at it.
-- `role-worker` copies the folder into a worktree and ships it. This stops once the three artifacts exist.
-- `task-board` creates a task file for a row with no ready folder. This writes the row it needs beside the folder and calls the same verbs.
-- `git-ship` ships a branch, and a ready folder never reaches one.
-- `references/ready.md` owns the folder's shape and lifecycle, and this skill owns the procedure that produces it, the way `write-human` and the `markdown` rule split.
+- The work itself, which `plan-ready` 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-ready/SKILL.md

@@ -1,136 +1,11 @@
 ---
 name: draft-ready
-description: Writes a ready folder for finished files, its `00-overview.md`, the thin plan that points at it, and the task with a board row placed, reported to an orchestrator, or left to the operator, in one invocation. Use when asked to "write a ready folder", "hand these files to a worker", "package these finished files for a worker", "make a ready handoff", or when a session already holds the exact text of a skill, rule, or doc and a worker should copy it rather than author it. Do NOT use to plan a change nobody has written yet, which is `plan-feature`, to copy a folder into a worktree and ship it, which is `role-worker`, or to file a task with no finished files behind it, which is `task-board`.
+description: Renamed from `draft-ready` to `plan-ready`. Answers a typed invocation of the old ready skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
 # Draft ready
 
-A warm session that has already written a change hands the exact text to the worker that ships it. This skill writes the three artifacts that handoff needs and stops before anyone is dispatched.
-
-Read these in parallel before writing:
-
-- `${CLAUDE_SKILL_DIR}/references/ready.md`: the folder layout, the overview frontmatter, the mirrored tree, and the thin-plan contract
-- `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`: the plan's sections and its answer contract
-- `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`: the task file's shape and origin lines
-- `${CLAUDE_SKILL_DIR}/references/assembly.md`: the overview and thin-plan templates and the destination match check
-
-## Guards
-
-- If the operator named no finished file, stop: `❌ No finished file named. A ready folder carries text that already exists, so write the files first or use /canon:plan-feature.`
-- If a named file does not resolve, stop: `❌ <path> does not exist. Name a file that is already written.`
-- Resolve `<main-root>` as `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. The folder, the plan, and the task all live there.
-
-## Step 1: read the finished files
-
-1. Take each finished file with the destination path the operator gave it. A file arriving with no destination is asked for once, since the mirrored tree cannot place it.
-2. Read every file whole. The overview states what the worker still owns beyond copying, and that comes off the files, not off the operator's description of them.
-3. Take the branch type from `${CLAUDE_SKILL_DIR}/../git-branch/references/branch.md`, never from a list carried here.
-4. Derive one kebab slug for the change. The folder, the plan, and the task all carry it.
-
-## Step 2: allocate the ordinal and the label
-
-Read `<main-root>/.canon/ready/` and `<main-root>/.canon/ready/archive/` together and take the highest `<nn>` across both, plus one. A folder set with no entry takes `01`. Keep this skill-local. No verb allocates a ready ordinal, and two writers running at once can claim one number, so re-read the folder immediately before Step 3 writes.
-
-Claim the label through the verb rather than reading it bare or scanning for it:
-
-```bash
-canon tasks next-label --claim --json
-```
-
-The claim reserves the label under `.canon/ordinal-locks/`, so a second session allocating at the same moment gets the next one. A bare read reserves nothing and can return a label a live claim already holds.
-
-Branch on the record's `reason` rather than on the exit code, taking `label` from a record that carries one.
-
-- `label-contended` means re-run the claim
-- Report the verb as unavailable and stop when the binary carries no `next-label` subcommand, or prints no record for an unknown `--claim`, since it predates the flag
-- Never fall back to a bare read or a label picked by hand, which reopens the collision the claim exists to prevent
-
-## Step 3: write the overview
-
-Write `<main-root>/.canon/ready/<nn>-<slug>/00-overview.md` from the template in `${CLAUDE_SKILL_DIR}/references/assembly.md`. Set `destinations` from the Step 1 list and nothing else, and state in prose what the worker still owns, or `nothing further` where the files are the whole change.
-
-## Step 4: mirror the tree
-
-Copy each finished file to `<main-root>/.canon/ready/<nn>-<slug>/<destination path>`, one command per file, so the tree mirrors the destinations exactly.
-
-```bash
-install -D -m 0644 <source> <main-root>/.canon/ready/<nn>-<slug>/<destination path>
-```
-
-- Copy whole and edit nothing. A change wanted now is made in the source file first and copied after.
-- Carry no notes, alternates, or drafts into the folder. Anything else belongs in the plan or the pull request body.
-- Write each of these at the main root, routed the way `session-worktree` states. Create a whole new file with a heredoc.
-
-## Step 5: write the thin plan
-
-Write `<main-root>/.canon/plans/feature-<slug>.md` from the template, by heredoc, per `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`.
-
-- List every Step 1 destination under `**Files to touch:**`, each with one clause on why it changes, pointing at the folder's copy rather than restating it.
-- Add a `**Constraints:**` line naming the ready folder as the verbatim source for those paths.
-- Name the branch type from Step 1 in `## Summary`. Write `None identified.` under `**Questions:**` unless a call is genuinely the operator's.
-
-Run the match check in `${CLAUDE_SKILL_DIR}/references/assembly.md` before going further. The two lists are one list, and a path in either without the other stops the run.
-
-## Step 6: write the task
-
-Write `<main-root>/.canon/tasks/<label>-<slug>.md` by heredoc from the label Step 2 claimed, never calling the verb again, which would claim another. Its frontmatter, H1, and `## Outcomes` follow `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`.
-
-Write a `Ready:` line beside the `Plan:` line pointing at the folder, then point the task at the plan through the verb:
-
-```bash
-canon tasks plan-link <task-stem> .canon/plans/feature-<slug>.md --json
-```
-
-Branch on the record rather than on the exit. The `Ready:` line orients a worker reading the task, and `canon tasks archive` reads it to move the folder on ship.
-
-### Place the row
-
-A task file with no row is a dropped task, so place the row in the same pass. The plan exists, so the row takes `## Run now`, per the tests in `${CLAUDE_SKILL_DIR}/../task-board/references/board.md`.
-
-A path `canon tasks plan-reach` reports as claimed is a shared file rather than a hold. Name each one and its holder wherever the row is reported, so whoever controls the board decides whether a contract, a relocation, or a sweep moves the row to `## Up next`.
-
-### Check the roster
-
-Check the roster the way `canon:task-board` Step 4 does, reading `canon sessions list --self --json` for this session and `canon sessions list --json` for a same-repository row under another `sessionId` whose `name` starts with `orchestrator-`. A refused read counts as failed.
-
-- **Orchestrator found.** Write neither file. Message that session with the row's title, the plan link, and the group with its reason, so two sessions never write the board at once.
-- **Not found, and this session's name starts with `worker-` or `planner-`.** Write neither file, since both role bodies ban a board write. Report the row and its group in Step 8.
-- **Not found otherwise, or the roster read fails.** Write the row into `priority.md` through the task file's `Bash` route, since a failed read looks like a solo project and stopping strands the task.
-
-Say which branch fired in Step 8.
-
-Regenerate the task index after writing, since a hook on `Write|Edit` never fires on `Bash`:
-
-```bash
-canon indexes regen .canon/tasks
-```
-
-## Step 7: validate
-
-```bash
-canon records validate plans --json
-canon markdown audit <main-root>/.canon/ready/<nn>-<slug>/00-overview.md
-canon markdown audit <main-root>/.canon/plans/feature-<slug>.md
-```
-
-Fix what the records name in the files this run wrote and re-run once. Report a finding on a file it did not write, such as a neighbor folder missing its overview, without repairing it.
-
-## Step 8: report
-
-```plaintext
-✅ Ready folder written: .canon/ready/<nn>-<slug>/
-   Plan: .canon/plans/feature-<slug>.md
-   Task: .canon/tasks/<label>-<slug>.md
-   Row: <label> <title>, <written under ## Run now | reported to <orchestrator name> | left for the operator to place>, <reason>
-   Archive on ship: canon tasks archive moves the folder to .canon/ready/archive/<nn>-<slug>/
-```
-
-Name the archive move every time, so whoever ships knows the verb carries the folder and needs no step of their own.
-
-## Rules
-
-- Edit no finished file. The worker copies verbatim, so a change belongs in the source before this runs.
-- Restate nothing the standards own. A shape question is answered by `ready.md` and a plan question by `plan.md`.
-- Dispatch nothing. Starting the worker belongs to whoever runs the board.
+This skill is now `plan-ready`. Run `/canon:plan-ready` instead, and change any file that still names this one.

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

@@ -1,40 +1,25 @@
 ---
 name: draft-screencast
-description: Why a recording script ships pre-seeded rather than blank, what the four discovery questions buy, and why the draft stays stack-agnostic
+description: Why a pointer answers under the old `draft-screencast` name, and the test that retires it
 ---
 
 # Draft screencast requirement
 
 ## Gap
 
-Without this skill, a recording plan arrives as a wall of blank fields, so the user fills a template instead of editing a draft and the work the skill was meant to do lands back on them. The opposite failure costs more. A session that skips discovery guesses the audience, the length, and the hero moment, then writes five beats for a video nobody asked for, and every one of them has to be thrown away rather than edited.
-
-A draft that names the recording software, the editing software, or the window manager pins the script to one machine and one person's setup, so it stops being reusable the moment anyone else records. And re-invoking to refine silently overwrites the edits the user made in the file, which is the one failure that destroys work rather than wasting it.
+Without this skill, a person typing the old name after the rename to `script-screencast` 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
 
-- Read project context and recent commits before proposing, since what shipped recently is usually the subject
-- Ask exactly four discovery questions, each carrying a default derived from that context
-- Wait for answers rather than reading silence as acceptance
-- Pre-seed every section with concrete content so the draft is shippable as written and the user edits down
-- Derive the slug from the topic and the discovery answers
-- Write to `demos/<slug>/beats.md` at the project root, the committed folder the rest of the demo lives in, and print that path on its own line
-- Seed a wrap section naming intro, outro, and music with a default each, so the choice of what surrounds the take is made at draft time rather than discovered at compose time
+- Name `script-screencast` 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
 
-- Name recording software, editing software, fonts, or window managers
-- Record, edit video, or generate captions
-- Re-run against an existing draft to refine it, since re-running overwrites
-- Infer the hero moment without asking, which is the beat the whole script is built around
-
-## Guards
-
-- No topic provided: stop rather than guessing what is being recorded
+- Carry any part of the screencast script 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
 
-- Producing the recording, which `record-screencast` owns
-- Refining an existing draft, which is a direct edit of the file
-- Slide decks, which `draft-slides` owns
-- Where the recording ships, which the draft lists and the user decides
+- The work itself, which `script-screencast` owns
+- Rewriting a stale citation, which `canon migrate skill-names` owns in a tracked file and the controlling session owns on the board