@erclx/aitk 3.24.0 → 3.25.1

package/README.md

@@ -116,7 +116,7 @@ git init
 aitk init
 ```
 
-`aitk init` installs base tooling configs, Claude seeds, and governance rules in one pass, and scaffolds a `.claude/wiki/` stub for your project's own reference pages. Governance defaults to the `base` stack, so a bare init lands the coding and doc-authoring rules in `.claude/rules/`. Each rule names the standard it answers to and reads it with `aitk standards <name>`, so no corpus is copied into your project. Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. Snippets install only when you name a category with `--snippets <category>`, such as `--snippets essentials`. Run `aitk tooling list --json` to see the catalog.
+`aitk init` installs base tooling configs, Claude seeds, and governance rules in one pass, and scaffolds a `.claude/wiki/` stub for your project's own reference pages. Governance defaults to the `base` stack, so a bare init lands the coding and doc-authoring rules in `.claude/rules/`. Each rule names the standard it answers to and reads it with `aitk standards <name>`, so no corpus is copied into your project. Pass `--stack <name>` for a framework stack, or `--skip governance` to leave rules out. A snippet resolves the same way, reached at its `@` reference through the plugin's live `claude/snippets` symlink rather than a copy. Run `aitk tooling list --json` to see the catalog.
 
 For the full journey from scaffold through adding a domain later to syncing upstream drift, see [target projects](docs/target-projects.md).
 

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

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

package/claude/skills/create-snippet/REQUIREMENT.md

@@ -9,15 +9,15 @@ description: Why a snippet needs its shape read from the reference and its write
 
 Without this skill, a snippet is drafted the way any other markdown file is drafted, so it arrives carrying frontmatter, headings, and a fill-in placeholder. None of the invocation channels strip those. Typing `>slug` in a chat inserts the scaffolding verbatim, and the file that was meant to be one instruction reads as a document.
 
-The write surface is the second failure. The toolkit authors at `snippets/` and a target project holds only the installed copy under `.claude/snippets/`, so a session picks whichever folder it noticed first. A toolkit snippet written into the consumed copy fails the drift assertion that regenerates that folder. A snippet written there in a target project is correct and looks identical, which is why the surface has to be resolved from what the project has rather than guessed.
+The write surface is the second failure. The toolkit authors at `snippets/` and a target project may still hold a stale `.claude/snippets/` copy from before that domain's install channel retired, so a session picks whichever folder it noticed first. A toolkit snippet written into the consumed copy fails the drift assertion that regenerates that folder. A snippet written there in a target project is correct and looks identical, which is why the surface has to be resolved from what the project has rather than guessed.
 
-Inside the project surface, a third failure sits one level deeper. A project-authored snippet sharing a name with a toolkit one used to be indistinguishable from it, so `aitk snippets sync` could not tell which side owned the file. The sync engine now reads ownership by location for anything under `.claude/snippets/project/`, so the skill has to write there rather than beside the toolkit-installed files.
+Inside the project surface, a third failure sits one level deeper. A project-authored snippet sharing a name with a toolkit one used to be indistinguishable from it, back when `aitk snippets sync` walked that folder and could not tell which side owned the file. That verb retired with the domain's install channel, so nothing reads ownership by location there any more, but the `project/` subfolder still separates the two by eye, which is worth keeping even with no sync left to protect from.
 
 ## Must
 
 - Read the bundled snippet reference before drafting, since the shape rules are what the invocation channels depend on
 - Resolve the write surface from which snippet folder the project has, rather than from whichever one the session noticed first
-- On the project surface, write under its `project/` subfolder so the sync engine reads the file as project-authored by location
+- On the project surface, write under its `project/` subfolder, keeping a project-authored file visually apart from a toolkit-installed one
 - Confirm the slug and the full body with the user before writing
 - Emit the written path in full, so the terminal can resolve it
 - State what the resolved surface implies after writing, since a root file needs the consumed copy regenerated and a project-local one needs copying to the toolkit to ship

package/claude/skills/create-snippet/SKILL.md

@@ -17,14 +17,14 @@ Creates one snippet file. Read these files in parallel:
 
 ## Steps
 
-1. Resolve the write surface: `snippets/` at the root if present, which is the toolkit's own authoring source. Otherwise `.claude/snippets/`, a target project's installed copy.
+1. Resolve the write surface: `snippets/` at the root if present, which is the toolkit's own authoring source. Otherwise `.claude/snippets/`, a stale copy a target project holds from before its install channel retired.
 2. Draft the content from the user's description. The snippet reference governs structure, invocation, and authoring conventions.
 3. Confirm the slug and full content with the user before writing
-4. Write the file. On the root surface: `<surface>/<category>/<slug>.md`, or `<surface>/<slug>.md` when the snippet takes no category. On the `.claude/` surface: the same shape nested one level deeper under `project/`, so the sync engine's location rule holds it apart from a toolkit-installed snippet regardless of what its name matches.
+4. Write the file. On the root surface: `<surface>/<category>/<slug>.md`, or `<surface>/<slug>.md` when the snippet takes no category. On the `.claude/` surface: the same shape nested one level deeper under `project/`, a convention kept for its own sake now that nothing syncs that folder.
 
 ## After writing
 
 Emit the full path on its own line.
 
 - Root surface: this is the toolkit's authoring source. Remind the user to run `bun run check` to regenerate the consumed copy under `.claude/`.
-- `.claude/` surface: the file is project-local, under `.claude/snippets/project/`. `aitk snippets sync` leaves everything there alone by location rather than by a name it fails to recognize. Remind the user to copy it to the toolkit repo, under `snippets/<category>/<name>.md`, if it should ship to every project.
+- `.claude/` surface: the file is project-local, under `.claude/snippets/project/`. Remind the user to copy it to the toolkit repo, under `snippets/<category>/<name>.md`, if it should ship to every project.

package/claude/skills/migration-claude-md/REQUIREMENT.md

@@ -36,6 +36,5 @@ The skill also writes into `.claude/context/`, a folder `migration-context` move
 ## Out of scope
 
 - Relocating `docs/` files, which `migration-context` proposes into this same `.claude/context/` folder. Run that skill first when both apply, so Step 3 reads a folder its moves have already populated.
-- Relocating root `standards/` and `snippets/`: `migration-standards`
 - Scaffolding the rule files it proposes, which `create-rule` does with the numbering and frontmatter
 - Regenerating `.claude/context/index.md`, which `aitk indexes regen` does once the user has applied the moves

package/claude/skills/migration-context/REQUIREMENT.md

@@ -33,5 +33,4 @@ A seed-derived `development.md` moved out of `docs/` comes back on the next seed
 ## Out of scope
 
 - Classifying `CLAUDE.md` sections, which `migration-claude-md` proposes into this same `.claude/context/` folder. Run this skill first when both apply, so that skill's append-or-create check reads a folder the moves have already populated.
-- Relocating root `standards/` and `snippets/`: `migration-standards`
 - Regenerating `.claude/context/index.md`, which `aitk indexes regen` does once the user has applied the moves

package/claude/skills/migration-superseded/REQUIREMENT.md

@@ -38,7 +38,6 @@ The last is the two-speed release skew arriving as a confident wrong answer. `su
 
 ## Out of scope
 
