@erclx/aitk 3.43.2 → 3.45.0

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

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

package/claude/skills/{toolkit-cli → aitk-cli}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-cli
+name: aitk-cli
 description: Why the overwrite contract is stated before a sync runs, and why the skill reads rather than executes
 ---
 
-# Toolkit cli requirement
+# Aitk cli requirement
 
 ## Gap
 
@@ -15,7 +15,7 @@ The inverse failure is quieter. A session that assumes a sync will pick up a cha
 
 Being reachable is a separate problem from being right. This is a pure reference whose moment happens inside another skill's run, so nothing brings it up unless a body names it. Three sibling requirement files named it and routed nothing, because Claude Code loads `SKILL.md` as the entry and never opens the sibling. A route lives in a body or it does not exist, and a fourth requirement mention would repeat the same defect.
 
-The two bodies now carrying an inline pointer are `claude-seed-sync` and `toolkit-operator`, each at the point it runs or prints an overwriting command.
+The two bodies now carrying an inline pointer are `claude-seed-sync` and `aitk-operator`, each at the point it runs or prints an overwriting command.
 
 ## Must
 
@@ -36,6 +36,6 @@ The two bodies now carrying an inline pointer are `claude-seed-sync` and `toolki
 
 ## Out of scope
 
-- Executing the sync, which the user runs or `toolkit-operator` routes
+- Executing the sync, which the user runs or `aitk-operator` routes
 - Reconciling a customized seed section by section: `claude-seed-sync`
 - Deciding which stack, rule, or standard a project should install, which the setup skills resolve from live catalogs

package/claude/skills/{toolkit-cli → aitk-cli}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: toolkit-cli
+name: aitk-cli
 description: Reference for what aitk sync and install commands overwrite, merge, or leave untouched in a target project. Use before running `aitk tooling`, `aitk standards`, `aitk claude sync`, or `aitk init`, or when asked "will this overwrite my changes". Do NOT use to run the commands, only to know their effect.
 ---
 

package/claude/skills/{toolkit-feedback → aitk-feedback-file}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-feedback
+name: aitk-feedback-file
 description: Why a toolkit defect is reported from session context alone, and what shipping through the CLI replaces
 ---
 
-# Toolkit feedback requirement
+# Aitk feedback file requirement
 
 ## Gap
 
@@ -35,6 +35,6 @@ The last failure is the session's own effort. Asked to report, a session starts
 ## Out of scope
 
 - Fixing the defect, which happens in the toolkit repository against its own source
-- Draining the queue this fills: `toolkit-triage`
+- Draining the queue this fills: `aitk-feedback-triage`
 - Filing an issue against the current project: `git-issue`
 - Complaints about tooling the toolkit does not own

package/claude/skills/{toolkit-feedback → aitk-feedback-file}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-feedback
+name: aitk-feedback-file
 description: Format a paste-back report about something broken, missing, or off in aitk and write it directly to the toolkit's `.claude/review/feedback/` folder via `aitk feedback`. Use when asked to "send this to the toolkit", "report this to aitk", "file toolkit feedback", or "give the toolkit feedback about X". Do NOT use for general complaints about other tooling, IDE issues, or in-project bugs that do not implicate aitk surfaces.
 ---
 
-# Toolkit feedback
+# Aitk feedback file
 
 Format a `## Toolkit feedback` block from the current session, then ship it to the toolkit repo without manual copy-paste.
 

package/claude/skills/{toolkit-triage → aitk-feedback-triage}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-triage
+name: aitk-feedback-triage
 description: Why the feedback queue is read from GitHub rather than local scratch, and why triage routes instead of implementing
 ---
 
-# Toolkit triage requirement
+# Aitk feedback triage requirement
 
 ## Gap
 
@@ -35,6 +35,6 @@ The queue also fails to drain even when the work ships. A fix merged with no lin
 
 ## Out of scope
 
-- Filing new feedback: `toolkit-feedback`
+- Filing new feedback: `aitk-feedback-file`
 - Writing the plan a plan-worthy issue needs: `claude-feature`
 - Triage of issues carrying any other label, which surface here by design only under the feedback label

package/claude/skills/{toolkit-triage → aitk-feedback-triage}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-triage
-description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `toolkit-feedback`), or for general GitHub issue triage unrelated to toolkit feedback.
+name: aitk-feedback-triage
+description: Triage open GitHub issues labeled `feedback` in the toolkit repo. List them, pick one, classify it as a direct fix or plan-worthy work, route to the right skill, and link the issue for close-out. Use when asked to "triage toolkit feedback", "work through the feedback issues", "process feedback issues", or "what feedback is open". Do NOT use to file new feedback (that is `aitk-feedback-file`), or for general GitHub issue triage unrelated to toolkit feedback.
 ---
 
