@erclx/canon 4.120.0 → 4.121.0

package/claude/skills/bash-script/references/prompts.md

@@ -0,0 +1,100 @@
+# Bash script prompts
+
+Interactive prompt templates for the `bash-script` skill, read only when the script prompts. Copy verbatim, alongside the colors and logging functions from `patterns.md`.
+
+Both prompts transition `◆` to `◇`, guard against non-TTY stdin with `[ -t 0 ]`, and write UI to stderr.
+
+```bash
+ask() {
+  local prompt_text=$1
+  local var_name=$2
+  local default_val=$3
+  local input=""
+  local char
+  local display_default=""
+  if [ -n "$default_val" ]; then
+    display_default=" (${default_val})"
+  fi
+  if [ ! -t 0 ]; then
+    log_error "${prompt_text} requires a TTY"
+  fi
+  echo -e "${GREY}│${NC}" >&2
+  echo -ne "${GREEN}◆${NC} ${prompt_text}${display_default} " >&2
+  while IFS= read -r -s -n1 char; do
+    if [[ $char == $'\x1b' ]]; then
+      read -rsn2 -t 0.001 _ || true
+      echo -ne "\r\033[K" >&2
+      echo -e "${GREY}◇${NC} ${prompt_text} ${RED}Cancelled${NC}" >&2
+      exit 1
+    elif [[ $char == $'\x7f' || $char == $'\x08' ]]; then
+      if [ -n "$input" ]; then
+        input="${input%?}"
+        echo -ne "\b \b" >&2
+      fi
+    elif [[ -z "$char" ]]; then
+      break
+    else
+      input+="$char"
+      echo -n "$char" >&2
+    fi
+  done
+  [ -z "$input" ] && input="$default_val"
+  echo -ne "\r\033[K" >&2
+  echo -e "${GREY}◇${NC} ${prompt_text} ${WHITE}${input}${NC}" >&2
+  export "$var_name"="$input"
+}
+```
+
+```bash
+select_option() {
+  local prompt_text=$1
+  shift
+  local options=("$@")
+  local cur=0
+  local count=${#options[@]}
+
+  if [ ! -t 0 ]; then
+    log_error "${prompt_text} requires a TTY"
+  fi
+
+  echo -ne "${GREY}│${NC}\n${GREEN}◆${NC} ${prompt_text}\n" >&2
+
+  while true; do
+    for i in "${!options[@]}"; do
+      if [ "$i" -eq "$cur" ]; then
+        echo -e "${GREY}│${NC}  ${GREEN}❯ ${options[$i]}${NC}" >&2
+      else
+        echo -e "${GREY}│${NC}    ${GREY}${options[$i]}${NC}" >&2
+      fi
+    done
+
+    read -rsn1 key
+    case "$key" in
+      $'\x1b')
+        if read -rsn2 -t 0.001 key_seq; then
+          if [[ "$key_seq" == "[A" ]]; then cur=$(( (cur - 1 + count) % count )); fi
+          if [[ "$key_seq" == "[B" ]]; then cur=$(( (cur + 1) % count )); fi
+        else
+          echo -en "\033[$((count + 1))A\033[J" >&2
+          echo -e "\033[1A${GREY}│${NC}\n${GREY}◇${NC} ${prompt_text} ${RED}Cancelled${NC}" >&2
+          exit 1
+        fi
+        ;;
+      "k") cur=$(( (cur - 1 + count) % count ));;
+      "j") cur=$(( (cur + 1) % count ));;
+      "q")
+        echo -en "\033[$((count + 1))A\033[J" >&2
+        echo -e "\033[1A${GREY}│${NC}\n${GREY}◇${NC} ${prompt_text} ${RED}Cancelled${NC}" >&2
+        exit 1
+        ;;
+      "") break ;;
+    esac
+
+    echo -en "\033[${count}A" >&2
+  done
+
+  echo -en "\033[$((count + 1))A\033[J" >&2
+  echo -e "\033[1A${GREY}│${NC}\n${GREY}◇${NC} ${prompt_text} ${WHITE}${options[$cur]}${NC}" >&2
+  SELECTED_OPTION="${options[$cur]}"
+}
+```

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

