@erclx/canon 5.45.0 → 5.47.0

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

@@ -7,17 +7,18 @@ description: Why a pointer answers under the old `draft-slides` name, and the te
 
 ## Gap
 
-Without this skill, a person typing the old name after the rename to `make-deck` meets an unknown command with nothing naming where the skill went. A target that has not run `canon migrate skill-names` still holds files telling someone to type it, and a live gitignored record written before the rename still names it, since the sweep reads the tracked listing only.
+Without this skill, a person typing the old name after the rename to `make-deck` meets an unknown command that names no successor. A target that has not run `canon migrate skill-names` still tells people to type it, and so does a live gitignored record, which the sweep never reads.
 
 ## Must
 
 - Name `make-deck` as the skill to run, so a typed invocation of the old name reaches the new one in one step
-- Carry `disable-model-invocation: true`, so routing never matches the old description against a request the new skill owns
+- Carry `disable-model-invocation: true`, so routing never matches the old description against a request `make-deck` owns
+- Retire once `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name
 
 ## Must not
 
 - Carry any part of the deck draft, which would give one behavior two bodies that drift apart
-- Retire on a release number. Retire it when `canon migrate skill-names --json` reports zero citations in every target the rollout reaches and no live `.canon/` record names the old name, since a release number retires it on a date nothing measured.
+- Retire on a release number, which retires it on a date nothing measured
 
 ## Out of scope
 

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

@@ -7,53 +7,29 @@ description: Why a figure decides between Mermaid, an architecture view, and fre
 
 ## Gap
 
-Without this skill, a session asked for a figure reaches for whichever path it thought of first. A graph-shaped subject gets model-authored SVG coordinates nobody checked against a render, drifting from the hand-drawn look every other figure in the project carries. A subject that is not graph-shaped gets forced through Mermaid's node-and-edge model, producing a diagram that answers a different question than the one asked. Either failure ships a figure a reader cannot trust, and a figure exists only to be trusted at a glance.
+Without this skill, a session asked for a figure takes the first path it thinks of. A graph gets SVG coordinates nobody checked against a render, and a subject that is not a graph gets forced through Mermaid. In a teach lesson the renderer cannot load the hand font, so labels clip, and a check reading the standalone image passes them.
 
-A teach lesson breaks the Mermaid path outright. The lesson letters its figures in a hand font the renderer cannot load, so the render sizes every label in a narrower fallback face and the lesson clips the text it actually shows. The check then reads the standalone image, rendered in that same fallback, and passes a figure the reader sees clipped. Both happened on one lesson, where every group title clipped mid-word and only a capture taken inside the lesson showed it.
-
-An architecture view asked for one at a time fails its own way. A session asked to refresh one view redraws every view beside it, so pictures nobody checked change in the same commit and the reviewer cannot tell which one the pass was about. It reaches for C4, state, or class diagrams that render differently in every viewer. A Mermaid source can satisfy every rule in the standard and still render as a picture asserting something false about the system, so a session that judges the source and calls it verified has spent the only signal a reader has on a picture nobody looked at.
-
-The color failure is the quiet one. Mermaid's own theme writes literal hex values, and a figure carrying one stops re-coloring itself the moment the host page switches its palette, which the figure standard's own accessibility bar rules out.
+Asked to refresh one architecture view, it redraws every view beside it. It judges the source and calls the figure verified, though a valid source can render a picture asserting something false. Mermaid's theme writes literal hex values, so the figure stops re-coloring when the page switches palette.
 
 ## Must
 
-- Apply the standard's earn-its-place bar before drawing anything
-- Decide between the Mermaid path and the freehand path by whether the subject reduces to a graph, not by which is faster to produce
-- Draw an architecture view from its named source signal, inside `flowchart` and `sequenceDiagram`, and render it through the Mermaid path
-- Draw only the view the request names, leaving every other figure in the destination untouched
-- Draw a figure bound for a teach lesson freehand whatever its shape, since the lesson's hand font is one the renderer cannot measure
-- Verify a figure bound for a rendered page by capturing it inside that page, and fall back to the standalone render only where the destination has no page to load
-- Keep the scoped overflow style as the documented fallback for a clipped group title wherever the Mermaid path still runs
-- Render the Mermaid path with the hand-drawn look and the figure font stack, never with Mermaid's default look
-- Rewrite every literal color the renderer wrote into the custom property the host stylesheet defines
-- Read the Mermaid render back and judge it against what the figure means to say, rather than judging the source
-- Read the node labels by hand, since no hook checks inside a fence
-- Cite only code paths that exist in an architecture view's caption or prose
-- Wrap either path in a `<figure>` and `<figcaption>` and give it an accessible name
+- The figure clears the standard's earn-its-place bar, and its path follows whether the subject reduces to a graph, with a teach lesson drawn freehand whatever its shape
+- An architecture view is drawn from its named source signal in `flowchart` or `sequenceDiagram`, and only the view the request names changes
+- The Mermaid render uses the hand-drawn look and the figure font stack, with every literal color rewritten to the host's custom property
+- The render is read back against what the figure means to say, and a figure bound for a rendered page is verified by a capture inside that page
+- Either path lands in a `<figure>` with a `<figcaption>` and an accessible name, and an architecture view's caption cites only code paths that exist
 
 ## Must not
 
-- Force a non-graph-shaped subject through Mermaid, or route a graph-shaped one through freehand SVG coordinates a model authored by hand outside a teach lesson
-- Report a figure bound for a rendered page as verified from the standalone render alone
-- Ship a literal hex color on either path
-- Report a clean verification when the Mermaid render was skipped or a defect survived
+- Draw with no subject or no destination, an architecture view with no planning file or folder structure to anchor it, or decoration for a subject that fails the bar
+- Report a figure verified from the standalone render alone, or report a clean check when the render was skipped or a defect survived
+- Ship a literal hex color, or commit a scratch render
 - Loop past two correction passes on a surviving defect
-- Commit a scratch render. Only the SVG that ships in the destination document survives
-- Redraw a figure the request did not name, or report one as drawn when it was left alone
-- Leave an architecture view as an unrendered fence
-
-## Guards
-
-- No subject given: stop, since nothing states what the figure has to show
-- No destination document given: stop, since the figure has nowhere to land
-- Subject does not clear the earn-its-place bar: stop rather than drawing decoration
-- An architecture view with no planning file and no folder structure to scan: stop, because nothing anchors it
-- Render fails for any reason: continue to the output and name the skipped check. A missing renderer degrades the loop rather than failing it.
+- Redraw a figure the request did not name, or leave an architecture view as an unrendered fence
 
 ## Out of scope
 
-- Mermaid's own layout, budgets, and label rules for the fence itself: the mermaid standard, cited rather than restated here
-- A UI screen mockup: `canvas-board`
-- Design tokens and the visual system: `canvas-board`, which carries a picked direction into the design document
-- Implementation detail behind an architecture view, which belongs in a context entry the caption points at
-- Which lesson needs a figure and where it sits among the lesson's blocks: `teach-workspace`, which calls this skill to draw one
+- Mermaid's layout, budgets, and label rules inside the fence, which the mermaid standard owns
+- A UI screen mockup, and design tokens or the visual system, which `canvas-board` owns
+- Which lesson needs a figure and where it sits, which `teach-workspace` owns
+- Implementation detail behind an architecture view, which the context entry the caption points at owns

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

@@ -7,43 +7,29 @@ description: What branch naming is for, the gaps it closes, and where the family
 
 ## Gap
 
-Without this skill, a branch name is invented once per session. The type prefix drifts from what the history already carries, the name runs past the width a pull request list renders, and a rename lands on a branch that already exists on the remote, which detaches every open pull request pointing at it.
+Without this skill, a branch name is invented once per session. The type prefix drifts from the history's convention, the name runs past the width a pull request list renders, and a rename lands on a branch the remote already carries, which detaches every open pull request pointing at it.
 
-A session standing on `main` has no route either. The `git.md` rule sends every git operation through a `git-*` skill, and the only one for branches stopped on `Cannot rename a protected branch`, so the first act of any feature, creating its branch, had no skill to go through.
+A session standing on `main` has no route to its first act either. Every git operation goes through a `git-*` skill, so creating a feature's branch needs one that creates as well as renames, and that agrees with the name a dispatcher already checked.
 
 ## Must
 
-- Read the branch format reference before generating, so the type vocabulary and the length limit come from one source
-- Create the branch on `main` or `master` and rename it anywhere else, so one skill covers both ends of a branch's start
-- Derive the name from the commits ahead of main when a rename carries no description
-- Take a created name from `canon tasks plan-branch` when the invocation names a plan, so the skill and the dispatch gate hold one derivation
-- Resolve whether the branch exists on the remote before proposing a rename, since the hazard is invisible from local state
-- Read the remote itself with `git ls-remote` before creating, since `origin/<name>` sees only the last fetch
-- Show the name and its length against the limit before renaming or creating
-- Execute immediately after the preview. The tool permission dialog is the confirmation gate.
+- The name follows the branch format reference, and the user sees it with its length before the branch changes
+- One skill creates on `main` or `master` and renames anywhere else
+- A created name for a plan comes from `canon tasks plan-branch`, and a rename with no description derives from the commits ahead of main
+- Remote existence is read before any rename or create, from the remote itself rather than the last fetch
+- A conforming name passes through as a success, so a chained caller continues
 
 ## Must not
 
-- Rename `main` or `master`
-- Rename when the current name already conforms. The skill is chained, so a conforming name has to pass through rather than churn the branch.
-- Rename a branch that exists on the remote. Local rename plus force push is not the same operation and it breaks the pull request.
-- Create a branch from anywhere but `main` or `master`, or create one whose name exists locally or on the remote
-- Invent a name when the plan verb refuses, since a name the skill calls non-conforming strands the rename at ship
+- Rename `main`, `master`, or a branch that exists on the remote
+- Create from anywhere but `main` or `master`, or onto a name that exists locally or on the remote
+- Invent a name when the plan verb refuses
 - Fetch or stash while creating
 - Emit anything after the result line
 
-## Guards
-
-- Create with no plan and no name: stop and name both missing inputs
-- Create with a name breaking the branch standard: stop and name the cap
-- Create with a name existing locally or on the remote: stop and say which
-- Rename name already conforms: stop with a success marker, not a failure, since a chained caller continues past it
-- Rename with no commits and no description: stop and name both missing inputs
-- Rename of a branch existing on the remote: stop and route to the surface that preserves the pull request link
-
 ## Out of scope
 
 - The commit message, which `git-commit` owns
-- Pushing and opening the pull request, which `git-pr` owns. That skill reads a conforming name as a precondition and refuses without one, so this skill runs first.
+- Pushing and opening the pull request, which `git-pr` owns and which refuses a non-conforming name
 - Splitting a branch whose commits span concerns, which `git-split` owns
-- Entering a worktree, which `session-worktree` owns and which names its own branch
+- Entering a worktree and naming its branch, which `session-worktree` owns

package/claude/skills/git-commit/REQUIREMENT.md

@@ -7,30 +7,26 @@ description: What commit generation is for, the gaps it closes, and where the fa
 
 ## Gap
 
-Without this skill, a commit message takes whatever shape the session settled on. The type and scope drift from the convention the history already follows, the subject runs past the length the log renders, and a lockfile diff floods the context the message is derived from so the message describes the lockfile.
+Without this skill, a commit message takes whatever shape the session picks. The type and scope drift from the history's convention, the subject runs past the log's width, and a lockfile diff crowds out the change the message should describe.
 
-A second failure is routing rather than shape. A plain request to commit reaches this skill and its grouping sibling alike, and the sibling's first step is to unstage everything and restage whole files, so a selection staged hunk by hand comes back widened to the files it sat in. The user reviewed one thing and shipped another, and nothing in the run says the set changed.
+A plain request to commit also reaches the grouping sibling, which restages whole files, so a hunk-level selection ships wider than the user reviewed.
 
 ## Must
 
-- Read the commit format reference and the versioning standard before generating, so the type, the scope, and the version discipline come from one source
-- Derive the message from the staged diff, with lockfiles excluded
-- Show the message and its length against the limit before committing, so an over-length subject is visible while it is still cheap to fix
-- Execute immediately after the preview. The tool permission dialog is the confirmation gate, and a second prompt trains the user to skim it.
-- Claim the single-concern and the hunk-level staged set in the description, and name the sibling for the multi-concern one. A boundary stated only here routes nothing, since the description is the field the choice is made from.
+- The message follows the commit format and versioning references
+- The message describes the staged diff with lockfiles excluded
+- The user sees the message and its length before the commit runs
+- The committed set is exactly the staged set
+- The description claims single-concern and hunk-level staged sets, and names `git-stage` for a mixed one
 
 ## Must not
 
-- Stage anything. What is committed has to be what the user chose to stage.
+- Stage or unstage anything
 - Commit when nothing is staged
-- Emit anything after the result line. A commit is a step inside a longer flow and prose here buries the next one.
-
-## Guards
-
-- Nothing staged: stop and name the command that stages
+- Emit anything after the result line
 
 ## Out of scope
 
-- Splitting a mixed diff across several commits, which `git-stage` owns. That skill restages whole files, so a hunk-level selection survives here and not there, and both descriptions carry the difference rather than leaving it stated only in these two files.
-- Naming the branch, which `git-branch` owns. The family shares its triggers and not its gaps: this one turns on the staged diff, the length limit, and lockfile exclusion, none of which a branch name has.
+- Splitting a mixed diff into several commits, which `git-stage` owns
+- Naming a branch, which `git-branch` owns
 - Pushing or opening a pull request, which `git-pr` owns

package/claude/skills/git-followup/REQUIREMENT.md

@@ -7,38 +7,27 @@ description: What the follow-up push is for, the gaps it closes, and how it spli
 
 ## Gap
 
-Without this skill, an edit made after a pull request is already open ships as a bare push. The body still describes the scope from before the edit, so a reviewer returning to the page reads a description the diff no longer matches. A reviewer who left comments gets no reply, and when a caller has already posted its own reply, a second one lands underneath it.
+Without this skill, an edit made after a pull request opens ships as a bare push. The body still describes the scope from before the edit, and a review fix always changes what shipped, so the description a merge records is false by the time review ends. A reviewer who left comments gets no reply, or a second one under the caller's own.
 
-A caller that rebased the branch before handing over hits a rejected push, since the tracking branch no longer reaches the head. A branch entered through a worktree hits the opposite shape, carrying an open pull request with no tracking ref at all, which read as a branch that had never been pushed.
-
-A fix commit answering a review is the sharpest case of the first paragraph, since it always changes what shipped. The routing that once picked whether to sync the body keyed off the same branch that decides whether to reply, so reaching `reply-owned` or a nonzero comment count meant the sync never ran at all. The description a merge record carries was true when the pull request opened and false by the time review finished, with nothing between the two that read it back.
+The push itself fails on two branch shapes. A caller that rebased before handing over hits a rejected push, and a branch entered through a worktree carries an open pull request with no tracking ref, which reads as a branch never pushed.
 
 ## Must
 
-- Refuse unless the branch has an open pull request, since every later step addresses it
-- Set the tracking ref at the push when the branch has none, since a branch entered through a worktree carries an open pull request without one
-- Delegate the message to `git-commit` rather than composing one, so a follow-up commit reads like every other commit
-- Sync the body when the new commit moves the scope, and the title when the shift makes it inaccurate
-- Reply on the pull request when it carries review comments, and scan that reply for the banned characters and internal phase labels before posting. A hook on `Bash` scans the body file of that post and denies an inline body, so the reply goes through a file.
-- Suppress the reply when the caller owns it, and still run the push and the body sync
-- Post the evidence through `pr-evidence` and read `canon pr evidence <number> --check --json` after it, since a followup that posts the evidence and stops leaves the preview for a relay
-- Force the push under a lease when the tracking branch no longer reaches the head, so a caller's rebase lands and a commit this session never read is not overwritten
+- Every follow-up commit syncs the body when it moves the scope, and the title when the shift makes it inaccurate, whether or not a reply runs
+- The message comes from `git-commit`, so a follow-up reads like every other commit
+- A pull request carrying review comments gets one reply, scanned for banned characters and phase labels and posted through a file, and none when the caller owns it
+- The push lands on a branch with no tracking ref, and on a rebased one under a lease that protects a commit this session never read
+- The evidence is posted through `pr-evidence` and read back with `canon pr evidence <number> --check --json`
 
 ## Must not
 
-- Run on `main`
-- Open a pull request. A missing one is the stop condition, not a step to add.
+- Run on `main`, or with nothing changed
+- Open a pull request. A missing one is the stop.
 - Post a second reply when the caller has already replied
 - Emit anything after the result line
 
-## Guards
-
-- On `main`: stop and say to switch to a pull request branch
-- Nothing changed: stop
-- No open pull request: stop and route to the skill that opens one
-
 ## Out of scope
 
 - Opening the pull request, which `git-pr` owns and `git-ship` chains
-- Deciding what to fix from a review, which `review-address` owns. This skill is that flow's push leg and takes the fixes as already made.
-- Grouping a multi-concern diff, which `git-stage` owns. A follow-up is one concern by definition, which is why this skill stages everything into a single commit.
+- Deciding what to fix from a review, which `review-address` owns
+- Grouping a multi-concern diff, which `git-stage` owns

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

@@ -58,6 +58,7 @@ A missing tracking ref is not a guard, since an open pull request proves the bra
    - Read the live title and body with `gh api repos/{owner}/{repo}/pulls/<number> --jq '{html_url, title, body}'`. Update the body with `gh api -X PATCH repos/{owner}/{repo}/pulls/<number> -F body=@<file> --silent` when the new commit changes scope, writing the new body to `<file>` first, and the title with `gh api -X PATCH repos/{owner}/{repo}/pulls/<number> -f title="<title>" --silent` when the scope shifted enough to make it inaccurate.
    - A fix commit answering a review changes what shipped exactly as much as an ordinary followup does, so the sync cannot wait on the invocation or the comment count below.
    - A body a person edited by hand between rounds gets no special handling: judge it against the tree the same way regardless of who wrote it last, since a hand-edit the fix commit has made stale is the exact drift this sync exists to close.
+   - Carry a `UI pass` line marked `<!-- pr-ui-pass -->` into any rewritten body unchanged, since `canon pr tick` owns it and a dropped marker defeats the reset on a new head.
 8. Route on the invocation and the comment count for the reply alone.
    - When invoked with `reply-owned`, skip this step: the caller posts its own reply.
    - Otherwise, if the count is above zero, the followup addresses review feedback: write a one-line summary of the fix to `.canon/tmp/pr/followup/summary-<number>.md` in its own call, run `canon labels scan --body-file .canon/tmp/pr/followup/summary-<number>.md` against it, which applies the rule in `${CLAUDE_SKILL_DIR}/../git-pr/references/publish.md`, then post it with `gh api -X POST repos/{owner}/{repo}/issues/<number>/comments -F body=@.canon/tmp/pr/followup/summary-<number>.md --silent`. A hook on `Bash` runs the same scan on that body file and denies the post on a hit, and it refuses an inline `-f body=` value, so the body goes through a file. The `pull_request` check the git-pr surface carries triggers on a push or an open rather than a plain edit, so neither this comment nor the title and body step 7 synced reaches it.

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

@@ -7,32 +7,26 @@ description: What issue filing is for, the gaps it closes, and which reporting p
 
 ## Gap
 
-Without this skill, an issue takes the shape of whatever the session was saying. It arrives with no label, so triage cannot filter it, and without the sections a triage pass reads, so the reader has to reconstruct the problem from narrative. Prose bans hold on files the hook watches and not on text leaving through `gh`, so a banned character survives into a published artifact that then has to be edited on the remote.
+Without this skill, an issue takes the shape of whatever the session was saying. It arrives with no label, so triage cannot filter it, and without the sections a triage pass reads, so the reader reconstructs the problem from narrative.
+
+Prose bans hold on files the hook watches and not on text leaving through `gh`, so a banned character survives into a published issue that then has to be edited on the remote. A missing remote or an unauthenticated `gh` surfaces only after the body is written.
 
 ## Must
 
-- Read the issue reference and the prose standard before formatting
-- Confirm a remote and an authenticated `gh` before composing, so the failure lands before a body is written rather than after
-- Scan the title and body for banned characters and internal phase labels as an explicit step. Reading the standard does not catch them, because the text is generated after the read.
-- Map the type to exactly one label, so filing and filtering agree
-- Ask once when the type is ambiguous between a bug and a task, since the label follows from it and a wrong label buries the issue
-- Pass the body through a file and remove it afterward, so shell quoting cannot mangle it
+- The title and body follow the issue reference and are scanned for banned characters and phase labels before filing
+- Each issue carries exactly one label mapped from its type, asked once when the type is ambiguous between a bug and a task
+- A remote and an authenticated `gh` are confirmed before any body is composed
+- The body passes through a file that is removed afterward
 
 ## Must not
 
-- Invent an issue from a thin session. Nothing concrete in context is a stop rather than a prompt to elaborate.
+- Invent an issue from a thin session
 - File anywhere other than the current origin
 - Open a pull request
 - Emit anything after the result line
 
-## Guards
-
-- No concrete bug or task in session context: stop and say what to provide
-- No remote: stop and name what `gh issue create` needs
-- `gh` not authenticated: stop and name the command that authenticates
-
 ## Out of scope
 
-- Reporting a toolkit defect from a target project, which `canon-feedback` owns. That path opens an issue on the toolkit repository rather than the current one.
+- Reporting a toolkit defect from a target project, which `canon-feedback` owns
 - Triaging issues already filed, which `canon-feedback-triage` owns
 - Opening a pull request, which `git-pr` owns

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

@@ -7,47 +7,28 @@ description: What pull request generation is for, the gaps it closes, and what i
 
 ## Gap
 
-Without this skill, a pull request body is written from memory of the branch rather than from its diff, so it describes the intent and omits what the work turned into. Testing boxes get ticked from intent, which records what was meant to run instead of what ran, and a reviewer trusts the list. A second push either errors on create or opens a duplicate pull request, and banned characters survive into a body the hook never sees.
+Without this skill, a pull request body is written from memory rather than the diff, so it describes the intent and omits what the work became. Testing boxes get ticked from intent, a second push errors or opens a duplicate, and banned characters survive into a body the hook never sees. The body grows into a wall nothing measures.
 
-Every pull request also lands unlabelled, so a merged list is a wall of titles with no way to filter it by surface. A reader looking for what changed in one domain reads all of them, and the conventional commit type in the title says what kind of change it is rather than where.
-
-A lookup that resolves by head branch alone carries its own failure. A branch name reused after an earlier pull request merged resolves to the closed one, so the run rewrites a merged pull request's title and body and reports its URL as the one it opened. Both fields are recoverable only through the issue timeline and the edit history, and nothing reports that the write landed on the wrong object.
+Every pull request lands unlabelled, so a merged list cannot be filtered by surface. A head-branch lookup resolves a reused name to the merged pull request and rewrites it. A pull request changing a rendered surface reaches review with no screenshots, and a hand-written `Closes` line closes an issue on a middle slice or misses one the task names.
 
 ## Must
 
-- Refuse a branch name that does not conform, since the name lands on the pull request permanently and renaming it afterward breaks the link
-- Derive the title and body from the commits and the diff against main, with lockfiles excluded
-- Run each check before writing its line, then state the result the run reported
-- Leave a box unchecked only for a human-only case, naming which human and why on the same line
-- Scan the title and body for banned characters and internal phase labels as an explicit step, on top of reading the prose standard
-- Detect an open pull request and edit it in place, so a follow-up push keeps the body in sync instead of failing
-- Scope that detection to an open pull request on the current head and the default base, so neither a reused branch name nor a second base resolves the wrong one
-- Resolve the pull request once and reuse what that resolution returned, so the number recorded never depends on how a lookup ranks two pull requests sharing a head
-- Prove before every write to an existing pull request that its head is the current branch and its state is open, and refuse with nothing written on a mismatch, so a wrong number reaching a write never lands on another branch's pull request
-- Print the head branch beside the number, so a caller writing to the pull request later has a value to check the number against
-- Label from the paths the branch changed, against a map the project declares, so the label set belongs to the project rather than to the skill
-- Apply labels after the pull request exists, so a label the remote does not carry costs a warning rather than the pull request
-- Report a refused label, since a warning nothing surfaces leaves the run indistinguishable from one that labelled
-- End every pull request it opens or edits by invoking `pr-evidence` with the number it resolved, since a pull request changing a rendered surface otherwise reaches review with no screenshots, checklist, or address
+- The title and body come from the commits and the lockfile-free diff against main, scanned for banned characters, phase labels, and density, and every ticked box records a check this run executed
+- A follow-up run edits the one open pull request on the current head and default base, resolved once, and every write first proves that pull request's head and open state
+- Closing lines come from `canon tasks closes`, one `Closes #NNN` per issue on the task's last slice only, with the scan failing a body that disagrees
+- Labels come from the paths the branch changed against a map the project declares, applied after the pull request exists, with a refused label reported
+- The run closes by invoking `pr-evidence` with the number it resolved, and prints the head branch beside that number
 
 ## Must not
 
