@erclx/canon 5.31.0 → 5.32.0

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

@@ -1,6 +1,6 @@
 ---
 name: draft-and-pick
-description: Drafts several candidates for a decision judged by looking, renders them side by side on one page, hands the operator the addresses, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write what to look at on a change already made, which is `ui-checklist`, to script a recording, which is `draft-screencast`, or to inspect a running app across many findings, which is `ux-walkthrough`.
+description: Drafts several candidates for a decision judged by looking, lays them out side by side as frames on one canvas page, hands the operator the address, takes the pick through the structured question surface, and loops on the pick until they stop. Use when asked to "draft some options", "show me a few versions", "try a few variations", "mock up alternatives", "give me candidates for X", or when a choice is taste rather than correctness. Do NOT use when the request already names the answer and asks for it to be built, which is `plan-feature`. Do NOT use to read source for roughness, which is `ux-audit`, to measure what a running interface costs to paint, which is `ux-measure`, to write what to look at on a change already made, which is `ui-checklist`, or to script a recording, which is `draft-screencast`.
 metadata:
   family: decide
 ---
@@ -9,6 +9,8 @@ metadata:
 
 Some decisions are settled by looking rather than by reasoning, and no draft is wrong until one is picked. Every step here puts several candidates in front of the operator and keeps the real surface untouched until they have chosen.
 
+The candidates live on the local design canvas, the surface `canon:canvas` drives. Every verb below is `canon canvas`, and `canon standards canvas` fixes the content format a frame takes. Read that standard before writing the first frame.
+
 ## Guards
 
 - If the request names one answer and asks for it to be built, stop: `❌ This names one answer, so there is nothing to pick between. Use /canon:plan-feature.`
@@ -19,25 +21,29 @@ Some decisions are settled by looking rather than by reasoning, and no draft is
 
 1. State the decision in one sentence, naming what changes between arms and what stays fixed.
 2. Emit the design read in the run's own output, in the form `design-taste` fixes. The layer comes from that skill's ordered catalog rather than from a word invented here, and the arms differ at it rather than somewhere cheaper to change. A run emitting no read has not decided what it is drafting, and a missing line is visible where an unstated layer is not.
-3. Derive a kebab slug from that sentence. Call the folder every file this run writes to `<dest>` below. `<dest>` is `.canon/tmp/<slug>/`, a nested `<slug>/` folder rather than a flat `<slug>-<file>.md`, which is the shape every temporary write in this project takes. Running inside a live `plan-groundwork` track is the one exception: `<dest>` is the track's own `evidence/<slug>/` instead, since a candidate render is evidence the track's decision file cites rather than spike input.
+3. Derive a kebab slug from that sentence. The first round's canvas page takes `<slug>` as its name, and Step 5 names each later round `<slug>-2`, `<slug>-3`, and so on. Inside a live `plan-groundwork` track, the run's renders land in the track's own `evidence/<slug>/renders/`, since a candidate render is evidence the track's decision file cites rather than spike input. Everywhere else they land in session scratch.
 4. Write one arm per candidate, each carrying an id, a label, and what the arm costs. An arm with no stated cost is not an option.
 5. Make the current state arm `0`, so the baseline is a candidate rather than an absence. A decision with nothing shipped yet says so and starts at arm `1`.
 6. Stop at three to five arms. Two is a comparison the operator can hold in prose, and past five the pick stops being a look and becomes a sort.
 
-## Step 2: author the candidate set as one page
+## Step 2: draft the arms as frames on one canvas page
+
+Every arm of a round sits as one frame on one canvas page, side by side. The comparison the operator judges is that page, never a set of separate images handed over to compare from memory.
+
+1. Start the canvas the way `canon:canvas` Step 1 states, unless this run already has: read `canon canvas list --json`, start `canon canvas serve --json` in the background unless the operator named an address that already answers, and fetch the `url` the record carries to check the shell's body holds a `<script` tag. Note whether this run started the server, since Step 6 stops only a server this run started. A refused serve or a blank shell stops the run, reported with its `reason`. A run with no canvas cannot draft, and no file stands in for one.
+2. Add the round's page with `canon canvas page add <page> --json` and record its name on the run's own list of pages it added. A name `canvas list` already shows belongs to somebody else, so take the next free suffix rather than writing into it.
+3. Add each arm as a frame with `canon canvas frame add <page> arm-<id> --width <px> --height <px> --json`. Name every frame `arm-<id>`, since Step 6's archive keeps those names and its readers key on them. Set the width the arm is judged at. A frame renders at its own layout width on the canvas and in a capture alike, so a decision about layout reads off the frame itself and needs no device toolbar.
+4. Write each arm's whole document to the `path` the add verb reported. From a linked worktree, take the heredoc route `canon:canvas` Step 3 gives for a main-root write.
+5. Lay the frames out in one row, in arm order, with `canon canvas frame move <page> arm-<id> --x <px> --y <px> --json`.
 
-Write every arm side by side on one self-contained HTML page at `<dest>/candidates.html`, and write each arm again as its own self-contained whole-page file at `<dest>/arms/arm-<id>.html`. Clear `<dest>/arms/` first on every pass through this step, including from Step 5's loop, so a file left behind by a wider earlier round never survives into a narrower one.
+### What every frame carries
 