@@ -9,7 +9,7 @@ Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/skill.md`: skill structure, skill types, frontmatter fields, invocation rules
 - `${CLAUDE_SKILL_DIR}/../../standards/skill-requirement.md`: what `REQUIREMENT.md` must answer, its sections, and its template
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for skill body text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for skill body text
 - The `write-human` skill: voice, rhythm, and sentence construction for skill body text
 
 ## Guards

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

@@ -7,7 +7,7 @@ description: Creates a new snippet file in `snippets/` or `.claude/snippets/`. U
 
 Creates one snippet file. Read these files in parallel:
 
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 - `${CLAUDE_SKILL_DIR}/../../standards/snippets.md`: authoring conventions, invocation channels, use patterns
 

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

@@ -7,7 +7,7 @@ description: Creates a new standard file in `standards/`. Use when asked to "cre
 
 Creates one standard file. Read these files in parallel:
 
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 - `${CLAUDE_SKILL_DIR}/../../standards/standard.md`: the meta-standard for shape, frontmatter, and structure
 

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

@@ -55,7 +55,7 @@ Use the returned content as the target shape. Keep every section heading and eve
 
 ## Step 4: fill the template
 
-Walk each section once. Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation and word choice throughout: no em dashes, no semicolons, no marketing buzzwords. Use commas or separate sentences instead.
+Walk each section once. Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation throughout: no em dashes, no semicolons. Use commas or separate sentences instead. Load the `write-human` skill for word choice, which keeps marketing words out.
 
 Mark any cell not traced to a source value by appending ` ? verify` inside the cell value, never as a trailing column. The cell stays inside the table shape: `| #ffffff ? verify |`. A trailing `| ? verify` after the row breaks the parser. A prose section takes its uncertainty inline instead, for example `Proposed 150ms ease-out, not yet confirmed.`, because a trailing tag on a sentence renders raw in the preview.
 

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

@@ -15,7 +15,7 @@ The instruction against that already existed. `draft-and-pick` Step 1 says to na
 
 The second half is the output itself. A model with no stated direction draws the population average of its training data, which produces interfaces that satisfy every craft rule and still read templated.
 
-Prose is already governed in two halves and design is governed in neither. Banned words ship as data a command reads, and the shapes no closed word set can match needed a skill of their own, because each is a pattern rather than a token. `standards/design.md` governs the shape of a project's design document and is silent on whether its values are any good.
+Prose is already governed in two halves and design is governed in neither. The character bans ship as data a command reads, and the shapes no closed word set can match needed a skill of their own, because each is a pattern rather than a token. `standards/design.md` governs the shape of a project's design document and is silent on whether its values are any good.
 
 Importing an external catalog wholesale fails on what those catalogs turn out to carry. The largest is 1,206 lines in one file, pinned to one framework, one styling library and one animation package, and it scopes itself out of dashboards, data tables and multi-step product UI. A second bans default fonts by name and prescribes a component library.
 
@@ -52,7 +52,7 @@ A rule failing any of the four is recorded as considered and declined rather tha
 
 - Name a framework, a styling library, an animation package, a component library or an icon set as a default. A rule that survives only inside one stack is not a taste rule.
 - Ship a frozen corpus of palettes, font pairings or product examples. A copy becomes a file some sync reconciles forever, and a traced reference is current by construction where a frozen one is not.
-- Restate the banned words, characters or spellings, which `markdown.md` states and `canon markdown audit` gates from package data
+- Restate the banned characters, which `markdown.md` states and `canon markdown audit` gates from package data
 - Express intensity as a numeric scale. A session picks a middle value and reports compliance, which satisfies the rule and decides nothing.
 - Claim the reported failure is closed. Nothing measures whether a round follows these rules, so this skill states them and the measurement is owed separately.
 - Duplicate a rule a surface already states for itself, such as slide layout or terminal color, where pointing at that surface is the whole of the correct answer

package/claude/skills/docs-sync/SKILL.md

@@ -7,7 +7,7 @@ description: Rewrites stale `README.md` and `docs/*.md` sections based on change
 
 Read these files in parallel:
 
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 - `${CLAUDE_SKILL_DIR}/../../standards/readme.md`: README structure, required sections, and content rules
 - `${CLAUDE_SKILL_DIR}/../../standards/docs.md`: the reader a page under `docs/` serves, its frontmatter, structure, and what it links out rather than carrying

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

@@ -12,7 +12,7 @@ A project the surface move has not reached keeps its context folder under `.clau
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/context.md`: the three questions an entry must answer, its frontmatter, required and expected sections, and what stays out of it
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 ## Guards

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

@@ -10,7 +10,7 @@ Drafts one brand-new `docs/*.md` page end to end: read the standard, decide wher
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/docs.md`: the reader a page serves, its frontmatter, structure, and what it links out to rather than restates
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 ## Guards

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

@@ -18,7 +18,7 @@ Read these in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/figures.md`: when a figure earns its place, the render-first policy, wrapping and captioning, and the color and accessibility rules
 - `${CLAUDE_SKILL_DIR}/../../standards/mermaid.md`: direction and layout, node and edge budgets, the accessibility fields, and how a render is verified, for the Mermaid path
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words and formatting for the caption prose
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: formatting for the caption prose
 - The `write-human` skill: voice and rhythm for the caption prose
 
 ## Step 2: does it earn its place

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

