@erclx/canon 5.45.0 → 5.46.0

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

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

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

@@ -7,44 +7,28 @@ description: Why a session changing what a caller can see needs stated rules on
 
 ## Gap
 
-Without this skill, a session changing a surface a caller depends on has nothing in front of it about what that caller can see or how a change lands without breaking it. It works for the one caller it opened, renames a field in place, returns whatever record it had in hand, and nothing in the toolkit answers before the change ships.
+A session changing a surface a caller depends on has nothing in front of it about what that caller can see or how a change lands without breaking it. It works for the one caller it opened, renames a field in place, and returns whatever record it held.
 
-The absence is measured across the shipped corpus. No folder under `claude/skills/` matches `api`, `interface`, or `contract`, and no file across `claude/` and `governance/` carries `hyrum` or a form of `idempotent`. The only related lines are the two error bullets in the core code rule, which state that errors are structured and hide internals and say nothing about exposure, versioning, or retries.
-
-The one skill nearest the subject leaves the pointer open. `codebase-layout` excludes shaping "a module's interface and seams" in its description and names no skill to take it, so a session routed away from layout on that question lands nowhere.
-
-`review-craft` lists the consumers of a changed contract, but only once the change exists. A rename caught at review costs a second pass over a surface that was cheap to shape before its first caller.
+No skill carries the subject, and the core code rule's two error bullets say nothing about exposure, versioning, or retries. `review-craft` lists a changed contract's consumers only once the change exists, when a rename costs a second pass over a surface that was cheap to shape before its first caller.
 
 ## Must
 
-- State Hyrum's Law as design rules a session can act on: decide what is observable, and expose no storage type, internal identifier, ordering, or timing by accident
-- Tell the session to write the contract, being the signature, flags, output shape, or schema, before the body
-- State one error shape per surface with a stable code a caller can branch on, and own the hidden-internals clause in the body, since no project rule carries it for every code stack
-- State validation at the boundary, once, with the value trusted inside
-- State additive change as the default: new fields and flags optional, nothing renamed or removed in place, no change of meaning under an existing name, and the One-Version Rule for a caller that cannot pin
-- State the four idempotency rules: store and honor a caller's key, claim it in one atomic step under a unique constraint, fail loudly on a reused key with a different body, and keep a key past the longest retry window
-- Record the external sources adopted and declined with the reason for each, so a later session extends the position instead of re-deriving it
-- Close with a table of the excuses a session gives for breaking a caller, each with its rebuttal, the red flags a session can see in its own diff, and a checklist each line of which answers yes or no against the surface the change produced
-- Exclude a visual interface by name in the description, since `design-taste` already routes on drafting or judging an interface
+- State Hyrum's Law as design rules, deciding what is observable and exposing no storage type, internal identifier, ordering, or timing by accident
+- Write the contract before the body, with one error shape per surface carrying a stable code, and validate once at the boundary
+- Make change additive by default, with new fields optional and nothing renamed, removed, or redefined in place, and the One-Version Rule for a caller that cannot pin
+- State four idempotency rules: honor a caller's key, claim it atomically, fail loudly on a reused key with a different body, and keep it past the retry window
+- Close with excuses, red flags, a checklist, and the external sources adopted and declined with the reason for each, and exclude visual interfaces by name in the description
 
 ## Must not
 
-- Name a framework, a protocol style, or a language in the body. Status codes, verbs, pagination, and schema languages stay out, so the body holds for a function, a command, a file format, and an endpoint alike.
-- Restate the consumer-listing axis `review-craft` carries for a finished change
-- Cover interface depth or the internals behind a boundary, which govern what sits behind a surface rather than what crosses it
-- Import an external skill's tone, such as a law stated as absolute, or an excuse row rebutting an objection no session has raised
-
-## Guards
-
-- A change that stays behind an existing boundary and alters nothing a caller observes skips the skill
-- A rename lands as an addition beside the old name, never in place, unless every caller lives in the same change and the change migrates each one
+- Name a framework, a protocol style, or a language in the body
+- Restate the consumer-listing axis `review-craft` carries, or cover the internals behind a boundary
+- Land a rename in place unless every caller sits in the same change and the change migrates each one
 
 ## Out of scope
 
