@erclx/canon 4.102.0 → 4.104.0

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.

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

@@ -1,38 +0,0 @@
----
-name: setup-smoke
-description: Why the heavy scaffold stages need an owner and what heuristic judges a server smoke pass
----
-
-# Setup smoke requirement
-
-## Gap
-
-Without this skill, a freshly scaffolded project's dev server, preview server, end-to-end suite, and screenshot harness never run anywhere. `setup-verify` excludes all three for the flakiness reasons that make them wrong for an unattended chain, and names no destination for any of them, so a broken dev server or a missing end-to-end dependency surfaces only once the user hits it by hand.
-
-A dev or preview server carries no exit code to read, since it runs until stopped rather than finishing on its own, unlike the leaf scripts `setup-verify` runs. Judging it needs a heuristic rather than a pass/fail read.
-
-## Must
-
-- Read the scripts the project declares and run only those, skip absent ones
-- Run `dev`, `preview`, `test:e2e`, `screenshot` in that fixed order, stopping at the first failure
-- Judge a server script by running it in the background, waiting a fixed window, checking the process is alive and its output carries no fatal error string, then killing it regardless of the outcome
-- Install dependencies itself when missing, so it runs standalone without `setup-verify` having run first
-
-## Must not
-
-- Invent a fallback command for an absent script
-- Run a composite script
-- Require `setup-verify` to have passed first
-- Duplicate a leaf script `setup-verify` already runs
-- Get invoked by anything other than a person or a chain naming it directly. Review this at each future change, since nothing can answer it before the skill has run. `canon docs target-projects` states the scaffold chain that keeps it outside the unattended path, for the same flakiness reasons that keep it out of `setup-verify`'s own leaf-script order.
-
-## Guards
-
-- No `package.json` at the project root stops, since there are no declared scripts to read
-- A missing dependency folder installs first rather than letting every script fail on the same cause
-
-## Out of scope
-
-- The leaf scripts `setup-verify` already runs: `lint:fix`, `typecheck`, `check`, `test:run`, `build`
-- Generating the configs these scripts drive, which the tooling stack reference owns
-- A true port-probe readiness check, since no manifest key exposes a generic port across stacks

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

@@ -1,53 +0,0 @@
----
-name: setup-smoke
-description: Runs the heavy scaffold checks setup-verify skips - dev and preview server smoke, Playwright end-to-end tests, and the screenshot harness - on the same declared-scripts contract. Use after setup-verify passes, or when asked to "run the smoke tests", "check the dev server", "run e2e against the scaffold", or "run the heavy checks". Do NOT use in place of setup-verify, or on a project without package.json.
----
-
-# Smoke scaffold
-
-Runs the local checks a scaffold's leaf scripts cannot cover: whether the dev and preview servers actually start, whether the end-to-end suite passes against a real server, and whether the screenshot harness produces output. Standalone from `setup-verify`. Neither skill requires the other to have run first.
-
-## Guards
-
-- If `package.json` does not exist at the project root, stop: `❌ No package.json found. Cannot smoke test.`
-- If `node_modules/` does not exist, run `bun install` first, then proceed.
-
-## Step 1: read scripts
-
-Read `package.json` from the project root and extract the `scripts` block. Do not hardcode script names.
-
-## Step 2: run the chain
-
-Run the scripts below in order. Stop on the first failure and surface the error.
-
-| Order | Script       | Skip if | How judged              |
-| ----- | ------------ | ------- | ----------------------- |
-| 1     | `dev`        | absent  | server smoke, see below |
-| 2     | `preview`    | absent  | server smoke, see below |
-| 3     | `test:e2e`   | absent  | leaf script: exit code  |
-| 4     | `screenshot` | absent  | leaf script: exit code  |
-
-Skip any script not present in `package.json`. Do not invent a fallback command. Run each leaf script as `bun run <script>` from the project root.
-
-### Server smoke
-
-`dev` and `preview` run until stopped, so there is no exit code to read. Start the script backgrounded, wait 5 seconds, then check two things: the process is still running, and its captured output carries no string matching `error`, `Error`, or `fatal`. Kill the process either way once judged. Report a failure on either check failing.
-
-This is weaker than a real readiness probe. No manifest key exposes a generic port to poll across stacks, so port-probing is out of reach here.
-
-## Step 3: report
-
-For each script run, report one of:
-
-- `✅ <script>`
-- `❌ <script>` followed by the failing output (last 40 lines) or, for a server script, the reason judged (process died, or a fatal string in its output)
-
-End with a summary line:
-
-- On pass: `✅ Scaffold smoke-tested (<n> scripts passed).`
-- On fail: `❌ Scaffold failed at <script>. Fix the error and re-run setup-smoke.`
-
-## Out of scope
-
-- `lint:fix`, `typecheck`, `check`, `test:run`, `build`. Those are `canon:setup-verify`'s leaf-script chain.
-- Generating the configs these scripts drive, which the tooling stack reference owns.

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