@@ -10,7 +10,7 @@ Drafts a project's `README.md` end to end: read the standard, detect the project
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/readme.md`: voice, structure, required and optional sections, badge selection, and what to link out to rather than carry. Voice is claimed here for a repository-root README, and `write-human` yields it there while keeping rhythm, density, and the machine-tell catalog everywhere, root README included.
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: rhythm, density, and sentence construction for all generated text
 
 ## Guards

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

@@ -10,7 +10,7 @@ Drafts one brand-new wiki reference page end to end: read the standard, settle p
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/wiki.md`: the two placement tests, the frontmatter contract, the naming convention, the sourcing rule, and the page template
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 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 body states the rule once and the standard stays the one owner of the path.

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

@@ -12,7 +12,7 @@ A project the surface move has not reached keeps its wireframes folder under `.c
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md`: the four questions a wireframe must answer, its frontmatter, the regions list and states table, the exclusions section, the Transcription-wireframes branch, and what moves to a context entry instead
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for the prose around the fences
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for the prose around the fences
 - The `write-human` skill: voice, rhythm, and sentence construction for the prose around the fences
 
 This skill stays fully independent of `docs-fold`'s wireframe coverage sweep, which only ever writes a bare `TODO` stub for a surface a diff touched and reports drift against one a wireframe already covers. Neither the stub nor the drift check is a draft, and this skill never reads or writes through that mechanism.

package/claude/skills/git-issue/SKILL.md

@@ -12,7 +12,7 @@ Format an issue from session context following the issue standard, then file it
 Read these in parallel:
 
 - `${CLAUDE_SKILL_DIR}/references/issue.md`: issue title, labels, body sections, and banned phrases
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 Then gather repo context in parallel:

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

@@ -9,7 +9,7 @@ Does not govern:
 - Pull request title and body: the pull request standard
 - Whether a phase label may appear in issue text: the versioning standard
 - Voice, rhythm, and sentence construction in issue prose: the `write-human` skill
-- Punctuation, formatting, and banned words in issue prose: the markdown standard
+- Punctuation and formatting in issue prose: the markdown standard
 
 ## Title
 

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

@@ -12,7 +12,7 @@ Read these files in parallel:
 - `${CLAUDE_SKILL_DIR}/../../standards/branch.md`: branch format, valid types, and constraints
 - `${CLAUDE_SKILL_DIR}/../../standards/pr.md`: structure, rules, and banned phrases
 - `${CLAUDE_SKILL_DIR}/references/labels.md`: label map format, matching, and the missing-label warning. Skip when the project has no `canon/config/pr-labels.toml` and no `.claude/canon/pr-labels.toml`.
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 - `${CLAUDE_SKILL_DIR}/../../standards/versioning.md`: phase label vs semver discipline
 

package/claude/skills/git-stage/SKILL.md

@@ -8,7 +8,7 @@ description: Groups staged files by concern and generates one conventional commi
 Read these files in parallel:
 
 - `${CLAUDE_SKILL_DIR}/../../standards/commit.md`: format, types, scopes, and constraints
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting for all generated text
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting for all generated text
 - The `write-human` skill: voice, rhythm, and sentence construction for all generated text
 
 ## Context

package/claude/skills/memory-capture/SKILL.md

@@ -27,7 +27,7 @@ Read in parallel, skipping any that do not exist:
 - `CLAUDE.md`: the project's write location and any rule it states over the folder
 - `.canon/memory/index.md`: existing index, to avoid duplicates
 - `canon/context/index.md`: the domain catalog Step 3 routes against, read under `.claude/` instead in a project the surface move has not reached
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: banned words, punctuation, and formatting applied to memory file bodies
+- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting applied to memory file bodies
 - The `write-human` skill: voice, rhythm, and sentence construction applied to memory file bodies
 
 ## Step 2: classify candidates

package/claude/skills/restate-plainly/REQUIREMENT.md

@@ -38,4 +38,4 @@ A restatement also fails in a way a rewrite does not. A run that compresses by d
 - Drafting or revising a passage, which is `write-human` on a markdown edit
 - Measuring cadence in finished output, which `canon markdown audit` reports from package data
 - Rewriting a document into a file, which is a proposal against the source rather than a restatement of it