-# Toolkit triage
+# Aitk feedback triage
 
 Consume the feedback queue that `aitk feedback --github` fills. Turn an open `feedback` issue into a scoped fix or a plan, then link the issue so merge closes it.
 

package/claude/skills/{toolkit-operator → aitk-operator}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: toolkit-operator
+name: aitk-operator
 description: Why the toolkit has one front door, what orienting on live catalogs prevents, and where it hands off
 ---
 
-# Toolkit operator requirement
+# Aitk operator requirement
 
 ## Gap
 
@@ -56,6 +56,6 @@ The last failure is a section no route reaches. `## Route` maps an intent or a d
 - First-time scaffold of a fresh project: `setup-init`
 - Seed and preamble drift in installed files: `claude-seed-sync`
 - Governance rule install and index bootstrap: `setup-gov` and `setup-indexes`
-- What a given sync overwrites once it runs: `toolkit-cli`
+- What a given sync overwrites once it runs: `aitk-cli`
 
 That last contract carries no row for the governance install this skill routes to, so the overwrite `Must` above reads nothing at one of its own destinations. The row belongs to the skill owning the table. This file records the silence rather than answering it, since a rule written here for a silent contract teaches a session that silence means safe.

package/claude/skills/{toolkit-operator → aitk-operator}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: toolkit-operator
+name: aitk-operator
 description: Front door to the toolkit in a target project. Orients on the toolkit's own docs and live `aitk` catalogs, then runs or routes any toolkit operation from a plain-language intent. Use when you want one entry point instead of picking a specific setup or sync skill, or when asked to "use the toolkit", "what can the toolkit do", "sync my standards", "install rules", or "help me set up this project". User-invoked only. Defers first-time scaffold to setup-init and seed drift to claude-seed-sync.
 disable-model-invocation: true
 ---
 
-# Toolkit operator
+# Aitk operator
 
 Front door to the toolkit. Orient first, then run the simplest operation that satisfies the intent or hand off to the owning skill. Never bypass `aitk` to edit managed files by hand.
 
@@ -90,7 +90,7 @@ The last row is a skill handoff rather than a command, so `## Execute` does not
 For operations this skill runs directly:
 
 - Read the catalog first with `aitk <domain> list --json`, then match against project context
-- Read the `toolkit-cli` skill before any install or sync, and warn the user by name about each surface it lists as overwritten. A command name says nothing about what it does to a file already there, and this skill is the one running it.
+- Read the `aitk-cli` skill before any install or sync, and warn the user by name about each surface it lists as overwritten. A command name says nothing about what it does to a file already there, and this skill is the one running it.
 - Run the CLI with `AITK_NON_INTERACTIVE=1` so it skips prompts. The tool permission dialog is the confirmation gate.
 - Report the command run and what changed. Emit the full relative path for any file written.
 - Re-run `aitk sync --check . --json` after any operation that wrote, and compare it against the report `## Diagnose` read before acting

package/claude/skills/aitk-rollout/REQUIREMENT.md

