@erclx/aitk 3.43.2 → 3.44.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.44.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/{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

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

@@ -16,7 +16,7 @@ Orchestrates the onboarding chain. Detects project type, resolves per-domain arg
 
 Three states reach this skill that the chain does not serve. Name the destination for each, so the refusal routes rather than ends. The first two stop the chain outright and the third runs it on a default the person may not want.
 
-- **An existing project.** Stop and hand off to `toolkit-operator`. It reads what the target already carries before it names a command, which this chain never does, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
+- **An existing project.** Stop and hand off to `aitk-operator`. It reads what the target already carries before it names a command, which this chain never does, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
 - **An install wanting the `.claude/` folder alone.** Stop. Run `aitk claude init` for the seed docs, then invoke `setup-indexes` to bootstrap the `index.md` system over the project's own documentation folders. Neither needs the tooling sync this chain runs.
 - **A language the toolkit carries no stack for.** The chain still runs, on `base`, with the fallback marked in the preview. A project that wants none of what `base` carries declines there and takes `setup-gov` for the governance layer, which is language-neutral. Say so at the preview rather than resolving it here, since the fallback is a working default and only the person can say whether it fits.
 

package/claude/skills/write-human/REQUIREMENT.md

@@ -41,6 +41,6 @@ Importing that catalog wholesale fails on a different measurement. External mate
 
 - The banned words, characters, and spellings, which `markdown.md` states for a reader and `aitk markdown audit` gates from package data
 - Markdown mechanics, being headings, lists, code spans, punctuation, and file references
-- Restating text that already exists in plainer words, which `restate` owns on a different trigger, since a restatement is asked for by name and this arrives on a glob match. The rules here still govern how that restatement reads, and that body cites this one rather than carrying a copy.
+- Restating text that already exists in plainer words, which `restate-plainly` owns on a different trigger, since a restatement is asked for by name and this arrives on a glob match. The rules here still govern how that restatement reads, and that body cites this one rather than carrying a copy.
 - What voice a given surface declares, which belongs to the standard governing that surface
 - Measuring whether finished output followed these rules, which needs a check this skill does not carry

package/claude/skills/write-human/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: write-human
-description: Carries the voice, rhythm, sentence construction, and information density rules a banned-word list cannot express, plus the catalog of machine tells that survive a clean ban scan. Use when writing or revising prose a person will read, when a passage reads flat or uniform, or when asked to "make this read like a person", "fix the cadence", "this reads like AI wrote it", "vary the sentences", or "tighten this without gutting it". Do NOT use for banned words, characters, or spellings, which `markdown.md` states and `aitk markdown audit` gates, and do NOT use to restate text that already exists in plainer words, which is `restate`, whose body loads these rules from here.
+description: Carries the voice, rhythm, sentence construction, and information density rules a banned-word list cannot express, plus the catalog of machine tells that survive a clean ban scan. Use when writing or revising prose a person will read, when a passage reads flat or uniform, or when asked to "make this read like a person", "fix the cadence", "this reads like AI wrote it", "vary the sentences", or "tighten this without gutting it". Do NOT use for banned words, characters, or spellings, which `markdown.md` states and `aitk markdown audit` gates, and do NOT use to restate text that already exists in plainer words, which is `restate-plainly`, whose body loads these rules from here.
 ---
 
 # Write human

package/docs/agents/demo.md

@@ -17,7 +17,7 @@ aitk demo run demos/inline-edit.json --cursor ~/cursors/theme --out assets
 
 ## The draft and the plan are different files
 
-`claude-screencast` drafts beats for a person. A beat carries what is on screen, one verb, what to watch for, an emphasis, and a caption, and none of that names a selector, a URL, a wait condition, or a timing. Those four are what an executor needs and what would ruin the draft, since the format is pre-seeded so the operator edits down rather than fills blanks.
+`aitk-screencast` drafts beats for a person. A beat carries what is on screen, one verb, what to watch for, an emphasis, and a caption, and none of that names a selector, a URL, a wait condition, or a timing. Those four are what an executor needs and what would ruin the draft, since the format is pre-seeded so the operator edits down rather than fills blanks.
 
 So `aitk demo compile` writes a second artifact rather than adding fields to a beat. It maps each beat's verb to a step, seeds the timing, marks which beat the still comes from, and leaves the target and the URL empty for a person to fill. The report names every field it could not supply.
 

package/docs/agents/index.md

@@ -36,6 +36,7 @@ CLI catalog and invocation rules for agents, split by command domain. Start with
 - [Standard success criteria](standards-audit.md): Reading the corpus against the Success criterion gate, why the check scopes to arrival rather than the whole corpus, and the exit codes it sets
 - [State-scoped risk](state-scoped-risk.md): Reading committed state rather than an arriving change, the shipped-tree corpus the secret scan reads, what it keys on and how a deliberate value is exempted, the advisory check and its network failure mode, and why one gates while the other reports
 - [Superseded values](superseded.md): Reading where the tree still asserts a value a changed convention no longer produces, why the sweep keys on the value rather than the file, the exemption marker, the blind spot it cannot reach, and why it reports rather than gates
+- [Targets](targets.md): The projects this toolkit installed into, the record the install writes against the sweep that backs it, what bounds each answer, and the cross-target pull request read
 - [Tasks](tasks.md): Selecting a shipped task by stem or pull request, recording a number and closing an outcome, the refusal reasons, the board and backlog checks validate runs, and why the board root defaults to the main worktree
 - [Teach](teach.md): Listing learning workspaces and the ordinal a new one takes, opening one with its required files, recording sources and glossary terms, resolving what the next lesson needs before it is written, the refusal reasons, and why every write here runs through a verb
 - [Test order](test-order.md): Reading where an implementation reached history ahead of its test, how a pair is decided, the three verdicts, the coverage the pairing cannot reach, and why the check reports rather than gates

package/docs/agents/overview.md

@@ -7,7 +7,7 @@ description: What this folder covers, the invocation rules every command inherit
 
 CLI catalog and invocation rules for agents working in this repository.
 
-This folder is an index of what an agent can run and how to run it cleanly from a script. It does not cover domain behavior. Read `CLAUDE.md` for project behaviors and load the matching `.claude/skills/aitk-*` skill when working inside a domain.
+This folder is an index of what an agent can run and how to run it cleanly from a script. It does not cover domain behavior. Read `CLAUDE.md` for project behaviors and load the matching `.claude/skills/internal-*` skill when working inside a domain.
 
 ## Invocation rules
 
@@ -22,5 +22,5 @@ See `CLAUDE.md` design principles. They apply to every command in this folder.
 ## Related
 
 - `CLAUDE.md`: project behaviors and design principles
-- `.claude/skills/aitk-*`: domain-scoped guidance for editing work
+- `.claude/skills/internal-*`: domain-scoped guidance for editing work
 - `docs/index.md`: full docs directory

package/docs/agents/scripting.md

@@ -146,4 +146,4 @@ git hooks, the end-to-end harness, and the shell scripts under `scripts/`, so a
 headless run carrying neither `--check` nor `--write` reports what it would
 replace and exits 1 rather than applying it. Run `--check` first to read the
 list, then `--write` to apply it. `aitk tooling sync --help` names both, and the
-full per-stack path list sits in the `toolkit-cli` skill.
+full per-stack path list sits in the `aitk-cli` skill.

package/docs/agents/sessions.md

@@ -13,12 +13,14 @@ description: Resolving live peer sessions to the worktree and branch each holds,
 aitk sessions list
 aitk sessions list --json
 aitk sessions list --branch feat/parser --json
+aitk sessions list --branch chore/agents --repository ../caret --json
 ```
 
-| Option            | Behavior                                     |
-| ----------------- | -------------------------------------------- |
-| `--json`          | Add a machine-readable record on stdout      |
-| `--branch <name>` | Report the sessions holding this branch here |
+| Option                | Behavior                                              |
+| --------------------- | ----------------------------------------------------- |
+| `--json`              | Add a machine-readable record on stdout               |
+| `--branch <name>`     | Report the sessions holding this branch               |
+| `--repository <path>` | Answer about this project rather than the working one |
 
 It reads and never writes. The question it answers is which session to address when work has to reach the one holding a given branch, which a session listing cannot answer on its own.
 
@@ -28,7 +30,11 @@ An exit code says nothing about a call made from a session, since a shell profil
 
 ## Scope and count
 
-`--branch` scopes the match to the repository the command runs in, and refuses outside one. A branch name identifies a branch inside a repository and nothing across a machine, so an unscoped match reaches a session working in a different project, and `main` collides on every machine running two of them.
+`--branch` scopes the match to one repository, and refuses when none resolves. A branch name identifies a branch inside a repository and nothing across a machine, so an unscoped match reaches a session working in a different project, and `main` collides on every machine running two of them.
+
+Which repository that is defaults to the one the command runs in, and `--repository <path>` names another. Every reading moves with it, the session match and the worktree and ref reads alike, because the answer is about that project rather than about where the caller stands. The roster underneath is machine-wide already, so the flag removes a filter rather than widening a search.
+
+That is what a dispatcher reaching outside its own project needs. Without it a check run from the toolkit against a branch held by a live session in a consuming project answered unclaimed, and two sessions were sent onto branches other sessions were holding. 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 bare run reports every repository and carries a `repository` field on each row, holding the shared git directory that a main checkout and all its linked worktrees agree on. That is what a caller filters on when it wants a scope of its own.
 

package/docs/agents/targets.md

@@ -0,0 +1,83 @@
+---
+title: Targets
+description: The projects this toolkit installed into, the record the install writes against the sweep that backs it, what bounds each answer, and the cross-target pull request read
+---
+
+# Targets
+
+## List
+
+`aitk targets list` reports the projects this toolkit has installed into, with where each answer came from.
+
+```bash
+aitk targets list
+aitk targets list --json
+aitk targets list --sweep ~/repos --json
+```
+
+| Option            | Behavior                                                |
+| ----------------- | ------------------------------------------------------- |
+| `--json`          | Add a machine-readable record on stdout                 |
+| `--sweep <path…>` | Also walk these roots for targets the record never held |
+| `--depth <n>`     | How deep below each swept root to walk, defaulting to 4 |
+
+Exit codes: `0` the population was read, `1` refused. A refusal carries a `reason` of `bad-depth`, and an absent index reports as unknown rather than as no targets.
+
+An exit code says nothing about a call made from a session, since a shell profile may wrap the binary in a function taking its status from a later command. Read the record's fields rather than the exit when a skill consumes this.
+
+## Where the answer comes from
+
+Every sync that stamps a target records it in a machine-level index at `$XDG_STATE_HOME/aitk/targets.json`, falling back to `~/.local/state/aitk/targets.json`. A project installed into since that shipped is therefore known without anyone naming it, and each row carries `stampedAt` from the sync that last touched it.
+
+`--sweep` walks the roots given and finds what the record never held, which is every target installed before the index existed. A row says which of the two found it, and a row the record knows keeps that source even when the sweep reaches it too.
+
+The record is the primary source and the sweep is the fallback, because they fail in opposite directions. A record only knows an install that ran after it shipped. A walk only knows the paths someone thought to name, which is how a hand census of this population was wrong in both directions at once: it counted two folders that had never been targets, counted one clone of a target already counted, and missed the clone a repair had actually run in.
+
+## What bounds a sweep
+
+A `--sweep` run carries a `bound` object naming the roots walked, the depth, the folders the walk stopped at on reaching the cap, the roots it could not read, and the directory symlinks it did not follow. Read it before treating a count as the population.
+
+The bound a sweep can never state is the machine. It reads this one, so a target on another machine or under a path nobody named is outside every answer it gives. That is the same limit the hand census had, and the record above is what closes it going forward rather than the sweep.
+
+`--depth` refuses anything that is not a whole number rather than falling back to the default. A value that is not one leaves every depth test false, so the walk runs to the bottom of its root while the bound claims a cap it never applied.
+
+## A project held in more than one clone
+
+A target cloned twice is one target. The sweep reads each checkout's `origin`, trims it to a form an ssh URL and an https URL of one repository agree on, and reports a single row holding every path.
+
+The row leads with the clone the record knows, because the record only names one a sync actually ran in. Every caller reading a single path takes the first, and picking that by sort order is the shape behind a repair that ran in one clone while a count was taken against another, leaving the target reported as untouched.
+
+Nothing removes a row. A project deleted, moved, or that dropped the toolkit stays in the index, so a count drifts upward over time. It surfaces on use rather than silently, since the read below refuses a path it cannot open.
+
+## Pulls
+
+`aitk targets pulls` reports, per target, every open pull request with its checks and the heading its newest review pass carries.
+
+```bash
+aitk targets pulls
+aitk targets pulls ../caret ../stackr --json
+```
+
+Naming paths reads those and looks up nothing. Naming none reads every target `aitk targets list` reports. One clone per project is read, since two checkouts sharing an origin answer the same query and reading both spends the rate limit to print one answer twice.
+
+Exit codes: `0` at least one target was read, `1` refused or every target refused.
+
+| Field            | Holds                                                                   |
+| ---------------- | ----------------------------------------------------------------------- |
+| `checks`         | `passing`, `failing`, `pending`, or `null` when GitHub reported none    |
+| `review`         | `open`, `closed`, or `null` when no pass has landed                     |
+| `reviewReadable` | `false` when the review query failed, leaving `review` covering nothing |
+
+`checks` is `null` rather than `passing` when no check ran at all, which is not the same answer. A failure outranks a run still going, since a job that already failed cannot be cleared by one still in flight.
+
+`review` reads the first line of the newest pass carrying `## Review` or `## Review closed`, which `claude-pr-review` owns and posts. A target leaves a wave on `closed` rather than on a worker's reply.
+
+A target that could not be read carries a `reason` rather than an empty pull list. Reading a failed query as no open work is what reports a target as done having read nothing, which is the failure mode of the hand-written shell loop this replaces.
+
+| Reason            | Means                                                  |
+| ----------------- | ------------------------------------------------------ |
+| `not-a-directory` | the path is not a directory, so nothing was read there |
+| `gh-unavailable`  | `gh` is not on the path                                |
+| `list-failed`     | the open pull request list could not be read           |
+
+The reads run one target at a time. They share one GitHub API quota, and a wave firing a dozen at once meets the secondary rate limit rather than an answer.