-- One page for the pick, never a set of separate images handed to the operator to compare from memory. The comparison they judge is `candidates.html`, which Step 3 renders and Step 4 asks about. The per-arm files exist only for Step 6's archival capture, once the pick is made, and only the last pass through this step is what Step 6 finds there.
-- Wrap each arm's markup in the same class on both files, chosen once per run and reused everywhere, so one selector addresses an arm on the combined page and on its own standalone file alike.
-- Label each arm on the page with its id and its cost, so the render carries what the question will ask about.
-- Give the combined page one control that sets every arm's theme at once, beside whatever per-arm control the arms carry. A set spanning both themes cannot be compared, since the operator has to toggle each arm and hold the earlier ones in memory, which is the failure the single-page rule exists to prevent.
-- Set that theme so it survives the arm reading its own preference back. An arm that stores a theme and applies it on load will overwrite whatever the control set, which shows the control in one state and the arm in the other, and it passes a fresh browser profile because the stored value is not there yet.
-- Write `<dest>/frame.html` from `${CLAUDE_SKILL_DIR}/references/frame.html` where the run has more than one round, and hand over its address beside the combined page. Replace the template's one data token with the JSON object its comment describes, listing the combined page and every per-arm file of this round and each earlier one, with each `src` relative to the frame and `themeKey` set to the key the arms read their theme from. The frame is the route to every round from one address, with a page picker and the global theme toggle. Earlier rounds are sibling folders, so serve the parent folder with `canon serve <parent> --entry <dest-name>/frame.html` rather than `<dest>`, and keep the per-arm files as the fallback where nothing is served.
-- Hand over the per-arm file addresses beside the combined page where the declared layer is composition, layout or space, and say that an arm is judged at a width by opening its own file in the browser's device toolbar. The combined page cannot answer that question at all: every arm sits in a column there while the media queries answer to the whole window, so each one renders its widest layout in a narrow space no matter how the window is sized. Build no width control of your own, since the browser already has one.
+- Label each arm inside its frame with its id and its cost. The composite capture draws no captions, so the label is how the render carries what the question will ask about.
+- Theme every arm off the `data-theme` attribute the canvas sets on each frame's root, so the canvas theme toggle sets the whole set at once. A set spanning both themes cannot be compared, since the operator has to hold one arm in memory while reading the next.
+- Give no arm a script that stores a theme and reapplies it on load. That script overwrites the toggle, shows one frame in the other theme, and passes a fresh browser profile because the stored value is not there yet.
 - Take the live-app branch instead when the surface under decision is a running app: lift the rendered markup and link a copy of the built stylesheet rather than inlining, per `${CLAUDE_SKILL_DIR}/references/live-arms.md`.
-- On the default path, inline every style, script, and asset the page needs. The render reads the file off disk, so a page reaching for a build step or a network font renders without it and the arms differ by something nobody chose.
-- On the default path, name a real font first in the stack, one the machine has or the page embeds, such as the project's own family from its design tokens. A generic keyword such as `system-ui` or `sans-serif` is refused, since it resolves to a different font on each machine. The render refuses a page that would rewrap against a substitute rather than shipping a false comparison, so a page naming no font at all is refused on whatever the default resolves to.
+- On the default path, inline every style, script, and asset the frame needs. A frame resolves nothing outside its own page folder, so one reaching for a build step or a network font renders without it and the arms differ by something nobody chose.
+- On the default path, name a real font first in the stack, one the machine has or the frame embeds, such as the project's own family from its design tokens. A generic keyword such as `system-ui` or `sans-serif` is refused, since it resolves to a different font on each machine. The capture refuses a frame that would rewrap against a substitute rather than shipping a false comparison, so a frame naming no font at all is refused on whatever the default resolves to.
 
 ### What varies
 
@@ -47,19 +53,17 @@ Write every arm side by side on one self-contained HTML page at `<dest>/candidat
 
 ## Step 3: render and hand off
 
-Serve the page first, then render it and look at what came back. Every run serves, whatever the decision's layer, since a pick asked about a page the operator cannot open is a question nobody can answer.
+Render the page and look at what came back before handing anything over:
 
 ```bash
