@erclx/canon 5.43.0 → 5.45.0

package/README.md

@@ -165,7 +165,7 @@ git init
 canon init
 ```
 
-`canon init` installs base tooling configs, Claude seeds, and governance rules in one pass, and scaffolds a `.claude/wiki/` stub for your project's own reference pages.
+`canon init` installs base tooling configs, Claude seeds, and governance rules in one pass.
 
 - Governance defaults to the `base` stack, so a bare init lands the workflow and doc-authoring rules in `.claude/rules/`.
 - Each rule names the skill it loads, so no corpus is copied into your project.

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
-  "version": "5.43.0",
+  "version": "5.45.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/backlog-triage/references/apply.md

@@ -25,12 +25,12 @@ An item already applied, by the test in the skill's Step 1, is skipped silently,
 
 Take the task stem from the item heading. Every verdict leaves the folder slug on its task, which is how Step 1 and `task-board`'s unlinked-origin scan both see the folder as acted on.
 
-| Verdict | Command and board write                                                                                                                                 |
-| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| decline | `canon tasks decline <stem> --reason "<reason>, backlog triage <slug> item <cluster>#<n>" --json`, which clears the backlog line                        |
-| archive | `canon tasks outcome <stem> --close <p> ... --json` for the named positions, then `canon tasks archive <stem> --json`                                   |
-| keep    | Append the `## Findings` line naming what reproduced, leaving the backlog line                                                                          |
-| promote | Move the backlog line to the bottom of `## Needs a plan` in `.canon/tasks/priority.md`, its `Waiting on` cell stating what cleared and ending in `last` |
+| Verdict | Command and board write                                                                                                          |
+| ------- | -------------------------------------------------------------------------------------------------------------------------------- |
+| decline | `canon tasks decline <stem> --reason "<reason>, backlog triage <slug> item <cluster>#<n>" --json`, which clears the backlog line |
+| archive | `canon tasks outcome <stem> --close <p> ... --json` for the named positions, then `canon tasks archive <stem> --json`            |
+| keep    | Append the `## Findings` line naming what reproduced, leaving the backlog line                                                   |
+| promote | `canon tasks place <stem> --group needs-a-plan --bottom --waiting "<what cleared>. Last" --json`, which clears the backlog line  |
 
 ### Archive and missing files
 

package/claude/skills/canon-cli/SKILL.md

@@ -33,7 +33,6 @@ Consult to pick the `canon` verb for a job, and before running a verb that write
 | Install or sync governance rules                                | `canon gov`     |
 | Sync a tooling stack's configs and seeds, or read its reference | `canon tooling` |
 | Set up or sync the Claude workflow                              | `canon claude`  |
-| Scaffold a wiki                                                 | `canon wiki`    |
 | Regenerate the `index.md` files                                 | `canon indexes` |
 | Read a toolkit reference doc                                    | `canon docs`    |
 
@@ -43,11 +42,11 @@ Each verb here has a skill that owns the job. Load the skill rather than driving
 
 | Job                                          | Verb                | Skill                       |
 | -------------------------------------------- | ------------------- | --------------------------- |
-| Render the design system                     | `canon design`      | `canon:draft-figure`        |
-| Render a slide deck                          | `canon slides`      | `canon:draft-slides`        |
-| Render an HTML source to a PNG               | `canon capture`     | `canon:draft-identity`      |
+| Render the design system                     | `canon design`      | `canon:draw-figure`         |
+| Render a slide deck                          | `canon slides`      | `canon:make-deck`           |
+| Render an HTML source to a PNG               | `canon capture`     | `canon:design-identity`     |
 | Serve a directory and print the link         | `canon serve`       | none                        |
-| Record a running app                         | `canon demo`        | `canon:draft-screencast`    |
+| Record a running app                         | `canon demo`        | `canon:script-screencast`   |
 | Report one computed property across routes   | `canon inventory`   | `canon:target-check`        |
 | Walk a page through interactions and measure | `canon drive`       | `canon:ux-measure`          |
 | Fetch a YouTube transcript                   | `canon transcripts` | `canon:youtube-transcripts` |

