@erclx/canon 5.31.0 → 5.33.0

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

@@ -1,53 +1,96 @@
 ---
 name: canon-cli
-description: Reference for what a canon verb does before you run it. Run `canon docs agents` for the full command catalog, `canon docs` for any other reference doc, and read this skill's own table for what a sync or install command overwrites, merges, or leaves untouched in a target project. Use when asked "which canon command do I run", "is there a doc for X", "will this overwrite my changes", or before running `canon tooling`, `canon standards`, `canon claude sync`, or `canon init`. Do NOT use to execute a sync, an install, or a docs lookup, only to know which command answers the question.
+description: Routes a job to the `canon` verb that does it, and warns which verbs can lose a project's edits before one runs. Use when asked "which canon command does X", "is there a verb for X", "which command tells me if X", "will this overwrite my changes", or before running `canon sync`, `canon gov sync`, `canon tooling sync`, `canon design sync`, `canon migrate`, or `canon indexes regen`. Do NOT use to execute a verb, only to pick one and know what it costs.
 metadata:
   family: answer
 ---
 
-# Toolkit CLI contract
+# Toolkit CLI router
 
-Consult before running an unfamiliar `canon` verb, before a sync or install, or when asked "will this overwrite my changes". This skill is reference only. It never runs a sync or an install.
+Consult to pick the `canon` verb for a job, and before running a verb that writes. This skill is reference only. It never runs a verb.
 
-## Verb catalog and reference docs
+## Find the verb
 
-- Run `canon docs agents` for the full command catalog and invocation contract, rather than guessing at a verb from its name.
-- Run `canon docs list` for every other reference doc, then `canon docs <topic>` by name.
-- State neither list here. Both read live off the CLI, and a copy in this body ships on a different cadence than the commands it names.
+- Each row below names a verb by its job. Subcommands and flags are not listed here, so read them where they are kept.
+- Run `canon <verb> --help` for a verb's subcommands and flags.
+- Run `canon docs agents` for the invocation contract behind every verb, and `canon docs list` for every other reference doc, then `canon docs <topic>` by name.
 
-## Overwrite contract
+## Project setup
 