@@ -0,0 +1,59 @@
+---
+name: aitk-rollout
+description: Why one skill carries both roles of an outbound wave, and where its boundary sits against the seven skills that operate inside a target
+---
+
+# Aitk rollout requirement
+
+## Gap
+
+Without this skill, a toolkit change reaches its consuming projects by hand. One measured pass across four targets took four hand-written `cd <path> && claude --bg` invocations, each carrying a brief composed by hand from that project's review. Nothing enumerated the targets, nothing derived the brief, and nothing applied a convention across the set.
+
+The conventions were already settled and reached none of the four. The branch and title shape was answered and reconfirmed, and the four pull requests carried four titles across two scopes, neither of them the settled one, with three naming the toolkit in the half of the shape that withholds it. A convention nothing applies holds only where somebody remembers it.
+
+The return leg dead-ends outside this repository. A review that posts a finding on a target's pull request has to reach the session holding that branch, and every dispatch guessed instead. All four sessions that opened those pull requests were still alive holding their worktrees hours later, two fresh addressers were sent over them, one refused on the worktree lock, and one cut a second worktree on the same branch, which would have put two sessions pushing to one ref.
+
+A wave ends without telling the operator what to do. Reading where four targets stood took a hand-written shell loop over four repositories, re-run three times as reviews landed, and every status line it produced named a repository and a number and no link. Merging is the one act only the operator performs, and they reached each result by navigating to it by hand.
+
+A worker's reply reads as done when it is not. One pull request's fix for two minor findings closed both and introduced four more, all in prose the fix added, including a claim about a workflow that runs on a trigger it does not declare. A loop that closes a target on the worker's word merges that.
+
+## Must
+
+- Enumerate the targets from the record the install writes, with the sweep as the fallback and its stated bound read before any count is trusted, since a hand census of this population was wrong in both directions at once
+- Write the branch and the title from a fixed shape rather than leaving either to the dispatched session, since the settled convention reached none of four hand-driven repairs
+- Carry one line in each target's body naming the toolkit as the source and where to change the content upstream, since a reader in that repository has no other route to the fact that a local edit is lost at the next wave
+- Name no toolkit version in any target's body, since the install stamp in that target already records `syncedAt` and a sha256 per synced file and a version string is the copy that goes stale
+- Dispatch one worker per target, with the branch checked as unclaimed in that target before the launch
+- Branch from the clone that is current rather than from whichever the record names first, since a working copy answers what that machine last pulled rather than what the target holds
+- Resolve who holds a branch before dispatching an addresser, and dispatch a fresh one only where the resolver reports the owning session gone
+- Address every finding whatever its severity, and close a target only when a narrow re-review posts `## Review closed`
+- Name a pull request URL on every line that reports a target, at dispatch and at hand-back both
+- Close a wave by naming every target with its URL, review heading, CI state, and what is owed, the targets needing nothing included
+
+## Must not
+
+- Merge anything, in either role, at any size. The operator holds that gate over every role rather than as a setting on a wave.
+- Reimplement what `aitk targets list`, `aitk targets pulls`, or `aitk sessions list --repository` already answers. Each is a shipped verb this body reads under `AITK_NON_INTERACTIVE=1`.
+- Restate the in-target diagnosis and routing that `aitk-operator` owns, or the review, address, and worktree procedures the three skills named below own
+- Read or write this repository's task board. The board is `claude-orchestrate`'s subject and a wave is not a row on it.
+- Bound the review and address loop with a count. The bound was declined with its failure mode stated, and what guards the loop is the orchestrator reviewing every round itself.
+- Edit a managed file in a target by hand rather than through the `aitk` verb that owns it
+- Be a skill nothing invokes but its author typing the name. Nothing else routes to it, since it carries `disable-model-invocation: true` and no sibling body names it, so a wave that only ever runs when somebody types the name is the signal that the loop never replaced the hand-driven pass it was built against.
+
+## Guards
+
+- `gh` absent: stop, since no target's pull request can be read or opened
+- The target index reads as unknown with no sweep behind it: stop and name the reason, rather than reporting a population of zero
+- The claim check refuses or comes back with either readability flag false: treat the target as unverified rather than clear and hand it to the operator
+- Every clone of a target is behind its remote: refuse that target rather than branching from a stale base
+- More than one session holds a target's branch: report the ambiguity and stop, rather than sending findings to whichever row came first
+
+## Out of scope
+
+- This repository's own board, queue, and worker dispatch, which `claude-orchestrate` holds
+- The role a session building one branch under one plan in this repository takes, which `claude-worker` holds. A rollout worker does not take it, since that body resolves session scratch against a main worktree root a target does not carry.
+- Entering the worktree, which `claude-worktree` owns, including the branch collision tests it runs before entry
+- Diagnosing what a target is behind on and routing each finding to its command, which `aitk-operator` owns
+- Posting a review to a pull request and moving its heading, which `claude-pr-review` owns
+- Answering a posted review inside the target, which `claude-address-review` owns
+- The commit and the pull request mechanics, which the `git-*` family owns