-canon serve <dest> --entry candidates.html --json
-canon capture <dest>/candidates.html --selector <element>
+canon canvas capture <page> --composite --json
 ```
 
-- Start `canon serve` in the background and read the link off its record, never assuming a port, since the printed link opens `index.html` without `--entry` and `<dest>` holds no such file. Keep each server up through the loop and note its process, since Step 5 re-enters this step and Step 6 stops them all. Serving needs no browser, so the link exists the moment the page is written.
-- Where Step 2 wrote a frame, hand over the frame's link instead, served from the parent folder as Step 2 says, and let no earlier round's `<dest>`-only link stand as the address a later round cites.
-- `--selector` has no default and the command refuses without it. Name the element wrapping the arms rather than `body`, which crops to whatever the page's own margins leave.
-- `canon capture` and `canon drive` both need a browser binary the toolkit does not install. When either refuses for that reason, report the refusal and name `bunx playwright install chromium` as the repair, stop every server Step 3 started, then stop rather than describing an arm nobody has seen.
-- Write the render inside the record that cites it wherever one exists, by pointing `--out` at `<dest>/renders/` rather than at a session scratch path. A pick taken from an image the record does not hold is a judgment nobody but this session can check, and the archival capture in Step 6 covers the final round alone.
-- Hand over the address rather than a description. Emit the link first on its own line, then the PNG path on its own line. A still answers how a thing looks and answers none of a hover response, a scroll-linked position, or a pace, which the served page does.
+- Point `--out` at `evidence/<slug>/renders/<page>.png` inside a live track, and leave it at its session-scratch default everywhere else. A pick taken from an image the track does not hold is a judgment nobody but this session can check, and the archive in Step 6 covers the picked round alone.
+- Read the PNG's `path` off the record. The composite shows every frame in its default theme, so look at the other theme on the live canvas where the arms carry two.
+- `canon canvas capture` needs a browser binary the toolkit does not install. When it refuses for that reason, report the refusal and name `bunx playwright install chromium` as the repair, stop the canvas server if this run started it, then stop rather than describing an arm nobody has seen.
+- A capture refusing on a font names the family it read off the frame's text. Take the repair `canon:canvas` Step 6 gives and capture again.
+- Hand over the address rather than a description. Emit the canvas link first on its own line, naming the page, then the PNG path on its own line. A still answers how a thing looks and answers none of a hover response, a scroll-linked position, or a pace, which the live frame does.
 - Never report a visual result you have not looked at. A claim about appearance with no render behind it is a guess.
 - Look to judge rather than to confirm. Reading the image back to check it rendered satisfies the rule above and still hands over weak work, so name the weakest thing on the page in a sentence. Where that sentence would embarrass the work, fix it and hand over the second version. Say the remaining weakness out loud either way, so the operator is not hunting for what you already know.
 
@@ -72,25 +76,28 @@ Put the choice to the operator through the structured question surface, since a
 - Rank the recommendation first and mark it `(Recommended)`.
 - Author the real arms only. The surface appends its own escapes for a free-text answer and for reopening the question, so writing either as an option ships a duplicate the tool rejects.
 - Take no pick on the operator's behalf when two arms are both defensible and the difference is taste. That call is theirs, and a silent one is the failure this skill exists to prevent.
+- Read `canon canvas selection --json` when the answer points at the canvas rather than naming an arm, such as "the selected one". Resolve it against the record's `page` as well as its `frame`, since every round names its arms `arm-<id>` from the same ids. A selected frame on the current round's page is the pick. One on an earlier round's page picks that round's arm, which is a revert, so name the round back to the operator before acting on it. A fresh element inside a picked frame is a correction Step 5 carries by its `index`.
+- Treat `selection: null`, a frame on a page this run did not add, or an element carrying `stale: true` as no answer, and ask again rather than guessing.
 
 ## Step 5: loop on the pick
 
-1. Write each iteration to its own `<dest>` rather than narrowing the previous one in place, suffixing the slug so the folders sort. An iteration overwritten is one a later pass cannot open, and the losing round is what stops a correction re-proposing something already rejected.
-2. Write fresh arms off the pick and return to Step 2 where the correction opens a new question. Revise the one arm where it does not. Each pass through Step 2 rewrites the frame with every earlier round's arms, since the list is baked in when the frame is written.
+1. Add each iteration as its own page, recorded on the run's list, rather than narrowing the previous page in place. A page overwritten is one a later pass cannot open, and the losing round is what stops a correction re-proposing something already rejected. The canvas page list reaches every round from one address.
+2. Write fresh arms off the pick and return to Step 2 where the correction opens a new question. Revise the one arm's frame where it does not.
 3. Re-render, hand off again, and take the next answer.
 4. Repeat until the operator says it is right. The loop stops on their word and on nothing else, so a run stopping because the arms stopped differing has stopped early.
-5. Hold the real surface untouched across every iteration. Nothing outside the run's own folders changes until the pick is final.
+5. Hold the real surface untouched across every iteration. Nothing outside the run's own canvas pages changes until the pick is final.
 
 ## Step 6: close
 
 1. Apply the winning arm to the real surface, in one change.
 2. Close out whatever document stated the decision as open, in the same change, naming the arm that won and the ones that stayed defensible. A pick that changes a surface and records nothing about why leaves the next reader to re-derive it from a diff. Skip this where nothing stated the decision.
-3. Batch-capture the final round's arm files, when `<dest>` is the scratch path: `canon capture <dest>/arms --selector <wrapper-class> --out <archive-dir>`, naming Step 2's chosen class. This is the directory-batch convention `draft-identity` Step 6 already uses.
-4. Resolve `<archive-dir>` as `.canon/picks/<slug>/` against the main worktree root, since shared session scratch resolves there rather than against a linked worktree this run happens to be building in. The capture is what keeps every arm past the pick, the losing ones included, as a durable revert record distinct from the live comparison page.
-5. Stop every background server Step 3 started, one per round where the loop re-entered it, then delete `<dest>` and every file inside it, when `<dest>` is the scratch path, now that every arm sits at the durable path above. A variant left behind there is a second design nobody maintains, and a server left running would serve a folder that no longer exists.
-6. Leave `<dest>` in place when it is a live track's `evidence/<slug>/`: `plan-groundwork`'s write scope treats evidence as durable rather than as scratch a session may delete, and the arms already sit at a durable path there. Stop every server there too.
-7. Report `<dest>` as still standing when the scratch-path delete is refused, naming the path for the operator to remove, rather than closing on a report the tree contradicts. The pick is applied either way, so the run has done its work and the folder is what outlives it.
-8. Report every surface that changed, each on its own line, name the arm that won by its id and its cost, and report the archival path from Step 3 where it ran.
+3. Capture the frames of the round the pick came from into the archive with `canon canvas capture <page> --out <archive-dir> --json`. That page is the final round's unless Step 4 resolved a revert to an earlier round, and archiving any other page would let item 5 delete the winning arm with nothing kept. Each frame lands as `arm-<id>.png`, which keeps every arm of that round past the pick, the losing ones included, as a durable revert record.
+4. Resolve `<archive-dir>` as `.canon/picks/<slug>/` against the main worktree root, since shared session scratch resolves there rather than against a linked worktree this run happens to be building in.
+5. Delete every page folder on the run's list from under the `content` folder `canon canvas list --json` reports, now that every arm sits at the durable path. Touch no page the run did not add, whatever its name. A variant left on the canvas is a second design nobody maintains.
+6. Stop the canvas server if this run started it, and leave one the operator started running.
+7. Leave the renders in place inside a live track's `evidence/<slug>/renders/`, since `plan-groundwork`'s write scope treats evidence as durable rather than as scratch a session may delete.
+8. Report each page still standing when its delete is refused, naming the path for the operator to remove, rather than closing on a report the tree contradicts. The pick is applied either way, so the run has done its work and the page is what outlives it.
+9. Report every surface that changed, each on its own line, name the arm that won by its id and its cost, and report the archive path.
 
 ## Reading a measurement
 
@@ -112,4 +119,5 @@ Cite these rather than restating them. A step reimplemented here rots against th
 - `design-taste` carries the layer catalog, the ordering, grey-boxing, and the defaults an arm should reach past
 - `write-human` carries the voice for any copy an arm puts in front of a reader
 - `git-stage`, `git-pr`, and `git-followup` carry the commits and the pull request
-- `review-branch` and `review-address` run the review pass
+- `review-pr` and `review-address` run the review pass
+- `canon:canvas` carries the canvas start-and-check sequence, the main-root write route for a frame, and the selection and capture refusals

package/claude/skills/draft-and-pick/references/live-arms.md

@@ -4,16 +4,16 @@ Read when the surface under decision is a running app rather than a static mocku
 
 ## Lift from the app
 
-- Dump the rendered markup of the surface under decision from the built page, after it has loaded, into a file under `<dest>`. Strip scripts from the dump.
-- Copy the built stylesheet and font files beside the page, at the path the dumped markup links them from, so a candidate page renders with the stylesheet the app ships. Every arm then differs from the shipped page only by what the arm names.
+- Dump the rendered markup of the surface under decision from the built page, after it has loaded, into a scratch file the run reads from. Strip scripts from the dump.
+- Copy the built stylesheet and font files into the canvas page folder, at the path each frame links them from, since a frame resolves only files inside its own page. Every arm then renders with the stylesheet the app ships and differs from the shipped page only by what the arm names.
 - Trim a large dump to the part the decision needs, and keep the wrapper classes intact so layout rules keyed to them still resolve.
-- Size each frame to the content width the decision names rather than the window width, since a container query reads the frame.
+- Set each frame's `--width` to the content width the decision names rather than the window width, since a container query reads the frame.
 - Write copy an arm introduces with `write-human`, and take every other word from the dump.
 
-## The page
+## The frames
 
-- Generate the page with a short script, one per round, so a shared change is one edit and a rerun.
-- Put a theme button on the page that flips the app's own theme switch on the root, rather than drawing each frame once per theme. Read `?arm=<id>&theme=<name>` to strip every other arm and the button for capture. Skip the button for an app that ships one theme.
-- Print each frame's measurement under it from a script in the page, so the numbers the operator reads are the browser's.
-- Write an index page linking one page per arm when an arm is a whole page or a route rather than a frame, with thumbnails copied beside it.
-- Name anything the preview cannot reproduce, such as an asset whose colors follow the browser rather than the page's theme button, rather than fixing the page around it.
+- Generate the frames with a short script, one per round, so a shared change is one edit and a rerun.
+- Leave the theme to the canvas toggle, which sets the app's own `data-theme` switch on every frame's root. Name the attribute the app's stylesheet reads where it is not `data-theme`, since the toggle sets that one alone.
+- Print each frame's measurement under it from a script in the frame, so the numbers the operator reads are the browser's.
+- Draw an arm that is a whole page or a route as one frame at that page's width, so it still sits beside the other arms on the round's page.
+- Name anything the canvas cannot reproduce, such as an asset whose colors follow the browser rather than the frame's theme, rather than fixing the frame around it.

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

@@ -20,16 +20,16 @@ The same procedure ran as five skills, one per kind, each restating the read, th
 - Confirm the resolved path, the kind's detections, and the full content with the user before writing, since placement and detection are judgment calls with no diff to preview them against
 - Regenerate the catalog of the folder the document landed in, where the kind keeps one, so the next run's collision check sees it
 - Draft a README from the template for every detected project type and combine them, never the closest one, since a project that is a CLI and a plugin owes its reader both
-- Carry each kind's own musts in its reference: the root check for context and wireframes, tier detection and the two modes for wireframes, both placement tests and a fetched source for the wiki, and project detection and rendered-value badges for the readme
+- Carry each kind's own musts in its reference: the root check for context, both placement tests and a fetched source for the wiki, and project detection and rendered-value badges for the readme
 
 ## Must not
 
 - Rewrite, refresh, or sync a document that already exists. A collision refuses toward the surface that owns the existing document.
 - Hand-edit an `index.md`. It regenerates from sibling frontmatter, and a hand edit is overwritten on the next regen.
 - Substitute recall for a failed fetch on the wiki kind, or invent an image or a placeholder path on the readme kind.
-- Build a companion render for a detected wireframe tier, or a hand-drawn diagram loop for a docs page.
+- Build a hand-drawn diagram loop for a docs page.
 - Widen the wiki's folder split to admit a subject its second placement test rejects. That is a change to the standard, argued there.
-- Assume this skill's routing needs no check. One description now covers five triggers, and a ranking over descriptions is a proxy for how Claude Code routes, so a review some months in should read real invocations back.
+- Assume this skill's routing needs no check. One description now covers four triggers, and a ranking over descriptions is a proxy for how Claude Code routes, so a review some months in should read real invocations back.
 
 ## Guards
 
@@ -40,7 +40,7 @@ The same procedure ran as five skills, one per kind, each restating the read, th
 ## Out of scope
 
 - Rewriting or syncing an existing `docs/` page or an authored README against a diff: `docs-sync`
-- Refreshing an existing context entry or wireframe, or stubbing a surface a diff touched: `context-fold`
-- Drafting a standard or a governance rule: `create-standard`, `create-rule`
+- Refreshing an existing context entry: `context-fold`
+- Drafting a governance rule: `create-rule`
 - Drawing a figure or a diagram for a document: `draft-figure`
 - Voice, rhythm, punctuation, and formatting in the drafted document: the `write-human` skill and the markdown standard

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

@@ -1,6 +1,6 @@
 ---
 name: draft-doc
-description: Drafts one brand-new project document from scratch against the standard for its kind, picking the kind from where it lands, a `docs/` page, a `canon/context/` entry, a `canon/wireframes/` surface, a wiki reference page, or a README.md. Checks the catalog for a name or topic collision, places it, confirms with the user, then writes. Use when asked to "write a new docs page for X", "write a context entry for X", "draft a wireframe for X", "write a wiki page for X", or "write a README" where none exists yet. Do NOT use to rewrite or sync an existing page or README against a diff, which is `docs-sync`, or to refresh a context entry or wireframe, which is `context-fold`.
+description: Drafts one brand-new project document from scratch against the standard for its kind, picking the kind from where it lands, a `docs/` page, a `canon/context/` entry, a wiki reference page, or a README.md. Checks the catalog for a name or topic collision, places it, confirms with the user, then writes. Use when asked to "write a new docs page for X", "write a context entry for X", "write a wiki page for X", or "write a README" where none exists yet. Do NOT use to rewrite or sync an existing page or README against a diff, which is `docs-sync`, or to refresh a context entry, which is `context-fold`.
 metadata:
   family: generate
 ---
@@ -13,15 +13,14 @@ Drafts one brand-new project document end to end: resolve its kind, read the sta
 
 Each kind has one standard and one reference. Load the reference for the resolved kind and no other, since every step below that differs by kind lives there.
 
-| Kind       | Lands at                                                 | Standard                                            | Reference                                      |
-| ---------- | -------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------- |
-| docs       | a page under `docs/`                                     | `${CLAUDE_SKILL_DIR}/../../standards/docs.md`       | `${CLAUDE_SKILL_DIR}/references/docs.md`       |
-| context    | an entry under `canon/context/`                          | `${CLAUDE_SKILL_DIR}/../../standards/context.md`    | `${CLAUDE_SKILL_DIR}/references/context.md`    |
-| wireframes | a surface under `canon/wireframes/`                      | `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md` | `${CLAUDE_SKILL_DIR}/references/wireframes.md` |
-| wiki       | a reference page on a subject owned outside this project | `${CLAUDE_SKILL_DIR}/../../standards/wiki.md`       | `${CLAUDE_SKILL_DIR}/references/wiki.md`       |
-| readme     | a `README.md`, at the root or in a folder                | `${CLAUDE_SKILL_DIR}/../../standards/readme.md`     | `${CLAUDE_SKILL_DIR}/references/readme.md`     |
+| Kind    | Lands at                                                 | Standard                                         | Reference                                     |
+| ------- | -------------------------------------------------------- | ------------------------------------------------ | --------------------------------------------- |
+| docs    | a page under `docs/`                                     | `${CLAUDE_SKILL_DIR}/../../standards/docs.md`    | `${CLAUDE_SKILL_DIR}/references/docs.md`      |
+| context | an entry under `canon/context/`                          | `${CLAUDE_SKILL_DIR}/../../standards/context.md` | `${CLAUDE_SKILL_DIR}/references/context.md`   |
+| wiki    | a reference page on a subject owned outside this project | `${CLAUDE_SKILL_DIR}/references/wiki.md`         | `${CLAUDE_SKILL_DIR}/references/wiki-kind.md` |
+| readme  | a `README.md`, at the root or in a folder                | `${CLAUDE_SKILL_DIR}/../../standards/readme.md`  | `${CLAUDE_SKILL_DIR}/references/readme.md`    |
 
-- Read the kind off the destination the request names: a path, a folder, or the document's own name, such as "a context entry" or "a wireframe".
+- Read the kind off the destination the request names: a path, a folder, or the document's own name, such as "a context entry" or "a wiki page".
 - Ask which kind when the request names no destination, offering the candidates the subject fits with the likeliest first. Never default to `docs/` without saying so, since a subject documented in the wrong surface is invisible to the session that looks for it in the right one.
 - If no subject is given for any kind but readme, stop: `❌ No subject given. Name what this document should cover.` A README covers the project or the folder it sits in, so its subject is the target path.
 
@@ -63,7 +62,7 @@ Settle the path and check the catalog for a collision the way the reference stat
 
 ### Preview
 
-**Kind:** `<docs | context | wireframes | wiki | readme>`
+**Kind:** `<docs | context | wiki | readme>`
 **Subject:** `<subject, or the target path for a README>`
 **Placement:** `<path>`
 <one line per preview field the reference names>

package/claude/skills/draft-doc/references/requirements.md

@@ -0,0 +1,61 @@
+---
+title: Requirements reference
+description: Shape and content rules for canon/REQUIREMENTS.md
+---
+
+# Requirements reference
+
+Applies to `canon/REQUIREMENTS.md`. Describes what the product does and why, not how it works. Update when scope changes, goals shift, or a non-goal is promoted to a feature.
+
+## Scope
+
+Governs the product-scope document at `canon/REQUIREMENTS.md`: goals and non-goals, with constraints and worldview when the project has them.
+
+Does not govern:
+
+- Execution order across the work the scope generates: `board.md`
+- Per-domain structure, narrative, and the rationale for a technical choice: `context.md`
+
+## What goes in
+
+- The problem being solved and for whom, as the record's opening line under the title
+- User-facing goals stated as outcomes, not implementation
+- Explicit non-goals that prevent feature creep. Mark deferred items "(deferred)" so they read as paused, not excluded. A non-goal resting on how an outside tool, an installer, or the model behaves may close with one `Revisit when <finding>.` sentence, and a non-goal resting on scope alone takes none.
+- Hard constraints that shape every decision, when the project has any
+
+## What does not go in
+
+- Implementation details, API names, or internal component references
+- Anything that describes how a feature is built rather than what it does
+- Measured results, such as scores, benchmark figures, or token counts. They move on every run and this file changes least. Name where the results live instead.
+- Content another canonical doc owns, such as the stack list, which the context entry of the domain it constrains holds, or the rules of this standard itself
+
+## Sections
+
+Require `## Goals` and `## Non-goals`. Add `## Constraints` when the project holds hard limits that shape every decision. Add `## Worldview` when the project holds beliefs that shape every decision, and keep a belief there only when it changes a decision, since a padded worldview turns into a second goals list. Drop a section rather than pad it with filler.
+
+## Length
+
+This file loads into every session, so its weight is paid before any work starts. Cap it by stating the clause `This record holds at most <n> words.` in the record itself, where a checker reads it and counts every word below the frontmatter. The cap is the record's own, so a record stating none is measured and never gated. The template and the seed a new project installs state it at 600, and a project loosens it by editing the number in its own record. At the cap, cut a goal or a constraint that no longer changes a decision before adding one.
+
+## Lifecycle
+
+The record may carry an optional `reviewed: YYYY-MM-DD` frontmatter field naming the day someone last read it whole for identity drift. Whoever finishes that review sets it as the review's last edit, and `canon records stale canonical` reads it to count the releases shipped since. A record with no field reads as never reviewed.
+
+Later scope arrives as a new section rather than as an extension of the goals. Name the section for what it delivers and state its entries as outcomes, the same way the goals are stated. Once every entry in it has shipped, delete the section, since version history keeps the old text and the document states the project as it stands. Nothing sequences a section into versions. Work reaches the board as discrete tasks under `tasks.md`, and `board.md` orders them by readiness, so a section here states what is wanted and never when it lands.
+
+## Template
+
+```markdown
+# Requirements
+
+[One line: the problem and who has it]
+
+This record holds at most 600 words.
+
+## Goals
+
+## Non-goals
+
+<!-- ## Constraints: include only when hard limits shape every decision -->
+```

