@erclx/canon 5.43.0 → 5.44.0

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

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

@@ -1,70 +1,11 @@
 ---
 name: draft-screencast
-description: Drafts a screencast script with pre-seeded beats, defaults, and decisions to `demos/<slug>/beats.md`. Reads project context, asks four discovery questions with proposed defaults, then writes a shippable draft. Use when asked to "draft a screencast", "write a recording script", "plan a demo video", or "scaffold a screencast for X". Do NOT re-invoke to refine an existing draft. Re-running overwrites. Edit the draft file directly.
+description: Renamed from `draft-screencast` to `script-screencast`. Answers a typed invocation of the old screencast skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
 # Draft screencast
 
-## Guards
-
-- If no topic is provided, stop: `❌ No screencast topic. Describe what you are recording.`
-- Draft, then hand off. Do not edit video, generate captions, or drive the application, since a recording is `record-screencast`'s job. Name it as the next step and stop.
-- Stack-agnostic in the draft. Never name a recording tool, an editing tool, a font, or a window manager.
-- Keep selectors, URLs, wait conditions, and timings out of the beats, since the compiler adds those four in a plan of its own and a beat carrying them stops being readable
-
-## Step 1: read the project context
-
-Read these in parallel from the project root, skipping any that do not exist:
-
-- `CLAUDE.md`: behavior rules and project pitch
-- `canon/REQUIREMENTS.md`: feature scope, non-goals, audience hints
-- `.canon/tasks/index.md`: current scope
-- Recent commits via `git log --oneline -20 2>/dev/null || echo "FALLBACK"`: what shipped recently is usually the recording subject.
-
-## Step 2: discovery with proposed defaults
-
-Ask exactly four questions in chat. Each carries a proposed default derived from Step 1. The user confirms, overrides, or says "use defaults" to accept all.
-
-```markdown
-**Discovery:**
-
-1. Audience: proposing technical peers. Override?
-2. Length: proposing 75-90s. Override?
-3. Hero moment: proposing <best guess from context, or "the single thing that has to land">. Override?
-4. What to cut: proposing <best guess, or "anything that is not the hero moment">. Override?
-```
-
-Wait for answers before drafting. Do not infer silence as acceptance.
-
-## Step 3: derive the slug
-
-Build a 2-to-4-word kebab-case slug from the topic and discovery answers. Examples: `auth-flow-redesign`, `cli-onboarding`, `inline-edit-launch`.
-
-## Step 4: write the draft
-
-Create `demos/<slug>/beats.md` at the project root, creating the folder if it does not exist. The file is committed with the rest of the demo's sources, so a recording can be rebuilt from the folder alone.
-
-### Fill the template
-
-Write all nine sections from `${CLAUDE_SKILL_DIR}/references/beats-template.md`, read on reaching this step. Pre-seed every section with concrete content so the draft ships as-is, and the user edits down rather than fills blanks. A run stopped at discovery skips it.
-
-Load `canon:video-craft` for every zoom and caption value the draft names, and report it rather than proceeding silently when it does not resolve.
-
-## Step 5: output
-
-Print the file path on its own line and a one-line summary. Do not paraphrase the path into prose.
-
-```markdown
-📝 Wrote demos/<slug>/beats.md
-
-Draft has 5 beats and pre-seeded defaults. Edit the beats, the resolved decisions, and the wrap.
-
-To record it rather than shoot it by hand:
-record-screencast demos/<slug>/beats.md
-```
-
-Name the skill and stop there. Do not compile the draft, do not run it, and do not generate captions. The operator edits the beats first, and the compiler reports which selectors and URLs they still owe it.
-
-Say so plainly if `canon demo compile` is not available, rather than driving the application some other way. The command ships with the CLI and the skills ship with the plugin, so a project carrying one and not the other is a real state.
+This skill is now `script-screencast`. Run `/canon:script-screencast` instead, and change any file that still names this one.

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

@@ -1,44 +1,25 @@
 ---
 name: draft-slides
-description: Why the skill draws a deck as HTML in the project's tokens inside its own folder, why the CLI owns the conversion, and why one render is read back before the deck is called done
+description: Why a pointer answers under the old `draft-slides` name, and the test that retires it
 ---
 
 # Draft slides requirement
 
 ## Gap
 
-Without this skill, a deck request turns into hand-built output. The session writes a deck into whatever path occurs to it, so a second deck overwrites the first and nothing lists either. It writes pptxgenjs code or hex colors per deck, so the deck takes neither the project's design nor any other deck's, and it invents attributes the converter does not read, so a section, a chart, or an entrance silently goes missing. Every slide comes out as a title over bullets, which is the shape that needs no decision and reads as a document rather than a deck.
-
-A first render shipped unread hands the audience the overlap, the overflow, and every element the converter fell back to a picture for, since markup that looks correct says nothing about the file it produces.
+Without this skill, a person typing the old name after the rename to `make-deck` 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 the existing decks and the slide format from the CLI before drawing, and pick a deck name no listed deck carries unless the request names one
-- Write each deck into its own folder under the slides record folder, one HTML file per slide in filename order
-- Draw with the project's custom properties so the deck takes the project's design
-- Vary the composition across the deck rather than repeating one shape
-- Size content to fit the slide frame, keeping titles short and lines tight
-- Shell out to the render command for the deck itself
-- Read every fallback and refusal the render reports, run one QA pass over the rendered images, and fix what both report
+- Name `make-deck` 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
 