package/claude/skills/aitk-rollout/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: aitk-rollout
+description: Takes one toolkit change out to every consuming project and brings each to a mergeable pull request. Carries an orchestrator role that enumerates the targets, dispatches a worker into each, reviews every pull request, and routes what each review posts, and a worker role that builds inside one target and answers its review. Use when asked to "roll this out to the targets", "take this change to every project", "run a rollout wave", "update the consuming projects", or when a session was dispatched into a target by a wave. Do NOT use for this repository's own board, which is `claude-orchestrate`, and merge nothing.
+disable-model-invocation: true
+---
+
+# Aitk rollout
+
+This skill runs outward. Every other skill for operating on a target assumes the session already sits inside it, and this one starts in the toolkit and reaches the projects the toolkit installed into.
+
+One wave takes one toolkit change to every target and ends with a pull request per target for a person to merge. Two roles carry three phases over one target list. The orchestrator enumerates, dispatches, reviews, and routes. The worker holds one target from the worktree entry to the merge of the branch it opened.
+
+`claude-orchestrate` owns this repository's own board and is a different subject. Read nothing from `.claude/tasks/` here and write nothing to it.
+
+## Take a role before anything else
+
+- The invocation or the launch prompt names the worker role, a target path, or both: worker. Skip to `## The worker role` and run no phase above it.
+- Neither is named: orchestrator. Run the three phases in order.
+
+The role is read off the prompt because nothing else carries it. A dispatched worker starts in the target's own checkout, which is a repository like any other from the session's side, so a test on the working directory answers the same for a worker in a target and an operator who invoked this from one. Reading the role wrong in that direction starts a second wave from inside a consuming project, which is why the dispatch below names the role and the path both rather than relying on either alone.
+
+Do not invoke `aitk:claude-worker` from either role. That body states the role for a session building one branch under one plan in this repository, and it resolves session scratch against a main worktree root a target does not carry, so a rollout worker reading it hunts for a plan nobody wrote.
+
+## Guards
+
+- `gh` absent from the path: stop. `❌ gh is not installed, so no target's pull request can be read or opened.`
+- `aitk targets list` refuses, or reports the index as unknown with no `--sweep` behind it: stop and name the reason. A count of zero taken from an index nothing read is a confident wrong answer.
+- Read a record's own `reason` field rather than a command's exit status. An operator's shell profile may wrap `aitk` in a function whose status comes from a trailing command, which reports every refusal as success.
+- Neither role merges anything, at any size and with no proportionality exception. A wave ends by handing the operator a list to merge from, and merging is the one act only they perform.
+
+## The fixed shape every target receives
+
+Every target in every wave takes the same branch and the same title, written from here rather than chosen per session. Four hand-driven repairs produced four titles across two scopes, neither of them this one, and three named the toolkit in the half of the shape that withholds it.
+
+- Branch: `chore/agents`, in every target and every wave.
+- Title: `chore(agents): <what changed in that target>`.
+- Body: the sections `${CLAUDE_SKILL_DIR}/../../standards/pr.md` fixes, describing what that target received.
+- Body, one line: name this toolkit as the source of the changed files and where to change the content upstream. A reader in that repository months later has no other route to the fact that these files are toolkit-managed and that a local edit is lost at the next wave.
+- Body, no version number anywhere in it. `${CLAUDE_SKILL_DIR}/../../standards/versioning.md` permits a semver tag only where the pull request cuts a release, and `.claude/aitk/config.json` in the target already records `syncedAt` and a sha256 per synced file. A version in the body is a second copy of a fact the target holds canonically, and it is the copy that goes stale while the pull request sits open.
+
+The title withholds the source and the body supplies it, because the two have different audiences. `agents` says what changed without saying where it came from, which is what a target's own history wants, and the source line is for a reader inside that repository rather than for whoever merges.
+
+One branch name across every target is also what lets the return leg resolve. `aitk sessions list --branch chore/agents --repository <clone>` answers about that project rather than the working one, and a branch each session named for itself gives that read nothing to match.
+
+## Phase 1: enumerate and dispatch
+
+### Read the population
+
+1. Pin the wave. Record the commit of this repository that the wave carries and name it in this session's own reports. Name it in no target's body.
+2. Enumerate. Run `aitk targets list --json` under `AITK_NON_INTERACTIVE=1`, adding `--sweep <root...>` to reach targets installed before the index existed. Read the `bound` object back before treating any count as the population, since it names the roots walked, the depth, where the walk stopped, and what it could not read. The bound a sweep can never state is the machine, so a target on another one sits outside every answer it gives.
+3. Pick the clone that is current. A row carries every checkout of that project under `paths` and leads with the one a sync ran in, which records where an install happened rather than what the checkout holds today. Fetch each candidate, compare it against the origin's default branch, and dispatch into one that is level. Refuse one that is behind rather than branching from a stale base, since three clones read as still owing the repair in one census and every one of them was behind its remote and nothing else.
+
+### Check, then dispatch
+
+4. Check the branch is unclaimed in that target. Run `aitk sessions list --branch chore/agents --repository <clone> --json` and read `claimed` off the record.
+   - `claimed: true`: something already holds it. Report what does, `worktree` when it names a path, `sessions` when it carries a row, and `refs` when the branch already exists, then leave that target out of the wave rather than colliding.
+   - `claimed: false` with `sessionsReadable` and `refsReadable` both true: dispatch.
+   - Anything else, a refusal or a record carrying no `claimed` key included: treat the target as unverified rather than clear, name which reading could not be taken, and hand it to the operator to launch by hand. Dispatching on a check that could not be read reproduces the collision the check exists to prevent.
+5. Dispatch one worker per target, one session each.
+
+```bash
+cd <clone> && claude --bg --model <model> -n "rollout-<target>" "Run /aitk:aitk-rollout in the worker role against the target at <clone>. <what the wave carries>"
+```
+
+`--bg` returns immediately, `-n` sets the name that separates a wave's worker from an operator's own launch in the roster, and `--model` overrides the inheritance that otherwise spends this session's model on every worker. Keep the `rollout-` prefix.
+
+Running the targets in turn is the alternative and it puts every target's diff through one session's context. A wave's spend scales with the target count instead, and nothing caps it, so weigh the count before widening rather than after.
+
+Report each dispatch by naming the target, the clone, the branch, the model, and the session name. Carry the pull request URL into every later report from the moment its worker announces one.
+
+## Phase 2: review every pull request
+
+1. Poll. Run `aitk targets pulls --json`, naming the wave's clones as arguments to read those alone. A target comes back as `read` with a `pulls` array or as `refused` with a `reason`, and a refusal is not a target with no work. Reading a failed query as no open work reports a target as done having read nothing.
+2. Review here, in this session. Invoke `aitk:claude-pr-review` and redirect every call that body makes, since it resolves a pull request from the repository the session stands in and this session stands in the toolkit. Every call takes a redirect, and the ones that silently answer about the wrong repository are worse than the ones that fail:
+   - `--repo <owner>/<name>` on `gh pr view`, `gh pr diff`, and `gh pr review`, where it is a global flag.
+   - `-C <clone>` on `git fetch origin pull/<n>/head`, `git merge-base`, `git diff`, `git log`, `git show`, and `git grep`.
+   - `GH_REPO=<owner>/<name>` on any `gh api repos/{owner}/{repo}/...` call, which is the close-out route. `gh api` takes no `--repo` flag and fills those placeholders from the working directory or from that variable, so the one call a flag cannot redirect is the one that edits a review in place.
+   - That project's own root file, rules, and context, read from under the clone.
+
+   A missed redirect reports rather than fails. A pass that redirects the `gh` half and leaves a `git` call alone reads this repository's history against a target's diff and reports a delta, which is a finding nobody can trace back to the call that produced it.
+
+   This session wrote none of these diffs, so reviewing them costs nothing in independence.
+
+3. Dispatch a reviewer into the target when a diff is too large for this session to hold. That is the fallback rather than the default. Dispatching one per target was measured and what it saved was reading four diffs, not reading four sets of findings, and that second half reaches this session either way, since routing a finding back means composing the brief from it.
+4. Read the heading each pass posted. `aitk targets pulls` reports `review` as `open`, `closed`, or `null` when no pass has landed, and reports `reviewReadable` as `false` when the query failed, which leaves `review` covering nothing.
+
+## Phase 3: route every finding and close each target
+
+1. Address every finding whatever its severity. A minor is a finding, and a reviewer calling one non-blocking does not close the pass that raised it.
+2. Resolve who holds the branch before dispatching anybody. Run `aitk sessions list --branch chore/agents --repository <clone> --json` and read the count rather than the first row.
+   - A live session holds it: send that session the findings and name `aitk:claude-address-review` for it to run, which is step 6 of `## The worker role` and the step that session already stands at. Never name this skill in that message. This body carries `disable-model-invocation: true`, which blocks the `Skill` tool rather than only suppressing an auto-trigger, and a session acting on an inbound message reaches a skill that way and no other, so a message naming this one halts the address leg with the branch built and the findings unread. A launch prompt is the one route to a flagged body, which is why the dispatch above names this skill and this message must not. Assuming the worker was gone is what one hand-driven pass got wrong. All four sessions that opened those pull requests were still alive holding their worktrees hours later, and of two fresh addressers sent over them, one refused on the worktree lock and one cut a second worktree on the same branch, which would have put two sessions pushing to one ref.
+   - No live session holds it: dispatch a fresh worker into that clone and brief it with the findings, since it holds none of the reasoning behind the diff.
+   - More than one row: report the ambiguity and stop rather than picking among candidates.
+3. Re-review when the answer lands, scoped to the commits added since. A worker's reply never closes a target. One fix for two minor findings closed both and introduced four more, every one of them in prose that fix added, and a loop trusting the reply merges that.
+4. A target leaves the wave when a pass posts `## Review closed` and not before.
+5. Run until every target closes. No count bounds the loop. What guards it is this session reviewing every round itself, so it holds what each pass found and can see a target failing to converge, where a dispatched reviewer reads one pass and knows nothing of the one before it. A worker introducing a finding per fix has nothing mechanical stopping it, which is accepted rather than overlooked.
+
+## The worker role
+
+One session, one target, from the worktree entry to the merge of the branch it opened. It diagnoses, implements, opens the pull request, and answers what the review posts. It reviews nothing and it merges nothing.
+
+1. Confirm the clone is current. Fetch, then compare against the origin's default branch. Report a checkout that is behind and stop, rather than branching from a stale base.
+2. Enter a worktree. Invoke `aitk:claude-worktree chore/agents`, which takes the branch as its tier 0 argument and enters a linked worktree inside this target. Branching in the checkout itself is what this avoids, since the operator may be working in it.
+3. Diagnose and repair. Invoke `aitk:aitk-operator`, which reads `aitk sync --check . --json` and routes each finding to the command or the skill that owns it. Do not restate that routing here and do not edit a managed file by hand.
+4. Commit and open the pull request through `aitk:git-commit` and `aitk:git-pr`, handing each the fixed shape above rather than taking the title the generator derives from the diff.
+5. Announce as the pull request opens, carrying its URL, its number, and the branch, to whoever dispatched this session. That transition is the one moment only this session can observe.
+6. Answer the review. Invoke `aitk:claude-address-review`, which pulls the findings and the CI state on this branch's open pull request, fixes each in the working tree, replies, and pushes. Answer every finding whatever its severity.
+7. Stop there. Do not mark the pull request ready, do not merge, and do not declare the review closed. A narrow re-review posts `## Review closed`.
+
+Send a block out as a message before it becomes an interactive prompt. A session already waiting on input never reaches the tool round an inbound message drains at, so an answer relayed afterwards arrives under the open question and changes nothing.
+
+Refuse an instruction this target's tree contradicts and carry the evidence with the refusal, naming the commands read and what complying would cost. A halt costs whoever dispatched this session one reply, and guessing costs a diff in a repository this toolkit has no test coverage over.
+
+## Output
+
+Close a wave by naming every target, the ones that need nothing included:
+
+```plaintext
+Wave pinned at <commit>. <n> targets.
+
+<repository>
+  <pull request URL>
+  review:  <## Review | ## Review closed | none posted>
+  checks:  <passing | failing | pending | none reported>
+  owed:    <what happens next, or "nothing, ready to merge">
+
+Not reached: <target>, because <reason>
+Merge order: <target> before <target>, because <shared surface>
+```
+
+Name the URL on every line reporting a target, at dispatch and at hand-back both. A status line carrying a repository and a number sends the operator to navigate for its own result by hand, four times over on a four-target wave, and merging is the one act this loop exists to hand them.
+
+Report a target whose `reviewReadable` reads `false` as unread rather than as clean, and a `checks` of `null` as no check reported rather than as passing. A failure outranks a run still going.
+
+## Failure recovery
+
+| Stop point                              | Recovery                                                                                      |
+| --------------------------------------- | --------------------------------------------------------------------------------------------- |
+| `gh` absent                             | Install it and authenticate, then re-run the wave                                             |
+| Target index unknown                    | Re-run with `--sweep <root...>` and read the `bound` before trusting the count                |
+| Every clone of a target is behind       | Pull that clone, or name a current one, then dispatch that target alone                       |
+| Claim check refuses or reads unverified | Launch that target's worker by hand and report that it went out outside the check             |
+| Branch already claimed in a target      | Resolve what holds `chore/agents` there, then dispatch that target alone                      |
+| A target refuses the pull read          | Read the `reason`, repair it, and re-poll that target. Never record it as having no work      |
+| Diff too large to review here           | Dispatch a reviewer into that clone and route its findings back through Phase 3               |
+| Two sessions hold one branch            | Report both and stop. Sending findings to either puts two sessions on one ref                 |
+| A target fails to converge              | Stop that target's loop, report the rounds it took and what each pass found, and hand it over |