-- Where the file holding a surface sits on disk: `codebase-layout`
-- Interface depth, deep modules, and the internals behind a boundary: `code-craft`
-- Listing the consumers a finished change breaks, and the docs it made false: `review-craft`
-- A visual interface, its layout, and its look: `design-taste`
-- Retiring a surface and migrating its last consumers off it, beyond the additive rule stated here
-- Protocol-specific guidance such as verbs, status codes, and pagination
-- Whether the guidance changes what a session ships, which needs a measured with-and-without run rather than a rule here
+- Where the file holding a surface sits on disk, which `codebase-layout` owns
+- Interface depth and the internals behind a boundary, which `code-craft` owns
+- Listing the consumers a finished change breaks, which `review-craft` owns
+- A visual interface, its layout, and its look, which `design-taste` owns
+- Retiring a surface and migrating its last consumers, which `deprecation-migration` owns

package/claude/skills/auto-ship/REQUIREMENT.md

@@ -9,37 +9,26 @@ description: What the post-plan pipeline is for, the gaps it closes, and why eve
 
 Without this skill, the run from an approved plan to an open pull request is a conversation. A session implements, then asks what comes next, and the answer varies by session. A run that halts leaves no stated resume point, so the user reconstructs how far it got from the working tree.
 
+A pull request opened ready stays mergeable through its CI run, and a draft mark typed against the wrong number holds someone else's release. Parallel batches sharing edge files conflict on each merge. A worker improvising the review wait polls issue comments and stalls with both reviewers idle.
+
 ## Must
 
-- Take the approved plan for the branch as the scope, and implement only what it describes
-- Load `build-in-slices` before implementing, so the build reaches history as tested slices rather than one uncommitted pass
-- Give every step a stop condition, and leave the code on the branch and the receipts on disk at each one
-- Check the branch's committed history for a test-order violation between verify and ship, and report any finding without gating on it, matching the verb's own contract
-- Delegate the ship sequence to `git-ship` rather than restating it, and name only what this chain adds to it
-- Open the pull request as a draft before the continuous integration watch begins, since a pull request marked after it is mergeable for the length of the run
-- Continue past a produced UI checklist rather than stopping on it, and report its unchecked boxes in the closing block, since the draft mark already holds the merge
-- Prove the draft target's head is the current branch and its state is open before marking it, and stop with nothing marked on a mismatch, since the number is retyped between steps and a draft mark on a release pull request holds that release
-- Stop a fan-in member after its verify and test order with a push and a done message rather than a pull request, and open an integrator's build by merging the member branches, since parallel batches sharing edge files put every open sibling into conflict on each merge
-- Wait for both review families through `canon pr review-state --wait` once CI passes on a launch that named a controller, which alone dispatches the reviewers, bounded at the lift's own default, and hand the record to the controller on a timeout, since a worker improvising the read polled issue comments, never saw a UI close posted as a review, and stalled with both reviewers idle
-- Name the recovery for the stop it took, since the value of stopping is that the user knows where to resume
+- The approved plan is the scope, built in tested slices through `build-in-slices`, and every step stops with the code on the branch and the recovery for that stop named
+- The ship sequence is delegated to `git-ship`, and the pull request is marked a draft before the CI watch, after proving its head is this branch and its state is open
+- A test-order finding between verify and ship is reported without gating, and a produced UI checklist is reported in the closing block without stopping
+- A fan-in member stops after verify with a push and a done message, and an integrator opens its build by merging the member branches
+- On a launch naming a controller, both review families are awaited through `canon pr review-state --wait`, and a timeout hands the record to the controller
 
 ## Must not
 
 - Expand past the plan, refactor a neighbor, or touch a file outside it without reason
-- Loop on a failed verify. One fix attempt against the reported errors, then stop.
-- Fix a failing check. The stop is deliberate, since a green pull request reached by auto-fix hides what broke.
-- Restate the ship sequence. Two copies of one order drift with nothing comparing them, which is what the merge into `git-ship` closed.
-- Skip that skill's own verify for repeating this chain's. The gate exists for the resumed run, and a chain that suppresses it leaves the resumed run reaching nothing.
-- Stop the chain or rewrite a commit over a test-order finding. The verb reports and never gates, and a commit already in history is a different act from the work this run is building.
-
-## Guards
-
-- Detached HEAD: stop, no slug resolves
-- No approved plan at the branch-derived plan path: stop, name the branch the slug came from, and say the invocation carried no argument, so a plan or a task path may be passed
-- Uncommitted changes unrelated to the plan: stop
+- Loop on a failed verify or auto-fix a failing check, since a green pull request reached that way hides what broke
+- Restate the ship sequence, or skip `git-ship`'s own verify for repeating this chain's
+- Stop the chain or rewrite a commit over a test-order finding
+- Run on a detached HEAD, a missing plan, or uncommitted changes unrelated to the plan
 
 ## Out of scope
 