-- The banned words, characters, and spellings, which `markdown.md` states and the audit gates
+- The banned characters, which `markdown.md` states and the audit gates

package/claude/skills/review-address/SKILL.md

@@ -107,8 +107,9 @@ the write and the post. Note any `.claude/` docs refreshed as a result of the
 fixes.
 
 The reply is a rendered-for-human GitHub surface, so load the `write-human`
-skill for voice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for
-the banned words, and keep each mapping to a line or two.
+skill for voice and word choice, follow
+`${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation, and keep each
+mapping to a line or two.
 
 Open the body with the `## Review response` heading so it anchors as a section
 distinct from human threads and stays subordinate to the `## Review` heading the
@@ -244,7 +245,7 @@ Do not merge. Hand back to the orchestrator for re-review.
 
 ## Post-review findings
 
-Not everything worth reaching the reviewing session surfaces inside the numbered flow above. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for the banned words, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting with `canon labels scan --body-file .canon/tmp/pr/reply/reply-<number>.md`.
+Not everything worth reaching the reviewing session surfaces inside the numbered flow above. A worker that settled a risk, filed a follow-up, or found something else worth reporting after Step 7 already closed the review posts it directly rather than waiting on a review pass that has nothing left to trigger it. Write the body the way Step 6 writes a reply: load `write-human` for voice and word choice, follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation, and run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan before posting with `canon labels scan --body-file .canon/tmp/pr/reply/reply-<number>.md`.
 
 Open with `## Post-review findings` rather than `## Review response`, since nothing on the thread is being answered. `review-pr` states the full heading set this belongs to and routes it the same as a response: `role-orchestrator`'s poll picks it up and sends the reviewing session back for a pass. Close the body with `🤖 Addressed by Claude Code` on its own line, matching the reply's footer.
 

package/claude/skills/review-branch/REQUIREMENT.md

@@ -15,6 +15,7 @@ Without this skill, a branch ships on the confidence of the session that wrote i
 - Resolve the base ref once, preferring the remote over local `main`, and reuse it in the guard and the read
 - Say when the baseline is unusable and name the narrowed scope, rather than letting a clean summary read as a clean branch
 - Flag only what will cause incorrect behavior or break a documented rule
+- Apply `canon:review-craft`'s axes and evidence bar, rendered output included, rather than carrying an axis list of its own
 - Grade every finding, since the caller gates on the counts rather than on the prose
 - Write the report to disk under a branch-derived slug, so what the ship step reads outlives the session
 

package/claude/skills/review-branch/SKILL.md

@@ -59,14 +59,13 @@ Read each file from the changed file list. Skip deleted files. Run reads in para
 
 ## Step 4: review and persist
 
+Invoke `canon:review-craft` before reading the diff for findings, whatever the diff's size. It carries what to look for and the evidence bar, rendered output included, and this step carries no axis list of its own to fall back on. Report it rather than proceeding silently when the skill does not resolve.
+
 Review the full diff and changed file contents for:
 
-1. Bugs and edge cases
-2. Error handling gaps
-3. Logic flaws that will cause problems when the code is extended
-4. Security issues relevant to the project context
-5. Violations of rules from `.claude/rules/` that apply to the changed files
-6. When the diff touches a file this project ships to a target holding none of its own history: a repository-relative path, a phase label naming a gitignored board, a same-repository pull request or commit reference, or a layout, stack, or config-path claim true of this checkout but stated as if it were general
+1. Every axis `canon:review-craft` states, held to its evidence bar
+2. Violations of rules from `.claude/rules/` that apply to the changed files
+3. When the diff touches a file this project ships to a target holding none of its own history: a repository-relative path, a phase label naming a gitignored board, a same-repository pull request or commit reference, or a layout, stack, or config-path claim true of this checkout but stated as if it were general
 
 Use `CLAUDE.md`, `canon/REQUIREMENTS.md`, `canon/ARCHITECTURE.md`, and the auto-loaded `.claude/rules/` as project context to inform what is intentional vs problematic. Do not fix, rewrite, or suggest refactors outside the scope of a finding.
 

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