package/claude/skills/canvas-board/REQUIREMENT.md

@@ -43,6 +43,6 @@ When the operator picks a frame, the session leaves the decision on the canvas a
 
 - What the canvas verbs do internally, which is the CLI's own contract
 - The content format a frame and a layout take, which the canvas standard fixes
-- Drafting candidates for a taste decision and taking the pick, which `draft-and-pick` runs on this canvas through the same verbs
+- Drafting candidates for a taste decision and taking the pick, which `pick-by-eye` runs on this canvas through the same verbs
 - Tracing reference images into design values or writing the design document from code, which no skill owns now
 - Backing up the canvas folder off one disk

package/claude/skills/canvas-board/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: canvas-board
-description: Drives the local design canvas, where pages hold HTML frames the operator sees, drags, selects, and edits in the browser. Starts the canvas when it is not running, confirms the live shell loads, makes pages and frames, edits a frame through its file, reads what the operator selected or restyled, captures finished frames, and carries a picked direction into the project's design document. Use when asked to "open the canvas", "put this on the canvas", "draw a frame for X", "change the one I selected", "what did I pick", "capture this frame", or "move that frame on the canvas". Do NOT use to draft candidates for a taste decision, which is `draft-and-pick`.
+description: Drives the local design canvas, where pages hold HTML frames the operator sees, drags, selects, and edits in the browser. Starts the canvas when it is not running, confirms the live shell loads, makes pages and frames, edits a frame through its file, reads what the operator selected or restyled, captures finished frames, and carries a picked direction into the project's design document. Use when asked to "open the canvas", "put this on the canvas", "draw a frame for X", "change the one I selected", "what did I pick", "capture this frame", or "move that frame on the canvas". Do NOT use to draft candidates for a taste decision, which is `pick-by-eye`.
 metadata:
   family: decide
 ---

package/claude/skills/context-fold/references/context.md

@@ -28,7 +28,7 @@ Does not govern:
 
 - Product scope, goals, and non-goals: `requirements.md`
 - Path-scoped coding rules: `rule.md`
-- Figures and architecture views, which answer structure questions an entry hands off: the `draft-figure` skill
+- Figures and architecture views, which answer structure questions an entry hands off: the `draw-figure` skill
 - The consumer-facing reference under `docs/`, whose reader is operating the project without the source open: `docs.md`
 
 ## Organizing principle

package/claude/skills/create-skill/REQUIREMENT.md

@@ -24,7 +24,7 @@ A fifth failure is the confirmation itself. A worker running a plan that adds a
 - Draft the sibling `REQUIREMENT.md` beside the body, from what the skill is for rather than from the drafted body
 - Confirm the name and both files with the user before writing, where a person is present to answer. The name is the routing key and a folder that disagrees with its frontmatter fails silently. Where nobody is present, record the three answers and both paths in the output and write.
 - Write to the conventional skills path, so discovery finds it without configuration. That is `.claude/skills/` in a target project. In the toolkit's own checkout, which the project root's `claude/.claude-plugin/plugin.json` marks, an `internal-*` skill goes under `.claude/skills/` and a plugin skill under `claude/skills/`
-- Leave the skills audit's dated-provenance check clean for the new folder before reporting it, with each incident moved to the requirement's `Gap`
+- Leave the skills audit's dated-provenance check clean for the new folder before reporting it, with each incident cut and left to git
 
 ## Must not
 

package/claude/skills/create-skill/SKILL.md

@@ -38,7 +38,7 @@ Read these in the same pass:
    - Does the body carry a procedure a session would get wrong from first principles? A one-line wrapper around a single command needs no skill.
    - Will anything invoke it other than the author typing its name? Carry this one into the drafted `REQUIREMENT.md`'s `Must not` section as a review criterion instead, since nothing can answer it before the skill has run.
    - Tell the user and stop when the first answer is yes or the second is no. A non-interactive run stops on both too, reporting which question failed and writing no folder.