package/claude/skills/draft-doc/references/wiki-kind.md

@@ -0,0 +1,53 @@
+---
+title: Wiki kind
+description: The root guard, both placement tests, catalog collision, sourcing from the owner, and vendor-folder regen for a brand-new wiki reference page, read by draft-doc once the request resolves to the wiki kind
+---
+
+# Wiki kind
+
+`draft-doc` reads this file when the request resolves to a wiki reference page. A page that already exists is edited against the same standard, never drafted a second time.
+
+The standard's `## Placement` section names the folder a page lands in and the vendor subfolder under it. Resolve both from the project root and call them `<wiki-root>` and `<vendor>` below, so the standard stays the one owner of the path.
+
+## Guards
+
+- If `<wiki-root>` does not resolve, say so and ask whether to create it before drafting. A project carrying no such folder has never taken the standard's placement rule, so creating it is a decision rather than a step.
+
+## Placement
+
+The standard sets two tests and a page has to pass both. Run them before drafting anything, since a page failing either is non-conforming however well it is written.
+
+- **Owned outside this repository.** A subject describing how this repository works fails. Refuse and offer the docs or context kind of this skill: `❌ <subject> is owned by this project, so it belongs in the docs surface or a context entry. Re-run draft-doc naming that destination.`
+- **Owned by the vendor the folder split covers.** The standard names one owner and one subfolder. A third-party tool or a vendor-neutral concept fails, however reference-like it reads. Refuse: `❌ <subject> is outside the wiki's folder split. Route it to the docs surface or a skill body rather than adding a second folder for it.`
+
+Do not widen the split to admit a subject. Adding a sibling folder is a change to the standard, argued there, rather than a placement this kind takes on its own.
+
+## Collision
+
+- Derive the page slug per the standard's `## Naming` section and check whether `<wiki-root>/<vendor>/<slug>.md` already exists. If it does, stop: `❌ <path> already covers this subject. Edit that page against the standard instead of drafting a second one.`
+- Read `<wiki-root>/<vendor>/index.md` and check every title and description it lists against the subject. Stop on a match: `❌ <path> already covers this subject under a different name. Edit that page instead.`
+
+## Source
+
+The standard forbids working from training knowledge, so the draft is built on a read rather than on recall.
+
+- Fetch current information through the `claude-code-guide` agent for any subject that agent covers. Its answer is the source the page is written from.
+- Reach a subject the agent does not cover through the owner's own published documentation. Invoke `canon:search-craft` with the skill tool before searching for it, since finding the owner's documentation is the field-and-authority step that skill carries, and report it rather than proceeding silently when the skill does not resolve.
+- Say the fetch failed and stop rather than substituting recall, even for a subject the session believes it knows. A page sourced from memory ships looking identical to one that was checked.
+- Close the intro with the `Source:` sentence the standard requires, linking the canonical page where one exists and naming the owner alone where the subject has no single URL.
+- Stamp the read date on a source revised without notice, as `read <date>`. A claim traced to an undated read cannot be checked against what was actually read.
+
+## Draft
+
+- Draft `title` and `description` frontmatter against the standard's contract, then the intro paragraph closing on `Source:` as a short orientation, then the lesson sections. Let the read of the source decide what is a lesson: keep a fact only when the source page does not state it, and leave reference detail to the source.
+- Write what the fetch returned rather than what the subject is assumed to do.
+- Answer one question per section and stop. A reader arrives to settle something specific rather than to read the page through.
+- Mark a claim the fetch left unsettled rather than smoothing over it. An unmarked gap reads as a checked fact.
+
+## Preview
+
+Add `**Source:** <owner, and the read it came from>`, and confirm the source with the path, since the standard states outright that a wiki file is not written unasked.
+
+## Write
+
+Regenerate `<wiki-root>/<vendor>`, naming the folder the page landed in rather than the root above it. The verb rewrites the `index.md` in the folder it is given and does not walk down, so regenerating at the root leaves the vendor catalog untouched. A page absent there is invisible to the next run's Collision step, which then drafts a second page on the same subject.