-- Relocating root `snippets/` into `.claude/`: `migration-standards`
 - Classifying `CLAUDE.md` sections into the three-tier model: `migration-claude-md`
 - Relocating `docs/` files by audience: `migration-context`
 - Reconciling a seed file against its source section by section, which diffs two files rather than splitting one into a folder: `claude-seed-sync`

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

@@ -36,7 +36,7 @@ The other is the refusal that ends rather than routes. An existing project, an i
 
 ## Out of scope
 
-- Installing governance rules alone: `setup-gov`. This skill installs governance beside tooling, standards, snippets, and the seeds.
+- Installing governance rules alone: `setup-gov`. This skill installs governance beside tooling and the seeds.
 - Bootstrapping the `index.md` system: `setup-indexes`. Neither `aitk init` nor this chain performs it.
 - 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

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

@@ -1,6 +1,6 @@
 ---
 name: setup-init
-description: Detects a new project's type and runs `aitk init` with a resolved stack and snippets in one shot. Use when bootstrapping a new project with the toolkit, or when asked to "init this project", "bootstrap the toolkit", "set up toolkit", or "one-shot install". Assumes the `aitk` CLI is on PATH. Do NOT use when only installing governance rules. Use `setup-gov` instead.
+description: Detects a new project's type and runs `aitk init` with a resolved stack in one shot. Use when bootstrapping a new project with the toolkit, or when asked to "init this project", "bootstrap the toolkit", "set up toolkit", or "one-shot install". Assumes the `aitk` CLI is on PATH. Do NOT use when only installing governance rules. Use `setup-gov` instead.
 ---
 
 # Init project
@@ -30,8 +30,6 @@ Run from the target project's current directory. Do not cd into the toolkit sour
 
 ```bash
 aitk gov list --json 2>/dev/null
-aitk snippets list --json 2>/dev/null
-aitk standards list --json 2>/dev/null
 aitk tooling list --json 2>/dev/null
 ```
 
@@ -49,8 +47,7 @@ Read these from the project root in parallel, skipping any that do not exist:
 - **Stack:** pick the closest governance stack by matching detected runtime or framework against stack names in the catalog. If nothing matches, fall back to `base` and carry the fallback into the preview.
 - **Tooling stack:** pick the closest tooling stack from `aitk tooling list --json` (e.g. `vite-react`, `astro`). Distinct from the governance stack. Fall back to `base` if no framework match, and carry that fallback into the preview too.
 - **Extras:** identify technologies not already covered by the picked stack. For each, find a rule whose `description` or `paths` points at that technology and pass it via `--add`. Do not add a rule the stack already pulls in.
-- **Snippets:** default to `all`. Narrow only if the user asked for a specific category.
-- **Skip (`--skip`):** `standards` and `wiki` are core and install by default. Add `--skip standards` or `--skip wiki` only when the user explicitly wants them left out.
+- **Skip (`--skip`):** `wiki` installs by default. Add `--skip wiki` only when the user explicitly wants it left out.
 
 ## Gap handling
 
@@ -59,7 +56,7 @@ If a detected technology has no matching rule or stack, do not guess. Surface th
 1. Defer to `setup-gov`. Author a rule in the toolkit, then re-run this skill.
 2. Proceed with the matched layer, listing the gap in the final report.
 
-Rules, snippets, and stacks are authored in the toolkit repo, never in the target project on the fly.
+Rules and stacks are authored in the toolkit repo, never in the target project on the fly.
 
 ## Preview
 