-2. Draft the full `SKILL.md` from the user's description, stating the current rule alone. An incident and the date it happened belong in the requirement's `Gap`, not in the body or a reference.
+2. Draft the full `SKILL.md` from the user's description, stating the current rule alone. An incident and the date it happened stay in git, never in the body, a reference, or the requirement.
 3. Draft the sibling `REQUIREMENT.md` from what the skill is for, in the shape the requirement standard states.
    - Write the gaps from the user's description rather than from the drafted body, since a requirement derived from the body records whatever the draft overfitted to.
 4. Confirm the skill name and both files with the user before writing, when a person can answer.
@@ -53,7 +53,7 @@ Steps 5 to 7 write the folder and check what landed before the run reports.
    - The root is `.claude/skills/` in a target project.
    - Where the project root holds `claude/.claude-plugin/plugin.json`, which is the toolkit's own checkout, an `internal-*` skill goes under `.claude/skills/` and every other skill under `claude/skills/`, since the plugin ships that tree.
 6. Run `canon claude skills audit --json` and read `findings.datedProvenance` for rows under `<root>/<name>/`.
-   - Move each row's incident into `REQUIREMENT.md` under `Gap`, cut the date from the file the row names, and re-run until no row names the folder.
+   - Cut each row's date and incident from the file the row names, leaving them to git, and re-run until no row names the folder.
    - When `canon` does not resolve or its record carries no `datedProvenance` key, say the check did not run rather than reporting the skill clean.
 7. Run `canon markdown audit <root>/<name>/` over the new body and any references, and fix every ban and density finding it reports.
    - Re-run it until it reports none, since every file in the folder is this run's draft.

package/claude/skills/create-skill/references/skill-requirement.md

@@ -35,12 +35,36 @@ A requirement that leaves any of the three open is non-conforming regardless of
 - Write the gaps from what the skill is for, then compare the body against them
 - A requirement derived from the body records the body's accidents as the requirement, and misinforms a reader who reads it in place of the body
 
+## Sections
+
+The file carries these H2s in this order and no others. `canon claude skills audit` reports a missing Gap or Must and a Guards heading.
+
+| Section        | When                                      | Holds                                                         |
+| -------------- | ----------------------------------------- | ------------------------------------------------------------- |
+| `Gap`          | Always                                    | The failures a session hits today without the skill, as prose |
+| `Must`         | Always                                    | The outcomes that close those failures, one per bullet        |
+| `Must not`     | When a behavior closes a gap and is wrong | That behavior, one per bullet                                 |
+| `Out of scope` | When a sibling owns an adjacent behavior  | The behavior and the skill that owns it                       |
+
+`Guards` is retired. A refusal condition is a `Must not` bullet, and the message it prints belongs to the body.
+
+## Caps
+
+The audit reports each cap it finds breached, and a rewrite batch turns the report into a gate for the files it brings under.
+
+- Each list holds at most 5 bullets. A sixth `Must` is a sign the skill does two jobs or the list restates its steps.
+- The file holds at most 400 words of body, frontmatter excluded
+- Gap carries no `YYYY-MM-DD` date and no `#NNN` issue or pull request number outside a code span
+
 ## Content
 
-- State each gap as an observed failure, not an intent. "Without this skill a session invents its own filename" can be shown wrong. "This skill helps manage tasks" cannot fail, so it constrains nothing.
-- Trace everything under `## Must` to a stated gap. A `Must` with no gap behind it is the padding the file exists to prevent.
-- Keep it high level. A requirement that outgrows one file has stopped being a requirement, and `references/` already holds detail.
-- Use `name` and `description` frontmatter, matching `SKILL.md` so the pair is consistent.
+- State each gap as a failure a session hits today, in the present tense. "Without this skill a session invents its own filename" can be shown wrong.
+- Never state a gap as an intent. "This skill helps manage tasks" cannot fail, so it constrains nothing.
+- Keep history out of Gap. The incident, its date, and the pull request that earned a rule stay in git, where `git log` on the file finds them.
+- Write each `Must` as an outcome a reader can check against the body, never as a step the body takes. "The committed set is exactly the staged set" is an outcome.
+- Trace every `Must` to a stated gap. A `Must` with no gap behind it is the padding the file exists to prevent.
+
+The frontmatter carries `name` and `description`, matching `SKILL.md` so the pair is consistent.
 
 ## Template
 