package/claude/skills/draft-doc/references/wiki.md

@@ -1,53 +1,73 @@
 ---
-title: Wiki kind
-description: The root guard, both placement tests, catalog collision, sourcing from the owner, and vendor-folder regen for a brand-new wiki reference page, read by draft-doc once the request resolves to the wiki kind
+title: Wiki reference
+description: Folder split, frontmatter, naming convention, and sourcing for a wiki reference page
 ---
 
-# Wiki kind
+# Wiki reference
 
-`draft-doc` reads this file when the request resolves to a wiki reference page. A page that already exists is edited against the same standard, never drafted a second time.
+Applies to each authored page in the `wiki` folder at the project root. Skip for `index.md` at any depth, which is a hand-maintained catalog rather than a reference page, and carries `subtitle` rather than `description`.
 
-The standard's `## Placement` section names the folder a page lands in and the vendor subfolder under it. Resolve both from the project root and call them `<wiki-root>` and `<vendor>` below, so the standard stays the one owner of the path.
+## Scope
 
-## Guards
+Governs each authored page in the `wiki` folder at the project root: which folder it belongs in, its frontmatter, its filename, and how it cites the subject it documents.
 
-- If `<wiki-root>` does not resolve, say so and ask whether to create it before drafting. A project carrying no such folder has never taken the standard's placement rule, so creating it is a decision rather than a step.
+Does not govern:
+
+- Voice, rhythm, sentence construction, and information density: the `write-human` skill
+- Headings, punctuation, word choice, and file references: `markdown.md`
+
+## What a working wiki page looks like
+
+A page works when a reader who has never opened it settles two things without asking anyone:
+
+- Which folder holds it, decided from the subject alone rather than from where it happened to get written
+- Where the content came from, so a claim can be checked against its owner rather than against this repository
+
+A page failing either is non-conforming even when it satisfies every shape rule below.
 
 ## Placement
 