@@ -0,0 +1,43 @@
+---
+name: review-craft
+description: Why every review needs one stated set of axes and an evidence bar, and where that judgment stops short of the procedures that run a review
+---
+
+# Review craft requirement
+
+## Gap
+
+Without this skill, what a review looks for is seven words copied between two procedure bodies: bugs, edge cases, error handling, logic flaws, security. Nothing states design and scope, what breaks in a consumer outside the diff, developer experience, executable prose, a doc the change made stale, which security classes to check, or how much evidence a finding needs before it is reported.
+
+The miss is measured. On a seeded branch that deleted a dirty-tree guard while the README two headings below the edited hunk still promised it, two runs of the local review found the removed guard and called the README clean. Security was not the gap: both runs caught the planted injection and the unpinned package under the one-word axis.
+
+Rendered output is the larger hole. `git-pr` posts an `## Evidence` comment through `canon pr evidence`, carrying base and head screenshots and a checklist a reviewer ticks. The pull request review named that heading only in its heading set, and no step opened an image. On a seeded pull request whose narrow head screenshot shows the navigation running off the edge while a ticked box claims it collapses, the review filed the finding off the stylesheet diff and said it had not rendered the page. On a styling change with no screenshot at all, on a project whose trunk keeps them, it did not mention the absence.
+
+## Must
+
+- Open with the one fact the change's safety rests on, read on a ladder of asserted, pointed at, walked through, tested, and reproduced
+- State the axes in reading order: design and scope, correctness and edge cases, what breaks outside the diff, tests, security, rendered output, developer experience and operations, and executable prose
+- Require every consumer of a changed contract to be listed and checked, and every doc the diff touches to be read whole for a claim the change made false
+- State a design finding as a concrete cost, so it survives the procedure's filter against subjective suggestions
+- Carry the evidence bar: confirm against the file at the reviewed head, quote a cited rule, name the breaking input, and drop what a gate owns or what rests on unread state
+- Carry security as classes with an exclusion list, in a reference loaded when the diff reaches one
+- Open the evidence images on a rendered change through `git show` at the row's own sha, never through the embedded address, within a stated read budget
+- Test each ticked checklist box against an opened image, and name a ticked box no image covers as untested
+- Flag a rendered change that carries no screenshot, as a finding where the trunk already keeps them and as a question elsewhere
+- Read the posted comment rather than running `canon pr evidence`, which compares the local checkout's diff and names the wrong change from a reviewing session not on the branch
+
+## Must not
+
+- State a severity or a posting rule. `review-pr` and `review-branch` each own a ladder, and the two define `should-fix` differently.
+- Restate the high-signal filter either procedure carries
+- Name a repository-specific capture layout, width list, or folder. The evidence marker and `canon/wireframes/` are target contracts, and everything else is the project's.
+- Carry a per-surface reference beyond security and rendered output before a measured miss asks for one
+
+## Out of scope
+
+- Running a review, reading the diff, posting findings, and grading them: `review-branch` and `review-pr`
+- The high-signal filter and the severity ladder, which stay in each procedure body
+- Which layer a test belongs at: `test-craft`
+- Capturing screenshots or writing the visual checklist: `canon pr evidence` and `ui-checklist`
+- A dispatched reviewer session that loads this skill, which a later trial decides
+- A deliberate full security audit: the built-in `security-review`

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