@@ -54,21 +78,56 @@ description: <one line, distinct from the SKILL.md description>
 
 ## Gap
 
-Without this skill, a session <observed failure>, <observed failure>.
+Without this skill, a session <failure it hits today>. <A second failure, when there is one>.
 
 ## Must
 
-- <behavior that closes a named gap>
+- <outcome that closes a named failure>
 
 ## Must not
 
 - <behavior that would be wrong even though it closes a gap>
 
-## Guards
+## Out of scope
+
+- <adjacent behavior>, which `<sibling-skill>` owns
+```
+
+### Worked example
+
+`git-commit`'s requirement in this shape, at 167 words as the audit counts them.
+
+```markdown
+---
+name: git-commit
+description: What commit generation is for, the gaps it closes, and where the family boundary sits
+---
+
+# Git commit requirement
+
+## Gap
+
+Without this skill, a commit message takes whatever shape the session picks. The type and scope drift from the history's convention, the subject runs past the log's width, and a lockfile diff crowds out the change the message should describe.
+
+A plain request to commit also reaches the grouping sibling, which restages whole files, so a hunk-level selection ships wider than the user reviewed.
+
+## Must
+
+- The message follows the commit format and versioning references
+- The message describes the staged diff with lockfiles excluded
+- The user sees the message and its length before the commit runs
+- The committed set is exactly the staged set
+- The description claims single-concern and hunk-level staged sets, and names `git-stage` for a mixed one
+
+## Must not
 
-- <the refusal condition and its message>
+- Stage or unstage anything
+- Commit when nothing is staged
+- Emit anything after the result line
 
 ## Out of scope
 
-- <the adjacent thing this deliberately does not cover, and what covers it>
+- Splitting a mixed diff into several commits, which `git-stage` owns
+- Naming a branch, which `git-branch` owns
+- Pushing or opening a pull request, which `git-pr` owns
 ```

package/claude/skills/create-skill/references/skill.md

@@ -132,7 +132,7 @@ A body holds behavioral rules and pointers to reference docs, front-loading the
 
 ### Current rule and grouping
 
-State the current rule only, in the body and in every file under `references/`. The incident and the date that earned a rule go in `REQUIREMENT.md` under `Gap`, or stay in git, and a date inside a fence or a code span is example data and stays.
+State the current rule only, in the body and in every file under `references/`. The incident and the date that earned a rule stay in git, and a date inside a fence or a code span is example data and stays.
 
 - Cut any rule that resists crisp one-line phrasing. Vague guidance is worse than none.
 - Group bullets under H2 headings by concern, keeping dos and don'ts together rather than in flat rules and constraints sections

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

@@ -0,0 +1,40 @@
+---
+name: design-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
+---
+
+# Design 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 `pick-by-eye`'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.
+
+## 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 `pick-by-eye`'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
+
+## Must not
+
+- Restate `pick-by-eye`'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 `pick-by-eye`, `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.
+
+## 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

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

@@ -0,0 +1,138 @@
+---
+name: design-identity
+description: Drafts a project's logo mark through pick-by-eye'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.
+metadata:
+  family: generate
+---
+
+# Design 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}/../pick-by-eye/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}/../pick-by-eye/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 `pick-by-eye` 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 `pick-by-eye`'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 `pick-by-eye` 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.
+
+- `pick-by-eye` 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.

package/claude/skills/{draft-identity → design-identity}/references/card-route.md

@@ -1,11 +1,11 @@
 ---
 title: Card route path
-description: How draft-identity writes the picked card composition into a project's existing Astro card route and captures it through the card server
+description: How design-identity writes the picked card composition into a project's existing Astro card route and captures it through the card server
 ---
 
 # Card route path
 
-Applies to Step 7 of `draft-identity` when the project already holds the card route scaffold. A project without it takes the page path in the skill body instead.
+Applies to Step 7 of `design-identity` when the project already holds the card route scaffold. A project without it takes the page path in the skill body instead.
 
 ## The scaffold
 

package/claude/skills/design-taste/REQUIREMENT.md