-The standard sets two tests and a page has to pass both. Run them before drafting anything, since a page failing either is non-conforming however well it is written.
+- Write a page here only when its subject is owned outside this repository. Route anything about how this repository works to `docs/`, `canon/context/`, or a skill body instead.
+- File the page in the `claude` subfolder of the `wiki` folder. A subject Anthropic does not own, whether a third-party tool or a vendor-neutral concept, is out of scope for this folder split. Route it to `docs/` or a skill body instead of adding a second wiki folder for it.
+
+## Frontmatter
 
-- **Owned outside this repository.** A subject describing how this repository works fails. Refuse and offer the docs or context kind of this skill: `❌ <subject> is owned by this project, so it belongs in the docs surface or a context entry. Re-run draft-doc naming that destination.`
-- **Owned by the vendor the folder split covers.** The standard names one owner and one subfolder. A third-party tool or a vendor-neutral concept fails, however reference-like it reads. Refuse: `❌ <subject> is outside the wiki's folder split. Route it to the docs surface or a skill body rather than adding a second folder for it.`
+- `title` (required): sentence case, naming the subject
+- `description` (required): one line naming what the page covers
 
-Do not widen the split to admit a subject. Adding a sibling folder is a change to the standard, argued there, rather than a placement this kind takes on its own.
+## Naming
 
