@erclx/canon 4.103.0 → 4.104.0

package/src/gate/stages.ts

@@ -10,6 +10,7 @@ import {
   recordIdempotence,
   sandboxCoverage,
   seedStandards,
+  rawFieldFileReference,
   shippedReferences,
   standardCriteria,
   unreferencedRules,
@@ -207,20 +208,6 @@ export const STAGES: readonly Stage[] = [
     ],
     success: 'Hero clean',
   },
-  {
-    id: 'tooling-paths',
-    label: 'Tooling paths',
-    checks: [
-      script('regen-tooling-paths.sh', 'Tooling-path regen failed'),
-      {
-        kind: 'drift',
-        pathspec: 'claude/skills/canon-cli/SKILL.md',
-        failure:
-          'The overwrite contract drifted from what the stacks hold. Run bun run check and commit claude/skills/canon-cli/SKILL.md.',
-      },
-    ],
-    success: 'Tooling paths clean',
-  },
   {
     // `canon/DESIGN.md`, the base stylesheet, the web stylesheet, and the
     // tab icon are all written from `src/design/tokens.ts` and none is edited
@@ -423,6 +410,15 @@ export const STAGES: readonly Stage[] = [
     skipped: 'No shipped corpus changed, so no reference was read',
     checks: [{ kind: 'measure', measure: shippedReferences }],
   },
+  {
+    // Same corpora as shipped-references and a separate stage, since the
+    // verdict is a flag spelling rather than an unresolvable reference.
+    id: 'raw-field-file-reference',
+    label: 'Raw-field file references',
+    scope: new RegExp(SHIPPED_CORPORA.map((corpus) => `^${corpus}/`).join('|')),
+    skipped: 'No shipped corpus changed, so no flag was read',
+    checks: [{ kind: 'measure', measure: rawFieldFileReference }],
+  },
   {
     // Scoped to the two files a citation can drift between, so an edit to
     // either one runs the check. web/src/content/copy.ts carries the anchors

package/src/gov/list.ts

@@ -30,7 +30,7 @@ export interface GovCatalog {
 
 /**
  * Reports each stack's own entries expanded, so a folder entry reaches a
- * consumer as the rules it stands for. `setup-gov` dedupes `--add` extras
+ * consumer as the rules it stands for. the `setup` skill dedupes `--add` extras
  * against this list, and a stack answering `core` there would re-add every
  * rule that folder already carries.
  *

package/src/sandbox/census.ts

@@ -71,9 +71,9 @@ export function listSkills(root: string): string[] {
  *
  * `<category>-<command>` is the rule `canon/context/sandbox/coverage.md` states, and it
  * alone pairs 29 of 54 skills. The bare `<command>` fallback is what reaches the
- * rest: `claude/setup-init.sh` drives the `setup-init` skill, not a
- * `claude-setup-init` that does not exist. Stating one spelling and shipping two
- * is what let the audit report a paired skill as unpaired.
+ * rest: `claude/target-setup.sh` drives the `target-setup` skill, not a `claude-target-setup` that
+ * does not exist. Stating one spelling and shipping two is what let the audit
+ * report a paired skill as unpaired.
  *
  * Returns undefined for a scenario driving no skill at all, which is every
  * `infra/` and `tooling/` scenario. Those exercise a CLI domain rather than a

package/src/shipped/references.ts

@@ -210,7 +210,7 @@ const PHASE_LABEL = /\bv\d+\.\d+(?!\.\d)\b/g
  *
  * Anchored on the trailing `\d{3}-[\w-]+\.md` rather than on the bare
  * `.claude/rules/` prefix, which is what keeps a folder mention carrying no
- * number, such as `create-rule`, `memory-review`, and `setup-gov` already
+ * number, such as `create-rule`, `memory-review`, and `target-setup` already
  * write correctly, from matching. The segment group between `rules/` and the
  * numbered file admits both a governance-namespace path
  * (`canon/core/055-scratch.md`) and a project-namespace one

package/standards/index.md

@@ -19,7 +19,6 @@ Reference docs for consistent authoring across the toolkit and target projects.
 - [Glossary reference](glossary.md): Frontmatter, entry shape, ordering, and the rules deciding which terms a glossary carries
 - [Groundwork reference](groundwork.md): Folder layout, ordinal naming, reserved numbering, frontmatter and dating, required file contents, and conventions for a measurement track
 - [Intake reference](intake.md): Folder layout, ordinal naming, reserved index number, frontmatter and dating, the item template, the answer contract, and retrieval
-- [Issue reference](issue.md): GitHub issue title, labels, and body conventions
 - [Markdown reference](markdown.md): Headings, paragraph and list structure, code spans, the date form, punctuation, emphasis, file references, banned words, and frontmatter wording
 - [Memory reference](memory.md): Filename and type prefix, frontmatter, the body shape per type, links between entries, and the lifecycle from write to retire
 - [Mermaid reference](mermaid.md): Direction and layout, node and edge budgets, accessibility fields, label punctuation, and render verification for a Mermaid diagram

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

@@ -1,37 +0,0 @@
----
-name: setup-gov
-description: Scope boundary for governance rule install and the authoring it refuses to do in a target
----
-
-# Setup gov requirement
-
-## Gap
-
-Without this skill, a session picks a stack name from memory and installs rules written for a framework the project does not use, passes an extra the catalog does not carry so the install warns on a file it cannot resolve, and adds a rule the picked stack already pulls in.
-
-The two costly failures are quieter. An unmatched technology gets the nearest rule instead of a stop, so the project carries governance authored for something adjacent and nothing marks it as a guess. A rule written directly into the target lands where no sync will ever reach it, so it drifts from the toolkit copy that owns it.
-
-The last failure sits at a boundary rather than inside a run. `setup-init` turns away a project whose language it carries no stack for and sends it here, and a body stating only what this skill does not cover leaves that route running one way, so a person arriving on it reads a skill that never says it is the destination.
-
-## Must
-
-- Read the catalog at run time and resolve both the stack and every extra against it
-- Name the evidence file behind each detected technology in the preview, so a wrong match is visible before the install rather than after
-- Dedupe extras against the rules the picked stack already resolves
-- Run the install non-interactively, since the CLI picker blocks where no terminal is attached
-- State the inbound route from `setup-init`, so a project sent here for the language-neutral rule layer can tell it landed at the destination the chain named
-
-## Must not
-
-- Author a rule inside the target project. Rules are authored in the toolkit and reach a project by install or sync.
-- Install a stack or extra whose name did not come from the catalog read
-
-## Guards
-
-- An unmatched technology stops and presents the options rather than resolving to a nearby rule. Authoring the missing rule in the toolkit, installing the matching layers without the technology-specific one, and aborting are the three, and this skill picks none of them.
-
-## Out of scope
-
-- The rest of the onboarding chain. This skill installs governance and nothing else, and `setup-init` is the one-shot path that installs governance beside tooling, snippets, and the seeds.
-- Scaffolding the rule file an unmatched technology needs. `create-rule` writes one into a target project, and a rule the toolkit should ship is authored under `governance/rules/` against `canon standards rule`.
-- Updating rules a project already has, which `canon gov sync` owns

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

@@ -1,77 +0,0 @@
----
-name: setup-gov
-description: Detects a project's stack from its files and installs matching toolkit governance rules into `.claude/rules/`. Use after scaffolding a new project, when asked to "install gov rules", "install governance", "set up governance", or when a target project has no `.claude/rules/` yet. Assumes the `canon` CLI is on PATH.
----
-
-# Gov install
-
-Automates `canon gov install` by inferring the stack and extras from the current project, then shelling out to the CLI with the resolved arguments.
-
-## Scope
-
-- Governance rules and nothing else. `setup-init` is the one-shot chain that installs governance beside tooling, standards, snippets, and the seeds.
-- This is where `setup-init` sends a project whose language the toolkit carries no stack for. Rules install without the `base` development dependencies the tooling layer would drop on it. Resolve and stop exactly as below, since a language with no stack is the unmatched case `## Gap handling` already owns and arriving by that route changes none of it.
-
-## Read the catalog
-
-Run this first to load the current stacks and rules. Never hardcode names. The catalog is the source of truth.
-
-```bash
-canon gov list --json 2>/dev/null
-```
-
-## Detect the stack
-
-Read these from the project root in parallel:
-
-- `package.json`: dependencies and devDependencies
-- Root config files: `astro.config.*`, `next.config.*`, `vite.config.*`, `tailwind.config.*`, `tsconfig.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
-- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
-- Directory structure via `ls -1` of the project root and `src/` if present
-
-## Match
-
-Match the detected evidence to the catalog:
-
-- Pick the closest stack. Match detected runtime or framework against stack names in the catalog.
-- Identify additional technologies not already covered by the picked stack. For each, find a rule whose `description` or `paths` points at that technology, then add it via `--add`.
-- Dedupe extras against stack rules. Do not add a rule the stack already pulls in.
-
-## Gap handling
-
-If a detected technology has no matching rule, stop and surface the gap. Do not guess.
-
-Present four options:
-
-1. Author a new rule in the toolkit at `governance/rules/<domain>/<num>-<name>.md` following `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, commit, then re-run install. Take this route when the toolkit should ship the rule to every project.
-2. Invoke `create-rule`, which scaffolds the file into the target project at a non-colliding number. Take this route when the rule is specific to this project and no sync should ever overwrite it.
-3. Install the matching non-<tech> rules and skip the tech-specific layer.
-4. Abort.
-
-This skill authors no rule itself. Option 1 writes in the toolkit repository, and option 2 hands the project-local file to `create-rule`.
-
-## Preview
-
-Before executing, output:
-
-- **Detected:** each technology with the file that evidenced it
-- **Stack:** picked stack name and total resolved rule count
-- **Extras:** each `--add` rule with a one-line reason
-- **Target:** resolved target path
-- **Command:** the exact shell command to run
-
-## Execute
-
-Run with `CANON_NON_INTERACTIVE=1` so no CLI picker prompts appear. Claude Code's tool permission dialog is the confirmation gate.
-
-```bash
-CANON_NON_INTERACTIVE=1 canon gov install <stack> --add <extras> <target>
-```
-
-## Response
-
-After execution, report:
-
-- Rule count installed
-- Target path
-- Any rules that failed to resolve (the CLI warns on missing rule files)

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

@@ -1,48 +0,0 @@
----
-name: setup-indexes
-description: Why index bootstrap is all-or-nothing per folder, what the confirmation loop protects, and why the convention block is pasted rather than written
----
-
-# Setup indexes requirement
-
-## Gap
-
-Without this skill, a session bootstrapping the index system writes `index.md` into a folder and leaves the sibling frontmatter for later, so the first regen hard-errors on the first file missing a `title`. Partial coverage is not a partial success. The folder is broken until every sibling carries both fields, and the error surfaces at regen rather than at the write that caused it.
-
-The scan is where the other failures start. A walk that does not prune reaches `node_modules`, gitignored output, and the snippets folder, which is invoked by reference rather than browsed and needs neither an index nor per-file frontmatter. A folder that already carries an `index.md` gets a second one written over the first.
-
-One failure predates the scan. `setup-init` declines an install that wants the Claude layer without the tooling chain and names this skill as where the index system gets bootstrapped, and a body that never states the inbound route leaves the person arriving on it unable to tell whether they landed at the destination or somewhere adjacent to it.
-
-Drafted frontmatter is a proposal, and a session that writes it before the user sees it turns a review into a cleanup. The convention block has the mirror failure. A session that paraphrases it into `CLAUDE.md` produces a copy that reads correctly and no longer matches its source, so the two drift with nothing reporting it. And a project with no `CLAUDE.md` gets one scaffolded to hold the block, which installs a file the project declined.
-
-A fourth failure sits after the scan rather than inside it. `## Present candidates` had no branch for a scan that finds zero folders, so an empty result walked straight into the ask with nothing to choose from. `setup-init` folds this skill into the onboarding chain, and a fresh scaffold usually carries no markdown-heavy folder yet, so the ordinary onboarding run reached the undefined case.
-
-## Must
-
-- Bootstrap all-or-nothing per chosen folder, since a folder carrying partial frontmatter hard-errors on regen
-- Prune the scan to folders a reader browses, and skip any folder already carrying an `index.md`
-- Surface every drafted `title` and `description` for the user to accept, edit, or reject before anything is written
-- Validate with a dry run and stop on the first reported error, before writing for real
-- Paste the convention block verbatim from its single source
-- Emit the closeout exactly once, whatever the seed step concluded
-- State the inbound route from `setup-init`, so an install wanting the Claude layer without the tooling chain can tell it landed at the destination the chain named
-
-## Must not
-
-- Write a draft the user has not confirmed
-- Index the snippets folder, which is read by reference rather than browsed
-- Create `CLAUDE.md` to hold the convention block. Name the skip and the command that installs the file.
-- Overwrite content below the frontmatter block, or touch a file the user rejected
-
-## Guards
-
-- A folder with fewer than the sibling threshold stays out of the candidate list unless the user names it explicitly, so the scan proposes and the user overrides
-- A `CLAUDE.md` already carrying the convention section skips the seed silently rather than appending a second copy
-- A scan that finds no candidate reports a one-line result and returns, skipping the ask and every step between it and the seed offer, rather than opening a prompt with nothing in it
-
-## Out of scope
-
-- Regenerating an index in a project that already runs the system, which `canon indexes regen` does on its own
-- Wiring the lint-staged entry or the hook, which the closeout offers and the user opts into
-- Installing governance rules or scaffolding a project: `setup-gov` and `setup-init`
-- Writing the frontmatter conventions themselves, which the prose standard owns

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

@@ -1,46 +0,0 @@
----
-name: setup-init
-description: Scope boundary for the one-shot onboarding chain and the setup steps it leaves to a caller
----
-
-# Setup init requirement
-
-## Gap
-
-Without this skill, a session installs a stack whose name it recalled rather than read, hand-writes configs the tooling sync already ships as golden files, and re-runs the chain over a project that owns its configs already.
-
-Two failures are the expensive ones because both return success. A monorepo run drops husky into every subtree, git honors one `core.hooksPath`, and the extra hook directories go quiet with nothing reporting it. A caller reads the chain as onboarding complete when plugin provisioning never runs, since no step states that it sits outside the chain.
-
-Two more start at the resolve step. A project whose language the toolkit carries no stack for resolves to `base`, and the preview reports the resolved name without marking it as a fallback, so `base` development dependencies, scripts, and hooks land on a project that will not use them and nobody had the moment to decline.
-
-The other is the refusal that ends rather than routes. An existing project, an install wanting the Claude layer without the tooling chain, and a language with no stack are the three states the chain does not serve, and each is declined by a declaration naming no destination, so the person who arrived with one reads a stop and goes no further.
-
-## Must
-
-- Resolve every domain argument against a catalog read at run time, so a stack, rule, snippet, or tooling name the catalog does not carry cannot reach the command line
-- Preview the resolved chain before the first command runs, naming the evidence file behind each detected technology
-- Pass `--skip base` on every subtree past the first in a monorepo, so the shared hook layer lands once
-- State which onboarding steps the chain does not run and why, so a caller knows what is left and where the boundary sits rather than inferring completeness from a clean report
-- Mark a stack reached by fallback as a fallback in the preview, and name what `base` carries, so the write can be declined at the one point it is still declinable
-- Name a destination for every state the chain does not serve, in this body rather than only in a reference doc the person would have to already know to open, and say for each whether the chain stops or runs on a default
-
-## Must not
-
-- Generate a config that tooling sync ships as a golden file. Generating from prose duplicates the installed file and the two drift.
-- Author a rule, stack, or snippet inside the target project when detection finds no match. Authoring happens in the toolkit and reaches a project by install or sync.
-- Grow an existing-project branch, a mode switch, or a clobber guard. The chain runs once against a fresh scaffold and the per-domain paths cover everything after that.
-
-## Guards
-
-- An unmatched technology stops for a decision. Surface the gap and either defer to rule authoring or proceed on the matched layer with the gap named in the report, rather than resolving to the nearest rule.
-
-## Out of scope
-
-- Installing governance rules alone: `setup-gov`. This skill installs governance beside tooling and the seeds.
-- 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 step 4
-- Publishing repository metadata: `repo-metadata`. It reaches a remote, which is past the project edge this chain stops at.
-- Making the first commit: `git-commit`. It reaches the project's history, which is past the project edge this chain stops at.
-- Re-installing into a project that already has the files, which the per-domain `canon <domain> install` and `canon sync` commands own
-- Deciding which of those per-domain commands an existing project needs: `canon-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 `canon claude init` does on its own and `setup-indexes` finishes

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

@@ -1,133 +0,0 @@
----
-name: setup-init
-description: Detects a new project's type and runs `canon 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 `canon` CLI is on PATH. Do NOT use when only installing governance rules. Use `setup-gov` instead.
----
-
-# Init project
-
-Orchestrates the onboarding chain. Detects project type, resolves per-domain arguments, previews the chain, then runs `canon init` with flags. The CLI holds the install logic. This skill only resolves and previews.
-
-## Scope
-
-- This skill and `canon init` run once on a fresh scaffold, never on an existing project. They do not guard against clobbering existing configs. When tempted to add guards, mode switches, or an existing-project branch, stop. Extend the per-domain `canon <domain> install` or `canon sync` paths instead.
-- The chain folds `setup-indexes` in as its own final step, once the project-scoped work is written. It still does not provision Claude Code plugins: `setup-plugins` owns that, installing once per machine rather than into a project, so no project-scoped chain can carry it. Name it in the report so a clean result does not read as onboarding complete.
-
-## Declined states
-
-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 `canon-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 `canon 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.
-
-Do not add a stack, a mode switch, or an existing-project branch to satisfy one of these. Each destination already exists and routing to it costs a line.
-
-## Read catalogs
-
-Run in parallel. Never hardcode stack, rule, snippet, or standards names.
-
-Run from the target project's current directory. Do not cd into the toolkit source tree. The `canon` CLI is global.
-
-```bash
-canon gov list --json 2>/dev/null
-canon tooling list --json 2>/dev/null
-```
-
-## Detect
-
-Read these from the project root in parallel, skipping any that do not exist:
-
-- `package.json`: `dependencies` and `devDependencies`
-- Root configs: `astro.config.*`, `next.config.*`, `vite.config.*`, `tailwind.config.*`, `tsconfig.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`
-- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
-- Directory structure via `ls -1` of the project root and `src/` if present
-
-## Resolve arguments
-
-- **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 `canon tooling list --json` (e.g. `vite-react`, `astro`, `nextjs`). Distinct from the governance stack. Fall back to `base` if no framework match, and carry that fallback into the preview too.
-- **Next.js:** map `next` in `package.json` dependencies, or a root `next.config.ts`/`.js`/`.mjs` file, to the `nextjs` tooling stack. The dependency name does not match the stack name by itself.
-- **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.
-- **Skip (`--skip`):** `wiki` installs by default. Add `--skip wiki` only when the user explicitly wants it left out.
-
-## Gap handling
-
-If a detected technology has no matching rule or stack, do not guess. Surface the gap and either:
-
-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 and stacks are authored in the toolkit repo, never in the target project on the fly.
-
-## Preview
-
-Before executing, output:
-
-- **Detected:** each technology with its evidence file
-- **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
-- **Skip:** any `--skip` entries with reason
-- **Target:** resolved target path
-- **Commands:** the full chain that will run
-
-A resolved name and a fallback read alike once written, so mark the fallback here rather than in the report. The preview is the last point before the first write, and the report runs after the files have landed.
-
-## Execute
-
-Run the chain in order, starting immediately after the preview. Each step's permission dialog is the confirmation gate, except step 5, which hands off to a skill that confirms its own folder list with the operator. Do not pause for additional confirmation elsewhere. Run from the target project's current directory.
-
-Step 1: `canon init` installs base tooling, claude seeds, governance rules, and wiki.
-
-```bash
-CANON_NON_INTERACTIVE=1 canon init \
-  --stack <stack> \
-  --add <rules> \
-  <target>
-```
-
-Omit any flag whose resolved value is empty.
-
-Step 2: `canon tooling sync <tooling-stack> --write` installs stack deps, scripts, gitignore entries, seeds, golden configs, and drops the reference doc. The extends chain is walked, so syncing `vite-react` also pulls `web` and `base` configs. Skip if the tooling stack is `base` (already synced by `canon init`).
-
-`--write` is required. A headless run without it reports what it would replace and exits 1, since golden configs overwrite whatever the target holds at those paths. Scaffolding into a fresh target has nothing to lose, so pass it directly rather than reading a report first.
-
-```bash
-CANON_NON_INTERACTIVE=1 canon tooling sync <tooling-stack> <target> --write
-```
-
-Monorepo with multiple language roots: run `canon init` once at the repo root so `base` (husky, prettier, cspell, commitlint, CI) lands single, then sync each subtree with `--skip base` so the shared layer is not re-dropped.
-
-```bash
-CANON_NON_INTERACTIVE=1 canon tooling sync vite-react ./frontend --skip base --write
-CANON_NON_INTERACTIVE=1 canon tooling sync python ./backend --skip base --write
-```
-
-Without `--skip base`, each subtree re-drops husky, and git honors only one `core.hooksPath`, so the extra hook dirs silently break. Each subtree keeps its own framework configs, and its own stack reference reads through `canon tooling reference <stack>`.
-
-Step 3: post-sync fixups. Golden configs arrive from sync, so no config generation is required. But a few items may need a one-time touch:
-
-- **ESLint version pin.** If `bun create vite` installed `eslint@^10` and the manifest pins `eslint@^9`, sync does not override a present dep. Run `bun add -d eslint@^9` if `bun run lint:fix` fails with `Class extends value undefined`.
-- **File naming.** `bun create vite`'s `App.tsx` violates the `KEBAB_CASE` rule. Rename to `app.tsx` and update the import in `main.tsx`.
-- **Docs.** Run `canon tooling reference <tooling-stack>` and `canon tooling reference web` for any stack-specific follow-ups (Chrome extension overrides, setup script details).
-
-Do not generate ESLint, Vitest, or Playwright configs. They ship as golden files. Generating from prose duplicates what sync already installed.
-
-Step 4: invoke `setup-verify`. Runs the `package.json` scripts and reports pass/fail.
-
-Step 5: hand off to `setup-indexes` to bootstrap the `index.md` system over the project's own documentation folders. The skill confirms candidate folders with the operator rather than running unattended, which is the one step in this chain that pauses for a conversation. A fresh scaffold usually has no markdown-heavy folder yet, so this step frequently hands off with nothing for `setup-indexes` to present, which is that skill's own outcome to define rather than a claim this chain makes for it.
-
-## Report
-
-After the chain, report:
-
-- Domains installed with a check per domain
-- Tooling stack synced (or skipped). Name the layers pulled via the extends chain.
-- Any post-sync fixups applied (ESLint pin, filename renames)
-- `setup-verify` outcome
-- `setup-indexes` outcome (folders bootstrapped, or none found)
-- Any domains or scripts that failed
-- Any detection gaps surfaced during resolve
-- Onboarding steps left to the caller: `setup-plugins` for Claude Code plugins
-
-The chain stops at the project edge. `repo-metadata` and `git-commit` also ship, reaching a remote and the project's history respectively, and neither runs here.

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

@@ -1,42 +0,0 @@
----
-name: setup-plugins
-description: Why plugin installs read a curated catalog, install user-scoped, and never touch toolkit workflow skills
----
-
-# Setup plugins requirement
-
-## Gap
-
-Without this skill, a session asked to install plugins invents marketplace sources and install strings from names it half remembers, and a plugin name that does not exist fails in a way that reads like a network problem. The catalog is the difference between an install and a guess.
-
-Scope is the failure that shows up later. A domain plugin installed into one project is missing from the next one, so the machine looks provisioned until the user opens another repository. The mirror mistake is treating toolkit workflow skills as plugins to install, when they load live through a plugin directory and a copied version goes stale the moment it lands.
-
-Two failures come from running the batch carelessly. A reinstall over a plugin already present costs time and can replace a working version. And a batch that aborts on the first failure leaves a partial install with no record of which rows ran, so the next attempt starts from an unknown state.
-
-## Must
-
-- Read the curated catalog through the skill's own directory, so the path resolves from any project
-- Detect what is already installed and skip those rows
-- Install user-scoped, since a domain plugin belongs to the machine rather than to one project
-- Run each install independently so one failure does not abort the batch
-- Preview the chosen rows, the scope, and the exact commands before executing
-- Report the failures with their CLI errors, the reload requirement, and the settings-level remedy for an over-triggering plugin
-
-## Must not
-
-- Install a plugin, marketplace, or command string that is not in the catalog
-- Install toolkit workflow skills, which load live rather than being copied
-- Reinstall a plugin already present
-- Pause for a confirmation beyond the tool permission dialog
-
-## Guards
-
-- The `claude` CLI absent from PATH stops before any install, since every step shells out to it
-- A catalog row that installs outside the plugin CLI runs its own installer verbatim rather than being forced through the marketplace path
-
-## Out of scope
-
-- Curating the catalog, which is an edit to the bundled reference rather than a run of this skill
-- Uninstalling, since an over-triggering plugin is tuned through settings rather than removed
-- Installing anything into a project, which every setup skill but this one does
-- First-time project scaffolding: `setup-init`

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

@@ -1,81 +0,0 @@
----
-name: setup-plugins
-description: Installs curated community and official Claude Code plugins user-scoped on the current machine via the `claude plugin` CLI. Use when asked to "install plugins", "set up plugins", "install the frontend/design/security/debugging plugins", "provision plugins on this machine", or when setting up Claude Code on a new computer. Do NOT use to install toolkit workflow skills, which load live via `--plugin-dir`. Assumes the `claude` CLI is on PATH.
----
-
-# Setup plugins
-
-Automates plugin installs by reading the curated catalog, detecting what is already
-installed, and shelling out to the `claude plugin` CLI with `--scope user` so the
-plugins are available in every project on this machine.
-
-Domain-knowledge plugins install once per machine. They are not copied into any
-project. Toolkit workflow skills are a separate concern and load live through
-`--plugin-dir`, so never install those here.
-
-## Guards
-
-- If the `claude` CLI is not on PATH, stop: `❌ claude CLI not found. Install Claude Code first.`
-
-## Read the catalog
-
-Read the curated list from the skill folder. Use `${CLAUDE_SKILL_DIR}`, which
-expands to this skill's own directory, so the path resolves from any project. Never
-invent plugin names or install strings that are not in it.
-
-- `${CLAUDE_SKILL_DIR}/references/plugin-catalog.md`: verified plugins, marketplace sources, and the recommended default set
-
-## Detect what is installed
-
-Run this to skip plugins already present. Do not reinstall an installed plugin.
-
-```bash
-claude plugin list 2>/dev/null || echo "NONE"
-```
-
-## Select
-
-When plugin names are passed as arguments, install exactly those and skip the prompt.
-
-When invoked bare, present the catalog grouped by category with the recommended
-default marked, then ask which to install. Accept a bulk answer:
-
-- `recommended`: the default set from the catalog
-- `all`: every catalog row not already installed
-- a specific list of plugin names
-
-## Preview
-
-Before executing, output:
-
-- **Installed:** plugins already present, skipped
-- **To install:** each chosen plugin with its category and marketplace source
-- **Scope:** `user` (every project on this machine)
-- **Commands:** the exact shell commands to run
-
-## Execute
-
-For each chosen plugin, add its marketplace source if it is not already added, then
-install the plugin user-scoped. Run each install independently so one failure does
-not abort the batch.
-
-```bash
-claude plugin marketplace add <source> 2>/dev/null || true
-claude plugin install <name> --scope user
-```
-
-For a catalog entry listed under "Installs outside the claude plugin CLI", skip the
-marketplace step and run its installer command verbatim instead.
-
-Claude Code's tool permission dialog is the confirmation gate. Do not pause for a
-separate confirmation.
-
-## Response
-
-After execution, report:
-
-- Plugins installed, each with its marketplace
-- Plugins skipped as already installed
-- Any install that failed, with the CLI error
-- A reload note: installed plugins apply on the next session or after `/reload-plugins`
-- A tuning note: if a plugin over-triggers, set `skillOverrides` in settings to `name-only`, `user-invocable-only`, or `off` rather than uninstalling

package/claude/skills/setup-plugins/references/plugin-catalog.md

@@ -1,53 +0,0 @@
----
-title: Plugin catalog
-description: Curated community and official Claude Code plugins that setup-plugins installs
----
-
-# Plugin catalog
-
-Curated domain-knowledge plugins the `setup-plugins` skill installs user-scoped.
-Each row is verified to install through the `claude plugin` CLI. This file holds
-only the actionable install data.
-
-## Install data
-
-Add the marketplace source once, then install the plugin by name. The CLI resolves
-the plugin across added marketplaces, so `<name>@<marketplace>` is only needed to
-disambiguate a name that exists in more than one marketplace.
-
-| Plugin              | Category  | Marketplace source       | Why                                                                  |
-| ------------------- | --------- | ------------------------ | -------------------------------------------------------------------- |
-| `frontend-design`   | design    | `anthropics/claude-code` | Steers UI generation toward intentional typography, hierarchy, color |
-| `security-guidance` | security  | `anthropics/claude-code` | Security-aware authoring guidance during code generation             |
-| `code-review`       | review    | `anthropics/claude-code` | Multi-agent PR review across compliance, bugs, history, and comments |
-| `superpowers`       | debugging | `obra/superpowers`       | Methodology skills: systematic-debugging, root-cause-tracing         |
-
-## Recommended default
-
-The `design` and `security` categories cover the common gaps for a new machine.
-When the user asks for a recommended set, propose `frontend-design` and
-`security-guidance`. Offer `code-review` and `superpowers` as additions.
-
-`code-review` overlaps the toolkit's own `review-branch` skill. They run in
-different places, the plugin on a PR and the toolkit skill on a local diff. Install
-`code-review` only when the user wants the GitHub-side flow too.
-
-## Installs outside the claude plugin CLI
-
-Some strong plugins do not distribute through a marketplace, so the `claude plugin`
-path does not reach them. List them here with their real installer. Surface them to
-the user during selection, but do not run their install through the marketplace
-step above. Run the installer command verbatim only when the user picks it.
-
-| Plugin       | Category | Installer                       | Why                                                               |
-| ------------ | -------- | ------------------------------- | ----------------------------------------------------------------- |
-| `impeccable` | design   | `npx impeccable skills install` | Curated anti-slop reference files, sharper than `frontend-design` |
-
-`npx impeccable skills install` detects the Claude Code harness and installs into
-`.claude/`. It may prompt, so it is not fully non-interactive. After install, run
-`/impeccable init` and reload.
-
-Install per project, not per machine. The skill invokes its scripts through paths
-relative to the current project (`.claude/skills/impeccable/scripts/*.mjs`), so a
-copy under `~/.claude/` cannot locate them once the working directory is a
-different project. Re-run the installer in each project that wants impeccable.