-- Hardcode a deck name, an attribute, or a chart type, which goes stale the moment the CLI changes
-- Reimplement the conversion, the master, or the packaging, which the CLI owns
-- Write a deck into the shared layouts folder, which is never listed as a deck
-- Invent token values when the project has no token stylesheet
-- Write centered body text or content that overflows a slide
-- Loop on aesthetics past a single fix pass
-
-## Guards
-
-- No token stylesheet: draw the deck anyway and say it renders unstyled.
-- Image conversion tools missing: skip the image pass and say so. Do not fail the render over a verification step.
+- Carry any part of the deck 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
 
-- Converting HTML to PowerPoint, which the CLI owns end to end
-- The project's palette and faces, which live in its token stylesheet rather than in the slides
-- Writing the content the deck is about, which the caller brings
-- Drafting a deck as a canvas page, which waits on a measurement of that authoring surface
-- Recording a demo, which `draft-screencast` owns
+- The work itself, which `make-deck` 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-slides/SKILL.md

@@ -1,80 +1,11 @@
 ---
 name: draft-slides
-description: Draws a deck as HTML slides in the project's own design, one folder under `.canon/slides/` per deck, then renders it to an editable PowerPoint file via `canon slides render`. Use when asked to "draft slides", "make a deck", "build a presentation", "turn this into slides", or "render the deck". Holds the deck design rules. Do NOT reimplement the conversion. The CLI owns layout into PowerPoint shapes, the master, and packaging. Assumes the `canon` CLI is on PATH.
+description: Renamed from `draft-slides` to `make-deck`. Answers a typed invocation of the old slides skill name by pointing at the new one.
+disable-model-invocation: true
 metadata:
   family: generate
 ---
 
 # Draft slides
 
-Draw each slide as an HTML file in a deck folder, then shell out to `canon slides render`. The CLI lays every slide out in a browser and rebuilds it as editable PowerPoint shapes. This skill owns the content, the slide markup, and the design choices the markup encodes.
-
-## Read the decks and the format
-
-Run the list first, then read the format. Never hardcode a deck name, an attribute, or a chart type.
-
-```bash
-canon slides list --json 2>/dev/null
-```
-
-The list returns one row per deck, carrying its `name`, `title`, slide count, and `path`. When the request names a deck the list holds, edit that folder. Otherwise pick a new kebab-case name no row carries.
-
-Read `${CLAUDE_SKILL_DIR}/references/deck.md`. It states what `deck.json` holds, what each slide declares on its `<body>`, the motion attributes, speaker notes, and charts. Each refusal prints as a `✗` line from the render.
-
-## Draw the deck
-
-A deck folder sits at `.canon/slides/<deck>/` from the project root, and holds:
-
-- One `.html` file per slide, rendered in filename order. Number them with a zero-padded prefix, such as `01-cover.html`, so a slide inserted later sorts where it belongs.
-- `deck.json`, optional, for the title, the header and footer bands, slide numbers, the mark, and embedded faces.
-- `assets/` for images the slides reference by a relative path.
-
-Never write a slide into `.canon/slides/layouts/`. That folder holds the project's shared layouts and is never listed as a deck.
-
-Each slide is a full HTML document laid out at 1280 by 720 CSS pixels. Position its blocks absolutely or with a flex or grid container sized to that frame, and keep every element inside it.
-
-## Design rules
-
-The render injects the project's token stylesheet ahead of each slide's own styles, so the deck takes the project's design rather than the toolkit's.
-
-- Use the project's custom properties, such as `var(--color-accent)`, for every color, face, and spacing value, read from `.claude/design/base.css` and overrides under `.claude/design/project/`
-- When neither exists, say the deck renders unstyled rather than inventing values to cover it
-- Leave the `--color-*` roles to the stylesheet. The master reads its colors off the first slide's `<html>`, so a slide computing its own `--color-text` is reported, since the bands keep the master's.
-- Vary the composition across slides. Never repeat a title over bullets on every slide. Reach for columns, a row of large numbers, a grid of cards, a chart, a pull quote, and section dividers.
-
-### Fit and shapes
-
-Text and shapes have to survive the conversion.
-
-- Keep titles short and lines tight, so text fits its box at the size the design sets rather than overflowing the frame.
-- Never write centered body text.
-- Prefer CSS the converter maps to native shapes. An unmappable property is drawn as a picture and reported on stderr, so a slide full of gradients and filters stops being editable.
-
-## Render
-
-Shell out to the CLI. It writes the deck and reports the path.
-
-```bash
-canon slides render <deck>
-```
-
-With one deck in the project the name can be left out. The render refuses with the deck list when there are several. Pass `--open` to open the deck, and `--mirror <dir>`, or set `CANON_SLIDES_MIRROR`, to copy it into a synced folder.
-
-Read every `✗` line the render prints. A picture fallback, a refused link, chart, or effect, and a missing token each leave the deck written with that piece degraded or left out.
-
-## QA loop
-
-Run this once after the first render, then stop.
-
-1. Convert the deck with `soffice --headless --convert-to pdf <deck>.pptx`, then `pdftoppm -r 90 -png <deck>.pdf slide`. If either is missing, skip the image pass and say so rather than fail the render.
-2. Open and inspect every rendered image in this session, checking each slide for overlap, overflow, low contrast, and empty regions.
-3. Fix the reported issues and the `✗` lines in the slide files once, re-render, and stop. Do not loop indefinitely on aesthetics.
-
-## Response
-
-After rendering, report:
-
-- The deck folder, the slide count, and the written `.pptx` path
-- Whether the project's token stylesheet was found
-- Each `✗` line the final render printed, or that it printed none
-- Any QA issues found and what changed, or that the deck passed clean
+This skill is now `make-deck`. Run `/canon:make-deck` instead, and change any file that still names this one.