-## Collision
+- Name a page by its kebab subject alone. The vendor folder it sits in already names the vendor, so a prefix repeats the folder.
+- The `codebase-layout` skill carries the same rule for every folder in a project, beyond the wiki.
 
-- Derive the page slug per the standard's `## Naming` section and check whether `<wiki-root>/<vendor>/<slug>.md` already exists. If it does, stop: `❌ <path> already covers this subject. Edit that page against the standard instead of drafting a second one.`
-- Read `<wiki-root>/<vendor>/index.md` and check every title and description it lists against the subject. Stop on a match: `❌ <path> already covers this subject under a different name. Edit that page instead.`
+## Sourcing
 
-## Source
+- Close the intro paragraph with a `Source:` sentence naming the owner. Link the canonical page where one exists, and name the owner alone where the subject has no single URL.
+- Link a docs page in its fetchable form, `https://code.claude.com/docs/en/<page>.md`, so a session reads the live text rather than a copy.
+- Fetch current information through the `claude-code-guide` agent when the subject is Claude Code. Do not work from training knowledge.
+- Propose an addition or correction and wait for confirmation. Do not write to a wiki file unasked.
 
-The standard forbids working from training knowledge, so the draft is built on a read rather than on recall.
+## Shape
 
-- Fetch current information through the `claude-code-guide` agent for any subject that agent covers. Its answer is the source the page is written from.
-- Reach a subject the agent does not cover through the owner's own published documentation. Invoke `canon:search-craft` with the skill tool before searching for it, since finding the owner's documentation is the field-and-authority step that skill carries, and report it rather than proceeding silently when the skill does not resolve.
-- Say the fetch failed and stop rather than substituting recall, even for a subject the session believes it knows. A page sourced from memory ships looking identical to one that was checked.
-- Close the intro with the `Source:` sentence the standard requires, linking the canonical page where one exists and naming the owner alone where the subject has no single URL.
-- Stamp the read date on a source revised without notice, as `read <date>`. A claim traced to an undated read cannot be checked against what was actually read.
+- Keep a page thin: the `Source:` sentence, an orientation paragraph, and lesson sections. The source owns the reference detail and a paraphrase of it falls behind within days.
+- Apply the lesson test per section: keep a fact about the subject only when the source page does not state it. Such a fact is a gotcha this project hit, a constraint it relies on, or how it uses the feature.
+- Read the current source before keeping or cutting a section. A fact kept from memory is the drift this shape exists to prevent.
+- Send a session that wants reference detail to the source and fetch it live. The page answers orientation and lessons only.
+- Leave a page with no lessons as the source link and the orientation paragraph. A catalog routes a reader by page, so the stub stays.
 
-## Draft
+## Template
 
-- Draft `title` and `description` frontmatter against the standard's contract, then the intro paragraph closing on `Source:` as a short orientation, then the lesson sections. Let the read of the source decide what is a lesson: keep a fact only when the source page does not state it, and leave reference detail to the source.
-- Write what the fetch returned rather than what the subject is assumed to do.
-- Answer one question per section and stop. A reader arrives to settle something specific rather than to read the page through.
-- Mark a claim the fetch left unsettled rather than smoothing over it. An unmarked gap reads as a checked fact.
+```markdown
+---
+title: <Subject>
+description: <one line naming what this page covers>
+---
 
-## Preview
+# <Subject>
 
-Add `**Source:** <owner, and the read it came from>`, and confirm the source with the path, since the standard states outright that a wiki file is not written unasked.
+<What the subject is and why it matters, in a short orientation.> Source: <owner, with a link to the canonical page where one exists>.
 
-## Write
+## <Lesson>
 
-Regenerate `<wiki-root>/<vendor>`, naming the folder the page landed in rather than the root above it. The verb rewrites the `index.md` in the folder it is given and does not walk down, so regenerating at the root leaves the vendor catalog untouched. A page absent there is invisible to the next run's Collision step, which then drafts a second page on the same subject.
+<A fact the source page does not state.>
+```

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