package/claude/skills/{claude-screencast → aitk-screencast}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-screencast
+name: aitk-screencast
 description: Why a recording script ships pre-seeded rather than blank, what the four discovery questions buy, and why the draft stays stack-agnostic
 ---
 
-# Claude screencast requirement
+# Aitk screencast requirement
 
 ## Gap
 
@@ -35,5 +35,5 @@ A draft that names the recording software, the editing software, or the window m
 
 - Producing the recording, which stops at the script by design
 - Refining an existing draft, which is a direct edit of the file
-- Slide decks, which `claude-slides-draft` owns
+- Slide decks, which `aitk-slides-draft` owns
 - Where the recording ships, which the draft lists and the user decides

package/claude/skills/{claude-screencast → aitk-screencast}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: claude-screencast
+name: aitk-screencast
 description: Drafts a screencast script with pre-seeded beats, defaults, and decisions to `.claude/.tmp/screencast/<slug>.md`. Reads project context, asks four discovery questions with proposed defaults, then writes a shippable draft. Use when asked to "draft a screencast", "write a recording script", "plan a demo video", or "scaffold a screencast for X". Do NOT re-invoke to refine an existing draft. Re-running overwrites. Edit the draft file directly.
 ---
 
-# Claude screencast
+# Aitk screencast
 
 ## Guards
 