-| Surface                                                                                       | Command              | Effect on existing files                                                    |
-| --------------------------------------------------------------------------------------------- | -------------------- | --------------------------------------------------------------------------- |
-| Golden configs                                                                                | `canon tooling sync` | Overwritten once `--write` is passed. Local edits are lost.                 |
-| Dictionary seeds (`.cspell/*.txt`)                                                            | `canon tooling sync` | Merged and sorted. Existing terms preserved.                                |
-| Other seeds (`cspell.json`, `.lintstagedrc`, base's `verify.yml` and PR template, state docs) | `canon tooling sync` | Copy-once. Dropped on first install, untouched after.                       |
-| Standards                                                                                     | none                 | Nothing installs. `canon standards <name>` reads and never writes.          |
-| Seed docs and `CLAUDE.md`                                                                     | `canon claude init`  | Skipped when present. Never overwritten.                                    |
-| Seed docs                                                                                     | `canon claude sync`  | Never touched. Only `.gitignore` is written.                                |
-| Stack references                                                                              | none                 | Nothing installs. `canon tooling reference <stack>` reads and never writes. |
-| `.gitignore`, deps, scripts                                                                   | any sync             | Additive. Existing entries preserved. Deps re-pin on major skew.            |
-| Generated `index.md`                                                                          | any sync or regen    | Rewritten from target state. Hand edits are lost.                           |
+| Job                                          | Verb            |
+| -------------------------------------------- | --------------- |
+| Bootstrap a project with toolkit domains     | `canon init`    |
+| Bring every installed domain current         | `canon sync`    |
+| Reinstall the CLI itself                     | `canon upgrade` |
+| Move a project off a retired name or layout  | `canon migrate` |
+| List the projects the toolkit installed into | `canon targets` |
 
-## What a tooling sync can overwrite
+## Domains
 
-A golden config is any file a stack ships under `configs/`, and the category is wider than its name suggests. It carries the phase-label gate workflow, the web stack's CI workflow, the git hooks, the end-to-end harness, the shell scripts under `scripts/`, and the editor settings, alongside the linters and compilers a reader expects. A stack inherits its parent's configs, so syncing `astro` also writes everything `web` and `base` hold.
+| Job                                                             | Verb              |
+| --------------------------------------------------------------- | ----------------- |
+| Install or sync governance rules                                | `canon gov`       |
+| Read an authoring standard by name                              | `canon standards` |
+| 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`      |
 
-No list of those paths ships in this body, since a copy would go stale on a different cadence than the stacks. Run `canon tooling diff <stack> <target>` for the list resolved against a real target. It reports every path, writes nothing, and exits 1 when any differs. A binary older than that verb answers the same question through `canon tooling sync <stack> <target> --check`, which names each file it would replace.
+## Author and render
 
-## Rules
+Each verb here has a skill that owns the job. Load the skill rather than driving the verb by hand.
 
-- `canon tooling sync` writes nothing until `--write` is passed. A headless run without it reports and exits 1, so a script that forgets the flag fails rather than silently skipping the sync.
-- Run `--check` first when the project carries local edits to a config the stack ships. The report names each file it would replace, which is the warning the user needs before the write.
-- An interactive run still prompts. `--write` skips the prompt, and `--check` refuses to write even with a TTY.
-- Seeds are user-owned. Dictionary `.txt` files merge and sort. Other seeds are copy-once, so re-seeding a structured file means deleting it and syncing again.
-- No command writes a standard into a project. A `.claude/standards/` folder from an older toolkit is inert, and deleting it costs nothing.
-- For section-level customizations of a seed doc, use the `seed-sync` skill, not `canon ... sync`. It diffs per section and preserves edits.
+| 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`      |
+| Serve a directory and print the link         | `canon serve`       | none                        |
+| Record a running app                         | `canon demo`        | `canon:draft-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` |
+| Open a learning workspace                    | `canon teach`       | `canon:teach-workspace`     |
+| Work on the local canvas                     | `canon canvas`      | `canon:canvas-board`        |
 
-## CLAUDE.md
+## Session and ship
 
-- `CLAUDE.md` is a copy-once seed. No `canon` sync command ever updates it. Reconcile it with the `seed-sync` skill, which diffs the preamble and each section and preserves customizations by default.
+| Job                                            | Verb              |
+| ---------------------------------------------- | ----------------- |
+| Read and close tasks on the board              | `canon tasks`     |
+| Read and answer intake folders                 | `canon intake`    |
+| Validate, size, and move session records       | `canon records`   |
+| Resolve live sessions to a worktree and branch | `canon sessions`  |
+| Reclaim worktrees whose branches merged        | `canon worktrees` |
+| Read a pull request                            | `canon pr`        |
+| File toolkit feedback as an issue              | `canon feedback`  |
+
+## Reports
+
+| Job                                       | Verb             |
+| ----------------------------------------- | ---------------- |
+| Scan the tree for credentials             | `canon secrets`  |
+| Read the dependency set for advisories    | `canon deps`     |
+| Check a changed set against the label map | `canon labels`   |
+| Measure comment density                   | `canon comments` |
+| Report context folder health              | `canon context`  |
+| Check markdown against the standards      | `canon markdown` |
+| Count files, extensions, and lines        | `canon census`   |
+
+## Verbs that can lose your edits
+
+Read the doc each line names before running one of these. `canon docs install-and-sync` covers the governance and design verbs, `canon docs sync` covers tooling, `canon docs indexes` covers regeneration, and `canon docs migrate` covers the migrate verbs. Run the `--check` or `--dry-run` form first where the verb has one.
+
+- `canon sync` runs every installed domain's sync, so it carries each risk below.
+- `canon gov sync` replaces a rule you edited and deletes a rule the toolkit retired, edited or not.
+- `canon tooling sync --write` replaces every golden config a stack ships. Seeds are copy-once and dictionaries merge. Nothing writes without the flag. See `canon docs sync`.
+- `canon design sync` replaces the shipped design files and leaves `.claude/design/project/` alone.
+- `canon migrate --write` rewrites files that cite a retired name or layout. It reports and writes nothing without the flag. See `canon docs migrate`.
+- `canon indexes regen` rewrites each generated `index.md` from the folder's current state, so a hand edit there is lost. See `canon docs indexes`.
+
+No command writes a standard into a project, so `canon standards` is safe to run. `CLAUDE.md` and the other seed docs are copy-once, and no sync updates them. Merge those by hand against the toolkit copy.
 
 ## Source of truth
 
-- Full semantics live in the toolkit's own context entries. This skill is the target-session summary. When they disagree, the context docs win.
+- `canon docs install-and-sync` states what each install and sync verb writes, refuses, or leaves alone. `canon docs indexes` and `canon docs migrate` state the same for their verbs. When a doc and this skill disagree, the doc wins.

package/claude/skills/canon-feedback/REQUIREMENT.md

@@ -19,7 +19,7 @@ The last failure is the session's own effort. Asked to report, a session starts
 - Name the surface and its type, since the toolkit routes on that rather than on the symptom
 - Write the stated fallback for a field the session cannot fill, so an empty field reads as absent rather than as unreported
 - Open a GitHub issue on the toolkit repo through the CLI so the report lands where triage reads it, and print the returned URL on its own line
-- Say which file and which reason when the issue call fails and the report falls back to a local folder, since a silent fallback leaves it where nothing reads it
+- Surface the block and the reason when the issue call fails, since a failure that prints nothing leaves the report where nothing reads it
 - Hold a report the operator marks sensitive, since the issue is public
 - Fall back to printing the block when the CLI is absent, so the report still exists
 

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

@@ -1,6 +1,6 @@
 ---
 name: canon-feedback
-description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback --github`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
+description: Format a report about something broken, missing, or off in canon and open it as a GitHub issue on the toolkit repo via `canon feedback`, where the toolkit's triage reads it. Use when asked to "send this to the toolkit", "report this to canon", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate canon surfaces.
 metadata:
   family: upkeep
 ---
@@ -73,10 +73,10 @@ command -v canon >/dev/null 2>&1
 
 The destination is a public GitHub issue on the toolkit repo, so the report leaves the machine. Hold it and ask when the operator has marked it sensitive, and never send it on a guess.
 
-Before the pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the composed block, phase-label half included. Nothing else checks what reaches the remote, so this scan is the only gate.
+Before the pipe below, run the scan in `${CLAUDE_SKILL_DIR}/../git-pr/references/publish.md` against the composed block, phase-label half included. Nothing else checks what reaches the remote, so this scan is the only gate.
 
 ```bash
-cat <<'EOF' | canon feedback --github
+cat <<'EOF' | canon feedback
 ## Toolkit feedback
 
 ...
@@ -85,20 +85,17 @@ EOF
 
 The CLI opens a GitHub issue on the toolkit repo, labeled `feedback` and each domain label the surface type names, such as `skills` for a plugin skill, and prints the issue URL, which this skill reports back on its own line. It needs `gh` authenticated. `git-issue` is not the route, since it files on the current repository and this report belongs on the toolkit's.
 
-From a toolkit checkout, a call that produces no URL falls back to `.canon/feedback/feedback-<slug>-<ts>.md` and prints the reason on stderr. Say so in the same reply, naming the file and the reason, since a silent fallback leaves the report where nothing reads it. A target project has no such folder, so a failed call there prints the block in chat.
+Read the outcome off stdout, never off the exit code, since a shell wrapper can flatten it. Stdout takes one of three shapes:
+
+- A line opening with `https://` is the filed issue. Report the URL.
+- A block opening with `## Toolkit feedback` is a failed call. The reason is on stderr, so show the block in chat with it and `📋 Paste this into an issue at https://github.com/erclx/canon/issues/new`.
+- Empty stdout is a refusal. Step 3 says how to repair it from stderr.
 
 If `canon` is not on PATH, fall back: print the block in chat and tell the user `📋 Copy the block above into a toolkit-repo session.`
 
 ## Step 3: read what the CLI said back
 
-The command exits 1 and writes nothing on a report it refuses, so a non-zero run is a block to repair rather than a report that shipped. Two refusals reach this step:
-
-- A named missing field. Add that heading with a real value or its stated fallback, then re-run. Do not report the defect as filed.
-- `gh` absent or its call failed. The stderr names which, since installing `gh` and fixing an authenticated call are different repairs. Fall back to printing the block in chat.
-
-A `--github` run from a toolkit checkout whose GitHub call fails warns and writes local scratch instead, which is a report filed on the other route rather than a failure.
-
-## Notes
+A report that was not filed reads one of two ways on stdout, and stderr carries the reason in both:
 
-- `canon feedback` resolves the toolkit root from the running `canon` binary's source location. If multiple toolkit clones exist on the machine, the first `canon` on PATH wins.
-- The local folder is a fallback for a failed issue call, and nothing reads it on a schedule. The issue is the durable record.
+- Empty stdout, with a named missing field on stderr. Add that heading with a real value or its stated fallback, then re-run. Do not report the defect as filed.
+- The block on stdout, with `gh` absent or its call failed on stderr. The stderr names which, since installing `gh` and fixing an authenticated call are different repairs. Show the block in chat with the reason and the paste line from Step 2.

package/claude/skills/canon-feedback-triage/REQUIREMENT.md

@@ -1,32 +1,30 @@
 ---
 name: canon-feedback-triage
-description: Why the feedback queue is read from GitHub rather than local scratch, and why triage routes instead of implementing
+description: Why the feedback queue is read from GitHub rather than local scratch, and why triage files measured items instead of routing or implementing
 ---
 
 # Canon feedback triage requirement
 
 ## Gap
 
-Without this skill, the feedback queue fills and nothing drains it. Reports arrive from projects the toolkit never sees, and a queue nobody reads on a schedule is the same as no queue. The local review folder looks like the right place to read, and it is the wrong one, because that content is per-machine session scratch that any cleanup removes.
+Without this skill, the feedback queue fills and nothing drains it. Reports arrive from projects the toolkit never sees, and a queue nobody reads on a schedule is the same as no queue. A local folder looks like the right place to read, and it is the wrong one, because that content is per-machine session scratch that any cleanup removes.
 
-Triage fails three ways once it starts. Unrelated issues get batched into one branch, so review has to judge several unconnected changes at once and can approve none of them cleanly. An issue needing a plan gets implemented inline from a paragraph of description, which skips the step where scope is argued. And an issue whose report contradicts itself gets a guess rather than a question, so the fix addresses a defect nobody confirmed.
-
-The queue also fails to drain even when the work ships. A fix merged with no link back leaves its issue open, and the next triage re-reads work already done.
+Triage fails three ways once it starts. An issue gets routed straight to a fix from a paragraph of description, which skips the step where scope is argued and the operator's call. An issue whose report contradicts itself gets a guess rather than a question, so the fix addresses a defect nobody confirmed. And the same issue gets filed twice, because two passes cannot see that the board already carries it.
 
 ## Must
 
 - Read the durable queue rather than local session scratch
-- Classify each issue in a fixed order and stop at the first match, stating the class and its one-line reason before routing
-- Route to the skills that own planning, branch naming, and the pull request body rather than restating them
-- Keep one issue to one branch and one pull request
-- Link a fix to its issue so merge closes it, and preserve that link when the body is regenerated
-- Ask on the issue when the report is unreadable, then move on rather than blocking the batch
+- File one measured item per open issue into an intake folder, headed so an answer finds its issue
+- File every open issue the board does not already carry, and name each skipped issue with its carrier
+- Measure each claim against the tree rather than carrying the issue's figures forward
+- Claim the folder through the CLI rather than picking an ordinal by hand
 
 ## Must not
 
-- Batch unrelated fixes into one branch
-- Implement a plan-worthy issue, which stops at the plan handed back to the user
-- Close an issue whose pull request has yet to merge
+- Post to the remote, whether a comment, a close, or a label
+- Implement a fix or write a plan, which the answered item routes to
+- Fill an answer slot, or read an empty one as agreement
+- Write outside the folder it claimed
 
 ## Guards
 
@@ -36,5 +34,6 @@ The queue also fails to drain even when the work ships. A fix merged with no lin
 ## Out of scope
 
 - Filing new feedback: `canon-feedback`
-- Writing the plan a plan-worthy issue needs: `plan-feature`
+- Answering the filed items: `plan-intake-answer`
+- Writing the plan a plan-worthy item needs: `plan-feature`
 - Triage of issues carrying any other label, which surface here by design only under the feedback label

package/claude/skills/canon-feedback-triage/SKILL.md

@@ -1,67 +1,86 @@
 ---
 name: canon-feedback-triage
-description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback`), or for general GitHub issue triage unrelated to toolkit feedback.
+description: Files every open GitHub issue labeled `feedback` on the toolkit repo into an intake folder as one measured item each, skipping any issue the board already carries. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `canon-feedback`), to answer the filed items (that is `plan-intake-answer`), or for general GitHub issue triage unrelated to toolkit feedback.
 metadata:
   family: upkeep
 ---
 
 # Canon feedback triage
 
-Consume the feedback queue that `canon feedback --github` fills. Turn an open `feedback` issue into a scoped fix or a plan, then link the issue so merge closes it.
+Consume the feedback queue that `canon feedback` fills. Each open `feedback` issue is measured against the tree and filed as one item for the operator, who answers it before anything is built.
 
-Run from the toolkit repo root. This skill reads GitHub issues, not local `.canon/review/` files. Those are ephemeral session scratch. The durable, cross-project queue is GitHub.
+The record is an ordinary intake folder at `.canon/intake/<nn>-feedback-triage/`. Read `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` before writing any file in it, since it holds the item format, the frontmatter, the index shape, and the answer contract this skill is bound by.
+
+Run from the toolkit repo root. This skill reads GitHub issues and writes only inside its claimed folder. It posts no comment, close, or label to GitHub.
 
 ## Guards
 
+- Resolve `.canon/tasks/` and `.canon/intake/` at the main worktree root, not `pwd`. Run `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside a git repo.
 - If `gh` is not on PATH, stop: `❌ gh CLI not found. Install it to read feedback issues.`
 - If `gh auth status` fails, stop: `❌ gh is not authenticated. Run gh auth login.`
 - If no open `feedback` issues exist, stop: `✅ No open feedback issues.`
+- Never fill a `You:` slot, and never read an empty one as agreement. Answering runs through `plan-intake-answer` or the operator's own edit.
+- Branch on each `canon` record's `ok` and `reason` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero.
 
 ## Step 1: list the queue
 
-Fetch open feedback issues:
-
 ```bash
-gh issue list --label feedback --state open --json number,title,url --jq '.[] | "#\(.number)\t\(.title)\t\(.url)"'
+gh issue list --label feedback --state open --limit 1000 --json number,title,body,labels
 ```
 
-Print each as a numbered line with its issue number, title, and URL. Do not open bodies yet. Ask which to triage, and accept "all" to work them in order.
+Take every issue. An issue without the `feedback` label does not surface here by design.
 
-## Step 2: read and classify
+## Step 2: drop what the board already carries
 
-For each picked issue, read the body:
+An issue is carried when its number appears in a live or archived task's `Issue:` line under `.canon/tasks/`, or in an item heading of an existing `.canon/intake/` folder, written `(#NNN)`. Search both at the main root.
 
-```bash
-gh issue view <n> --json title,body,labels --jq '"\(.title)\n\n\(.body)"'
-```
+Set each carried issue aside with its carrier, a task path or a folder and item. Name every one in the overview, so a re-run while an earlier folder sits unanswered files nothing twice. When every issue is carried, stop: `✅ Every open feedback issue is already on the board.`
+
+## Step 3: claim the folder
+
+Run `canon records ordinal intake feedback-triage --claim --json` and take its `name`. The verb creates the folder in the same act, so two sessions opening at once never share one. Where the installed binary carries no such subcommand, report it and stop rather than picking an ordinal by hand.
 
-Classify against the toolkit's own surfaces. Score in this order and stop at the first match:
+## Step 4: measure each issue
 
-1. **Direct fix.** One surface, one file, no architectural choice. A typo, a stale reference, a one-line rule or doc correction, a single wording fix. Route straight to the edit.
-2. **Plan-worthy.** Multiple files, a new skill or rule, a behavior change, or a cross-surface move. Route to `plan-feature`.
-3. **Needs clarification.** The observed and expected behavior conflict or the surface is unnamed. Comment on the issue asking for the missing detail, then skip it.
+For each remaining issue, measure its claim against the tree during this pass. Grep for the construct its defect names and count the sites, check whether the behavior it asks for exists, and search the log for a commit or pull request that shipped it under another task. Never carry a figure from the issue forward as current, since it states what was true when it was filed.
 
-State the class and the one-line reason per issue before routing. Do not batch unrelated fixes into one branch.
+Classify each against the toolkit's own surfaces:
 
-When the fix encodes into a skill, standard, or seed, keep the principle and strip the reporting project's specifics: its filenames, frameworks, deploy targets, and label values. The issue describes one project, and the fix serves every project that installs the toolkit.
+- **Direct fix.** One surface, one file, no architectural choice. A typo, a stale reference, a one-line correction.
+- **Plan-worthy.** Multiple files, a new skill or rule, a behavior change, or a cross-surface move.
+- **Needs clarification.** The observed and expected behavior conflict or the surface is unnamed. The item asks the operator for the missing detail.
 
-## Step 3: route
+Strip the reporting project's specifics from the fix, being its filenames, frameworks, deploy targets, and label values. The issue describes one project, and the fix serves every project that installs the toolkit.
 
-- Direct fix: rename the branch to a conventional name (invoke `git-branch`), make the edit, then open the PR with `git-pr`.
-- Plan-worthy: invoke `plan-feature` with the issue body as the feature description. Let it write the plan and stop. Hand the plan slug back to the user. Do not implement.
-- Needs clarification: run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the question first, since it reaches the remote with nothing else checking it and this scan is the only gate. Then `gh issue comment <n> --body "<one question>"`, and move on.
+Name the commit the pass measured against in the overview.
 
-Match one issue to one branch and one PR. A single feedback issue is a single unit of work.
+## Step 5: write the items
 
-## Step 4: close-out
+Write one item per issue in the intake item format, one cluster file per domain the fix touches, numbered in read order. Head each item `### N. <defect> (#NNN)` so an answer finds its issue.
 
-Link every fix back to its issue so the queue drains on merge.
+- `Problem:` states what this pass measured, with the count, path, or commit behind it
+- `Fix:` states the class from Step 4 and the change it names
+- `Open:` reads `fix, plan, ask, or decline?` on every item
+- `Suggested:` opens with exactly one of those tokens, then the reason
+- `You:` ships empty
+
+Write `00-overview.md` last, per the intake standard, with the counts by token, an open-questions list linking each item, the commit measured against, and every issue skipped in Step 2 with its carrier. Where the pass runs out of context before the index, write `99-next-session.md` naming the last issue filed.
+
+## Output
+
+```plaintext
+📂 Opened .canon/intake/<nn>-feedback-triage/
+
+**Filed:** <N> issues across <N> clusters, measured against <sha>
+**Skipped:** <n> already carried
+**Suggested:** <n> fix, <n> plan, <n> ask, <n> decline
+
+Next: /canon:plan-intake-answer to answer the `You:` slots
+```
 
-- For a PR-backed fix, add a `Closes #<n>` line to the PR body so GitHub closes the issue on merge. When `git-pr` regenerates the body, keep that line.
-- For a fix that ships without a PR, run the scan in `${CLAUDE_SKILL_DIR}/../../standards/publish.md` against the close message first, since it reaches the remote with nothing else checking it and this scan is the only gate. Then close it directly: `gh issue close <n> --comment "Fixed in <commit or PR url>."`
-- For a plan-worthy route, leave the issue open. It closes when the resulting PR merges with its `Closes #<n>` line.
+An answered fix or plan item promotes through `task-board` with an `Issue: #NNN` line, and the shipping pull request's `Closes #NNN` drains the queue. Closing a declined issue on GitHub stays the operator's act.
 
 ## Notes
 
-- The `feedback` label is what `canon feedback --github` and the `toolkit-feedback.yml` issue form both apply. An issue without it does not surface here by design.
-- This skill routes, it does not reimplement. `plan-feature` owns planning, `git-pr` owns the PR body, `git-branch` owns the branch name. Do not duplicate their logic.
+- The `feedback` label is what `canon feedback` and the `toolkit-feedback.yml` issue form both apply.
+- This skill files and never reimplements. `plan-intake-answer` owns the answers and `task-board` owns the task a fix becomes.

package/claude/skills/{canvas → canvas-board}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: canvas
+name: canvas-board
 description: Scope boundary for driving the local design canvas, and the line between a drafted frame and the design it feeds
 ---
 
-# Canvas requirement
+# Canvas board requirement
 
 ## Gap
 
@@ -25,7 +25,7 @@ When the operator picks a frame, the session leaves the decision on the canvas a
 - Read the operator's selection when they point at something, and treat a stale element pick as unknown
 - Read a frame's inline styles before restyling it, and say which operator edits were kept and which dropped
 - Capture once per finished frame or page rather than after every edit
-- Carry a picked direction into the project's design document or wireframes
+- Carry a picked value into the project's design document, and leave a picked layout on the canvas for the plan that builds it
 
 ## Must not
 
@@ -43,7 +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 its own render path
-- Tracing reference images into design values, which is `sketch-design`
-- Writing the design document itself, which is `design-extract`
+- Drafting candidates for a taste decision and taking the pick, which `draft-and-pick` 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 → canvas-board}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: canvas
-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 trace reference images into design values, which is `sketch-design`, or to write the design document from code, which is `design-extract`.
+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`.
 metadata:
   family: decide
 ---
 
-# Canvas
+# Canvas board
 
-Drive the canvas the operator is looking at. A page is a folder of HTML frames and a frame is one file, so a session draws by writing files and the operator sees each write land in the browser. The content format is fixed by `${CLAUDE_SKILL_DIR}/../../standards/canvas.md`. Read it before writing a frame.
+Drive the canvas the operator is looking at. A page is a folder of HTML frames and a frame is one file, so a session draws by writing files and the operator sees each write land in the browser. The content format is fixed by `${CLAUDE_SKILL_DIR}/references/canvas.md`. Read it before writing a frame.
 
 Every verb below is `canon canvas`. Run `canon docs canvas` for the full verb reference, its records, and its refusals.
 
@@ -16,7 +16,7 @@ Every verb below is `canon canvas`. Run `canon docs canvas` for the full verb re
 - If `canon` is not on PATH, stop: `❌ canon CLI not found.`
 - If `canon canvas --help` reports no such command, stop: `❌ The installed canon carries no canvas command. Update the CLI and re-run.`
 - Write no frame before the canvas is serving and the shell has loaded. A frame nobody can see is a draft reported as delivered.
-- Never present a frame as the project's design. The canvas is a drafting surface and the project's design document or wireframes hold what was decided.
+- Never present a frame as the project's design. The canvas is a drafting surface and the project's design document holds what was decided.
 - Never promise the canvas survives a lost checkout. Its folder is gitignored and nothing backs it up.
 
 ## Step 1: start the canvas and confirm the shell
@@ -102,7 +102,7 @@ The operator restyles elements from the inspector, and each edit lands as inline
 
 When the operator picks a frame, the decision leaves the canvas.
 
-- Carry visual values, being color, type, spacing, and radius, into the project's design document, through the skill that owns it. Carry structure and layout into the project's wireframes.
+- Carry visual values, being color, type, spacing, and radius, into the project's design document, editing its sections in place under the `design.md` standard. Leave structure and layout on the canvas, and name the frame in the plan that builds it.
 - Name the frame the decision came from in the reply, and leave the frame on the canvas until the operator clears it.
 - Never cite a frame path from a tracked file. The folder is gitignored, so the citation resolves on this machine alone.
 
@@ -113,7 +113,7 @@ When the operator picks a frame, the decision leaves the canvas.
 Page:     <page>, <n> frames
 Selected: <page>/<frame>, element <index>, or none, or stale
 Capture:  <path of each capture written>
-Carried:  <the design document or wireframe the pick went to, or not yet>
+Carried:  <the design document the pick went to, the plan that cites the frame, or not yet>
 ```
 
 Write the canvas line's URL as a markdown link. Omit the capture line when nothing was captured and the carried line when no direction was picked. Emit every path from the project root.

