@erclx/aitk 0.32.0 → 0.34.0

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

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.32.0",
+  "version": "0.34.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/bash-script/REQUIREMENT.md

@@ -0,0 +1,36 @@
+---
+name: bash-script
+description: Scope boundary for the interactive script house style and the stream discipline underneath it
+---
+
+# Bash script requirement
+
+## Gap
+
+Without this skill, a session asked for a human-facing shell tool writes one whose frame decoration, log lines, and prompts all land on stdout, so the script cannot be piped and any data it emits arrives mixed with its own presentation.
+
+Three more failures share a cause, which is that an interactive script is written as though a person is always watching. A prompt blocks forever when stdin is not a terminal, which is the shape every CI job and every agent run has. A cancellation path prints both a cancel line and an error, or an exit trap prints a closing frame the success path already printed, so the same run reports twice. And each generated script picks its own icons, casing, and frame characters, so a folder of them reads as several unrelated tools.
+
+The visual conventions this skill fixes are otherwise arbitrary. Their value is that they are the same across every script, which is a property no individual script can establish for itself.
+
+## Must
+
+- Keep every frame, log line, and prompt on stderr, and reserve stdout for data. `--help` is the one exception, since its consumer is a person rather than a pipe.
+- Guard every prompt on an attached terminal and refuse inside the frame rather than blocking on a read that will never return
+- Give the timeline one owner per exit path, so success, cancellation, and error each close it exactly once
+- Copy the shared templates rather than restating them, keeping only the colors and functions the script uses
+
+## Must not
+
+- Assert a convention the generated script cannot be checked against by reading it. A rule that cannot be verified from the output is style with no gate behind it.
+- Carry a second copy of the timeline, logging, or prompt implementations. The bundled reference is the single copy, and a body that restates it drifts from it.
+
+## Guards
+
+- A request for a script with no human at the terminal stops and routes to `cli-script` rather than generating a timeline nothing will render
+
+## Out of scope
+
+- Non-interactive automation, CI, and agent-run scripts: `cli-script`, which keeps the error handling and the stdout contract and drops the timeline, the icons, and the prompts
+- GitHub Actions workflow files: `ci-workflow`
+- What the generated script does. This skill fixes the shape of the output and the stream it goes to, and the commands belong to the request.

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

@@ -0,0 +1,35 @@
+---
+name: ci-workflow
+description: Scope boundary for pipeline structure against job contents, and the reproducibility rules under it
+---
+
+# CI workflow requirement
+
+## 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.
+
+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.
+
+## Must
+
+- Gate a job only on a data dependency or on a cost that justifies the wait, and leave every other job parallel
+- 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
+- Bound artifact upload to failures and set an expiry on it
+
+## 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.
+
+## Out of scope
+
+- The shell scripts a job invokes: `cli-script`
+- Secrets, environments, and deploy targets, which live in the repository settings rather than in the workflow this skill writes
+- CI systems other than GitHub Actions. The structure rules generalize and the file format does not, so a different system is a different skill rather than a flag on this one.

package/claude/skills/claude-groundwork/SKILL.md

@@ -12,7 +12,8 @@ Read `${CLAUDE_SKILL_DIR}/references/folder-format.md` before writing any file i
 ## Guards
 
 - If no topic is given, stop: `❌ No topic. Name what needs measuring.`
-- Apply the qualifying test before creating anything. Two of these three must hold: the current state is not known, more than one approach is live, and committing wrong costs more than a day of measuring. When one or fewer holds, stop: `❌ Already decided enough to plan. Run /claude-feature instead.`
+- Apply the qualifying test in open mode alone, after Step 1 resolves the mode and before the folder is created. Two of these three must hold: the current state is not known, more than one approach is live, and committing wrong costs more than a day of measuring. When one or fewer holds, stop: `❌ Already decided enough to plan. Run /claude-feature instead.`
+- Resume and close are exempt from the test above. A track that has already been measured fails it by definition, since its current state is now known and its approaches have narrowed, so applying the test to either mode refuses the folder that same test admitted.
 - Do not pause for approval between steps. The write scope below is what makes that safe.
 
 ## Write scope

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

@@ -15,6 +15,7 @@ Without this skill, the memory folder grows and never drains. Entries pile up re
 - Verify the rule is not already stated or implied in the target before proposing a promotion, by reading the target rather than trusting the memory's claim about it
 - Rewrite a rule into the destination's voice instead of moving it unchanged
 - Write the proposal to a receipt on disk and take no action until the user decides per item
+- Route every decision channel through the receipt, writing a decision given in chat into its item's slot before the parse reads the file, so a channel the skill advertises drains the pen rather than passing over it
 - Keep a promotion on its own commit, since a change to how the agent operates should not ride inside a feature a reviewer is vetting for something else
 - Confine the pass that runs after application to the one receipt it tested, so tidying up removes a file whose decisions are known to be resolved and leaves the pen and every untested receipt alone
 

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

@@ -181,7 +181,7 @@ Apply edits one at a time via `Edit`. Claude Code's tool permission dialog is th
 
 As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied, ⏭ for skipped, 🗑 for deleted, or 🤝 for handed off. Refresh the summary block counts at the top. Do not delete the review file. It stays as a receipt until Cleanup runs or the next Propose pass overwrites it.
 
-**Chat shortcut:** the user replies with `all`, `none`, or a comma-separated list of numbers. Apply only the numbered items.
+**Chat shortcut:** the user replies with `all`, `none`, a comma-separated list of numbers, or `skip <nums>`. Write the matching verb into the `Decision:` slot of every item the reply names, `apply` for `all` or a bare list and `skip` for a `skip` reply, then run the parse above against the file. A reply of `none` writes nothing. A slot the reply does not name keeps its own value, so the receipt stays the source of truth and an empty slot still means take no action.
 
 End with: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Omit empty buckets. If anything is pending, remind the user they can refine `Decision:` lines and re-ping, run "discuss" for question items, or commit a skip with `skip <nums>` in chat.
 