@@ -1,39 +0,0 @@
----
-name: setup-verify
-description: Why a fresh scaffold is checked with declared leaf scripts in a fixed order, and what the excluded stages would cost
----
-
-# Setup verify requirement
-
-## Gap
-
-Without this skill, a freshly scaffolded project is handed over on the strength of the configs looking right, and the first typo surfaces when the user runs something. A scaffold is generated from a reference, so the errors it carries are wiring mistakes and missing dependencies, both of which any script run would have caught.
-
-The naive check fails two ways. A session that assumes script names runs `test` against a stack that exposes `test:run`, or invents a fallback command when a script is absent, and either result reports on something the project never declared. A session that runs a composite script gets one failure covering several stages, so the output names the wrapper rather than the break.
-
-The stages left out are the ones that lie, and each now has an owner in `canon:setup-smoke` rather than nowhere at all. A dev server or a preview reads as failed when it starts slowly, a browser test needs an install and a running server before it can even fail correctly, and a CI workflow cannot be judged locally at all. Including any of them turns a scaffold check into a flaky one, and a flaky check gets ignored.
-
-## Must
-
-- Read the scripts the project declares and run only those
-- Run leaf scripts in a fixed order, so a failure points at the exact stage that broke
-- Stop at the first failure and surface its output rather than continuing to collect more
-- Report per script and close with one summary line naming the failing stage when there is one
-
-## Must not
-
-- Invent a fallback command for an absent script. Skip it.
-- Run a composite script, which hides which stage broke
-- Run a dev server, a preview, or a browser test
-
-## Guards
-
-- No `package.json` at the project root stops, since there are no declared scripts to read
-- A missing dependency folder installs first rather than letting every script fail on the same cause
-
-## Out of scope
-
-- Dev and preview smoke tests, which `project-commands` starts on request and `canon:setup-smoke` checks automatically
-- Browser end-to-end tests, which need a browser install and a running server, covered by `canon:setup-smoke`
-- CI workflow validation, which runs on the pull request rather than locally. `canon:setup-smoke` runs the same stages locally as the closest proxy
-- Generating the configs it checks, which the tooling stack reference owns

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

@@ -1,51 +0,0 @@
----
-name: setup-verify
-description: Verifies a freshly scaffolded project by running its `package.json` scripts in order and reporting pass/fail per script. Use after the agent has followed a tooling stack reference and generated configs, or when asked to "verify the scaffold", "check the setup", "run verify", or "make sure everything works". Do NOT use on a project without `package.json`, or to run E2E or dev servers.
----
-
-# Verify scaffold
-
-Runs the local verification chain against a freshly scaffolded project. Catches config typos, missing deps, and wiring mistakes before the user ever sees them.
-
-## Guards
-
-- If `package.json` does not exist at the project root, stop: `❌ No package.json found. Cannot verify.`
-- If `node_modules/` does not exist, run `bun install` first, then proceed.
-
-## Step 1: read scripts
-
-Read `package.json` from the project root and extract the `scripts` block. Do not hardcode script names. Different stacks expose different scripts.
-
-## Step 2: run the chain
-
-Run the scripts below in order. Stop on the first failure and surface the error. Each script is a leaf command so failures point at the exact break.
-
-| Order | Script      | Skip if                     |
-| ----- | ----------- | --------------------------- |
-| 1     | `lint:fix`  | absent                      |
-| 2     | `typecheck` | absent                      |
-| 3     | `check`     | absent                      |
-| 4     | `test:run`  | absent, fall back to `test` |
-| 5     | `build`     | absent                      |
-
-Skip any script not present in `package.json`. Do not invent a fallback command. Do not run composite scripts like `check:full`. Do not run `dev`, `preview`, `test:e2e`, `test:ui`, `screenshot`.
-
-Run each as `bun run <script>` from the project root.
-
-## Step 3: report
-
-For each script run, report one of:
-
-- `✅ <script>`
-- `❌ <script>` followed by the failing output (last 40 lines)
-
-End with a summary line:
-
-- On pass: `✅ Scaffold verified (<n> scripts passed).`
-- On fail: `❌ Scaffold failed at <script>. Fix the error and re-run setup-verify.`
-
-## Out of scope
-
-- Dev server and preview server smoke tests. Too flaky for a scaffold check, where a slow start reads as a failure. Use `project-commands` to start one on request, or `canon:setup-smoke` to check both automatically.
-- Playwright E2E tests. Require browser install and a running server. Use `canon:setup-smoke`.
-- CI workflow validation. Runs in GitHub Actions on PR, not locally. `canon:setup-smoke` runs the same end-to-end and screenshot stages locally, as the closest proxy.