@erclx/canon 5.42.0 → 5.44.0

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.

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

@@ -0,0 +1,59 @@
+---
+name: draw-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
+---
+
+# Draw 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.
+
+## 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
+
+## 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.
+
+## 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

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

@@ -0,0 +1,85 @@
+---
+name: draw-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`.
+metadata:
+  family: generate
+---
+
+# Draw 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.>
+```

package/claude/skills/{draft-figure → draw-figure}/references/architecture-set.md

@@ -1,11 +1,11 @@
 ---
 title: Architecture set
-description: The five architecture views with each one's question, source signal, and diagram type, the code-scan fallback, cited paths, and what moves to canon/context/ instead, read by draft-figure when a request names an architecture view
+description: The five architecture views with each one's question, source signal, and diagram type, the code-scan fallback, cited paths, and what moves to canon/context/ instead, read by draw-figure when a request names an architecture view
 ---
 
 # Architecture set
 
-`draft-figure` reads this file when the request names an architecture view. It shapes the subject, then the figure goes through `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` like any other graph-shaped figure. The destination stays the one the user named.
+`draw-figure` reads this file when the request names an architecture view. It shapes the subject, then the figure goes through `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` like any other graph-shaped figure. The destination stays the one the user named.
 
 ## The five views
 

package/claude/skills/{draft-figure → draw-figure}/references/hand-drawn.md

@@ -1,11 +1,11 @@
 ---
 title: Hand-drawn path
-description: Authoring a freehand SVG, its color and accessibility audit, and the in-page capture loop a rendered destination takes, read by draft-figure once a figure is drawn by hand
+description: Authoring a freehand SVG, its color and accessibility audit, and the in-page capture loop a rendered destination takes, read by draw-figure once a figure is drawn by hand
 ---
 
 # Hand-drawn path
 
-`draft-figure` reads this file when Step 3 routes a figure to a freehand drawing: a teach lesson whatever its subject, or a subject no flowchart reduces to.
+`draw-figure` reads this file when Step 3 routes a figure to a freehand drawing: a teach lesson whatever its subject, or a subject no flowchart reduces to.
 
 ## Draw
 

package/claude/skills/{draft-figure → draw-figure}/references/mermaid-path.md

@@ -1,11 +1,11 @@
 ---
 title: Mermaid path
-description: The hand-drawn render config, the SVG and PNG pair, the hex rewrite, the scoped overflow fallback, the label check, and the PNG read-back with its two-pass stop, read by draft-figure once a figure routes through Mermaid
+description: The hand-drawn render config, the SVG and PNG pair, the hex rewrite, the scoped overflow fallback, the label check, and the PNG read-back with its two-pass stop, read by draw-figure once a figure routes through Mermaid
 ---
 
 # Mermaid path
 
-`draft-figure` reads this file when Step 3 routes a figure through Mermaid, whether the subject is graph-shaped or an architecture view the architecture set already shaped.
+`draw-figure` reads this file when Step 3 routes a figure through Mermaid, whether the subject is graph-shaped or an architecture view the architecture set already shaped.
 
 ## Draft the fence
 

package/claude/skills/{draft-figure → draw-figure}/references/mermaid.md

@@ -13,7 +13,7 @@ Governs the Mermaid attribute wherever a fence is written, being direction and l
 
 Does not govern:
 
-- Which architecture view a figure draws and what question it answers: the `draft-figure` skill's architecture set
+- Which architecture view a figure draws and what question it answers: the `draw-figure` skill's architecture set
 - Language, word choice, punctuation, and formatting in the prose around a fence: `markdown.md`
 - Voice, rhythm, and sentence construction in that prose: the `write-human` skill
 - The mechanism behind any component a diagram draws: `context.md`

package/claude/skills/git-commit/references/commit.md

@@ -56,6 +56,7 @@ A scope names a component, never a file or the type again.
 - Use imperative mood (`add` not `added`)
 - Describe the actual technical change, not that something changed
 - Do not use vague verbs (`improve`, `refine`, `enhance`)
+- Name what changed in the project on a sync or upgrade commit, never the toolkit version, since the config stamp records it
 
 ### Form and quoting
 
@@ -66,11 +67,6 @@ The subject carries the change and nothing around it.
 - No backslash escaping or internal double quotes
 - No conversational filler or introductory phrases
 
-## Trailers
-
-- Do not add a `Co-authored-by` trailer crediting Claude or Anthropic, by name or by address
-- The `commit-msg` hook refuses a commit carrying one, so remove the line and commit again
-
 ## Examples
 
 ### Correct

package/claude/skills/git-pr/references/pr.md

@@ -33,6 +33,7 @@ Does not govern:
 - Format: `<type>(<scope>): <subject>`, with `!` before the colon for a breaking change
 - Casing: lowercase for `<type>`, `<scope>`, and first word of `<subject>`
 - Length: 72 characters maximum
+- Subject: follows the subject rules in `commit.md`, including the one for a sync or upgrade title
 
 ## Content
 

package/claude/skills/make-deck/REQUIREMENT.md

@@ -0,0 +1,44 @@
+---
+name: make-deck
+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
+---
+
+# Make deck 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.
+
+## 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
+
+## 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.
+
+## 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 `script-screencast` owns

package/claude/skills/make-deck/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: make-deck
+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.
+metadata:
+  family: generate
+---
+
+# Make deck
+
+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

package/claude/skills/markdown-craft/REQUIREMENT.md

@@ -15,7 +15,7 @@ The rules also had three carriers, a standard, a generated rule pointing at it,
 
 - Hold the format and structure reference in `references/markdown.md`, the one copy, read by sibling path from every skill that writes markdown
 - Send the session to `canon markdown audit` after an edit, since the audit reads the bans from the package and a restated list would drift
-- Route voice to `write-human` and a Mermaid fence to `draft-figure` rather than restating either
+- Route voice to `write-human` and a Mermaid fence to `draw-figure` rather than restating either
 
 ## Must not
 

package/claude/skills/markdown-craft/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: markdown-craft
-description: Carries the format and structure rules for markdown, being headings, the density limits, paragraph and list shape, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording, and runs the audit after an edit. Use before a substantial markdown edit, when writing a README, a doc, a skill body, or any `.md` file, or when asked "what are the markdown rules" or "which characters are banned". Do NOT use for voice, rhythm, or word choice, which is `write-human`, or for a Mermaid fence or figure, which is `draft-figure`.
+description: Carries the format and structure rules for markdown, being headings, the density limits, paragraph and list shape, code spans, the date form, punctuation, emphasis, file references, American spelling, and frontmatter wording, and runs the audit after an edit. Use before a substantial markdown edit, when writing a README, a doc, a skill body, or any `.md` file, or when asked "what are the markdown rules" or "which characters are banned". Do NOT use for voice, rhythm, or word choice, which is `write-human`, or for a Mermaid fence or figure, which is `draw-figure`.
 metadata:
   family: answer
 ---
@@ -14,4 +14,4 @@ Run `canon markdown audit <path>` after the edit, and fix every ban and density
 ## Routes
 
 - Voice, rhythm, sentence construction, and information density: load `write-human`.
-- A Mermaid fence or a figure: load `draft-figure`, since the audit skips every line inside a fence.
+- A Mermaid fence or a figure: load `draw-figure`, since the audit skips every line inside a fence.