package/claude/skills/claude-orchestrate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: claude-orchestrate
-description: Asserts the orchestrator role for the current session, holds the build loop and the queue-refill sweep, and dispatches to the roadmap, feature, review, and worktree skills. Use when asked to "be the orchestrator", "run the orchestrator", "orchestrate this project", or to set up the control session for parallel feature builds. Do NOT build features or merge PRs in this session.
+description: Asserts the orchestrator role for the current session, holds the build loop and the queue-refill sweep, and dispatches to the feature, review, and worktree skills. Use when asked to "be the orchestrator", "run the orchestrator", "orchestrate this project", or to set up the control session for parallel feature builds. Do NOT build features or merge PRs in this session.
 disable-model-invocation: true
 ---
 
@@ -70,7 +70,7 @@ That command returns nothing for a roadmap that exists but has never been commit
 
 ## The loop
 
-1. Own the roadmap while a scope exists to sequence. Run `claude-roadmap` to draft or resequence `.claude/ROADMAP.md` from the MVP list in `.claude/REQUIREMENTS.md`, and skip it once that list has shipped, since later work then arrives as discrete items rather than as versions. Capture a needed resequence in the plan or a task file for a worker to apply in its branch, so the tracked edit ships in a PR rather than dirtying main.
+1. Own the roadmap while a scope exists to sequence. Capture a needed draft or resequence of `.claude/ROADMAP.md` in the plan or a task file, naming the MVP list in `.claude/REQUIREMENTS.md` as the source, so a worker runs `claude-roadmap` in its branch and the tracked edit ships in a PR rather than dirtying main. Stop owning it once that list has shipped, since later work then arrives as discrete items rather than as versions.
 2. Plan the next feature. Run `claude-feature` here, with the cross-feature context, to write a plan to `.claude/plans/`. Planning stays in this warm session so the plan front-loads reasoning a cold worker would otherwise re-derive.
 3. Decide parallelism and merge order. Note which plans touch a shared wiring seam so their PRs merge in sequence, not at once.
 4. Verify the plan against the tree. Reading it is not enough, since a plan goes stale from whatever merged after it was written. Grep for each construct it names and count the sites against the count it claims. Check that every phase label it cites is still open. Open each file it describes rather than trusting its account of the contents. Correct the plan before handing it over.

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

@@ -1,6 +1,6 @@
 ---
 name: claude-pr-review
-description: What the independent pull request review is for, the gaps it closes, and why it posts twice
+description: What the independent pull request review is for, the gaps it closes, and why it posts until nothing is open
 ---
 
 # Claude PR review requirement
@@ -11,11 +11,12 @@ Without this skill, a pull request is reviewed only by the session that wrote it
 
 ## Must
 
-- Post both passes. A first pass opens the review against the whole change, and a close-out confirms the prior findings landed.
+- Post until the review closes. A first pass opens against the whole change, and each later pass checks whether the prior findings landed.
+- Set the heading from the finding count rather than the pass number, so the most recent review comment's heading reports whether anything is open
 - 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 close-out to the commits added since the prior pass, once that commit is confirmed to still reach the head
+- 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
-- Post a close-out even with nothing to report, since a first pass left unanswered reads as a review nobody closed
+- Post the closing pass even with nothing to report, since a review left unanswered reads as one nobody closed
 - Key the body file on both the pull request number and the head commit, so no two passes overwrite each other
 - Scan the comment for banned characters and internal phase labels before posting, since a finding phrased against a phase label reaches a reader with no task board
 
@@ -23,7 +24,7 @@ Without this skill, a pull request is reviewed only by the session that wrote it
 
 - Merge. Review and post, and leave the gate to the human.
 - Publish a claim the skill did not check. A failed fetch and a rebase both strand the prior commit, and only one of them is a rebase.
-- Invent a third heading, or append a number GitHub already renders
+- Invent a heading beyond the two it posts and the response heading `claude-address-review` owns, or append a number GitHub already renders
 - Review local uncommitted changes
 - Lecture on process. The lenses land as findings, not as asides.
 

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

@@ -1,6 +1,6 @@
 ---
 name: claude-pr-review
-description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass under `## Review`, and a close-out under `## Review closed` that reads only the commits added since. Reads project docs and the roadmap for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes. That is `claude-review`.
+description: Reviews an open pull request from an independent session and posts findings as a review comment on the PR. Posts a first pass against the whole change and every later pass against only the commits added since, under `## Review` while anything is open and `## Review closed` once nothing is. Reads project docs and the roadmap for cross-feature context a self-review lacks. Use when asked to "review the PR", "review this feature's PR", "post a PR review", "re-review the PR", "close out the review", "confirm the findings are fixed", or acting as the orchestrator reviewing a worker's PR. Do NOT use to review local uncommitted changes. That is `claude-review`.
 ---
 
 # Claude PR review
@@ -10,9 +10,12 @@ This is the orchestrator's independent review, distinct from `claude-review`.
 to disk. This one reviews an open PR the session did not write and posts the
 findings to the PR, so the vantage is independent and the output is durable.
 
-It posts twice over a pull request's life. A first pass opens the review against
-the whole change. A close-out confirms the findings are closed and reads only
-the commits added since. Both are this skill, and the pass is detected from the
+It posts at least twice over a pull request's life. A first pass opens the
+review against the whole change, and every later pass reads only the commits
+added since. The heading reports state rather than pass number: a pass carrying
+findings takes `## Review`, and `## Review closed` is reserved for a pass
+carrying none, so the most recent comment's heading reports where the review
+stands. Every pass is this skill, and which one it is gets detected from the
 thread rather than named by the caller.
 
 ## Guards