@@ -69,7 +66,6 @@ Before executing, output:
 - **Stack:** picked governance stack + resolved rule count. Mark it `fallback` when no detected runtime or framework matched a catalog name.
 - **Tooling stack:** picked tooling stack. Mark it `fallback` on the same test, and name what `base` lands: configs, seeds, and gitignore entries in every case, plus the JavaScript development dependencies, scripts, and hook activation wherever a `package.json` exists to carry them. A project outside that ecosystem runs none of the second group and keeps the first.
 - **Extras:** each `--add` rule with a one-line reason
-- **Snippets:** resolved category
 - **Skip:** any `--skip` entries with reason
 - **Target:** resolved target path
 - **Commands:** the full chain that will run
@@ -80,13 +76,12 @@ A resolved name and a fallback read alike once written, so mark the fallback her
 
 Run the chain in order, starting immediately after the preview. Each step's permission dialog is the confirmation gate. Do not pause for additional confirmation. Run from the target project's current directory.
 
-Step 1: `aitk init` installs base tooling, claude seeds, governance rules, standards, snippets, and wiki.
+Step 1: `aitk init` installs base tooling, claude seeds, governance rules, and wiki.
 
 ```bash
 AITK_NON_INTERACTIVE=1 aitk init \
   --stack <stack> \
   --add <rules> \
-  --snippets <category> \
   <target>
 ```
 

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

@@ -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 three bodies now carrying an inline pointer are `claude-seed-sync`, `migration-standards`, 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 `toolkit-operator`, each at the point it runs or prints an overwriting command.
 
 ## Must
 
@@ -38,5 +38,4 @@ The three bodies now carrying an inline pointer are `claude-seed-sync`, `migrati
 
 - Executing the sync, which the user runs or `toolkit-operator` routes
 - Reconciling a customized seed section by section: `claude-seed-sync`
-- Relocating a project's folders into the layout a newer version expects: `migration-standards`
 - Deciding which stack, rule, or standard a project should install, which the setup skills resolve from live catalogs

package/claude/skills/toolkit-operator/REQUIREMENT.md

@@ -27,7 +27,7 @@ The last failure is a section no route reaches. `## Route` maps an intent or a d
 - Run the CLI non-interactively and report the command run, what changed, and the full path of anything written
 - Read the overwrite contract from the body before any install or sync, and name each surface it lists as overwritten before running one
 - Read the reverse walk beside the forward sections, so a folder the toolkit stopped shipping and a migration with a live case both reach the user
-- Hand off a named migration to the skill the report names, the way an unmigrated domain reaches `migration-standards`
+- Hand off a named migration to the skill the report names, and name an unmigrated domain's root and install path for the user to move themselves when no skill covers it
 - Route a measurement intent to the audit offers from the route table itself, rather than leaving the section reachable only by reading past the table
 - Rank a lifecycle row against the audit offers where the route table itself states it, so a session acting on the lifecycle row reads the ranking without opening the section being ranked
 - Offer every audit whose surface the target carries, and offer none whose surface it lacks

package/claude/skills/toolkit-operator/SKILL.md

@@ -42,7 +42,7 @@ Map the stated intent, or what `## Diagnose` found, to one lifecycle phase, then
 
 The two can name different rows, and a reply answers both rather than picking one. Run or hand off what the finding names, then answer the intent in the same reply. A measurement intent therefore reaches the audit offers below even on a target whose diagnostic found scaffold work, which is the case a session leaving from the scaffold row would otherwise never read.
 
-- A domain in `unmigrated`: hand off to `migration-standards`
+- A domain in `unmigrated`: name it, the root path, and the install path. No command moves it, so the user runs the relocation themselves
 - An entry in `migrations`: hand off to the skill its `skill` field names, spelled as the report spells it. Both of them propose without writing, so the handoff is where this stops
 - Anything in `superseded`: name which files and what replaced them, then hand off to `migration-superseded`. Both skills propose, so neither moves nor deletes the file
 - A folder in `unclaimed`: name it and the attribution it carries. No command moves it and the content may be the project's own, so the decision is the user's

package/docs/agents/commands.md