@@ -0,0 +1,50 @@
+---
+name: review-craft
+description: Carries what a code review looks for and how much evidence a finding needs, from design and scope through breakage outside the diff, developer experience, executable prose, stale docs, security classes, and rendered output checked against the screenshots a pull request carries. Use when reviewing a change, when a review procedure loads it for its axes, or when asked "what should a review look for", "what does a good review check", "how sure do I need to be before flagging this", or "did the review look at the screenshots". Do NOT use to run a review, post it, or grade its findings, which is `review-branch` for local work and `review-pr` for a pull request, and do NOT use for a deliberate full security audit, which is the built-in `security-review`.
+---
+
+# Review craft
+
+A review with no stated axes reads the changed lines for bugs and stops there. What breaks in a consumer the diff never opened, a doc the change made false a section away from its hunk, or a screenshot showing the opposite of what a ticked box claims all go unread. This skill carries the judgment: what to look for, in what order, and how sure to be before calling it a finding.
+
+The procedure that loaded this skill owns everything else: which files to read, the filter that decides what gets reported, the severity ladder, and where the report goes. Nothing here grades a finding or posts one.
+
+## Open with the one fact the change's safety rests on
+
+Name the single claim that, if false, makes this change unsafe to merge, then say how far the change proves it. Read the proof on this ladder, weakest first:
+
+- **Asserted.** The description or a comment says so.
+- **Pointed at.** It names the code or the test that would show it.
+- **Walked through.** The reasoning traces the path and holds.
+- **Tested.** A test in the diff fails if the claim is false.
+- **Reproduced.** Someone ran it and recorded what happened.
+
+A risky claim resting on assertion alone is where the review spends its reading. A trivial one needs no more than asserted.
+
+## Read the axes in this order
+
+An axis whose condition the diff meets is not optional. When axis 5 or 6 names a reference and its condition holds, read that reference before moving to the next axis, however clear the diff looks without it.
+
+1. **Design and scope.** Does the change do one thing, is it more complex than the problem needs, and does it build what nobody asked for? State a design finding as a concrete cost, such as a second path nobody calls, a layer with one caller, or a flag no caller passes, never as a preference.
+2. **Correctness and edge cases.** The empty input, the boundary value, the refused call, the second run, the concurrent run, and the error path a caller actually meets.
+3. **What breaks outside the diff.** List every consumer of a changed contract, whether a function signature, a file format, a flag, an output shape, or a heading another tool matches, and check the change against each one. Then list each behavior the diff removes or changes, such as a guard, a refusal, a default, or an output, and search every doc the diff touches, in full rather than at the hunk, for a sentence still promising the old behavior. File that sentence as a finding against the doc, quoting it and naming its section, since the doc is what goes wrong for the next reader.
+4. **Tests.** Hand each test the change adds or edits to `canon:test-craft` and its final filter. Report it rather than proceeding silently when that skill does not resolve.
+5. **Security.** Read `${CLAUDE_SKILL_DIR}/references/security.md` when the diff runs a command, writes a file, handles input from outside the process, touches a secret, adds a dependency, or changes a default a consumer installs.
+6. **Rendered output.** Read `${CLAUDE_SKILL_DIR}/references/ui.md` when the diff touches a file that paints, such as markup, a stylesheet, a component, a template, or a design token, or when the pull request carries an evidence comment. A finding read off a stylesheet diff says what the author changed, and only the screenshot says what a user sees, so the reference opens the images and checks whether any exist.
+7. **Developer experience and operations.** Ports, hooks, scripts, config, and scaffold defaults a consumer installs. A new required step nobody documented, a default that fails on a clean machine, or a hook that slows every commit is a finding even when the code is correct.
+8. **Executable prose.** A skill body, a rule, or a prompt is instructions a model runs. Read it the way you read code: a step that races another, a precondition it never states, a branch with no exit, and two instructions that contradict each other are bugs.
+
+## Hold every finding to the evidence bar
+
+- Confirm each finding against the file at the reviewed head before grading it. A finding read off the diff alone misses the guard three lines outside the hunk.
+- Quote the rule when a finding cites one, with its file, so the author can check the claim without finding the rule first.
+- Name the input or the state that breaks, not only the line. A finding with no failing case is a suspicion.
+- Drop what a linter, a type checker, or a gate in the project already owns. The gate reports it with more certainty than a review can.
+- Drop a finding resting on state you did not read. Say what you would need to read instead.
+
+## What this delegates
+
+- Which files a pass reads, the high-signal filter, the severity ladder, and where findings go: `review-branch` for local work and `review-pr` for a pull request
+- Which layer a test belongs at and what makes it good: `test-craft`
+- Writing what a reviewer should look at on a rendered change: `ui-checklist`
+- A deliberate full security audit of a codebase: the built-in `security-review`

package/claude/skills/review-craft/references/security.md

@@ -0,0 +1,21 @@
+# Security classes
+
+Read each class against the diff. A class the diff does not reach is skipped, not reported as clean. Name the input that reaches the sink and the path it takes, since a class named with no path is a suspicion rather than a finding.
+
+## Classes to check
+
+- **Shell and command injection.** A value from an argument, an environment variable, a file, or a network response reaching a shell: through `eval`, an unquoted expansion, a string built into a command, or a subprocess call that takes a single command string. Quoting the variable at the call site is the fix to look for.
+- **Path traversal in a file write.** A path built from outside input and written without being resolved and checked against the directory it must stay inside. A `..` segment, an absolute path, and a symlink inside the target each escape a naive join.
+- **Secrets and personal data leaving the process.** A token, a key, a password, or personal data reaching a log line, an error message, a session transcript, a published page, a pull request comment, or a sync to a remote. Check what a debug line prints and what a verbose flag adds.
+- **Supply chain.** One-shot package execution of an unpinned version, which runs whatever the registry serves that day. A new dependency, and what its install scripts run. A lockfile that changes without a manifest change.
+- **Time of check to time of use on a file write.** An existence or permission check followed by a write to the same path in a later step, and a predictable name in a shared temporary directory. Another process can swap the path in between.
+- **Insecure defaults a consumer installs.** A config, a scaffold, or a seed that turns a check off, opens a port on every interface, grants a broad permission, or ships a placeholder secret. The consumer inherits the default without reading it.
+
+## Excluded
+
+Do not report these as security findings. Raise one as a correctness finding only when the diff shows a concrete failing case.
+
+- Denial of service, rate limiting, and resource exhaustion
+- Generic input validation with no proven impact
+- Open redirects
+- A theoretical attack needing access the attacker would already need to have