@@ -53,7 +53,7 @@ The color failure is the quiet one. Mermaid's own theme writes literal hex value
 ## 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 wireframe or screen mockup: `draft-doc`
-- Design tokens and the visual system: `design-extract`
+- A UI screen mockup: `canvas`
+- Design tokens and the visual system: `canvas`, 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/draft-figure/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: draft-figure
-description: Drafts one hand-drawn figure for a document, deciding whether the subject is Mermaid-shaped, an architecture view, or needs freehand SVG, then draws it. Renders the Mermaid path through Mermaid's own hand-drawn look, reads the render back, and fixes what it exposes. Wraps every path in the figure standard's caption, color, and accessibility rules. Use when asked to "draw a figure", "add a hand-drawn diagram", "draft a figure for this doc", "draw this relationship as a figure", "draw the architecture", "diagram the system", or "show the components". Do NOT use for a UI wireframe, which is `draft-doc`, or for design tokens, which is `design-extract`.
+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`.
 metadata:
   family: generate
 ---
@@ -41,14 +41,14 @@ The standard states this as a render-first policy rather than a ban on any tool-
 
 Read the reference for the path Step 3 picked and follow it:
 
-- Architecture set: read `${CLAUDE_SKILL_DIR}/references/architecture-set.md` to shape the view, then `${CLAUDE_SKILL_DIR}/references/mermaid.md` to draw and render it. The architecture branch always renders and reads back. An unrendered fence is not a figure.
-- Mermaid path: read `${CLAUDE_SKILL_DIR}/references/mermaid.md`.
+- Architecture set: read `${CLAUDE_SKILL_DIR}/references/architecture-set.md` to shape the view, then `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` to draw and render it. The architecture branch always renders and reads back. An unrendered fence is not a figure.
+- 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.md` states before confirming.
+- 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.
 - When the destination is a rendered page, an HTML file a browser loads, the check that counts is the figure inside that page, which Step 6 captures once the figure is written, on either path. A markdown destination has no page to load, so the checks above are the whole check there.
 

package/claude/skills/draft-figure/references/architecture-set.md

@@ -5,7 +5,7 @@ description: The five architecture views with each one's question, source signal
 
 # 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.md` like any other graph-shaped figure. The destination stays the one the user named.
+`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.
 
 ## The five views
 
@@ -14,7 +14,7 @@ Draw the view the request names. Each answers one question and is drawn from one
 | View           | Question it answers                                     | Source signal                                     | Diagram type                         |
 | -------------- | ------------------------------------------------------- | ------------------------------------------------- | ------------------------------------ |
 | System context | Who uses the system, what it talks to, where it ends    | `canon/REQUIREMENTS.md`                           | `flowchart TB`                       |
-| Components     | The layered structure inside the boundary               | `canon/ARCHITECTURE.md`                           | `flowchart TB` with `subgraph` lanes |
+| Components     | The layered structure inside the boundary               | `canon/context/index.md` and the folder layout    | `flowchart TB` with `subgraph` lanes |
 | Request flow   | A request lifecycle, an agent loop, or an actor handoff | the entry point and its handlers                  | `sequenceDiagram`                    |
 | Data pipeline  | Retrieval, ranking, queues, or ETL                      | the pipeline's modules                            | `flowchart TB`                       |
 | Deployment     | Hosts, services, and infrastructure config              | deploy config, compose files, infrastructure code | `flowchart TB`                       |
@@ -25,8 +25,8 @@ Stay inside `flowchart` and `sequenceDiagram`. C4, state, ER, and class diagrams
 
 ## Sources
 
-- Read `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`, `CLAUDE.md`, and the language manifest (`package.json`, `pyproject.toml`, `Cargo.toml`) when present, plus the top-level folder layout through `ls`. Do not recurse speculatively.
-- When neither planning file exists and no folder structure names a boundary, stop: `❌ No source signal for <view>. Add canon/ARCHITECTURE.md or run inside a project folder.`
+- Read `canon/REQUIREMENTS.md`, `canon/context/index.md`, `CLAUDE.md`, and the language manifest (`package.json`, `pyproject.toml`, `Cargo.toml`) when present, plus the top-level folder layout through `ls`. Do not recurse speculatively.
+- When neither planning file exists and no folder structure names a boundary, stop: `❌ No source signal for <view>. Add canon/REQUIREMENTS.md or run inside a project folder.`
 - When the view came from a code scan rather than planning prose, open the caption with `Source: code.` and add `Fidelity is lower than prose-driven figures. Verify against the project's intent.`
 
 ## Caption and prose

package/claude/skills/draft-figure/references/hand-drawn.md

@@ -26,6 +26,6 @@ canon capture <destination> --selector figure --out .canon/tmp/figures/
 - Fix a clipped label, a misaligned shape, or an arrow that misses its target in the destination and capture again. Stop after two correction passes.
 - When the capture fails, keep the figure and name the skipped check in the output.
 
-A Mermaid figure bound for a rendered page takes this same capture, since its standalone PNG is measured in the renderer's own fonts and can read clean while the page clips it. A clipped group title there takes the scoped overflow style `${CLAUDE_SKILL_DIR}/references/mermaid.md` states.
+A Mermaid figure bound for a rendered page takes this same capture, since its standalone PNG is measured in the renderer's own fonts and can read clean while the page clips it. A clipped group title there takes the scoped overflow style `${CLAUDE_SKILL_DIR}/references/mermaid-path.md` states.
 
 A markdown destination has no page to load, so the read of the markup, or of the standalone render on the Mermaid path, is the whole check there.