@@ -42,7 +45,7 @@ Find the commit the last pass covered:
 gh pr view <number> --json reviews --jq '[.reviews[] | select(.body // "" | split("\n")[0] | rtrimstr("\r") | . == "## Review" or . == "## Review closed")] | last | .commit.oid'
 ```
 
-Match the first line for equality against the two headings this skill posts. A prefix test also matches `## Review response` and any heading merely starting with those words, which would scope the close-out to whatever commit that comment carried. The `\r` trim covers a body composed in the GitHub web editor, which stores CRLF.
+Match the first line for equality against the two headings this skill posts. A prefix test also matches `## Review response` and any heading merely starting with those words, which would scope the pass to whatever commit that comment carried. The `\r` trim covers a body composed in the GitHub web editor, which stores CRLF.
 
 An empty result is a first pass. Read the whole change:
 
@@ -54,7 +57,7 @@ gh pr diff <number>
 gh pr diff <number> --name-only
 ```
 
-A commit is a close-out. Fetch the pull request head so both commits are local:
+A commit is a later pass. Fetch the pull request head so both commits are local:
 
 ```bash
 git fetch -q origin pull/<number>/head
@@ -82,7 +85,7 @@ Review the diff and files for the same axes as `claude-review` (bugs, edge cases
 
 Apply the high-signal filter: flag only what will cause incorrect behavior, break a documented rule, or mislead a downstream feature. If uncertain, do not flag.
 
-A close-out applies the same axes to the delta, and adds one check the first pass cannot make: did each prior finding land, and did the fix regress anything it touched. Findings of its own are normal findings, stated at the same severity and counted the same way.
+A later pass applies the same axes to the delta, and adds one check the first pass cannot make: did each prior finding land, and did the fix regress anything it touched. Findings of its own are normal findings, stated at the same severity and counted the same way. That count is what Step 4 reads to pick the heading, so a pass raising one of its own is not a close-out.
 
 Use severity: `critical` (blocks merge), `should-fix` (fix before merge), `minor` (visibility only).
 
@@ -109,10 +112,10 @@ X critical, Y should-fix, Z minor. Reviewed against project docs and roadmap.
 🤖 Reviewed by Claude Code
 ```
 
-A close-out keeps that shape and changes the heading and the summary line:
+A later pass carrying findings keeps that shape and changes only the summary line:
 
 ```markdown
-## Review closed
+## Review
 
 Re-reviewed `<short-sha>`, N commits since the prior pass. X critical, Y should-fix, Z minor.
 
@@ -123,9 +126,13 @@ Re-reviewed `<short-sha>`, N commits since the prior pass. X critical, Y should-
 🤖 Reviewed by Claude Code
 ```
 
-Open a first pass with `## Review` and a close-out with `## Review closed`, so a reader scanning the thread can tell an open review from a confirmation that its findings are closed without opening either. Both anchor as a section distinct from human threads. Do not invent a third heading, and do not append the PR number, which GitHub already renders above the comment.
+The heading reports whether anything is open and the summary line reports which pass this is. Post under `## Review` whenever the pass carries a finding at any severity, whether it is the first pass or the fourth. Reserve `## Review closed` for a pass carrying none, which makes it the marker worth scanning for rather than a label on a kind of pass. A pull request thread then reads as `## Review`, the worker's answer under `## Review response` from `claude-address-review`, another `## Review` while anything is still open, and `## Review closed` when nothing is.
+
+Read the state off the most recent review comment rather than off the presence of a closed one. A close-out does not close the pull request, so a commit pushed after it gets its own pass, and that pass reopens the review under `## Review` when it raises anything.
 
-Name the scope in the close-out summary line, since a reader cannot otherwise tell a narrow read from a full one. When the fallback in Step 2 fired, replace the commit count with `Re-reviewed the full change, the prior pass's commit is no longer on the branch`. Budget the body. State each finding as the failure and the fix in two or three sentences, not a paragraph of reasoning. Omit files with no findings. Do not lecture on process. The integration, contract, and consumer lenses stay, but as findings, not asides.
+Both of this skill's headings anchor as a section distinct from human threads. Do not invent one beyond those two and the `## Review response` a sibling owns, and do not append the PR number, which GitHub already renders above the comment.
+
+Name the scope in every summary line after the first pass, since a reader cannot otherwise tell a narrow read from a full one. When the fallback in Step 2 fired, replace the commit count with `Re-reviewed the full change, the prior pass's commit is no longer on the branch`. Budget the body. State each finding as the failure and the fix in two or three sentences, not a paragraph of reasoning. Omit files with no findings. Do not lecture on process. The integration, contract, and consumer lenses stay, but as findings, not asides.
 
 The `What is right` section is optional, capped at three bullets, and included only when it changes the merge decision. Drop it otherwise and let the summary line carry the approval.
 
@@ -137,9 +144,7 @@ Before posting, run the scan in `.claude/standards/publish.md` against the body,
 gh pr review <number> --comment --body-file .claude/.tmp/pr-review/body-<number>-<short-sha>.md
 ```
 
-If a first pass has no findings, post this body instead, under the same `## Review` heading and with the footer included: `✅ No blocking findings. Reviewed against project docs and roadmap.` followed by the footer line.
-
-If a close-out has no findings, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.` under `## Review closed`, again with the footer. Post it even when there is nothing to report. A first pass left with no closing comment reads as a review nobody answered.
+A pass with no findings takes `## Review closed` and a short body, with the footer line included either way. On a first pass, post `✅ No blocking findings. Reviewed against project docs and roadmap.` On a later pass, post `✅ Prior findings addressed. Re-reviewed <short-sha>, N commits since the prior pass.` Post that one even when there is nothing to report. A review left with no closing comment reads as one nobody answered.
 
 ## Step 5: output
 

package/claude/skills/claude-seed-sync/REQUIREMENT.md

@@ -0,0 +1,40 @@
+---
+name: claude-seed-sync
+description: Scope boundary for section-granular seed reconciliation against the bulk install and sync commands
+---
+
+# Claude seed sync requirement
+
+## Gap
+
+Without this skill, a project that edited an installed seed or standard has two ways to take an upstream change and both lose something. `aitk standards install` overwrites every file, so the edits are gone with no record of what they were. `aitk standards sync` updates only files it already finds and adds none, so a standard written after the project installed never arrives at all. Neither can deliver one upstream section into a file the project has customized, which is the case a grown project is always in.
+
+A whole-file diff does not close it either. It cannot separate a section the user rewrote on purpose from a section the toolkit moved on without them, so the choice reaches the user as accept everything or lose everything, and the safe answer is always to skip.
+
+Two failures belong to the audit rather than to the diff. A decision taken in chat dies with the session, so an audit half applied cannot be resumed and the second run starts over. And a file the toolkit generates rather than ships, such as an index rebuilt from sibling frontmatter, is absent from every source catalog by design, so a naive comparison reports it as a local addition and invites the user to reconcile something nothing owns.
+
+## Must
+
+- Read seed and standard content from the CLI rather than holding a copy, so the audit and the install cannot disagree
+- Diff per section, treating the preamble as a section of its own
+- Separate a customized section from a stale one, and default the customized one to no action
+- Persist the proposal and every decision to a review file that stays the source of truth across re-pings
+- Apply one section at a time, never by rewriting a file
+
+## Must not
+
+- Propose removing a section present only in the target. Those are the customizations the skill exists to preserve.
+- Write a target file before a decision is recorded against the item
+- Read an empty decision slot as consent
+
+## Guards
+
+- No `aitk` on PATH, or no `.claude/` directory at the project root, stops before any read
+
+## Out of scope
+
+- Bulk install and sync of a whole domain, which `aitk <domain> install` and `aitk <domain> sync` own and `toolkit-cli` documents. Reach for this skill when the target holds edits worth keeping, and for those commands when it does not.
+- Golden configs, which overwrite by design and carry no section structure to diff
+- Governance rules: `aitk gov sync`
+- First-time scaffold of a project that has installed nothing yet: `setup-init`
+- Public `README.md` and `docs/` prose: `docs-sync`

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

@@ -121,7 +121,7 @@ Re-read the review file as source of truth. For each item, parse `Decision:`:
 - `defer` or empty: leave 📝 pending, no action.
 - Contains `?` or unrecognized verb: leave 📝 pending, no action.
 
-Chat shortcut: the user replies with `all`, `none`, or a comma-separated list of numbers. Apply only the numbered items.
+Chat shortcut: the user replies with `all`, `none`, a comma-separated list of numbers, or `skip <nums>`. Write the matching verb into the `Decision:` slot of every item the reply names, `apply` for `all` or a bare list and `skip` for a `skip` reply, then run the parse above against the file. A reply of `none` writes nothing. A slot the reply does not name keeps its own value, so the receipt stays the source of truth and an empty slot still means take no action.
 
 Apply edits one at a time via `Edit`, replacing one section at a time. Never rewrite a whole file. Claude Code's tool permission dialog is the confirmation gate per edit.
 

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

@@ -0,0 +1,38 @@
+---
+name: docs-sync
+description: Scope boundary for consumer-facing prose against the agent-facing docs the ship chain syncs beside it
+---
+
+# Docs sync requirement
+
+## Gap
+
+Without this skill, a rename or a dropped flag ships with the README still describing the old surface. Nothing fails, because no test reads prose, so the doc stays wrong until a person hits it.
+
+Three failures belong to the sync itself rather than to the drift. A session that syncs by rewriting whole files churns sections the change never reached, which costs the reviewer the ability to tell the sync from the feature. A doc edited earlier in the same session reads as current while a later change leaves one of its sections stale, so file-level classification passes where section-level would not. And a hardcoded doc list never checks the file someone added after the list was written.
+
+The quiet one is the baseline. A diff resolved against a bare local ref equals HEAD on `main` and on a branch before its first commit, so every committed change drops out of the set. The skill then reports nothing to sync, which reads as a clean result rather than as an admission that it could not see the work.
+
+## Must
+
+- Resolve one merge base, prefer the remote ref over the local one, and reuse it everywhere the skill reads the diff
+- Say so in the output when the baseline degrades, rather than reporting a clean pass off a set it could not build
+- Discover the doc set by glob at run time
+- Classify and rewrite at section level, so a partly stale file is partly rewritten
+- Write immediately after the preview, since the tool permission dialog is the confirmation gate
+
+## Must not
+
+- Touch a section the change does not reach
+- Rewrite a doc to match the diff when the doc records an intent the diff departed from. That is a finding rather than a sync.
+
+## Guards
+
+- No committed change and no working-tree change stops the skill before it reads any doc
+
+## Out of scope
+
+- `.claude/` planning docs, tasks, plans, and context entries: `claude-docs`, which runs immediately before this skill in the ship chain and resolves the same baseline. The split is by audience, so a file's location decides which skill owns it rather than its subject.
+- `CLAUDE.md` and the installed seed docs: `claude-seed-sync`, which reconciles them per section against the toolkit source
+- Changelog entries, which release tooling generates from commit messages
+- Whether the prose conforms to its standards. `claude-standards-audit` reports violations and fixes none, and this skill writes prose it does not audit.

package/docs/agents.md

@@ -399,6 +399,8 @@ The table check reports a catalog that grows a row per shipped thing, not a tabl
 
 The provenance check reports the markers narrating how a domain reached its shape rather than describing what it is: a date, a change number, or a release label. The standard admits a rejected alternative and the reasoning that killed it while refusing the provenance attached to it, so a marker names a line to read rather than a line to delete. Findings group by entry and sort left to right within a line, since what a reader acts on is which file to open. Fenced blocks are excluded, which keeps a pinned version in an install command from reading as a claim the entry makes. Frontmatter is excluded with them, since the content checks read the body alone, and that is what keeps a diagram entry's dated `verified` stamp a record of its last check rather than a marker to settle. Length is the exception, counting the whole file, so a reader applying the 150-rendered-line checkpoint against the body alone lands a few lines under what the tool reports.
 
+This one check covers `.claude/context/` alone, while length, depth, and the table finding reach every audited folder. The rule is stated in `.claude/standards/context.md`, which opens its scope by handing diagrams and wireframes to `diagrams.md` and `wireframes.md`, and the sibling standards do not restate it. A marker reported in a diagram entry would cite a rule that entry's own standard routes elsewhere. The split is between kinds of rule rather than kinds of folder: a threshold on how far a reader travels generalizes across entry types, while a rule about what an entry may say is the jurisdiction a scope statement exists to settle. The scoping key is the folder an entry was audited under, so `--folder` still reaches a folder the default list does not carry, and a domain split into `context/<sub-area>/` is governed as `context`. Every run states the reach, including a run where no audited folder is the governed one. The JSON record carries it as `checkpoints.provenanceFolder` and a per-folder `governsContent`.
+
 Index drift compares an index against its siblings in both directions. An entry the index does not link is invisible to a session choosing what to open, and a linked name resolving to nothing sends one to a path that opens nothing.
 
 ### The citation gate
@@ -413,15 +415,15 @@ What remains is a sentence naming a hypothetical entry to show the shape of a na
 
 Use these to discover what's available instead of hardcoding names.
 
-| Command                          | Returns                                      |
-| -------------------------------- | -------------------------------------------- |
-| `aitk tooling list --json`       | Stacks, extends chain, dep and script counts |
-| `aitk snippets list --json`      | Presets and categories with their slugs      |
-| `aitk standards list --json`     | Standards docs and the paths each governs    |
-| `aitk gov list --json`           | Governance stacks and rule sets              |
-| `aitk claude seeds list --json`  | Seed doc sources with content                |
-| `aitk claude skills list --json` | Plugin skills with their descriptions        |
-| `aitk docs list --json`          | Consumer docs plus per-domain context        |
+| Command                          | Returns                                       |
+| -------------------------------- | --------------------------------------------- |
+| `aitk tooling list --json`       | Stacks, extends chain, dep and script counts  |
+| `aitk snippets list --json`      | Presets and categories with their slugs       |
+| `aitk standards list --json`     | Standards docs and the paths each governs     |
+| `aitk gov list --json`           | Governance stacks and rule sets               |
+| `aitk claude seeds list --json`  | Seed doc sources with content                 |
+| `aitk claude skills list --json` | Plugin skills, descriptions, requirement flag |
+| `aitk docs list --json`          | Consumer docs plus per-domain context         |
 
 Every catalog serializes through `JSON.stringify`, so a name carrying a quote
 emits valid JSON. `aitk tooling list` and `aitk snippets list` previously built
@@ -448,6 +450,12 @@ or unparseable returns an empty description rather than failing the listing, so
 one malformed file cannot hide the rest of the catalog. `--names` emits skill
 names one per line.
 
+Each entry also carries `requirement`, whether the folder holds a sibling
+`REQUIREMENT.md`. Coverage of that file is selective by design, so a `false` is
+not a gap to close and the flag answers which skills carry one without a caller
+listing the directory itself. It says nothing about why, which is a judgment the
+toolkit records against its own corpus rather than in the catalog.
+
 ## Non-interactive examples
 
 ```bash

package/docs/ai-workflow.md

@@ -68,7 +68,7 @@ When features are independent, run them in parallel instead of sequentially. Use
 - Ship each worktree separately with `aitk:git-ship`
 - For full autonomy per worktree, invoke `aitk:claude-autoship` instead of the manual chain. Approve the plan, walk away, come back to draft PRs.
 
-To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `aitk:claude-orchestrate`. It owns the roadmap via `aitk:claude-roadmap`, plans each feature, refills the ready queue so a free worker never waits, and reviews each worker's PR with `aitk:claude-pr-review`, while workers address the posted findings with `aitk:claude-address-review`. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
+To run several worktrees as a coordinated flow rather than ad hoc, assert the orchestrator role in one warm session with `aitk:claude-orchestrate`. It owns the roadmap, handing a needed draft or resequence to a worker that runs `aitk:claude-roadmap` in its branch, plans each feature, refills the ready queue so a free worker never waits, and reviews each worker's PR with `aitk:claude-pr-review`, while workers address the posted findings with `aitk:claude-address-review`. The human launches workers and merges. See [operating model](operating-model.md) for the full loop.
 
 Roadmap ownership holds while a scope exists to sequence. Once the MVP list in `.claude/REQUIREMENTS.md` has shipped, later work arrives as discrete items and the orchestrator reads `.claude/tasks/priority.md` for execution order instead.
 
@@ -131,11 +131,11 @@ Before the first feature session on a UI-heavy project, pick a design tier. The
 | `aitk:claude-groundwork`     | Before a plan is warranted, measure an unknown in a scratch folder under `.claude/.tmp/groundwork/`                  |
 | `aitk:claude-feature`        | Before implementation, scan for conflicts and ambiguities                                                            |
 | `aitk:claude-roadmap`        | Sequence MVP scope into ordered versions in `.claude/ROADMAP.md`                                                     |
-| `aitk:claude-orchestrate`    | Assert the orchestrator role, refill the ready queue, and dispatch the roadmap, feature, and review skills           |
+| `aitk:claude-orchestrate`    | Assert the orchestrator role, refill the ready queue, and dispatch the feature, review, and worktree skills          |
 | `aitk:claude-diagram`        | Draft per-kind mermaid entries under `.claude/diagrams/` from architecture and code, then verify each rendered image |
 | `aitk:claude-design-extract` | Draft `.claude/DESIGN.md`, sourcing tokens from existing UI code or proposing them from requirements on day one      |
 | `aitk:claude-review`         | In a fresh session, review all changes since main                                                                    |
-| `aitk:claude-pr-review`      | Review an open PR from an independent session, then close the review out against the commits added since             |
+| `aitk:claude-pr-review`      | Review an open PR from an independent session, then re-review the commits added since until nothing is open          |
 | `aitk:claude-address-review` | Address PR findings and CI status, refresh stale docs, then push a follow-up                                         |
 | `aitk:claude-tasks`          | Add a task to `.claude/tasks/` or archive a shipped one out of the folder                                            |
 | `aitk:claude-docs`           | When decisions diverged from plan, update `.claude/` docs                                                            |

package/docs/operating-model.md

@@ -29,12 +29,12 @@ dispatch, not logic.
 
 One feature travels this path end to end.
 
-1. Orchestrator drafts or resequences the roadmap with `claude-roadmap`, reading scope from `.claude/REQUIREMENTS.md`. The skill stops when that file carries a later scope section, since the MVP list it sequences has shipped and a fresh requirements pass owns what follows.
+1. Orchestrator captures a needed roadmap draft or resequence in the plan or a task file, naming `.claude/REQUIREMENTS.md` as the scope source, and a worker runs `claude-roadmap` in its branch so the tracked edit ships in a PR. The skill stops when that file carries a later scope section, since the MVP list it sequences has shipped and a fresh requirements pass owns what follows.
 2. Orchestrator plans the next feature with `claude-feature`, writing a plan to `.claude/plans/`. Planning stays in the warm session because good planning is cross-feature. It needs the contract other features consume and the shared wiring seam. A cold session would re-derive or guess.
 3. The human opens a worker worktree with `claude-worktree` and runs `claude-autoship` against the plan. The worker builds, self-checks, opens a PR, and stops at the PR boundary.
 4. Orchestrator reviews the PR with `claude-pr-review` and posts findings to it.
 5. Worker addresses the findings with `claude-address-review`, then pushes a follow-up.
-6. Orchestrator closes the review out with `claude-pr-review` again. The second pass reads only the commits the follow-up added and posts under `## Review closed`, so the thread shows one review ending rather than a second one opening.
+6. Orchestrator closes the review out with `claude-pr-review` again. The second pass reads only the commits the follow-up added, and posts under `## Review closed` when it finds nothing open or under `## Review` when it does, so a reader learns the state from the heading. Repeat from step 5 until the review closes.
 7. The human reads the result and merges. The orchestrator tells any trailing worker to rebase when its branch shares a seam with the merged one.
 
 There is no loop construct here. Each worker is a single build that halts at the
@@ -58,11 +58,12 @@ merge is the final gate. No layer repeats another.
 
 Review travels on the PR, not through chat. `claude-pr-review` posts findings to
 the PR. `claude-address-review` reads them back, fixes each, replies or resolves
-the threads, and pushes a follow-up. `claude-pr-review` then runs a second time
-to close the review out, reading only what the follow-up added.
+the threads, and pushes a follow-up. `claude-pr-review` then runs again, reading
+only what the follow-up added.
 
-The two passes carry different headings, `## Review` and `## Review closed`, so
-a thread can be scanned for state without opening either comment. The feedback
+The heading carries the state rather than the pass number. A pass with a finding
+takes `## Review` and a pass with none takes `## Review closed`, so a thread can
+be scanned for what is still open without opening a comment. The feedback
 becomes a durable artifact both sessions read, survives a session ending, and
 anchors to the change. That removes the copy-paste that otherwise routes review
 through the human between two sessions.

package/governance/rules/claude/510-context.md

@@ -10,6 +10,7 @@ paths:
 
 - Before non-trivial work in a domain, read its `.claude/context/<domain>.md` entry. Use `.claude/context/index.md` to find it.
 - Leave the entry conforming when work in its domain changes what it describes.
+- Rewrite the decision a change supersedes rather than appending a second one narrating the transition.
 
 ## Authority
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.32.0",
+  "version": "0.34.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/src/claude/skills-list.ts

@@ -6,6 +6,7 @@ const FRONTMATTER = /^---\n([\s\S]*?)\n---/
 export interface SkillListing {
   readonly name: string
   readonly description: string
+  readonly requirement: boolean
 }
 
 /**
@@ -15,6 +16,10 @@ export interface SkillListing {
  *
  * The folder name wins over the frontmatter `name` when they disagree, because
  * Claude Code invokes a skill by its directory.
+ *
+ * `requirement` reports whether the folder carries `REQUIREMENT.md`. Coverage is
+ * selective by design, so a false is not a gap to close and this field carries no
+ * reason for one. The toolkit records those separately from the catalog.
  */
 export function listSkills(root: string): SkillListing[] {
   const skillsRoot = join(root, 'claude', 'skills')
@@ -30,6 +35,7 @@ export function listSkills(root: string): SkillListing[] {
   return paths.map((path) => ({
     name: dirname(path),
     description: readDescription(join(skillsRoot, path)),
+    requirement: existsSync(join(skillsRoot, dirname(path), 'REQUIREMENT.md')),
   }))
 }
 

package/src/commands/context.ts

@@ -2,9 +2,11 @@ import { resolve } from 'node:path'
 import type { Command } from 'commander'
 import {
   type EntryReport,
+  governsContent,
   LENGTH_CHECKPOINT,
   measureFolders,
   PEER_BULLET_CHECKPOINT,
+  PROVENANCE_FOLDER,
   RENDER_WIDTH,
   RUN_CHECKPOINT,
 } from '@/context/audit'
@@ -90,8 +92,8 @@ function parseFolders(list: string | undefined): string[] | string {
 
   if (names.length === 0) return 'Empty --folder list. Pass at least one name.'
 
-  // `..` would resolve the audit root above `.claude/`, where `presentNames`
-  // has no folder name to slice out and hands the citation pattern undefined.
+  // `..` would resolve the audited folder above `.claude/`, taking the scan
+  // and the citation pattern outside the tree the audit describes.
   const invalid = names.filter((name) => !FOLDER_NAME.test(name))
   if (invalid.length > 0) {
     return `--folder takes folder names under .claude/, not paths: ${invalid.join(', ')}`
@@ -138,7 +140,7 @@ async function runAudit(
     reportLength(entries)
     reportDepth(entries)
     reportTables(entries)
-    reportProvenance(entries)
+    reportProvenance(entries, folders)
     reportDrift(drift)
     outro()
   }
@@ -150,6 +152,7 @@ async function runAudit(
         folders: folders.map((folder) => ({
           path: folder.rel,
           entries: folder.entries.length,
+          governsContent: governsContent(folder),
         })),
         citations: {
           scanned: citations.scanned,
@@ -164,6 +167,7 @@ async function runAudit(
           runCountsBlankLines: true,
           renderWidth: RENDER_WIDTH,
           peerBullet: PEER_BULLET_CHECKPOINT,
+          provenanceFolder: PROVENANCE_FOLDER,
         },
       })}\n`,
     )
@@ -332,9 +336,28 @@ function reportTables(entries: readonly EntryReport[]): void {
  * time, and a flat list of those buries the entries holding one. What a reader
  * acts on is which file to open, so the count sits beside the name and the
  * lines follow it.
+ *
+ * The reach is stated on every run, including the run where nothing is in
+ * scope. A check that covered three folders and now covers one reads as quietly
+ * missing things unless the report says which folder it measured.
  */
-function reportProvenance(entries: readonly EntryReport[]): void {
+function reportProvenance(
+  entries: readonly EntryReport[],
+  folders: readonly AuditedFolder[],
+): void {
   logStep('Provenance')
+
+  const governed = folders.filter(governsContent)
+  if (governed.length === 0) {
+    logInfo(
+      `Out of scope. The rule is stated in the standard governing .claude/${PROVENANCE_FOLDER}/, and no audited folder is that one.`,
+    )
+    return
+  }
+
+  logInfo(
+    `Covers .claude/${PROVENANCE_FOLDER}/ alone, whose standard carries the rule. The sibling standards do not restate it.`,
+  )
   logInfo('Fenced blocks are excluded. A marker is a judgment, never a defect.')
 
   const carrying = entries

package/src/context/audit.ts

@@ -61,6 +61,25 @@ const PROVENANCE: readonly { kind: ProvenanceKind; pattern: RegExp }[] = [
   { kind: 'release', pattern: /\bv\d+\.\d+(?:\.\d+)?\b/g },
 ]
 
+/**
+ * The folder whose standard carries the exclusion above.
+ *
+ * `standards/context.md` opens its scope by handing diagrams and wireframes to
+ * `diagrams.md` and `wireframes.md`, so a marker reported in either would cite
+ * a rule that entry's own standard routes elsewhere. The length, depth, and
+ * table checkpoints are quoted from the same standard and keep reaching every
+ * audited folder, because a threshold on how far a reader travels generalizes
+ * across entry types while a rule about what an entry may say does not.
+ *
+ * Restating the exclusion in the sibling standards was the alternative. It
+ * duplicates one knowledge item across three surfaces, which the root
+ * instruction file forbids, and pointing is not available because the surface
+ * they would point at is the one disclaiming them. Should a diagram entry ever
+ * accumulate narration, the escalation is an attribute standard owning the rule
+ * across document types, not restoring this reach without an owner.
+ */
+export const PROVENANCE_FOLDER = 'context'
+
 export type ProvenanceKind = 'date' | 'change' | 'release'
 
 export interface TableFinding {
@@ -95,6 +114,7 @@ export interface EntryReport {
   /** First line of the longest run, or 0 when the entry has no run at all. */
   readonly longestRunLine: number
   readonly catalogTables: readonly TableFinding[]
+  /** Empty for an entry no standard bans a change narrative in. */
   readonly provenance: readonly ProvenanceFinding[]
 }
 
@@ -320,7 +340,18 @@ function provenance(lines: readonly BodyLine[]): ProvenanceFinding[] {
     .map((each) => each.finding)
 }
 
-export function measureEntry(rel: string, source: string): EntryReport {
+/**
+ * Measures one entry, scanning for provenance only when a standard claims it.
+ *
+ * The caller passes jurisdiction rather than deriving it from `rel`, because a
+ * path prefix hardcodes what `--folder` exists to override and misses a domain
+ * split into `context/<sub-area>/`.
+ */
+export function measureEntry(
+  rel: string,
+  source: string,
+  governsContent = true,
+): EntryReport {
   const lines = bodyLines(source)
   const run = longestRun(lines)
 
@@ -333,7 +364,7 @@ export function measureEntry(rel: string, source: string): EntryReport {
     longestRun: run.length,
     longestRunLine: run.line,
     catalogTables: catalogTables(lines),
-    provenance: provenance(lines),
+    provenance: governsContent ? provenance(lines) : [],
   }
 }
 
@@ -341,6 +372,9 @@ export function measureEntry(rel: string, source: string): EntryReport {
  * Measures every entry in the audited folders. A generated `index.md` is not
  * among them, since its body is rewritten on every regen and no checkpoint
  * describes a catalog.
+ *
+ * Jurisdiction is applied here rather than at the report, so the JSON record
+ * and the printed run agree on which entries a content rule reached.
  */
 export async function measureFolders(
   root: string,
@@ -351,10 +385,19 @@ export async function measureFolders(
   for (const folder of folders) {
     for (const path of folder.entries) {
       reports.push(
-        measureEntry(relative(root, path), await readFile(path, 'utf8')),
+        measureEntry(
+          relative(root, path),
+          await readFile(path, 'utf8'),
+          governsContent(folder),
+        ),
       )
     }
   }
 
   return reports
 }
+
+/** Reports whether the folder's standard is the one carrying the exclusion. */
+export function governsContent(folder: AuditedFolder): boolean {
+  return folder.name === PROVENANCE_FOLDER
+}

package/src/context/folders.ts

@@ -18,6 +18,13 @@ export const DEFAULT_FOLDERS: readonly string[] = [
 ]
 
 export interface AuditedFolder {
+  /**
+   * The requested folder name this was resolved under, which is what says
+   * which standard governs the entries. A nested split folder carries the name
+   * of the folder it sits beneath rather than its own, so
+   * `.claude/context/claude-plugin` is governed as `context`.
+   */
+  readonly name: string
   /** Repo-relative folder path, used verbatim in every report line. */
   readonly rel: string
   readonly indexPath: string
@@ -35,7 +42,7 @@ export interface AuditedFolder {
  * here for the sole reason that this repository has no wireframes.
  */
 export function presentNames(folders: readonly AuditedFolder[]): string[] {
-  return [...new Set(folders.map((folder) => folder.rel.split('/')[1]))]
+  return [...new Set(folders.map((folder) => folder.name))]
 }
 
 async function readEntries(dir: string): Promise<string[]> {
@@ -80,6 +87,7 @@ export async function resolveFolders(
 
     for (const each of [...new Set(dirs)].sort()) {
       folders.push({
+        name,
         rel: relative(root, each),
         indexPath: `${each}/${INDEX_FILE}`,
         entries: await readEntries(each),

package/standards/context.md

@@ -105,6 +105,7 @@ Only the `development` entry carries this section. It is not a general-purpose h
 - Both checkpoints count rendered lines, so wrap each source line at 80 columns and sum the heights. Source lines undercount an entry authored one line per bullet, where a block of fifteen paragraph-bullets occupies fifteen lines and renders past sixty. Counting the two checkpoints in different units would put a file measured one way beside a run measured another.
 - Exempt a block whose lines are all list items at one level averaging under roughly 130 characters. A flat list of short peers is already navigable, and a subheading dropped into it splits a set that belongs together. Bullet count says nothing on its own, since a catalog of one-liners and a stack of paragraphs reach the same count and read nothing alike, so weight is what decides. Mixing prose with the list, or nesting levels inside it, ends the exemption at any weight.
 - Never cut a `## Decisions` or `## Gotchas` entry to shorten a file. Cut a `## Layout` or `## CLI` section instead.
+- Retire a decision or gotcha once its subject is gone, rewriting the bullet to state the current design rather than leaving the narration of what it replaced beside it. A rejected alternative is not a retired one, so what was tried and why it lost stays whatever its age. The rule above protects content whose subject is live, and this one releases content whose subject is not.
 - Split into a folder (`.claude/context/<domain>/<sub-area>.md`) when a domain has three or more sub-areas that do not fit cleanly in one file. That split is the natural ceiling.
 - Keep a split domain's `index.md` generated. The catalog body is rewritten on every regen, so the domain's own overview and layout belong in a sibling file rather than in it, and the `subtitle` is what names the file to start with.
 - Author a catalog that grows a row per shipped thing as a bullet list, never a markdown table. A table pads its columns to a shared width, so one row outgrowing its column reflows every row and turns a one-line edit into a whole-file rewrite that conflicts with any sibling branch. This is what forced the split above.

package/standards/tasks.md

@@ -48,7 +48,33 @@ Readiness is three groups under fixed headings, `## Run now`, `## Up next`, and
 - `## Up next`: a written plan exists, and the task either collides with something running or waits on another task to land. The blocker column names which.
 - `## Needs a plan`: everything else. The task has no plan, or the plan it carries no longer describes the work.
 
-Each group fixes its own columns, which follow from the test above it rather than from preference. `## Run now` carries `Task`, `Touches`, and `Plan`, since neither half of its test is checkable without the last two. `## Up next` carries `Task`, `Touches`, and `Waiting on`, the last naming whether a collision or a dependency holds it. `## Needs a plan` carries `Task` and `Waiting on` alone, because a task with no plan has no bounded file set to state.
+Each group fixes its own columns, which follow from the test above it rather than from preference. Neither half of the `## Run now` test is checkable without the file set and the plan sitting beside the task. The blocker column under `## Up next` names whether a collision or a dependency holds the row. `## Needs a plan` states no file set at all, because a task with no plan has no bounded one to state. A group with no rows keeps its heading and its header row.
+
+```markdown
+---
+title: Priority
+description: One line on what the board covers
+---
+
+# Priority
+
+## Run now
+
+| Task                            | Touches                 | Plan                                 |
+| ------------------------------- | ----------------------- | ------------------------------------ |
+| [vXX.Y <slug>](vXX.Y-<slug>.md) | <what the task touches> | [<slug>](../plans/feature-<slug>.md) |
+
+## Up next
+
+| Task | Touches | Waiting on |
+| ---- | ------- | ---------- |
+
+## Needs a plan
+
+| Task                            | Waiting on                              |
+| ------------------------------- | --------------------------------------- |
+| [vXX.Y <slug>](vXX.Y-<slug>.md) | <the collision or the task it waits on> |
+```
 
 The tests live here so the board does not carry them. Writing them as a sentence under each heading produces the paragraph the rule above deletes, and a criterion with no home gets restated from memory every time the board is touched.