-- Tick a testing box from intent or from a past session. The box records a run.
-- Put a request for the reviewer in the Testing list, since a request is not a result
-- Create a second pull request when one is open
-- Edit a pull request that is not open, or record its number on a task
-- Name a domain of any one project in the skill body or its references
-- Create a label the map names and the remote lacks
+- Run on a non-conforming branch name or with no commits ahead of main
+- Tick a testing box from intent, or put a request for the reviewer in the Testing list
+- Create a second pull request, or edit one that is not open
+- Name a domain of any one project in the body or its references, or create a label the remote lacks
 - Emit anything after the result line
 
-## Guards
-
-- Branch name does not conform: stop and route to the skill that renames
-- No commits ahead of main: stop
-- No label map in the project: label nothing and warn nothing, since an absent map is a decision rather than a gap
-
 ## Out of scope
 
-- Naming the branch, which `git-branch` owns. This skill requires a conforming name and refuses without one rather than fixing it.
+- Naming the branch, which `git-branch` owns
 - Grouping the diff into commits, which `git-stage` owns
-- Pushing a later edit onto an already-open pull request, which `git-followup` owns. The overlap is real and the split is by state: this skill brings a pull request into existence and keeps it accurate, that one carries a fix onto one already under review.
+- Pushing a later edit onto a pull request already under review, which `git-followup` owns

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