package/claude/skills/{claude-slides-draft → aitk-slides-draft}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: claude-slides-draft
+name: aitk-slides-draft
 description: Why the skill owns deck content and the CLI owns layout, and why one render is read back before the deck is called done
 ---
 
-# Claude slides draft requirement
+# Aitk slides draft requirement
 
 ## Gap
 
@@ -36,4 +36,4 @@ Reimplementing spacing and palette logic is the failure that survives the sessio
 - Rendering, which the CLI owns end to end
 - The palette and the type scale, which live in the CLI rather than in the source
 - Writing the content the deck is about, which the caller brings
-- Recording a demo, which `claude-screencast` owns
+- Recording a demo, which `aitk-screencast` owns

package/claude/skills/{claude-slides-draft → aitk-slides-draft}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: claude-slides-draft
+name: aitk-slides-draft
 description: Drafts a `.claude/SLIDES.md` source from a topic, picks a layout per slide, then renders it to PowerPoint via `aitk slides render`. Use when asked to "draft slides", "make a deck", "build a presentation", "turn this into slides", or "render a SLIDES.md". Holds the deck design rules. Do NOT reimplement render logic. The CLI owns layout and styling. Assumes the `aitk` CLI is on PATH.
 ---
 

package/claude/skills/{cli-script → bash-cli-script}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: cli-script
+name: bash-cli-script
 description: What a non-interactive automation script owes its caller, and the stdout contract that separates it from the human-facing generator
 ---
 