-- Writing the plan, which `plan-feature` owns. This chain starts from one already approved.
-- The behavior of each step, owned by the skill invoked. This skill owns the order and the stop conditions.
-- The ship sequence and the resume path after a stop, both of which `git-ship` owns. That skill is the tail of this chain, invoked at Step 6 rather than copied into it, so the overlap is one body reached two ways rather than two bodies stating one order.
+- Writing the plan, which `plan-feature` owns
+- The behavior of each step, which the skill that step invokes owns
+- The ship sequence and the resume path after its stops, which `git-ship` owns

package/claude/skills/backlog-triage/REQUIREMENT.md

@@ -7,41 +7,30 @@ description: Why the backlog gets a measured verdict per row with a lean toward
 
 ## Gap
 
-Without this skill, the backlog only grows. `task-board` declines one named task and `task-complete` archives one, and nothing reads the backlog as a whole, so a row stays until somebody happens to remember it and decides by hand. The orchestrator's backlog re-test only clears a row upward onto the board, so no sweep ever takes one off. A backlog past fifty rows had no surface that could say which of them still mattered.
+Without this skill, the backlog only grows. `task-board` declines one named task and `task-complete` archives one, but nothing reads the backlog as a whole, and the orchestrator's re-test only clears a row upward. A long backlog has no surface that can say which rows still matter.
 
-Four failure modes cost more than the rest. A pass that judges a row by what its task file says rather than by the tree keeps every row, since a task file reads as live the day it was written and every day after. A pass that applies its own verdicts decides rows on silence, which ships a decline nobody approved on a board with no history to restore it from. A keep that carries no measurement is the default nobody argues with, so a triage without a lean toward decline ends with the same backlog it started with. And a keep that measures only that the defect still exists keeps nearly everything, since a row filed against the tree almost always still reproduces. One pass suggested keeping 24 of 27 rows that way, where the operator kept 6 and promoted 1.
+Judged by its own task file, every row reads live and stays. Applied without the operator, verdicts decline rows on silence, on a board with no history to restore them. Measuring only that a defect still exists keeps nearly everything, since a row filed against the tree almost always reproduces.
 
 ## Must
 
-- Measure every row against the tree and the log during the pass, carrying a count, a path, or a commit rather than the task file's own claim
-- Suggest keep or promote only for a row that names a cost, being a wrong result the pass observed or a case someone hit, including a user asking for a feature or working around its absence, or a reach, being a defect on a path the project ships that changes what its users or targets receive, hit or not, and suggest decline for a row whose defect merely still exists
-- Name the commit or pull request per outcome position before suggesting archive
-- File into an ordinary intake folder, so the intake list and answer verbs read and write it unchanged
-- Carry the verdict in the suggestion line and the task stem in the item heading, rather than in new fields
-- Split filing from applying by the operator's answer, so filing writes only inside the intake folder and applying writes only what was approved
-- Apply through the existing decline, outcome, and archive verbs
-- Leave the folder slug on every task a verdict touched, so a re-run writes nothing twice
-- Refuse to apply under a planner or worker session, and hand a promote to a live orchestrator rather than writing the ordering file beside it
+- Every row is measured against the tree and the log, carrying a count, a path, or a commit rather than the task file's claim
+- Keep or promote is suggested only for a row naming a cost someone hit or a reach into what the project ships, and decline for a row whose defect merely still exists
+- Verdicts are filed into an ordinary intake folder, in the suggestion line and item heading, so the intake verbs read them unchanged
+- Applying writes only what the operator approved, through the existing decline, outcome, and archive verbs, and archive names the commit or pull request per outcome position
+- Every task a verdict touched carries the folder slug, so a re-run writes nothing twice
 
 ## Must not
 
-- Fill an operator's answer slot, or infer a verdict from an empty one or from a free-text answer
-- Read a suggestion carrying no verdict token as keep
+- Fill an answer slot, or read a verdict from an empty answer, a free-text answer, or a suggestion with no verdict token
 - Treat age as evidence for or against a row
 - Retry an archive with guessed outcome positions after a refusal