package/claude/skills/review-craft/references/ui.md

@@ -0,0 +1,72 @@
+# Rendered output
+
+A screenshot is the one artifact that shows what a change paints. Reading the markup and the styles tells you what the author meant, and the image tells you what happened. Open the images rather than inferring them from the diff.
+
+## When it applies
+
+The diff touches a file that paints: markup, a stylesheet, a component or template, a design token file, a rendered document source, or a path a `canon/wireframes/` surface file names. Or the pull request carries an evidence comment, whatever the diff touches.
+
+## First, check that a screenshot exists
+
+Run this before any other section, since a pass that finds nothing to open otherwise reads the stylesheet instead and reports as if it had looked. Read its answer before composing any report or body, never in the same batch as the write, since what it decides is a finding the report has to carry.
+
+Read `gh pr view <number> --json comments,headRefOid` and take the comment whose body carries a `<!-- pr-evidence: head=<sha> -->` marker. Match the marker, never the first line, since the body opens with a `**Preview:**` line when the project has a preview address.
+
+Flag the change as shipping no screenshot when it paints and the pull request carries no marked comment, carries one with no `## Evidence` section, or carries only a checklist posted alone. Then decide how to raise it by whether the project keeps captures, which is the same test `canon pr evidence` applies:
+
+```bash
+git ls-tree -r --name-only <base> | grep -E '(^|/)evidence/.*\.(png|jpe?g|gif|webp|avif|svg)$' | head -1
+```
+
+- A path prints: the project keeps captures and this change skipped them. File it as a finding against the pull request.
+- Nothing prints: raise it as a question with no severity, since a project with no capture harness would otherwise take the flag on every styling change.
+
+Stop reading this reference once the flag is raised, since there is nothing to open. Otherwise continue with the comment in hand.
+
+## Reading the comment
+
+Compare the marker's head with `headRefOid`. When it trails, the images describe an older head. Name which later commits touched a painting file, and read the images as evidence about that older head only.
+
+## Opening the images
+
+Each row embeds `github.com/<repo>/blob/<sha>/<path>?raw=true`. A session cannot fetch that address from a private repository, so never follow it and never report an image you did not open. Fetch the head instead:
+
+```bash
+git fetch -q origin pull/<number>/head
+mkdir -p .canon/tmp/pr/review/evidence/<number>
+git show <sha>:<path> > .canon/tmp/pr/review/evidence/<number>/<side>-<name>.png
+```
+
+Take the sha from the row, so the base and head sides are exactly what the comment shows. Then open each file with the file-reading tool. A `*(new)*` base cell has no before image.
+
+## How many to open
+
+Open at most 12 images per pass, filled in this order:
+
+1. Every image a ticked checklist box or the `Seen at:` line names
+2. The head side of each state at its narrowest and widest captured width, in one theme
+3. The base side, only for a state whose head image looks wrong or whose diff was meant to change appearance
+
+A second theme earns a read only when the diff touches a color token. Name the states left unopened on one line, as a note rather than a finding, so the reader knows what the pass did not see.
+
+## Comparing
+
+Read `canon/wireframes/index.md` and open only the surface files the evidence states map to. Check each opened image for the layout, the order of regions, and the behavior at that width the surface file states. Check `canon/DESIGN.md` for the tokens the image makes visible: color, type scale, spacing, and component rules.
+
+Read the width and theme from whatever the image path carries, and fix no width list, since which widths matter belongs to the project. Skip a comparison silently when the project has no wireframe or design file.
+
+A finding names the wireframe or design-file line the image breaks, never a taste.
+
+## The checklist
+
+The `## What to look at` block between the `pr-checklist` markers is the author's claim about what was verified.
+
+- Test each ticked box against an opened image showing the state and width it names. Flag a box whose image contradicts it, quoting the box.
+- A ticked box no image covers is untested rather than confirmed, and the finding says so.
+- Read the `**Widths:**` block's `Seen at:` line against the widths the images carry.
+- Test only the rows the current comment shows. A box ticked on an earlier head can describe images the comment no longer carries.
+- Leave unchecked boxes to the procedure's own read of the description.
+
+## With no pull request
+
+A local review has no comment to read. Read each changed image under an `evidence/` path segment from the working tree, and its base side with `git show <base>:<path>`. Read the checklist handoff at `.canon/tmp/handoff/ui-checklist/<slug>.md` at the main worktree root when it exists. A painting change with no changed evidence image takes the flag from the first section, decided by the same `git ls-tree` test.