@@ -75,6 +75,10 @@ Follow Testing discipline in `${CLAUDE_SKILL_DIR}/references/pr.md`. Run each ch
 
 Leave a box unchecked only for the human-only cases the reference defines, and name which human and why on the same line. A request for the reviewer is not a test result, so it belongs under `## For the reviewer` rather than in the Testing list.
 
+### Name the issues the pull request closes
+
+Ask `canon tasks closes` which issues this pull request closes before writing the body, and put one `Closes #NNN` line per issue last in `## Summary`. Read `${CLAUDE_SKILL_DIR}/references/closing-issues.md` on reaching this step for the invocation, the refusals it skips silently, and why an earlier slice of a sliced task carries none.
+
 ### Pre-publish scan
 
 Before running the final command, run the scan in `${CLAUDE_SKILL_DIR}/references/publish.md` against the PR title and body, on top of the banned phrases in `${CLAUDE_SKILL_DIR}/references/pr.md`. The title and body go straight to the remote, so run it whatever backs it downstream.
@@ -94,12 +98,14 @@ BODY
 Then run:
 
 ```bash
-canon labels scan --title "<title>" --body-file .canon/tmp/pr/body.md --json
+canon labels scan --title "<title>" --body-file .canon/tmp/pr/body.md --closes <numbers|none> --json
 ```
 