+- Apply under a planner or worker session, or write the ordering file beside a live orchestrator rather than handing it the promote
 - Change the intake standard, the intake skills, or the task verbs to fit triage
 
-## Guards
-
-- No backlog file: stop
-- Unread items in the newest triage folder: stop and name the answer skill
-- An item carrying no answer slot: stop and name the folder to repair
-- Apply under a session named for the planner or worker role: stop before writing
-
 ## Out of scope
 
 - Filing a brain dump, which `plan-intake` owns
 - Answering the filed items, which `plan-intake-answer` owns
-- Creating or declining one named task outside a triage, which `task-board` owns, and archiving one, which `task-complete` owns
-- Ordering the rows a promote lands under `## Needs a plan`, which the orchestrator's refill sweep owns
-- Skipping rows kept at a recent triage, which waits on a second triage measuring the re-read cost
+- Creating or declining one named task outside a triage, which `task-board` owns
+- Archiving one named task outside a triage, which `task-complete` owns
+- Ordering the rows a promote lands under `## Needs a plan`, which `role-orchestrator` owns

package/claude/skills/build-in-slices/REQUIREMENT.md

@@ -7,39 +7,29 @@ description: Why a building session needs stated rules for working through a pla
 
 ## Gap
 
-Without this skill, nothing in the toolkit says how a session works through a plan once it starts building. `test-first` loops per behavior and stops at refactor, and `auto-ship` Step 2 says to implement only what the plan describes and nothing about how. No skill asks for a commit per slice, for a build left passing between slices, or for a defect noticed outside the plan to be written down rather than fixed.
+Nothing says how a session works through a plan once it starts building. `test-first` loops per behavior and stops at refactor, and `auto-ship` says to implement only what the plan describes. No skill asks for a commit per slice, a build left passing between slices, or a noticed defect written down rather than fixed.
 
-The ship chain assumed the work arrives uncommitted. `git-ship` ran `git-stage` unconditionally, and that skill stops on an empty index, so a session that committed as it went never reached the pull request whenever the sync steps wrote nothing.
+Without those, a session builds in one pass and tests at the end, so the diff outgrows what anyone can read and a late failure could come from any change. A defect found on the way gets fixed in the same diff, and the review reads two changes as one.
 
 ## Must
 
-- State the cycle per slice: implement, run the slice's tests and the checks its change could affect, commit through `git-commit`, then move on from the committed state
-- State how the next slice is chosen: one path end to end, the riskiest piece first, and the contract first when two sides are written against it
-- Keep each commit safe to revert on its own: one logical change, a test committed with or ahead of its code, and never a delete and its replacement in one commit
-- Route a defect noticed outside the plan to the open task's `## Findings`, or to the handover where no task exists, and leave its file unchanged
-- Limit the rule against re-running a check on unchanged code to the session's own repeats, so it never reads as permission to skip a verify step a chain runs
-- Record the external sources adopted and declined with the reason for each, so a later session extends the position instead of re-deriving it
-- Close with a table of the excuses a session gives for skipping a slice commit or widening scope, each with its rebuttal, the red flags a session can see in its own work mid-task, and a checklist each line of which answers yes or no against the branch the build produced
+- Work each slice as implement, run its tests and the checks its change could affect, commit through `git-commit`, then move on from the committed state
+- Choose the next slice as one path end to end, the riskiest piece first, and the contract first when two sides are written against it
+- Keep each commit safe to revert alone, with one logical change, a test committed with or ahead of its code, and no delete sharing a commit with its replacement
+- Route a defect noticed outside the plan to the open task's findings or the handover, and leave its file unchanged
+- Re-run a check only after an edit it could see, never to skip a chain's verify step, then close with excuses, red flags, a checklist, and the sources adopted and declined with the reason for each
 
 ## Must not
 
-- Restate the scope floors of minimal edits and no unrequested features, which a scope call the skill makes already holds
-- Carry simplicity or abstraction rules, which `code-craft` owns
-- Name a feature flag pattern, since the slices of one branch merge as one pull request rather than reaching trunk one at a time
-- Name a framework, a test runner, or a line-count threshold, none of which holds across stacks
+- Restate the scope floors of minimal edits and no unrequested features
+- Carry simplicity or abstraction rules, a feature flag pattern, a framework, or a line-count threshold
 - Describe a raw `git commit` recipe in place of `git-commit`