@@ -71,7 +71,7 @@ Each domain exposes a consistent shape where applicable: `list`, `install`, `syn
 | Domain      | Subcommands                                                                                                                           |
 | ----------- | ------------------------------------------------------------------------------------------------------------------------------------- |
 | `tooling`   | `list`, `sync`, `ref`, `create`, `verify`, `inject`, `prune-gitignore`                                                                |
-| `snippets`  | `list`, `install`, `sync`, `create`                                                                                                   |
+| `snippets`  | `list`, `create`                                                                                                                      |
 | `standards` | `list`, `<name>`                                                                                                                      |
 | `gov`       | `list`, `install`, `sync`, `build`, `regen`, `test-order`, `superseded`                                                               |
 | `claude`    | `init`, `sync`, `routing`, `seeds list`, `skills list`, `skills audit`, `skills drift`, `skills reach`, `skills rank`, `setup [dest]` |

package/docs/agents/context-audit.md

@@ -76,7 +76,7 @@ Three exclusions keep it from firing on prose about paths. Fenced blocks are ski
 
 Two cases remain, and no syntax separates either from a real reference. One is a sentence naming a hypothetical entry to show the shape of a name. The other is a line instructing a target project about its own tree, which resolves against the target rather than against this repository and passes here only while the two layouts agree. Splitting a seeded domain into a folder ends that agreement and turns every such line red at once.
 
-Append `<!-- audit-ignore-citations -->` to the source line in either case. The marker suppresses citation checking for its own line only, and the reference-form check reads it too, since both ask whether a line points at a file and the marker is how a line says it displays a name instead.
+Append `<!-- audit-ignore-citations: <path> -->` to the source line in either case, naming the exact path the sentence displays. The marker excuses only the paths it names, so a line carrying a real reference beside the displayed one keeps that reference checked. A bare `<!-- audit-ignore-citations -->` with no path excuses every citation the line carries instead, and the reference-form check reads either form the same way, since both ask whether a line points at a file and the marker is how a line says it displays a name instead.
 
 The marker itself stays out of anything that installs. A seed, a plugin skill body, and a stack reference all reach a target, so a marker there lands as toolkit bookkeeping in someone else's tree. Reword those lines to drop the path instead, and where a stop message has to spell it, move that message into a fenced block, which this check already skips.
 

package/docs/agents/install-and-sync.md

@@ -26,10 +26,8 @@ rules, skills, and docs may cite. `aitk standards rule` carries the reserved
 number bands behind that placement, where `900-999` is the range a
 project-authored rule takes and everything below it belongs to the toolkit.
 
-`aitk snippets sync` reports the same way for a snippet outside
-`.claude/snippets/project/`, since both adapters declare the subfolder.
-`aitk sync --check` does not. It skips every orphaned entry, so the destination
-reaches the two domain sync verbs alone.
+`aitk sync --check` does not report an orphaned entry. It skips every one, so
+the destination reaches `aitk gov sync` alone, the one domain sync verb left.
 
 When the target's install recorded a stack, `aitk gov sync` also reports a
 rule that stack lists and `.claude/rules/` does not hold, as a `missing` entry
@@ -46,30 +44,27 @@ installs into no project, so the domain has nothing in a target to reconcile.
 and then the corpus inside the package, and `aitk standards list --json` carries
 the catalog.
 
-`aitk snippets sync` matches by path relative to `.claude/snippets/`. It
-matches by path relative to that directory, so a snippet the toolkit no longer
-ships, or one authored directly in the target, is reported and skipped rather
-than deleted, and a snippet under `.claude/snippets/project/` skips the same
-way regardless of path, since that subfolder is project-authored by location.
-It is not preset-aware, so a project that installed `essentials`
-does not grow new snippets on a sync. Use `aitk snippets install` to add them.
+There is no `aitk snippets sync` and no `aitk snippets install` either, on the
+same ground: `claude/snippets` in the plugin cache symlinks live to the
+toolkit's own `snippets/`, so a session reaches one at its `@` reference with
+no copy to reconcile. `aitk snippets list --json` carries the catalog and
+`aitk snippets create` is the one verb left that still writes a file.
 
 ## Install guards
 
-`aitk gov install` and `aitk snippets install` require their first argument
-under `AITK_NON_INTERACTIVE=1`. Both used to fall back to an interactive picker
-that resolved to its first option headlessly, so `aitk gov install` with no
-stack installed whichever stack sorted first and `aitk snippets install` with no
-category installed every category. Each now reports the valid names on stderr
-and exits 1.
+`aitk gov install` requires its first argument under
+`AITK_NON_INTERACTIVE=1`. It used to fall back to an interactive picker that
+resolved to its first option headlessly, so a call with no stack installed
+whichever stack sorted first. It now reports the valid names on stderr and
+exits 1.
 
 Every documented agent path already passes the argument, including
 `aitk init`. The confirm-then-apply prompt after it still resolves to `Yes`
-headlessly, so a call that names its stack or category is unchanged.
+headlessly, so a call that names its stack is unchanged.
 
-`aitk gov install` also refuses the toolkit root as a target, matching
-`aitk snippets install`. Both resolve the target before anything else, so a path
-that does not exist fails rather than being scaffolded.
+`aitk gov install` also refuses the toolkit root as a target. It resolves the
+target before anything else, so a path that does not exist fails rather than
+being scaffolded.
 
 ## Standards resolution
 
@@ -227,14 +222,13 @@ refusal rather than a shape nobody stated.
 to, with nothing at the path the current one reads. It carries `rootPath`,
 `installPath`, and a file count. Without it a project holding `standards/` at its
 root reports zero entries for that domain and reads as clean, which is the most
-misleading state the report can produce. Route it to `migration-standards`.
+misleading state the report can produce.
 
-That skill reads this field rather than listing the folder itself, so the entry
-is the detection on both sides of the handoff and the two cannot disagree. The
-count is what makes the difference visible: it counts only files whose basename
-the toolkit ships, so a root folder holding the project's own documents beside
-the installed ones reports the installed subset, where a listing reports every
-file and proposes relocating the lot.
+The field currently names no domain. Standards and snippets are the two the
+toolkit ever installed at a project root, and both closed their install channel,
+so a project still holding a root `standards/` or `snippets/` folder is carrying
+its own authoring surface rather than an unfinished install. Nothing proposes
+moving either, and no command relocates the content. Move it yourself.
 
 #### Rules the target never received
 
@@ -268,8 +262,8 @@ rule the chain lists reaches both surfaces the same way.
 A target stamped before governance recorded a chain falls back to the older
 band-inference read below. The measurement there anchors on governance's own
 stamp rather than on the oldest anchor across domains, since rules are
-domain-scoped and a shared anchor would let a snippets sync move the revision
-rules are measured from. A target carrying no chain and no governance anchor
+domain-scoped and a shared anchor would let another domain's sync move the
+revision rules are measured from. A target carrying no chain and no governance anchor
 reports nothing at all: it has no date to measure against, and diffing from the
 start of history would read the whole catalog as new.
 
@@ -343,9 +337,8 @@ colliding on a retired name costs the walk no reads. The cost is that a file the
 toolkit shipped and the target renamed goes unmatched, the same limit the
 `unmigrated` count carries.
 
-`migrations` names a proposal-only skill with a live case in this target, which
-is the treatment `unmigrated` already gives `migration-standards`. It fires on a
-`CLAUDE.md` past 250 lines for `migration-claude-md`, and on a `docs/` folder
+`migrations` names a proposal-only skill with a live case in this target. It
+fires on a `CLAUDE.md` past 250 lines for `migration-claude-md`, and on a `docs/` folder
 holding markdown with no populated `.claude/context/` for `migration-context`.
 Each entry carries the skill name and the measurement behind it, so a consumer
 can check the proposal before running it. Without the field both skills are
@@ -371,24 +364,16 @@ so this section reports and gates nothing.
 
 ## Bootstrap
 
-`aitk init` installs up to six core domains and reports each one independently. A
+`aitk init` installs up to four core domains and reports each one independently. A
 domain that fails does not abort the run, so the command finishes the rest and
 exits 1 naming the failures. Passing any flag skips the confirmation prompt,
 which is what makes it scriptable.
 
 `--stack` defaults to `base`, and the default
 does not read as a passed flag, so a bare `aitk init` installs governance and
-still prompts. `--skip` takes `wiki`, `governance`, and `snippets`, and warns
-without aborting on any other value. There is no `--standards`, since no run
-writes a standard into the target.
-
-`--snippets` carries no default. A bare `aitk init` installs no snippets and
-reports the domain as skipped, the same way an explicit `--skip snippets`
-does, both naming `aitk snippets install essentials <target>` as the recovery
-command. `--snippets none` is a distinct, deliberate way to reach the same
-zero-file result while still running the step, which is what lets a scripted
-caller assert "install nothing" without depending on an empty string, which
-`aitk snippets install` refuses.
+still prompts. `--skip` takes `wiki` and `governance`, and warns
+without aborting on any other value. There is no `--standards` and no
+`--snippets`, since no run writes either corpus into the target.
 
 ## Unguarded tooling primitives
 

package/docs/agents/scripting.md

@@ -106,12 +106,6 @@ aitk tooling inject base /path/to/project --configs --seeds
 # Prints the number removed on stdout, diagnostics on stderr
 aitk tooling prune-gitignore base /path/to/project
 
-# Install a snippet preset
-AITK_NON_INTERACTIVE=1 aitk snippets install essentials /path/to/project
-
-# Update snippets already installed, leaving project-authored ones alone
-AITK_NON_INTERACTIVE=1 aitk snippets sync /path/to/project
-
 # Print one standard. Nothing installs the corpus, so this is how a target reads one
 AITK_NON_INTERACTIVE=1 aitk standards slug >slug.md
 

package/docs/agents/skills-reach.md

@@ -34,7 +34,7 @@ A path the toolkit does not hold is dropped rather than reported. The measure as
 
 ## The ownership key
 
-A cited path counts when it sits under an authoring root no install channel delivers. Standards install nowhere and are read through the plugin corpus, snippets land under `.claude/snippets/`, governance rules under `.claude/rules/`, and the rest is this repository's own source, catalogs, and contract pages.
+A cited path counts when it sits under an authoring root no install channel delivers. Standards and snippets install nowhere and are read through the plugin corpus, governance rules install under `.claude/rules/`, and the rest is this repository's own source, catalogs, and contract pages.
 
 `src/`, `scripts/`, and bare `docs/` are deliberately outside the list. A body naming one of those is describing the reader's own tree, so listing them reports a correct citation on every run and buries the finding under the pass.
 

package/docs/ai-workflow.md

@@ -262,7 +262,6 @@ This section is the corpus the coverage claim is measured against: every name `a
 | `aitk:claude-seed-sync`     | After a toolkit update, to reconcile installed seeds without losing customizations |
 | `aitk:migration-claude-md`  | When `CLAUDE.md` grew past what always-load context should carry                   |
 | `aitk:migration-context`    | When `docs/` holds agent-flavored files belonging in `.claude/context/`            |