-# CLI script requirement
+# Bash CLI script requirement
 
 ## Gap
 

package/claude/skills/{cli-script → bash-cli-script}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: cli-script
+name: bash-cli-script
 description: Generates non-interactive Bash scripts for automation, CI, and agent-run tasks. Lean functional style with structured logging, strict error handling, and a clean stdout, no interactive UI. Use when asked for "a non-interactive shell script", an automation script, a CI or cron script, or a pipeline helper. Do NOT use for a human-facing interactive tool with prompts or a visual timeline UI, that is `bash-script`.
 ---
 
-# CLI script
+# Bash CLI script
 
 Generate non-interactive Bash scripts for automation, CI, and agent-run workflows. Optimize for robustness and composability, not visual polish. For a human-facing interactive tool with prompts and a timeline UI, use `bash-script` instead.
 

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

@@ -27,10 +27,10 @@ The visual conventions this skill fixes are otherwise arbitrary. Their value is
 
 ## 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
+- A request for a script with no human at the terminal stops and routes to `bash-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
+- Non-interactive automation, CI, and agent-run scripts: `bash-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/bash-script/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bash-script
-description: Generates production Bash scripts with a visual timeline UI, state-based interactive prompts, and strict error handling. Use when asked for "a human-facing shell tool", an interactive bash script, or a DevOps tool with framed terminal output. Do NOT use for a non-interactive automation, CI, or pipeline script, that is `cli-script`.
+description: Generates production Bash scripts with a visual timeline UI, state-based interactive prompts, and strict error handling. Use when asked for "a human-facing shell tool", an interactive bash script, or a DevOps tool with framed terminal output. Do NOT use for a non-interactive automation, CI, or pipeline script, that is `bash-cli-script`.
 ---
 
 # Bash script
@@ -11,7 +11,7 @@ Load `${CLAUDE_SKILL_DIR}/references/patterns.md` for the timeline lifecycle, lo
 
 ## Guards
 
-- A request for a script with no human at the terminal stops and routes to `cli-script`. CI jobs, cron entries, agent-run tasks, and any script whose output is consumed by a pipe render no timeline, so generating one costs the frame and returns nothing.
+- A request for a script with no human at the terminal stops and routes to `bash-cli-script`. CI jobs, cron entries, agent-run tasks, and any script whose output is consumed by a pipe render no timeline, so generating one costs the frame and returns nothing.
 
 ## Script setup
 

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

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

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

@@ -67,7 +67,7 @@ For each in-scope entry (see Scope), pick one action:
 - **Promote to a standards file**: the rule is an authoring reference that belongs in the project's own standards folder as `<domain>.md`.
 - **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `.claude/context/index.md`. Append it to `.claude/.tmp/memory-routing/<slug>.md` in the format `claude-memory-capture` writes, and tell the user to run `/claude-docs` from a branch. Do not edit the context entry here.
 - **Hand off to governance**: the rule is coding-standards class (typescript, testing, naming, error-handling, performance, logging, concurrency, planning). Do not author the rule file inline. Never edit the synced `.claude/rules/` copies of toolkit rules, because `aitk gov sync` overwrites them. Stop at handoff.
-  - In the toolkit repo, point the user at `aitk-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
+  - In the toolkit repo, point the user at `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
   - In a target project, point the user at the `create-rule` skill, which scaffolds a project-local rule under `.claude/rules/`.
 - **Retire**: the rule is stale, already absorbed into a durable surface, too vague to phrase as a rule, or a one-time incident narrative. Apply moves the file to `.claude/.tmp/memory-archive/` rather than deleting it.
 
@@ -134,7 +134,7 @@ Before applying any item, check the worktree state:
 
 If the result is `MAIN`, stop and tell the user: `❌ Apply phase mutates tracked files. Run /claude-worktree first.` Discuss and Challenge phases only touch `.claude/review/` scratch and run from anywhere.
 
-Before applying a promote to root `CLAUDE.md`, load `aitk-claude` so its seed-mirror rule fires on the edit.
+Before applying a promote to root `CLAUDE.md`, load `internal-claude` so its seed-mirror rule fires on the edit.
 
 Promotions are a separate concern from any feature in flight. Keep the promoted edits on their own commit. Do not fold a `CLAUDE.md` or skill-body change into a feature's commits, because a feature reviewer should not have to vet a change to how the agent operates.
 

