vigiles 3.0.0 → 4.0.0

package/dist/setup-plan.d.ts

@@ -10,9 +10,9 @@
  */
 /** What `vigiles init` will set up. */
 export interface SetupPlan {
-    /** Pillar 1 — verify instruction files (specs, types, compile, audit, hooks). */
-    verify: boolean;
-    /** Pillar 2 — test the harness (scaffold a starter harness test + CI job). */
+    /** Lint pillar — verify instruction-file references (specs, types, compile, lint/audit, hooks). */
+    lint: boolean;
+    /** Test pillar — test the harness (scaffold a starter harness test + CI job). */
     test: boolean;
     /** Wire CI (the `zernie/vigiles@v1` Action; creates a workflow if none). */
     gha: boolean;
@@ -26,11 +26,17 @@ export interface ParsedSetupArgs {
     target?: string;
     strict: boolean;
     yes: boolean;
-    pillars?: "verify" | "test" | "both";
+    /** Lint pillar — `--lint` → true, `--no-lint` → false, absent → undefined. */
+    lint?: boolean;
+    /** Test pillar — `--test` → true, `--no-test` → false, absent → undefined. */
+    test?: boolean;
+    /** `--harness=claude,codex` override (empty = auto-detect). */
+    harness?: string;
     gha?: boolean;
     plugin?: boolean;
 }
-/** Parse `init` args into the choices the user pinned. */
+/** Parse `init` args into the choices the user pinned. The two pillars are
+ * selected with `--lint` / `--test`. */
 export declare function parseSetupArgs(args: readonly string[]): ParsedSetupArgs;
 /** The non-interactive defaults: both pillars, CI, and the plugin. */
 export declare function defaultPlan(strict?: boolean): SetupPlan;
@@ -41,11 +47,45 @@ export declare function defaultPlan(strict?: boolean): SetupPlan;
  */
 export declare function shouldPrompt(parsed: ParsedSetupArgs, isTTY: boolean): boolean;
 /** Interactive answers (only the fields the prompts cover). */
-export type SetupAnswers = Partial<Pick<SetupPlan, "verify" | "test" | "gha" | "plugin">>;
+export type SetupAnswers = Partial<Pick<SetupPlan, "lint" | "test" | "gha" | "plugin">>;
+/**
+ * How to install vigiles's skills/hooks for ONE harness — the deterministic
+ * decision behind the IO in cli.ts, so a CI test asserts WHICH commands an
+ * install runs without a network call or a real `claude`/`codex` binary.
+ *
+ * The method is genuinely harness-specific: Claude Code has a GLOBAL plugin
+ * marketplace (installs to ~/.claude/plugins/, nothing in the repo); Codex has
+ * no global store — its config is repo-committed (`.codex/`, AGENTS.md), so its
+ * instructions are read directly and skills are an opt-in, repo-local concern.
+ */
+export interface InstallPlan {
+    harness: string;
+    /** Shell commands to auto-run (empty = nothing runnable here). */
+    commands: string[];
+    /** One-line success message printed after the commands run. */
+    successMessage: string;
+    /** The equivalent commands a user runs by hand (printed on failure / no-CLI). */
+    manualSteps: string[];
+    /** Always-printed informational lines (where it installs, caveats). */
+    notes: string[];
+    /** Whether this method writes files into the consumer's repo (vendoring). */
+    vendors: boolean;
+}
+/** Per-harness install plan. `hasClaude` gates the auto-run `claude plugin` CLI
+ * (else the same two steps are printed as `/plugin` slash commands).
+ *
+ * Both methods install GLOBALLY, never into the repo: Claude through its plugin
+ * marketplace (~/.claude/plugins/), Codex through the cross-agent `skills` CLI
+ * with `-g -y` (the global store ~/.agents/skills/, which Codex reads). Codex
+ * gets the skills but NOT hooks — Codex hook wiring (.codex/config.toml [hooks])
+ * is not automated yet. */
+export declare function planPluginInstall(harnesses: readonly string[], opts: {
+    hasClaude: boolean;
+}): InstallPlan[];
 /**
  * Resolve the final plan: defaults, then flags, then interactive answers (each
  * layer overrides the previous only where it has an opinion). `--target` pins a
- * bare Pillar-1 spec (no harness scaffold).
+ * bare lint-pillar spec (no harness scaffold).
  */
 export declare function resolvePlan(parsed: ParsedSetupArgs, answers?: SetupAnswers): SetupPlan;
 //# sourceMappingURL=setup-plan.d.ts.map

package/dist/setup-plan.js

@@ -13,28 +13,36 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.parseSetupArgs = parseSetupArgs;
 exports.defaultPlan = defaultPlan;
 exports.shouldPrompt = shouldPrompt;
+exports.planPluginInstall = planPluginInstall;
 exports.resolvePlan = resolvePlan;
 function flagValue(args, prefix) {
     return args.find((a) => a.startsWith(prefix))?.slice(prefix.length);
 }
-/** Parse `init` args into the choices the user pinned. */
+/** `--name` → true, `--no-name` → false, neither present → undefined. */
+function boolFlag(args, name) {
+    if (args.includes(`--${name}`))
+        return true;
+    if (args.includes(`--no-${name}`))
+        return false;
+    return undefined;
+}
+/** Parse `init` args into the choices the user pinned. The two pillars are
+ * selected with `--lint` / `--test`. */
 function parseSetupArgs(args) {
-    const pillarsRaw = flagValue(args, "--pillars=");
-    const pillars = pillarsRaw === "verify" || pillarsRaw === "test" || pillarsRaw === "both"
-        ? pillarsRaw
-        : undefined;
     return {
         target: flagValue(args, "--target="),
         strict: args.includes("--strict"),
         yes: args.includes("--yes") || args.includes("-y"),
-        pillars,
+        lint: boolFlag(args, "lint"),
+        test: boolFlag(args, "test"),
+        harness: flagValue(args, "--harness="),
         gha: args.includes("--no-gha") ? false : undefined,
         plugin: args.includes("--no-plugin") ? false : undefined,
     };
 }
 /** The non-interactive defaults: both pillars, CI, and the plugin. */
 function defaultPlan(strict = false) {
-    return { verify: true, test: true, gha: true, plugin: true, strict };
+    return { lint: true, test: true, gha: true, plugin: true, strict };
 }
 /**
  * Whether to drop into interactive prompts: a human at a TTY who passed neither
@@ -44,42 +52,109 @@ function defaultPlan(strict = false) {
 function shouldPrompt(parsed, isTTY) {
     if (!isTTY || parsed.yes || parsed.target)
         return false;
-    const allPinned = parsed.pillars !== undefined &&
-        parsed.gha !== undefined &&
-        parsed.plugin !== undefined;
+    const pillarsPinned = parsed.lint !== undefined || parsed.test !== undefined;
+    const allPinned = pillarsPinned && parsed.gha !== undefined && parsed.plugin !== undefined;
     return !allPinned;
 }
+/**
+ * Apply the pillar flags. A positive flag (`--lint` and/or `--test`) is an
+ * explicit SELECTION — enable exactly the named pillars. Otherwise default to
+ * both and let a `--no-*` flag drop one.
+ */
+function applyPillarFlags(plan, parsed) {
+    if (parsed.lint === true || parsed.test === true) {
+        plan.lint = parsed.lint === true;
+        plan.test = parsed.test === true;
+        return;
+    }
+    if (parsed.lint === false)
+        plan.lint = false;
+    if (parsed.test === false)
+        plan.test = false;
+}
+function applyAnswers(plan, answers) {
+    if (answers.lint !== undefined)
+        plan.lint = answers.lint;
+    if (answers.test !== undefined)
+        plan.test = answers.test;
+    if (answers.gha !== undefined)
+        plan.gha = answers.gha;
+    if (answers.plugin !== undefined)
+        plan.plugin = answers.plugin;
+}
+/** Per-harness install plan. `hasClaude` gates the auto-run `claude plugin` CLI
+ * (else the same two steps are printed as `/plugin` slash commands).
+ *
+ * Both methods install GLOBALLY, never into the repo: Claude through its plugin
+ * marketplace (~/.claude/plugins/), Codex through the cross-agent `skills` CLI
+ * with `-g -y` (the global store ~/.agents/skills/, which Codex reads). Codex
+ * gets the skills but NOT hooks — Codex hook wiring (.codex/config.toml [hooks])
+ * is not automated yet. */
+function planPluginInstall(harnesses, opts) {
+    return harnesses.map((harness) => {
+        if (harness === "claude") {
+            return {
+                harness,
+                commands: opts.hasClaude
+                    ? [
+                        "claude plugin marketplace add zernie/vigiles",
+                        "claude plugin install vigiles@vigiles",
+                    ]
+                    : [],
+                successMessage: "✓ Installed the vigiles plugin (hooks + skills) into ~/.claude/plugins/",
+                manualSteps: [
+                    "/plugin marketplace add zernie/vigiles",
+                    "/plugin install vigiles@vigiles",
+                ],
+                notes: [
+                    "Installs globally to ~/.claude/plugins/ — nothing is added to your repo.",
+                ],
+                vendors: false,
+            };
+        }
+        if (harness === "codex") {
+            // The cross-agent `skills` CLI with `-g -y` installs to the global store
+            // ~/.agents/skills/ (NOT the repo, and NOT ~/.codex/ — verified against
+            // the real CLI). Skills only; Codex hooks (.codex/config.toml [hooks])
+            // are not wired automatically.
+            return {
+                harness,
+                commands: ["npx --yes skills add zernie/vigiles -a codex -g -y"],
+                successMessage: "✓ Installed the vigiles skills into ~/.agents/skills/ (global, not vendored)",
+                manualSteps: ["npx skills add zernie/vigiles -a codex -g -y"],
+                notes: [
+                    "Codex reads AGENTS.md directly; the skills install globally to ~/.agents/skills/ (not the repo).",
+                    "Codex hooks (.codex/config.toml [hooks]) are not auto-wired yet — add them manually for compile-on-edit.",
+                ],
+                vendors: false,
+            };
+        }
+        return {
+            harness,
+            commands: [],
+            successMessage: "",
+            manualSteps: [],
+            notes: [`No plugin install path for harness '${harness}'.`],
+            vendors: false,
+        };
+    });
+}
 /**
  * Resolve the final plan: defaults, then flags, then interactive answers (each
  * layer overrides the previous only where it has an opinion). `--target` pins a
- * bare Pillar-1 spec (no harness scaffold).
+ * bare lint-pillar spec (no harness scaffold).
  */
 function resolvePlan(parsed, answers) {
     const plan = defaultPlan(parsed.strict);
-    if (parsed.pillars === "verify") {
-        plan.verify = true;
-        plan.test = false;
-    }
-    else if (parsed.pillars === "test") {
-        plan.verify = false;
-        plan.test = true;
-    }
+    applyPillarFlags(plan, parsed);
     if (parsed.gha === false)
         plan.gha = false;
     if (parsed.plugin === false)
         plan.plugin = false;
     if (parsed.target)
         plan.test = false;
-    if (answers) {
-        if (answers.verify !== undefined)
-            plan.verify = answers.verify;
-        if (answers.test !== undefined)
-            plan.test = answers.test;
-        if (answers.gha !== undefined)
-            plan.gha = answers.gha;
-        if (answers.plugin !== undefined)
-            plan.plugin = answers.plugin;
-    }
+    if (answers)
+        applyAnswers(plan, answers);
     return plan;
 }
 //# sourceMappingURL=setup-plan.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vigiles",
-  "version": "3.0.0",
+  "version": "4.0.0",
   "description": "Compile .spec.ts files to instruction files (CLAUDE.md, AGENTS.md) with linter cross-referencing",
   "bin": {
     "vigiles": "dist/cli.js"

package/skills/audit-feedback-loop/SKILL.md

@@ -1,76 +0,0 @@
----
-name: audit-feedback-loop
-description: Scan the current repo and score its feedback loop maturity for AI-assisted development
-disable-model-invocation: true
----
-
-Scan the current repository and score its feedback loop maturity for AI-assisted development.
-
-## Instructions
-
-Analyze this repository and score its **feedback loop maturity** using the levels below. Check for each signal, then output a summary report.
-
-### Maturity Levels
-
-**Level 0 — Vibes**
-No CI config, no linter rules, no CLAUDE.md. The AI agent is flying blind.
-
-**Level 1 — Guardrails**
-Has CI + standard linters, but no custom rules. The agent gets basic feedback but can't learn project-specific conventions.
-
-**Level 2 — Architecture as Code**
-Has custom lint rules, CLAUDE.md rules have enforcement annotations. The agent gets rich, project-specific feedback.
-
-**Level 3 — The Organism**
-Has CI + custom rules + screenshot/visual tests + observability + scheduled agent tasks. The entire development loop is instrumented.
-
-### Signals to Check
-
-Scan the repository for the following and note which exist:
-
-1. **CI Configuration**: Look for `.github/workflows/`, `.circleci/`, `Jenkinsfile`, `.gitlab-ci.yml`, `bitbucket-pipelines.yml`, `.travis.yml`, etc.
-2. **Linter Config** (language-aware):
-   - **JS/TS**: `eslint.config.*`, `.eslintrc*`, `biome.json`, `.prettierrc*`, `deno.json`
-   - **Python**: `pyproject.toml` (look for `[tool.ruff]`, `[tool.pylint]`, `[tool.flake8]`), `setup.cfg`, `.flake8`, `ruff.toml`
-   - **Rust**: `clippy.toml`, `.clippy.toml`, `rustfmt.toml`
-   - **Go**: `.golangci.yml`, `.golangci.yaml`
-   - **Ruby**: `.rubocop.yml`
-   - **Java/Kotlin**: `checkstyle.xml`, `pmd.xml`, `detekt.yml`
-3. **Custom Lint Rules**: Look for custom plugins, rule directories, or inline rule definitions in linter configs
-   - JS/TS: `eslint-plugin-*`, `eslint-rules/` directories
-   - Python: custom Ruff/Pylint plugins, AST-based checks
-   - Rust: custom Clippy lints
-   - Go: custom analyzers
-4. **CLAUDE.md**: Check if `CLAUDE.md` exists at the repo root
-5. **CLAUDE.md Enforcement**: Check if using vigiles v2 specs (`CLAUDE.md.spec.ts` exists) or v1 annotations (`**Enforced by:**` in CLAUDE.md). v2 specs = higher maturity.
-6. **Type-Safe Specs**: Check for `CLAUDE.md.spec.ts` or `*.spec.ts` files — indicates typed spec compilation via vigiles v2
-7. **Generated Types**: Check for `.vigiles/generated.d.ts` — indicates linter rules are type-checked at authoring time
-8. **Screenshot/Visual Tests**: Look for Playwright (`playwright.config.*`), Cypress (`cypress.config.*`), Chromatic, Percy, BackstopJS configs
-9. **Observability**: Search for imports/usage of `@sentry/`, `dd-trace`, `@datadog/`, `newrelic`, `@opentelemetry/`, `sentry_sdk`, `structlog`, `tracing` (Rust), `opentelemetry` in source files
-10. **Scheduled Agent Tasks**: Look for cron patterns in CI configs, `.github/workflows/` with `schedule:` triggers, or references to scheduled Claude Code tasks
-
-### Output Format
-
-```
-## Feedback Loop Audit
-
-**Repository:** <repo name>
-**Primary language(s):** <detected languages>
-**Score: Level X — <Name>**
-
-### Signals Found
-- [x] CI Configuration: <details>
-- [ ] Custom Lint Rules: not found
-- [x] CLAUDE.md: found, 5 enforced / 2 guidance / 1 missing
-...
-
-### Recommendations
-1. <Most impactful next step to level up>
-2. <Second recommendation>
-3. <Third recommendation>
-
-### How to Level Up
-<Specific, actionable advice for reaching the next maturity level>
-```
-
-Be specific about file paths and what you found. Give actionable recommendations tailored to the project's language and toolchain.

package/skills/enforce-rules-format/SKILL.md

@@ -1,71 +0,0 @@
----
-name: enforce-rules-format
-description: Validate that all rules have proper enforcement classification (enforce/check/guidance)
-disable-model-invocation: true
----
-
-Validate that every rule in the project's instruction files has a proper enforcement classification, and fix any that are missing.
-
-## Instructions
-
-### Step 1: Detect Format
-
-Check which format the project uses:
-
-**v2 (spec-based):** Look for `CLAUDE.md.spec.ts` or any `*.spec.ts` files. If found, this is a v2 project — rules must use `enforce()`, `check()`, or `guidance()`.
-
-**v1 (hand-written):** Look for `CLAUDE.md`, `AGENTS.md`, `.cursorrules`. If found without a spec file, this is a v1 project — rules need `**Enforced by:**` or `**Guidance only**` annotations.
-
-### Step 2: Validate
-
-**For v2 specs:**
-
-The TypeScript type system already prevents unannotated rules — you can't create a rule without calling `enforce()`, `check()`, or `guidance()`. So focus on:
-
-1. Do `enforce()` rules reference real linter rules? Run `npx vigiles compile` to check.
-2. Are there guidance rules that COULD be `enforce()`? Check linter configs for matching rules.
-3. Are there `check()` assertions that could be delegated to a linter? Suggest `enforce()` instead.
-
-```bash
-npx vigiles compile
-npx vigiles discover
-```
-
-**For v1 hand-written files:**
-
-Scan for `###` headings. Each must have one of:
-
-- `**Enforced by:** \`linter/rule-name\``
-- `**Guidance only** — reason`
-- `<!-- vigiles-disable -->`
-
-Report missing annotations with a summary table.
-
-### Step 3: Fix Issues
-
-For each issue found:
-
-1. Check the project's linter configuration for matching rules
-2. Suggest `enforce("linter/rule")` (v2) or `**Enforced by:** \`linter/rule\`` (v1)
-3. If no linter rule exists, suggest `guidance()` (v2) or `**Guidance only**` (v1)
-4. **Ask the user** before making changes
-
-### Step 4: Suggest Migration
-
-If the project uses v1 format, suggest migrating to v2 specs for type safety:
-
-> Your rules could benefit from type-safe specs. Run the `migrate-to-spec` skill to convert your CLAUDE.md to a typed .spec.ts file.
-
-### Step 5: Verify
-
-Run the appropriate command:
-
-```bash
-# v2
-npx vigiles compile && npx vigiles check
-
-# validate
-npx vigiles check
-```
-
-Report the validation result.

package/skills/generate-logo/SKILL.md

@@ -1,103 +0,0 @@
----
-name: generate-logo
-description: Generate or iterate on the vigiles logo using ImageRouter API
----
-
-# Generate Logo
-
-Generate logo variations for vigiles using the ImageRouter API (imagerouter.io).
-
-## Setup
-
-Get an API key from https://imagerouter.io/api-keys. Pass it as an argument or set `IMAGEROUTER_API_KEY` env var. Do NOT commit the key.
-
-## API
-
-```
-Endpoint: https://api.imagerouter.io/v1/openai/images/generations
-Auth: Bearer token in Authorization header
-Method: POST, Content-Type: application/json
-```
-
-### Request body
-
-```json
-{
-  "prompt": "...",
-  "model": "google/nano-banana-2",
-  "quality": "high",
-  "size": "1024x1024",
-  "response_format": "url",
-  "output_format": "png"
-}
-```
-
-### Available models (image generation)
-
-List models: `GET https://api.imagerouter.io/v1/models`
-
-Known good models:
-
-- `google/nano-banana-2` — best quality, $0.07/image
-- `google/nano-banana-2:free` — free tier
-- `openai/gpt-image-1` — OpenAI's image model
-- `black-forest-labs/FLUX-1.1-pro` — FLUX pro
-
-### Response
-
-```json
-{
-  "created": 1775430873,
-  "data": [{ "url": "https://storage.imagerouter.io/..." }],
-  "cost": 0.069,
-  "latency": 27627
-}
-```
-
-Download the image from the URL in `data[0].url`.
-
-## Current logo
-
-The current logo (`logo.png`) is v6: overlapping translucent flame petals on dark background, amber-orange palette. Generated with `google/nano-banana-2`.
-
-### Prompt that produced it
-
-```
-A premium, refined logo icon for a developer tool called vigiles that compiles
-typed TypeScript specs to AI instruction files. Inspired by OpenAI geometric aesthetic and Apple
-minimalism. A single abstract geometric shape: an upward-pointing flame composed
-of 3 overlapping translucent rounded shapes, creating depth through overlap —
-similar to how the OpenAI logo uses overlapping curves. Warm amber to deep orange
-color palette. Black background. No text. No letters. Pure abstract mark. Clean
-enough to be an app icon. Luxurious, premium, modern tech company feel.
-```
-
-## Design principles
-
-- **Flame/torch motif** — vigiles were Rome's night watchmen who carried torches
-- **Amber/orange palette** — matches GitHub Action branding color
-- **No text in the icon** — must work at 16px favicon size
-- **Dark background variant** for README, light/transparent variant for npm
-
-## Example curl
-
-```bash
-curl 'https://api.imagerouter.io/v1/openai/images/generations' \
-  -H "Authorization: Bearer $IMAGEROUTER_API_KEY" \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "prompt": "YOUR PROMPT HERE",
-    "model": "google/nano-banana-2",
-    "quality": "high",
-    "size": "1024x1024",
-    "response_format": "url",
-    "output_format": "png"
-  }'
-```
-
-## Workflow
-
-1. Generate variations with different prompts
-2. Save as `logo-v*.png` (gitignored)
-3. Pick the best, copy to `logo.png`
-4. Commit `logo.png` only

package/skills/pr-to-lint-rule/SKILL.md

@@ -1,97 +0,0 @@
----
-name: pr-to-lint-rule
-description: Convert a recurring PR review comment into an automated lint rule with tests and spec entry
-disable-model-invocation: true
-argument-hint: <description of recurring PR feedback>
----
-
-Convert a recurring PR review comment into an automated lint rule.
-
-## Arguments
-
-$ARGUMENTS — A natural language description of the pattern to enforce. Examples:
-
-- "we keep telling people not to import directly from antd, use our design system barrel file instead"
-- "people forget to use our custom logger instead of console.log"
-- "don't use unwrap() in production code, use expect() or proper error handling"
-- "API route handlers must use the withAuth wrapper"
-
-## Instructions
-
-You are generating an automated lint rule from a recurring code review pattern. Follow these steps:
-
-### Step 1: Detect the Project Language and Toolchain
-
-Look at the repository to determine:
-
-- **Primary language** (JS/TS, Python, Rust, Go, Ruby, etc.)
-- **Linter in use** (ESLint, Ruff, Clippy, golangci-lint, RuboCop, etc.)
-- **Testing framework** (Vitest, Jest, pytest, cargo test, etc.)
-- **Existing custom rules** (to match conventions)
-
-**If the language or linter cannot be confidently detected** (e.g. polyglot repo, no linter config, or multiple candidates), **ask the user** which language and linter to target before generating anything.
-
-### Step 2: Generate the Lint Rule
-
-Based on the detected (or user-specified) language, generate the appropriate rule type:
-
-**Read the linter-specific reference doc before generating.** Each doc covers existing plugins to check first, rule/lint anatomy, AST patterns, auto-fix safety, testing, and edge cases.
-
-| Language              | Linter    | Reference doc                 |
-| --------------------- | --------- | ----------------------------- |
-| JavaScript/TypeScript | ESLint    | `../linter-docs/eslint.md`    |
-| Python                | Ruff      | `../linter-docs/ruff.md`      |
-| Python                | Pylint    | `../linter-docs/pylint.md`    |
-| Ruby                  | RuboCop   | `../linter-docs/rubocop.md`   |
-| Rust                  | Clippy    | `../linter-docs/clippy.md`    |
-| CSS                   | Stylelint | `../linter-docs/stylelint.md` |
-
-For all linters, follow this order:
-
-1. **Check existing plugins/rules first** — see the plugin table in the linter doc
-2. **Try built-in config options** — most linters have `no-restricted-*` or equivalent rules that handle one-off patterns without custom code
-3. **Only write a custom rule** when you need AST analysis, auto-fix, or configurable options beyond what exists
-
-If a custom rule is needed, the reference doc provides: rule anatomy, AST node cheat sheet, auto-fix/suggest patterns, testing examples, and registration instructions.
-
-#### For Go (go/analysis)
-
-No linter doc yet. Generate an analyzer using `golang.org/x/tools/go/analysis` with `analysistest` tests.
-
-#### For other languages
-
-Generate the most idiomatic linting approach with test cases and integration instructions.
-
-### Step 3: Add to Instruction File
-
-**If the project uses v2 specs** (has `CLAUDE.md.spec.ts`):
-
-Add an `enforce()` rule to the spec file:
-
-```typescript
-"<rule-id>": enforce("<linter>/<rule-name>", "<why>"),
-```
-
-Then run `npx vigiles compile` to regenerate CLAUDE.md.
-
-**If the project uses v1** (hand-written CLAUDE.md):
-
-Append an annotation block:
-
-```markdown
-### <Rule title — imperative, concise>
-
-**Enforced by:** `<linter>/<rule-name>`
-**Why:** <One sentence explaining the architectural reason>
-```
-
-### Step 4: Present the Output
-
-Show the user:
-
-1. All generated files with full contents
-2. Step-by-step integration instructions
-3. The spec rule or CLAUDE.md block to add
-4. How to verify it works (run the linter, expect it to catch a violation)
-
-Ask the user if they want you to write the files and update the spec/CLAUDE.md.