-| `aitk:migration-standards`  | When standards sit at the root while rules point into `.claude/`                   |
 | `aitk:migration-superseded` | When a drift report names a `.claude/` file a folder has replaced                  |
 | `aitk:toolkit-feedback`     | When something in the toolkit is broken, missing, or off                           |
 | `aitk:toolkit-triage`       | In the toolkit repo, to work through the open feedback issues                      |

package/docs/target-projects.md

@@ -27,7 +27,7 @@ The `aitk` CLI is separate. Twenty skills invoke it in a command position, and a
 bun install --global @erclx/aitk
 ```
 
-The package ships the catalogs the CLI reads, not only `src/`, so `aitk init` resolves snippets, governance, tooling, and the seeds from wherever the package landed, and `aitk standards <name>` reads the corpus from there too.
+The package ships the catalogs the CLI reads, not only `src/`, so `aitk init` resolves governance, tooling, and the seeds from wherever the package landed, and `aitk standards <name>` reads the corpus from there too.
 
 Pointing Claude Code at a checkout stays the development path, where a local skill edit overrides the installed copy for that session.
 
@@ -46,12 +46,12 @@ The chain is:
 
 - `aitk init` installs base tooling, Claude seeds, and governance rules into `.claude/rules/` in the same pass
 - `aitk tooling sync <stack> --write` adds stack-specific deps, scripts, and gitignore entries
-- The agent reads `aitk tooling reference <stack>` (plus parents) as its audit context, follows it to generate eslint, vitest, playwright configs and the stack's setup script, and extends `.claude/context/ci.md` and `.claude/context/development.md` per the reference's extend sections <!-- audit-ignore-citations -->
+- The agent reads `aitk tooling reference <stack>` (plus parents) as its audit context, follows it to generate eslint, vitest, playwright configs and the stack's setup script, and extends `.claude/context/ci.md` and `.claude/context/development.md` per the reference's extend sections <!-- audit-ignore-citations: .claude/context/development.md -->
 - `setup-verify` runs the installed `package.json` scripts (lint, typecheck, check, test, build) and reports pass or fail
 
 The chain serves a fresh scaffold and names a destination for the three states it does not. An existing project goes to `aitk:toolkit-operator`, which reads what the project already carries before naming a per-domain command. An install wanting the Claude layer without the tooling chain runs `aitk claude init` for the seed docs and then `aitk:setup-indexes` for the index system. A language the toolkit ships no stack for is the one of the three the chain still runs for, on `base`, with the fallback marked in the preview so it can be declined there.
 
-Keep the `## Scripts` table in `.claude/context/development.md` current as scripts are added. Base tooling seeds that entry with the commands it installs, and each stack reference extends the table. `project-commands` reads it to start the app or run a check on request, so a command missing from the table cannot be run that way. A project whose entry outgrew one file and split into `.claude/context/development/` keeps the table in `overview.md`, which is where the skill looks next. <!-- audit-ignore-citations -->
+Keep the `## Scripts` table in `.claude/context/development.md` current as scripts are added. Base tooling seeds that entry with the commands it installs, and each stack reference extends the table. `project-commands` reads it to start the app or run a check on request, so a command missing from the table cannot be run that way. A project whose entry outgrew one file and split into `.claude/context/development/` keeps the table in `overview.md`, which is where the skill looks next. <!-- audit-ignore-citations: .claude/context/development.md -->
 
 ### From scaffold to first feature
 