package/claude/skills/claude-memory-review/references/receipt-format.md

@@ -45,4 +45,4 @@ Decision:
 
 ## Variation by action
 
-For Hand off items, the body is a pointer to the governance target instead of a rewritten rule: `aitk-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md` in the toolkit repo, or the `create-rule` skill in a target project. For Retire items, skip the rewrite block. Every item gets a `Decision:` slot regardless of action. `Take:` is added only when a question response is needed.
+For Hand off items, the body is a pointer to the governance target instead of a rewritten rule: `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md` in the toolkit repo, or the `create-rule` skill in a target project. For Retire items, skip the rewrite block. Every item gets a `Decision:` slot regardless of action. `Take:` is added only when a question response is needed.

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

@@ -38,7 +38,7 @@ Two failures belong to the audit rather than to the diff. A decision taken in ch
 
 ## 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.
+- Bulk install and sync of a whole domain, which `aitk <domain> install` and `aitk <domain> sync` own and `aitk-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`

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

@@ -31,7 +31,7 @@ The report is what separates a file the project edited from one the toolkit move
 
 Keep every seed regardless of state. `CLAUDE.md` is the file a project edits most, and its `drifted` verdict is the case this skill exists for.
 
-Read the `toolkit-cli` skill before naming a sync command in the output. It states which surfaces a sync overwrites, merges, or writes once.
+Read the `aitk-cli` skill before naming a sync command in the output. It states which surfaces a sync overwrites, merges, or writes once.
 
 Fall back to the appearance heuristic in step 3 when the report cannot attribute, which is `historyUnavailable` set on the relevant section or the command failing outright. Say so in the summary block, because a fallback audit reports guesses rather than facts.
 

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

@@ -33,6 +33,6 @@ Without this skill, an issue takes the shape of whatever the session was saying.
 
 ## Out of scope
 
-- Reporting a toolkit defect from a target project, which `toolkit-feedback` owns. That path writes into the toolkit rather than the current repository.
-- Triaging issues already filed, which `toolkit-triage` owns
+- Reporting a toolkit defect from a target project, which `aitk-feedback-file` owns. That path writes into the toolkit rather than the current repository.
+- Triaging issues already filed, which `aitk-feedback-triage` owns
 - Opening a pull request, which `git-pr` owns

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

@@ -1,6 +1,6 @@
 ---
 name: git-issue
-description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `toolkit-feedback`), or to open a pull request (that is `git-pr`).
+description: Format a bug or task from the current session into a GitHub issue and file it on the current repo via `gh issue create`. Use when asked to "file an issue", "open an issue", "log this bug", "raise an issue", or "track this as an issue". Do NOT use to report a toolkit defect from a target project (that is `aitk-feedback-file`), or to open a pull request (that is `git-pr`).
 ---
 
 # Git issue

package/claude/skills/{restate → restate-plainly}/REQUIREMENT.md

@@ -1,9 +1,9 @@
 ---
-name: restate
+name: restate-plainly
 description: Why a plain restatement is asked for by name, and where its boundary sits against the skill that drafts and the command that measures
 ---
 
-# Restate requirement
+# Restate plainly requirement
 
 ## Gap
 

package/claude/skills/{restate → restate-plainly}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: restate
+name: restate-plainly
 description: Restates a dense answer or a named markdown document in plain language, cutting jargon and keeping only what changes a decision. Use when asked to "restate that in plain language", "say that plainly", "what does this actually mean", "cut the jargon", "give me the plain version", or "restate this document". Do NOT use to draft or revise prose, which is `write-human`, and do NOT fire on the model's own judgment that its own output was dense.
 ---
 
-# Restate
+# Restate plainly
 
 Return the plain version of something already written. The reader asked because they stopped to decode rather than to decide, so the restatement earns its place by getting them to the decision.
 

package/claude/skills/setup-init/REQUIREMENT.md

@@ -41,5 +41,5 @@ The other is the refusal that ends rather than routes. An existing project, an i
 - Provisioning Claude Code plugins: `setup-plugins`. Those install once per machine rather than into a project, so no project-scoped chain can carry them.
 - Running the verification scripts, which `setup-verify` owns and this chain invokes as its last step
 - Re-installing into a project that already has the files, which the per-domain `aitk <domain> install` and `aitk sync` commands own
-- Deciding which of those per-domain commands an existing project needs: `toolkit-operator`. That skill reads the target before naming one, which this chain never does, so it is the destination rather than a guess made here.
+- Deciding which of those per-domain commands an existing project needs: `aitk-operator`. That skill reads the target before naming one, which this chain never does, so it is the destination rather than a guess made here.
 - Seeding the `.claude/` folder without the tooling chain, which `aitk claude init` does on its own and `setup-indexes` finishes