+Drop `--closes` when the closes step skipped a refusal, since no list was decided to grade against.
+
 ### Reading the scan
 
-Branch on the JSON record rather than the exit code, since a shell function wrapping `canon` can flatten a non-zero exit to 0. Stop and fix the title or body on any key below, and do not proceed to `### Final command` until a re-run comes back clean on all six.
+Branch on the JSON record rather than the exit code, since a shell function wrapping `canon` can flatten a non-zero exit to 0. Stop and fix the title or body on any key below, and do not proceed to `### Final command` until a re-run comes back clean on all nine.
 
 | Key                 | Fix                                                                                  |
 | ------------------- | ------------------------------------------------------------------------------------ |
@@ -109,6 +115,9 @@ Branch on the JSON record rather than the exit code, since a shell function wrap
 | `titleFormatIssues` | Fix the `## Title` rule in `pr.md` it names, being structure, casing, or length      |
 | `bannedCharacters`  | Restructure the sentence around the named character                                  |
 | `sections`          | Rename or drop each heading in `outside`, and add each required heading in `missing` |
+| `missingClosures`   | Add a `Closes #NNN` line for each number listed                                      |
+| `strayClosures`     | Delete the closing keyword for each number listed                                    |
+| `density`           | Regroup or split the named section per `## Formatting` in `pr.md`, keeping each path |
 
 Leave `cutsRelease` and `semverTags` alone, since a release-please pull request legitimately carries version references its own fixed shape explains.
 