@@ -88,12 +88,11 @@ Run `aitk tooling list --json` and `aitk gov list --json` to see the current cat
 
 No standard is written into the project. Each governance rule's authority line names `aitk standards <name>`, which answers from the corpus inside the CLI's own package, and every toolkit skill names the copy in its own plugin root. `aitk markdown audit` needs no standard at all, its ban sets and checkpoints shipping with the package as data.
 
-Snippets does not install by default. Pass `--snippets <category>`, such as `--snippets essentials`, to take it. Its own rule describing the `@` reference convention installs alongside it, so a project that declines snippets never receives a rule for a behavior it holds no snippet to exercise.
+No snippet is written into the project either. `claude/snippets` in the plugin cache symlinks to the toolkit's own `snippets/`, so a session reaches one at its `@` reference with no install step, the same live resolution `claude/standards` gives a rule's authority line.
 
-`governance`, `snippets`, and `wiki` are skippable:
+`governance` and `wiki` are skippable:
 
 - `--skip governance`: leave `.claude/rules/` empty, so no coding standard loads on a file match. The preview names any `--add` rules the skip drops, and the run prints the `aitk gov install <stack> <path>` command to add rules afterward, carrying those extras so one paste restores what the skip declined.
-- `--skip snippets`: the explicit spelling for what a bare init already does, since `--snippets` carries no default. Both print the `aitk snippets install essentials <path>` command afterward.
 - `--skip wiki`: skip the `.claude/wiki/` scaffold. A target that already carries a root `wiki/` keeps it, since the verb reports that folder rather than migrating it.
 
 The plugin corpus carries runtime behavior rather than reference prose alone, because the pre-publish scan and the branch-slug transform each have a standard of their own, `publish.md` and `slug.md`, cited by the skills that run them.
@@ -105,9 +104,8 @@ When a new need appears after scaffold, install the one domain without re-runnin
 - Governance rule for a newly adopted library: invoke `aitk:setup-gov`, or run `aitk gov install <stack> --add <rule> <path>`
 - Project-specific rule the toolkit does not ship: invoke `aitk:create-rule`. It scaffolds a rule into `.claude/rules/` with a non-colliding number, and `aitk gov sync` leaves it untouched.
 - Index.md system for a markdown-heavy folder that emerged: invoke `aitk:setup-indexes`
-- A snippet preset or category: `aitk snippets install <preset|category|all> <path>`. The argument is required, since the picker refuses headlessly rather than choosing for the caller
 
-Standards are not on that list, and there is nothing to add. No standard installs into a project, by default or by flag, so a session that needs one runs `aitk standards <name>` and reads it from the copy inside the package. A project holding a `.claude/standards/` folder from an older toolkit is carrying a stale artifact nothing reads, and deleting it is safe.
+Standards and snippets are not on that list, and there is nothing to add for either. Neither installs into a project, by default or by flag, so a session reads a standard with `aitk standards <name>` and a snippet through its `@` reference off the live plugin symlink, both resolving against the toolkit rather than a project copy. A project holding a `.claude/standards/` or `.claude/snippets/` folder from an older toolkit is carrying a stale artifact nothing reads, and deleting it is safe.
 
 Per-domain mechanics live in the corresponding `docs/<domain>.md`. The skill body in `claude/skills/<skill>/SKILL.md` covers detection and preview.
 