-
-## Guards
-
-- A change that is already one behavior in one place skips the skill
-- A defect outside the plan is fixed on the branch only when the plan's own change cannot pass without it, and the commit says so
+- Fix an outside defect on the branch unless the plan's own change cannot pass without it, and then say so in the commit
 
 ## Out of scope
 
-- The red, green, refactor loop inside one behavior: `test-first`
-- Which layer a test belongs at: `test-craft`
-- The shape of a function, class, or module a slice writes: `code-craft`
-- What a building session may write, the board it may not, and the messages it owes: `role-worker`
-- The message format of a commit: `git-commit`
-- Safe defaults for a new interface, which belong to the skill shaping what a caller sees
-- Whether the guidance changes what a session ships, which needs a measured with-and-without run rather than a rule here
+- The red, green, refactor loop inside one behavior, which `test-first` owns
+- Which layer a test belongs at, which `test-craft` owns
+- The shape of a function, class, or module a slice writes, which `code-craft` owns
+- What a building session may write and whom it reports to, which `role-worker` owns
+- The message format of a commit, which `git-commit` owns

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

@@ -7,40 +7,28 @@ description: Why a session is routed from a job to its canon verb from one place
 
 ## Gap
 
-Without this skill, a session guesses at a verb from its name and runs a `canon` sync to find out afterward what it did. The command names give nothing away. `install` and `sync` differ per domain, some surfaces overwrite unconditionally, some merge, some are written once and never touched again, and none of that is visible from the command line the user typed.
+Without this skill, a session guesses at a verb from its name. It learns afterward what the verb did, because `install` and `sync` differ per domain, with some surfaces overwriting, some merging, and some written once and never again. Golden configs and edited rules get replaced unwarned. A copy-once seed waits on a sync that never rewrites it.
 
-The damage lands on the files a project owns. A golden config carrying local edits is replaced without a warning anyone saw, and a governance sync takes back a rule the project had edited. The user learns which category a file was in by losing the edit.
-
-The inverse failure is quieter. A session that assumes a sync will pick up a change edits a seed and waits for an update that never comes, because the seed is copy-once and no sync command writes it again. Both failures are one missing fact available before the command runs.
-
-A third gap is the route itself. `canon --help` lists every top-level verb by a one-line description, and a session with a job in hand pays a `--help` read per candidate to find the one that does it, or picks by name and lands on the wrong one. The job-to-verb mapping is the fact the session needs and no verb answers.
-
-Being reachable is a separate problem from being right. This is a pure reference whose moment happens inside another skill's run, so nothing brings it up unless a body names it. A route lives in a body or it does not exist, and a mention in a sibling's requirement file is not one.
+The route is missing too. `canon --help` lists each verb in one line, so a session with a job pays a read per candidate or picks by name. The job-to-verb mapping is the fact it needs, and nothing brings it up unless a body names it.
 
 ## Must
 
-- Name each target-usable top-level verb by its job, never its subcommands or flags
-- Route an author-and-render verb to the skill that owns it rather than describing it
-- Warn about a verb that can lose the project's edits before it runs, naming what it replaces
-- Point each destructive verb at `canon docs install-and-sync`, which owns the overwrite detail
-- Point to `canon <verb> --help --all` and `canon docs agents` for subcommands, flags, and the invocation contract, and have the session read that help before running a verb no skill body spells out, a verb a skill pins in full being exempt
-- Defer to `canon docs install-and-sync` when it and this summary disagree, since the summary is a copy and the doc is the source
+- Name each target-usable top-level verb by its job, never its subcommands or flags, and route an author-and-render verb to the skill that owns it
+- Warn before a verb that can lose the project's edits runs, naming what it replaces, and defer to `canon docs install-and-sync` where the summary disagrees
+- Point to `canon <verb> --help --all` and `canon docs agents` for subcommands, flags, and the invocation contract, and have the session read that help before running a verb no skill body spells out
+- Route a verb or surface the skill does not cover to `canon docs` rather than to an inference from a similar row
+- Fail a coverage test naming each top-level verb that the body neither carries nor exempts, and each exemption naming something no longer a verb
 
 ## Must not
 