package/claude/skills/git-pr/references/closing-issues.md

@@ -0,0 +1,47 @@
+---
+title: Close the task's issues
+description: How git-pr asks canon tasks closes which issues the pull request closes, the Closes line it writes into the body, the refusals it skips silently, and why an earlier slice carries none
+---
+
+# Close the task's issues
+
+Reached before the body is written. A task that cites `Issue: #NNN` ships and archives while its issue stays open unless the pull request body carries a closing keyword, and GitHub closes the issue only when that pull request merges into the default branch. `git-pr` always bases on the default branch, so no handling for another base is needed.
+
+## Ask the verb
+
+The plan is the one `task-number.md` names, so reuse the filename an earlier step already read.
+
+```bash
+canon tasks closes --plan feature-<slug> --json
+```
+
+The verb reads the current branch itself and counts the names it carried before a rename, so pass nothing else. Branch on the record rather than the exit code.
+
+| Record                                              | Route                                                                              |
+| --------------------------------------------------- | ---------------------------------------------------------------------------------- |
+| `ok: true`, `closing: true`                         | Write one `Closes #NNN` line per number in `issues`, and pass the list to the scan |
+| `ok: true`, `closing: false`                        | Write no closing line, and pass `--closes none` to the scan                        |
+| `ok: false`, `no-board`, `no-match`, or `ambiguous` | Write nothing and run the scan without `--closes`                                  |
+| Any other refusal                                   | Report it rather than swallowing it                                                |
+
+The three skipped refusals are the ones `task-number.md` skips, and for the same reason. A guessed task would close the wrong issue.
+
+## The line
+
+- Put the lines last in `## Summary`, after its sentences, one per issue
+- Write `Closes #NNN` with no trailing period, since GitHub reads the keyword and the number and a period adds nothing
+- Write one keyword per issue, because GitHub reads a keyword followed by a comma list as closing the first number alone
+
+The scan takes the same list, so a missing line or a closing keyword the verb did not name fails the body:
+
+```bash
+canon labels scan --title "<title>" --body-file .canon/tmp/pr/body.md --closes <numbers|none> --json
+```
+
+## Why an earlier slice carries none
+
+The verb applies the condition the merge-time archive applies, being no open outcome and no other branch on the task's `Pending branch:` line. The issue then closes exactly when the task archives. An earlier slice merging with a closing keyword would close the issue while later slices are still to ship.
+
+A re-run on an earlier slice's branch reads the same way. The verb looks up the branch's own pull request numbers, and one that is on the task's `Pull request:` line without being last reports `earlier-slice` and no closing line. The lookup runs over REST, and a failed one reports `lookup-failed` and no closing line once the task lists a pull request, since a failure cannot rule an earlier slice out.
+
+`git-ship` ticks the outcomes before `git-pr` runs, so the condition holds at body time. A run with outcomes not yet ticked reads as an earlier slice and writes no line. That is the safe side, since the issue stays open, and the record's `reason` names why.