@@ -125,17 +123,17 @@ The report opens by naming the binary running it. The installed version reads ag
 
 #### Then the causes
 
-A `stale` file still matches what the toolkit installed, so the update is mechanical. A `customized` file carries local edits, so taking the upstream version is a decision and `aitk:claude-seed-sync` is the tool for it. A `stranded` file sits where an older toolkit installed it and the toolkit has since moved, which is what `aitk:migration-standards` handles.
+A `stale` file still matches what the toolkit installed, so the update is mechanical. A `customized` file carries local edits, so taking the upstream version is a decision and `aitk:claude-seed-sync` is the tool for it. A `stranded` file sits where an older toolkit installed it and the toolkit has since moved, which is a relocation the report names but no command runs.
 
-That attribution comes from `.claude/aitk/config.json`, a stamp every install and sync writes. A target stamped before that path shipped is read from the retired `.claude/aitk.json` instead, reported rather than migrated. Snippets and governance record a hash per installed file. Governance also records the stack `aitk gov install` was given, and tooling records the stack chain it resolved instead of any file hash, since its install runs no per-file walk to attribute.
+That attribution comes from `.claude/aitk/config.json`, a stamp every install and sync writes. A target stamped before that path shipped is read from the retired `.claude/aitk.json` instead, reported rather than migrated. Governance records a hash per installed file, plus the stack `aitk gov install` was given, and tooling records the stack chain it resolved instead of any file hash, since its install runs no per-file walk to attribute.
 
-Each domain holds its own toolkit commit, so syncing governance today does not move the revision snippets measures against, and each domain reports the upstream commits touching its own source path. Running any sync stamps that domain, and the report names the ones still unstamped.
+Each domain holds its own toolkit commit, so syncing governance today does not move the revision tooling measures against, and each domain reports the upstream commits touching its own source path. Running any sync stamps that domain, and the report names the ones still unstamped.
 
 A project that has never synced under a toolkit new enough to write a stamp falls back to the toolkit's own git history. Installed content matching any version that history published proves the file untouched, so it reports `stale` naming the commit it came from, and content matching no published version stays `drifted`. That fallback needs the toolkit as a git checkout. Installed from the registry it ships source without history, and the report says attribution was unavailable rather than reading every file as a local edit.
 
-Further causes sit outside the per-domain scan, each naming something that walk cannot see. A seed the project edited is reported under `seeds` and reconciled with `aitk:claude-seed-sync`, since no sync command touches a seed. A file a newer seed folder replaced is reported under `superseded`, such as `.claude/TASKS.md` against the `.claude/tasks/` that now ships, and nothing moves it because the content is the project's own. A domain sitting at the root layout with nothing under `.claude/` is reported under `unmigrated` and handed to `aitk:migration-standards`.
+Further causes sit outside the per-domain scan, each naming something that walk cannot see. A seed the project edited is reported under `seeds` and reconciled with `aitk:claude-seed-sync`, since no sync command touches a seed. A file a newer seed folder replaced is reported under `superseded`, such as `.claude/TASKS.md` against the `.claude/tasks/` that now ships, and nothing moves it because the content is the project's own. A domain sitting at the root layout with nothing under `.claude/` is reported under `unmigrated`, and no command moves it either. The project moves the content itself.
 
-That third one matters most on an older project. Before it existed, a target holding `snippets/` at its root reported zero entries for that domain, so a project that had never migrated was indistinguishable from one that was fully current. It covers snippets alone, since a root `standards/` folder in a target is the project's own authoring surface and nothing proposes moving it.
+`unmigrated` currently names no domain, since standards and snippets are the two the toolkit ever installed at the project root and both closed their install channel. A target still holding a root `standards/` or `snippets/` folder from an older toolkit is carrying its own authoring surface now, not an unfinished install, and nothing proposes moving either.
 
 #### Rules you never received
 