package/claude/skills/review-pr/REQUIREMENT.md

@@ -22,6 +22,7 @@ Scoping a later pass off GitHub's review stamp skipped real work. On 2026-09-07
 - Detect the pass from the thread rather than taking it from the caller, matching the heading for equality so a neighboring comment cannot be read as a prior pass
 - Scope a later pass to the commits added since the prior one, once that commit is confirmed to still reach the head
 - Apply the integration, contract, and consumer lenses a self-review structurally cannot
+- Apply `canon:review-craft`'s axes and evidence bar, rendered output included, rather than carrying an axis list of its own
 - Read each test the branch added or changed against `canon:test-craft`'s final filter, scoped to those files and never the suite
 - Post the closing pass even with nothing to report, since a review left unanswered reads as one nobody closed
 - State a withdrawal or a regrade on the thread with the fact that settled it, since a finding dropped in silence reads the same as one nobody answered

package/claude/skills/review-pr/SKILL.md

@@ -63,7 +63,7 @@ Read `${CLAUDE_SKILL_DIR}/references/scope.md` for finding the commit and verdic
 
 ## Step 3: review
 
-Review the diff and files for the same axes as `review-branch` (bugs, edge cases, error handling, logic flaws, security, rule violations, checkout assumptions in a shipped file), then add the three lenses a self-review structurally cannot apply:
+Invoke `canon:review-craft` with the skill tool now, and read nothing for findings until it has loaded, whatever the diff's size. It carries what to look for and how much evidence a finding needs, rendered output included, and this step carries no axis list of its own to fall back on. Read the diff and files against its axes. Add the two that stay here: rule violations, and checkout assumptions in a shipped file. Report it rather than proceeding silently when the skill does not resolve. Then add the three lenses a self-review structurally cannot apply:
 
 - Integration: does this fit the board's order, the shared wiring seam, and any sibling PR in flight?
 - Contract: does a contract downstream features depend on land correctly, and should the plan itself be questioned?

package/claude/skills/review-pr/references/post.md

@@ -13,7 +13,7 @@ Derive both segments from Step 1. Never pick a suffix by hand, and never reuse a
 
 When `<prior-oid>` from Step 2 equals `headRefOid`, the head repeats and the folder already holds `body-<number>-<short-sha>.md`. Add a third segment taking the id of the reply Step 2 resolved, giving `body-<number>-<short-sha>-r<comment-id>.md`, which is `<body-file>` on that path. That satisfies both prohibitions above rather than carving an exception into either. Step 2 already stopped the pass when that resolution came back empty, so reaching this line means the comment id is in hand.
 
-The comment is a rendered-for-human GitHub surface, so load the `write-human` skill for voice and follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for the banned words: cut editorializing, and keep every sentence load-bearing. Match this shape on a first pass:
+The comment is a rendered-for-human GitHub surface, so load the `write-human` skill for voice and word choice and follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` for punctuation: cut editorializing, and keep every sentence load-bearing. Match this shape on a first pass:
 
 ```markdown
 ## Review

package/claude/skills/role-planner/REQUIREMENT.md

@@ -41,7 +41,7 @@ confident merge order off a partial picture. Which rows collide, what merges
 before what, and whether a row should run at all stay with the controlling
 session, and no body states that boundary for the planning side.
 
-Nothing scans a plan for banned words either. `.gitignore` ignores
+Nothing scans a plan for ban hits either. `.gitignore` ignores
 `.canon/plans/`, and the audit's default path set is what git lists, so no gate
 ever opens one. Six ban hits landed across the four trial plans and three of the
 four carried at least one, caught only because the planner ran

package/claude/skills/standards-audit/SKILL.md

@@ -75,7 +75,7 @@ For each changed file, audit against every rule:
 - **Pattern rules**: grep the file for every token the standard bans. Grep is authoritative. Reading alone misses occurrences.
 - **Judgment rules**: check each rule in context against the standard that states it.
 
-Every changed markdown file gets the pattern pass, since `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` applies to all of them. Take the banned tokens from that standard at read time rather than from a list held here. It carries the banned words, the banned spellings, and the banned characters together, so one read covers every token this pass greps for.
+Every changed markdown file gets the pattern pass, since `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` applies to all of them. Take the banned tokens from that standard at read time rather than from a list held here. It carries the banned characters, so one read covers every token this pass greps for.
 
 ## Step 4: report