@@ -9,9 +9,9 @@ description: Why a design round needs a stated layer ordering and a taste catalo
 
 Without this skill, a design round has no vocabulary to declare what it is varying and no standard of quality once it has. Both halves failed together and each is measured.
 
-The failure was measured on a real page. Four `draft-and-pick` rounds ran against one landing page in a single working session, and three changed nothing the operator could see. Each varied a property at Surface, being palette, figure treatment, heading separation and underline reach, against a page whose defect sat at composition.
+The failure was measured on a real page. Four `pick-by-eye` rounds ran against one landing page in a single working session, and three changed nothing the operator could see. Each varied a property at Surface, being palette, figure treatment, heading separation and underline reach, against a page whose defect sat at composition.
 
-The instruction against that already existed. `draft-and-pick` Step 1 says to name the layer and Step 2 says a palette cannot be picked ahead of a composition. All four rounds skipped both, and nothing reported it. A session told to name a layer has no catalog to name from, so the rule had nothing behind it.
+The instruction against that already existed. `pick-by-eye` Step 1 says to name the layer and Step 2 says a palette cannot be picked ahead of a composition. All four rounds skipped both, and nothing reported it. A session told to name a layer has no catalog to name from, so the rule had nothing behind it.
 
 The second half is the output itself. A model with no stated direction draws the population average of its training data, which produces interfaces that satisfy every craft rule and still read templated.
 
@@ -27,7 +27,7 @@ A session handed either one unfiltered adopts a stack the project does not use,
 - Enumerate the layers in settle order, so an instruction to name one has a catalog behind it
 - State that a round varies one layer, and that a complaint is worked at the lowest layer it reaches rather than the cheapest one to change
 - Carry grey-boxing as the operational form of the ordering rule, since removing the higher layers from view is what makes a lower one judgeable
-- Cite the correctness floor rather than restating it. `copy`, `a11y`, `forms` and `ux-completeness` already carry accessibility, keyboard, forms, states and rendered copy on the rendered paths, and a second copy here drifts with nothing comparing the two.
+- Cite the correctness floor rather than restating it. `copy`, `a11y`, `keyboard`, `forms` and `ux-completeness` already carry accessibility, keyboard, forms, states and rendered copy on the rendered paths, and a second copy here drifts with nothing comparing the two.
 - Hold in the body what every design moment pays for, being the read, the layers, the ordering, grey-boxing and the locks, and defer everything a single moment needs.
 - State what has to stay constant across a whole surface, since coherence is a property of the whole and each of those is broken one section at a time.
 - Detect the mode before reading anything when a surface already exists, and name what cannot change silently, since a slug, a field name or an analytics event breaks something outside the surface.
@@ -56,7 +56,7 @@ A rule failing any of the four is recorded as considered and declined rather tha
 - Express intensity as a numeric scale. A session picks a middle value and reports compliance, which satisfies the rule and decides nothing.
 - Claim the reported failure is closed. Nothing measures whether a round follows these rules, so this skill states them and the measurement is owed separately.
 - Duplicate a rule a surface already states for itself, such as slide layout or terminal color, where pointing at that surface is the whole of the correct answer
-- Be reached only by an author typing its name. `claude/skills/create-skill/references/skill.md` makes this a review criterion rather than a check, since nothing answers it before the skill has run. The intended non-author caller is the declared read in `draft-and-pick`'s output. A round producing no read, with this skill never loaded, is the evidence that the description's triggers are too weak.
+- Be reached only by an author typing its name. `claude/skills/create-skill/references/skill.md` makes this a review criterion rather than a check, since nothing answers it before the skill has run. The intended non-author caller is the declared read in `pick-by-eye`'s output. A round producing no read, with this skill never loaded, is the evidence that the description's triggers are too weak.
 
 ## Guards
 
@@ -66,11 +66,11 @@ A rule failing any of the four is recorded as considered and declined rather tha
 
 ## Out of scope
 
-- Accessibility, keyboard interaction, ARIA and alt text, which `a11y` owns on every rendered path
+- Accessibility, ARIA and alt text, which `a11y` owns on every rendered path, and keyboard interaction, which `keyboard` owns
 - State coverage, empty and loading treatment, destructive confirmation and truncation, which `ux-completeness` owns
 - Validation timing, error placement and save blocking, which `forms` owns
 - Rendered copy casing, button labels and error wording, which `copy` owns