@@ -202,7 +200,7 @@ cd <your-project>
 claude
 ```
 
-In the session, invoke `aitk:setup-init`. The skill detects no framework and resolves tooling to `base`, governance to `base`, and snippets to `all`. The preview marks both stacks as fallbacks, since neither came from a match, then the chain runs `aitk init`.
+In the session, invoke `aitk:setup-init`. The skill detects no framework and resolves tooling to `base` and governance to `base`. The preview marks both stacks as fallbacks, since neither came from a match, then the chain runs `aitk init`.
 
 Ongoing: run `aitk sync --check .` to see what has drifted, then invoke `aitk:claude-seed-sync` for seed drift or `aitk sync .` for a catch-all refresh.
 

package/governance/rules/claude/575-hooks.md

@@ -0,0 +1,17 @@
+---
+description: State the hook stdin guard and the silencing rule for .claude/hooks scripts and their seeded copies
+paths:
+  - '.claude/hooks/**/*.sh'
+  - 'tooling/claude/seeds/.claude/hooks/**/*.sh'
+---
+
+# Hook standards
+
+## Reading a payload
+
+- Open a hook that reads a payload with a bounded `IFS= read -r -d '' -t 2 input`, exiting non-zero on an empty payload. An unbounded `cat` blocks forever against a hand run or an open socket, holding the session open with it. A test already checks this per file across both hook trees, but the rule stops the pattern being rediscovered rather than caught only after the fact.
+
+## Silencing output
+
+- Before silencing a hook's output, name the stage that catches the same failure. A hook that is the only enforcer of a rule makes its documented guarantee false when it discards that output.
+- Where no other stage catches the failure, capture the output into a variable, exit 0 on success, and emit the error lines as `additionalContext`.

package/governance/stacks/base.toml

@@ -1,4 +1,6 @@
 extends = ""
-# Both folders whole. Every rule authored under them ships to a base consumer,
-# so adding one is a single edit rather than a file and a name here.
-rules = ["core", "claude", "120-bash"]
+# All three folders whole. Every rule authored under them ships to a base
+# consumer, so adding one is a single edit rather than a file and a name here.
+# `snippets` carries the `@`-reference convention rule, which lost its only
+# other delivery path when `aitk snippets install` retired.
+rules = ["core", "claude", "snippets", "120-bash"]

package/package.json

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

package/scripts/core/install-check.sh

@@ -67,7 +67,7 @@ mkdir -p "$TARGET_DIR"
 log_info "Initialized git in $TARGET_DIR"
 
 log_step "Run aitk init"
-(cd "$TARGET_DIR" && AITK_NON_INTERACTIVE=1 bun run "$CLONE_DIR/src/cli.ts" init --stack base --snippets essentials 2>&1 | pipe_output) || log_error "aitk init failed"
+(cd "$TARGET_DIR" && AITK_NON_INTERACTIVE=1 bun run "$CLONE_DIR/src/cli.ts" init --stack base 2>&1 | pipe_output) || log_error "aitk init failed"
 log_info "aitk init completed"
 
 log_step "Assert scaffold"
@@ -76,18 +76,16 @@ log_step "Assert scaffold"
 # catches a failed domain, and the gate stays green while the target is
 # missing everything that domain provides.
 #
-# Standards name no path because the corpus installs into no target. A scaffold
-# reads a standard through `aitk standards <name>`, which resolves against the
-# copy inside the package.
-#
-# Snippets carries no default, so the run above passes `--snippets essentials`
-# explicitly. The snippets path has to name a slug that preset still carries;
-# editing the preset without editing this line fails the gate on a correct
-# install. The rule path confirms the domain's own convention rule installs
-# alongside it, since a target that declined snippets never receives it.
-for path in "CLAUDE.md" ".claude/snippets/decision-help.md" ".claude/rules/snippets/505-at-references.md" ".claude/wiki/index.md" ".claude" ".claude/context/index.md" ".claude/wireframes/index.md" ".claude/diagrams/index.md" \
+# Standards and snippets name no path because neither corpus installs into a
+# target. A scaffold reads a standard through `aitk standards <name>` and a
+# snippet through the plugin's live `claude/snippets` symlink, both resolving
+# against the toolkit rather than a copy this gate could assert on. The
+# `@`-reference convention rule is the one snippets-domain file that still
+# installs, since `base` carries `governance/rules/snippets/` as a
+# folder-whole entry the same way it does `core` and `claude`.
+for path in "CLAUDE.md" ".claude/wiki/index.md" ".claude" ".claude/context/index.md" ".claude/wireframes/index.md" ".claude/diagrams/index.md" \
   ".prettierrc" ".editorconfig" ".lintstagedrc" ".husky/pre-commit" ".github/workflows/verify.yml" "scripts/verify.sh" \
-  ".claude/rules/core/000-constitution.md"; do
+  ".claude/rules/core/000-constitution.md" ".claude/rules/snippets/505-at-references.md"; do
   if [ ! -e "$TARGET_DIR/$path" ]; then
     log_error "Missing after aitk init: $path"
   fi

package/scripts/core/verify.sh

@@ -21,13 +21,15 @@ SANDBOX_UNDECLARED_CEILING=47
 
 # Rules no stack reaches, space separated and sorted the way `aitk gov list`
 # emits them. `260-shadcn` and `320-tanstack-query` are opt-in libraries a
-# project may not want; `505-at-references` ships with no stack on purpose,
-# since a rule under `claude/` would reach every base consumer through the
-# folder-whole entry, and only `aitk snippets install` writes it, alongside
-# the snippets a caller took. All three are recorded here rather than in a
-# config file: the list is what a reader compares a new arrival against, and a
-# config file would absorb the arrival silently.
-GOV_EXPECTED_UNREFERENCED="260-shadcn 320-tanstack-query 505-at-references"
+# project may not want. `505-at-references` used to sit here too, shipping
+# with no stack on purpose since a rule under `claude/` would reach every
+# base consumer through the folder-whole entry there. Its own install
+# channel, `aitk snippets install`, retired with nothing left to deliver it,
+# so `base` now carries `snippets` as a folder-whole entry of its own and the
+# rule reaches every base consumer through that instead. Both are recorded
+# here rather than in a config file: the list is what a reader compares a
+# new arrival against, and a config file would absorb the arrival silently.
+GOV_EXPECTED_UNREFERENCED="260-shadcn 320-tanstack-query"
 
 # The retained counts the audit stage compares each run against. Spelled here
 # rather than derived, because this script only ever names the file in a remedy