-- Run, or send the session to run, a `canon` command that writes or installs. The skill is read before acting on a sync.
-- List a subcommand, a flag, or a JSON shape. That restates the docs and is the drift the one-name-per-verb rule removes.
-- List a verb that only works inside the toolkit repository. A named exemption set in the coverage test holds that boundary.
-- Take a mention in a sibling's requirement file as an inbound route. The pointer lives in the body that needs it.
-
-## Guards
-
-- A test fails naming each top-level verb in `COMMAND_GROUPS` that the body neither carries as `canon <verb>` nor exempts, and fails again when an exemption names something that is no longer a verb
-- A verb or surface the skill does not cover routes to `canon docs` rather than to an inference from a similar row
+- Run, or send the session to run, a `canon` command that writes or installs
+- List a subcommand, a flag, or a JSON shape, which restates the docs
+- List a verb that only works inside the toolkit repository
+- Take a mention in a sibling's requirement file as an inbound route, since the pointer lives in the body that needs it
 
 ## Out of scope
 
-- Executing the sync, which the user runs
-- Reconciling a customized seed section by section, which an operator does by hand
-- Deciding which stack, rule, or standard a project should install, which the setup skills resolve from live catalogs
-- Diagnosing what a project is behind on: `target-check`
+- Executing the sync, which the user owns
+- Reconciling a customized seed section by section, which an operator owns
+- Deciding which stack, rule, or standard a project installs, which `target-setup` owns
+- Diagnosing what a project is behind on, which `target-check` owns

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

@@ -7,36 +7,28 @@ description: Why a toolkit defect is reported from session context alone, and wh
 
 ## Gap
 
-Without this skill, a toolkit defect noticed inside a target project dies with the session. The user is told to mention it in the toolkit repository later, which means retyping a report they no longer have the context to write, so the defect is either reported badly or not at all.
+Without this skill, a toolkit defect noticed in a target project dies with the session. The user retypes a report later without the context, so it is reported badly or not at all. A block printed in chat needs a copy-paste into another repository, which gets skipped under time pressure, and a report naming no surface cannot be routed.
 
-The report itself fails two ways. A block printed in chat needs a copy-paste into another repository, and a step that manual is skipped under any time pressure. A report that names no surface cannot be routed, because the toolkit acts on a plugin skill, a CLI command, and a seed through different paths, and the difference is not recoverable from the symptom.
-
-The last failure is the session's own effort. Asked to report, a session starts diagnosing instead, searching the toolkit and reading its surfaces to find the cause. That spends the context the report was meant to capture cheaply, and it produces a diagnosis from a project that cannot see the toolkit's current source.
+Asked to report, a session also starts diagnosing, which spends the context the report was meant to capture and yields a diagnosis from a project that cannot see the toolkit's source.
 
 ## Must
 
-- Build the report from what the session already holds
-- 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
-- Surface the block and the reason when the issue call fails, since a failure that prints nothing leaves the report where nothing reads it
-- Carry the whole request in the issue body alone, since a comment is easy to miss and a body and a comment that differ leave triage choosing
+- Build the report from what the session already holds, name the surface and its type, and write the stated fallback for a field it cannot fill
+- Carry the whole request in the issue body alone, since a body and a comment that differ leave triage choosing
+- Open a GitHub issue on the toolkit repository through the CLI and print the returned URL on its own line
+- Surface the block and the reason when the issue call fails or the CLI is absent, so the report still exists
 - 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
 
 ## Must not
 
 - Probe the project, list files, grep, or read toolkit surfaces to enrich the report
-- Guess the surface type when the session is ambiguous. Ask one line.
+- Guess the surface type when the session is ambiguous
 - Diagnose or fix, which needs the toolkit's source rather than the target's
-
-## Guards
-
-- Nothing in session context pointing at a toolkit issue stops, since a report assembled from nothing wastes the triage it reaches
+- Report from a session holding nothing that points at a toolkit issue
 
 ## Out of scope
 
 - Fixing the defect, which happens in the toolkit repository against its own source
-- Draining the queue this fills: `canon-feedback-triage`
-- Filing an issue against the current project, which `git-issue` does and this skill cannot delegate to, since that skill targets the current repository
+- Draining the queue this fills, which `canon-feedback-triage` owns
+- Filing an issue against the current project, which `git-issue` owns
 - Complaints about tooling the toolkit does not own

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

@@ -7,33 +7,28 @@ description: Why the feedback queue is read from GitHub rather than local scratc
 
 ## 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. 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.
+Without this skill, the feedback queue fills and nothing drains it. A local folder looks like the place to read and is the wrong one, since that scratch is per-machine and any cleanup removes it.
 