-- The candidate loop, the arm set, the render and the pick, which `draft-and-pick` owns and which this skill is loaded alongside rather than inside
+- The candidate loop, the arm set, the render and the pick, which `pick-by-eye` owns and which this skill is loaded alongside rather than inside
 - The shape of the project's design document, its sections and its role tables, which `claude/skills/canvas-board/references/design.md` governs
 - Prose on the surface being designed, which `write-human` and `markdown.md` govern between them
 - Measuring whether finished output followed these rules, which needs a check this skill does not carry and which no command reaches while a render is an image rather than a parse

package/claude/skills/design-taste/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-taste
-description: Carries the layer model that decides which design decision settles first, the rules that keep a surface coherent across sections, and the catalog of defaults a model reaches for when nothing states a direction. Use when drafting or judging an interface, a page, or any rendered surface, when output reads generic or templated, when redesigning something that already exists, or when asked to "make this look designed", "why does this look like AI made it", "give it taste", "what layer is this decision at", or "grey-box this first". Do NOT use for accessibility, forms, or state coverage, which the `ui` governance rules carry, for the shape of the project's design document, which `design.md` governs, or to run the candidate loop, which is `draft-and-pick`.
+description: Carries the layer model that decides which design decision settles first, the rules that keep a surface coherent across sections, and the catalog of defaults a model reaches for when nothing states a direction. Use when drafting or judging an interface, a page, or any rendered surface, when output reads generic or templated, when redesigning something that already exists, or when asked to "make this look designed", "why does this look like AI made it", "give it taste", "what layer is this decision at", or "grey-box this first". Do NOT use for accessibility, forms, or state coverage, which the `ui` governance rules carry, for the shape of the project's design document, which `design.md` governs, or to run the candidate loop, which is `pick-by-eye`.
 metadata:
   family: build
 ---
@@ -156,7 +156,7 @@ Run `${CLAUDE_SKILL_DIR}/references/preflight.md` against the output. It is the
 
 Four neighbors own the rest.
 
-- The candidate loop, the arm set, the render, and the pick: `draft-and-pick`
+- The candidate loop, the arm set, the render, and the pick: `pick-by-eye`
 - The shape of the project's design document and where its values live: `${CLAUDE_SKILL_DIR}/../canvas-board/references/design.md`
 - Reading source for roughness: `ux-audit`. Measuring what a running interface costs to paint: `ux-measure`
 - Prose on the surface being designed: the `write-human` skill

package/claude/skills/design-taste/references/kinds.md

@@ -47,7 +47,7 @@ Documentation, articles, reference pages, learning material. The reader arrived
 ## Kinds this file does not cover
 
 - **Transactional flows** such as checkout, sign-up and settings are read as application UI. Their distinctive rules, state coverage and error recovery, sit in the `ui` governance rules.
-- **Presentation surfaces** such as slide decks are drafted by `draft-slides`, which carries the deck's design rules. Take the layer ordering and the floor from the body and the rest from it.
+- **Presentation surfaces** such as slide decks are drafted by `make-deck`, which carries the deck's design rules. Take the layer ordering and the floor from the body and the rest from it.
 - **Terminal and text-mode surfaces** have no layout engine and their own color rules, stated where the writing surface is decided rather than here.
 
 A read naming any of the three above takes the body's rules and says it has no per-kind guidance, naming the surface that governs it. A read naming a kind this file does not list at all says so rather than borrowing the nearest section.

package/claude/skills/design-taste/references/preflight.md

@@ -101,5 +101,5 @@ Every word on the surface states what is true of it.
 
 ## Handover
 
-- [ ] The weakest thing on the surface is named out loud, per `draft-and-pick` Step 3, and fixed where naming it would embarrass the work
+- [ ] The weakest thing on the surface is named out loud, per `pick-by-eye` Step 3, and fixed where naming it would embarrass the work
 - [ ] The floor the `ui` governance rules carry has been applied, not assumed