package/{standards → claude/skills/canvas-board/references}/canvas.md

@@ -9,6 +9,17 @@ Applies to the canvas content under `.canon/canvas/`, where each page is a folde
 
 The folder is gitignored, so nothing in a repository checks its shape and nothing backs it up by default.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working canvas looks like](#what-a-working-canvas-looks-like)
+- [Pages](#pages)
+- [Frames](#frames)
+- [Layout](#layout)
+- [Tokens](#tokens)
+- [What a frame must not assume](#what-a-frame-must-not-assume)
+- [Template](#template)
+
 ## Scope
 
 Governs the canvas content under `.canon/canvas/`: page folder names, frame files, the `layout.json` shape, how tokens reach a frame, and what a frame must not assume about where it renders.
@@ -80,7 +91,7 @@ The keys below are the ones a reader parses. The frame names are placeholders.
 - Do not assume the theme. The canvas theme toggle is the operator's own state, and a capture shows each frame in its default theme.
 - Do not assume a network. Name only fonts the machine has, or ship the font beside the frame, since a capture refuses a frame naming a font it cannot find.
 - Do not assume a default font. Set `font-family` with an installed family first on an element the frame's text inherits from, since a capture checks the first family of the text it renders and the browser's default serif is absent from many machines.
-- Do not assume the frame is the source. A picked direction is carried into the project's design document or its wireframes, and the operator clears the frame once it has been carried.
+- Do not assume the frame is the source. A picked direction is carried into the project's design document or a plan, and the operator clears the frame once it has been carried.
 - Do not assume the canvas survives the checkout. The folder is gitignored, so a lost checkout loses every page in it.
 
 ## Template

package/{standards → claude/skills/canvas-board/references}/design.md

@@ -1,27 +1,35 @@
 ---
 title: Design reference
 description: Shape and content rules for canon/DESIGN.md
-paths:
-  - 'canon/DESIGN.md'
 ---
 
 # Design reference
 
 Applies to `canon/DESIGN.md`. Captures visual intent and the decisions behind how things look, not a style guide, component spec, or framework reference. Update when a visual decision is made or a rule changes.
 
+## Contents
+
+- [Scope](#scope)
+- [What goes in](#what-goes-in)
+- [What does not go in](#what-does-not-go-in)
+- [Format](#format)
+- [Prose budget](#prose-budget)
+- [The uncertainty tag](#the-uncertainty-tag)
+- [Sections](#sections)
+- [Template](#template)
+
 ## Scope
 
 Governs the visual-intent document at `canon/DESIGN.md`: tokens described as intent, layout constraints, and the omissions that keep visual scope closed.
 
 Does not govern:
 
-- Screen layout, on-screen copy, and interaction intent: `wireframes.md`
 - Per-domain implementation narrative: `context.md`
 
 ## What goes in
 
 - A token's exact value, anchored to the surface it was read from and tagged per `## The uncertainty tag` when unconfirmed. Fall back to intent language ("mid gray, muted text") only where no source exists yet to anchor from.
-- Layout constraints and sizing rules not obvious from wireframes
+- Layout constraints and sizing rules not obvious from the tokens and the code
 - Visual rules a developer could get wrong without guidance
 - Non-obvious omissions ("no motion", "no custom icons") that prevent scope creep
 
@@ -34,7 +42,7 @@ Does not govern:
 ## Format
 
 - Use tables for token systems, one row per token. Write every other rule as a short bullet, one decision per line, within `## Prose budget`.
-- Plain English over technical notation. If a section could be removed and the developer would still build correctly from wireframes and code alone, remove it.
+- Plain English over technical notation. If a section could be removed and the developer would still build correctly from the tokens and code alone, remove it.
 - Keep table headers and role names intact so the render tooling can parse the token tables.
 
 ## Prose budget

package/claude/skills/ci-workflow/REQUIREMENT.md

@@ -35,6 +35,5 @@ A cache keyed on a static string serves a stale browser or toolchain after a ver
 
 ## Out of scope
 
-- The shell scripts a job invokes: `bash-cli-script`
 - Secrets, environments, and deploy targets, which live in the repository settings rather than in the workflow this skill writes
 - CI systems other than GitHub Actions. The structure rules generalize and the file format does not, so a different system is a different skill rather than a flag on this one.