-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.
+Triage then fails three ways. An issue routes to a fix from a paragraph, which skips the scope argument. A self-contradicting report gets a guess instead of a question. The same issue gets filed twice because two passes cannot see the board carries it.
 
 ## Must
 
-- Read the durable queue rather than local session scratch
-- 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
+- Read the durable queue through the `gh` CLI rather than local session scratch, and stop when it is absent or unauthenticated
+- File one measured item per open issue into an intake folder, headed so an answer finds its issue, 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
+- Report an empty queue as nothing open rather than widening the label to find work
 
 ## Must not
 
 - 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
+- Implement a fix or write a plan
 - Fill an answer slot, or read an empty one as agreement
 - Write outside the folder it claimed
 
-## Guards
-
-- The `gh` CLI absent or unauthenticated stops, since the queue is unreachable
-- An empty queue reports nothing open rather than widening the label to find work
-
 ## Out of scope
 
-- Filing new feedback: `canon-feedback`
-- 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
+- Filing new feedback, which `canon-feedback` owns
+- Answering the filed items, which `plan-intake-answer` owns
+- Writing the plan a plan-worthy item needs, which `plan-feature` owns
+- Issues carrying any other label, which no skill here owns

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

@@ -7,42 +7,28 @@ description: Scope boundary for driving the local design canvas, and the line be
 
 ## Gap
 
-Without this skill, a session asked to draw on the canvas writes frames into a folder nothing is serving, so the operator sees nothing and the session reports the frames as drawn. When the server is running, the session trusts a passing capture as proof the canvas works. Captures go through the frame route, so a shell that answers its address with an empty page passes every capture while the operator looks at a blank tab.
+Without this skill, a session asked to draw on the canvas writes frames nothing is serving and reports them drawn. It trusts a passing capture, though a blank shell passes every capture while the operator sees an empty tab. From a linked worktree it writes a copy the canvas never serves, and it captures after every edit.
 
-It reads "this one" from the conversation rather than from the operator's selection, and when it does read the selection it acts on an element index recorded against an earlier version of the file, which lands the edit on a different element. It restyles through a class while the operator's inspector edit sits on the element as inline style, so the change never shows and the session reports it as made.
-
-It writes frames from a linked worktree with the file tools, which refuse the main-root path and offer a worktree copy the canvas never serves. It captures after every edit, filling session scratch with images of drafts nobody picked.
-
-When the operator picks a frame, the session leaves the decision on the canvas and cites the frame as the design, so the project's design document never learns it and a gitignored file becomes the only record.
+It reads "this one" from the conversation rather than the operator's selection, or acts on a stale element pick and edits the wrong element. It restyles through a class while the operator's inspector edit sits inline, so the change never shows. A picked frame stays on the canvas as the only record, and the design document never learns it.
 
 ## Must
 
-- Start the canvas when it is not serving, before writing any frame
-- Confirm the live shell loads at the address the server reported, rather than trusting a capture
-- Read the address off the server's record rather than composing one
-- Make pages and frames through the verbs, so a box and the operator's drags share one locked writer
-- Name the main-root write route for a frame written from a linked worktree
-- 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 value into the project's stylesheet and its intent into the design document, and leave a picked layout on the canvas for the plan that builds it
+- The canvas is serving and its live shell loads at the address the server reported before any frame is written, and a refusal or a blank shell is reported rather than drawn into
+- Pages and frames go through the verbs, so the session and the operator's drags share one writer, and a frame from a linked worktree takes the main-root route
+- The operator's selection decides what "this one" means, and a stale element pick reads as unknown
+- A frame's inline styles are read before a restyle, the run names which operator edits it kept and dropped, and capture runs once per finished frame or page
+- A picked value lands in the project's stylesheet and its intent in the design document, while a picked layout stays on the canvas for the plan that builds it
 
 ## Must not
 
-- Present the canvas as the project's source of truth for design
-- Promise the canvas survives a lost checkout
+- Present the canvas as the project's source of truth for design, or promise it survives a lost checkout
+- Write frames when `canon` or its canvas command is missing
 - Name any third-party design tool, or the canvas's predecessor surface
-- Be invoked only by the author typing its name. A request to draw, select, or capture on the canvas should reach it by description, and a run where it never fires on such a request is a defect in the description
-
-## Guards
-
-- No `canon` on PATH, or an installed CLI with no canvas command, stop rather than writing files nothing serves
-- A server that refuses to start, or a shell that answers blank, stop and report it rather than drawing into it
+- Be reached only by the author typing its name, since a request to draw, select, or capture on the canvas should reach it by description
 
 ## Out of scope
 
-- 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 `pick-by-eye` runs on this canvas through the same verbs
-- Tracing reference images into design values or writing the design document from code, which no skill owns now
-- Backing up the canvas folder off one disk
+- Drafting candidates for a taste decision and taking the pick, which `pick-by-eye` owns
+- What the canvas verbs do internally, which the CLI's own contract owns
+- The content format a frame and a layout take, which the canvas standard owns
+- Tracing reference images into design values, writing the design document from code, and backing up the canvas folder, which no skill owns

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

@@ -7,34 +7,25 @@ description: Scope boundary for pipeline structure against job contents, and the
 
 ## Gap
 
-Without this skill, a session writes a pipeline whose jobs run in sequence because `needs` was used to express the order a person reads them in rather than a data dependency. The pipeline then costs the sum of its jobs where it could have cost the longest one, and the waste compounds on every push.
+Without this skill, a session chains jobs with `needs` to express reading order rather than a data dependency, so the pipeline costs the sum of its jobs. The same session splits a one-minute gate into parallel jobs, each repaying checkout, install, and toolchain setup, so the gate gets slower while reporting no earlier.
 
-The same session splits a gate that finishes in a minute into three parallel jobs, which fails in the other direction. Each job repays checkout, dependency install, and toolchain setup before it reaches a stage, so the gate gets slower while reporting no earlier, and the roster reads as a design decision rather than as a cost nobody measured.
-
-The rest are reproducibility failures that surface as flakes. An action pinned to a moving ref changes under the project, so a run that passed yesterday fails today with no commit behind it and the diff explains nothing.
-
-A cache keyed on a static string serves a stale browser or toolchain after a version bump, and the failure reads as a broken test rather than a stale cache. Artifacts upload on every run and never expire, so storage grows with the commit count while the ones worth reading are the failures. And a workflow with no manual trigger can only be reproduced by pushing a commit, which is the wrong instrument for a run that failed for an environmental reason.
+The rest surface as flakes. An action pinned to a moving ref changes under the project, a cache keyed on a static string serves a stale toolchain after a bump, artifacts upload on every run and never expire, a broad default token grants writes nobody needed, and a workflow with no manual trigger reproduces only by pushing a commit.
 
 ## Must
 
-- Gate a job only on a data dependency or on a cost that justifies the wait, and leave every other job parallel
-- Start the checks that share setup in one job and split them only once a run log puts the gate past roughly two minutes
-- Pin every action to a tag that cannot cross a major version
-- Key a cache on the version string of the thing it caches
-- Give every workflow a manual trigger beside its primary one, except one that commits back, where a manual run has no branch to land on
-- Default the token to read-only and grant a write scope only on the job that needs it
-- Bound artifact upload to failures and set an expiry on it
+- A job is gated only on a data dependency or a cost that justifies the wait, and checks sharing setup stay in one job until a run log puts the gate past roughly two minutes
+- Every action is pinned to a tag that cannot cross a major version, and every cache is keyed on the version of what it caches
+- Every workflow carries a manual trigger beside its primary one, except one that commits back
+- The token defaults to read-only, with a write scope granted only on the job that needs it
+- Artifact upload is bounded to failures and expires
 
 ## Must not
 
-- Own what runs inside a job. The build, test, and deploy commands come from the project, and a workflow asserting its own is a second copy of the project's scripts.
-- Enumerate the job set as a fixed list. Projects add and remove jobs, and what has to survive that is the parallel and gated structure rather than the roster.
-
-## Guards
-
-- A request for a deploy, publish, or release step stops at the gate. The job's contents carry credentials and an environment this skill cannot see, so it emits the `needs` wiring and names what the caller has to fill in rather than guessing a deploy command.
+- Own what runs inside a job, or guess a deploy command. A deploy, publish, or release step gets its `needs` wiring and the inputs the caller fills in.
+- Enumerate the job set as a fixed list
 
 ## Out of scope
 
-- 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.
+- Secrets, environments, and deploy targets, which live in the repository settings
+- The deploy setup on a host, which `deploy-app` owns
+- CI systems other than GitHub Actions, which a separate skill would own