azclaude-copilot 0.4.35 → 0.4.37

package/.claude-plugin/marketplace.json

@@ -8,8 +8,8 @@
   "plugins": [
     {
       "name": "azclaude",
-      "description": "AZCLAUDE is a complete AI coding environment for Claude Code. It installs 36 commands, 9 auto-invoked skills, 15 specialized agents, 4 hooks, and a persistent memory system — in one command.\n\nKey features:\n• Memory across sessions — goals.md + checkpoints injected automatically before every session\n• Self-improving loop — /reflect fixes stale CLAUDE.md rules, /reflexes learns from tool-use patterns, /evolve creates agents from git evidence\n• Autonomous copilot mode — /copilot runs a three-tier team (orchestrator → problem-architect → milestone-builder) across sessions until the product ships\n• Spec-driven workflow — /constitute writes project rules, /spec writes structured ACs, /analyze detects plan drift and ghost milestones, /blueprint traces every milestone to a spec\n• Security layer — 111-rule environment scan (/sentinel), pre-write secret blocking, pre-ship credential audit\n• Progressive levels 0–10 — start with CLAUDE.md, grow into multi-agent pipelines and self-evolving environments\n• Zero dependencies — no npm packages, no external APIs, no vector databases. Plain markdown files and Claude Code's native architecture.\n• Smart install — npx azclaude-copilot@latest auto-detects first install vs upgrade vs verify. Context-aware onboarding shows the right next command for your project state.\n\nExample use cases:\n• /setup — scan an existing project, detect stack + domain + scale, fill CLAUDE.md, generate project-specific skills and agents automatically\n• /copilot \"Build a compliance SaaS with trilingual support\" — walk away, come back to working code across multiple sessions\n• /sentinel — run a scored security audit (0–100, grade A–F) across hooks, permissions, MCP servers, agent configs, and secrets\n• /evolve — detect gaps in the environment, generate new skills and agents from git co-change evidence, report score delta (e.g. 42/100 → 68/100)\n• /constitute — write your project's constitution (non-negotiables, architectural commitments, definition of done) — gates all future AI actions\n• /analyze — cross-artifact consistency check: ghost milestones, spec vs. code drift, unplanned commits\n• /reflect — find stale, missing, or contradicting rules in CLAUDE.md and propose exact fixes\n• /debate \"REST vs GraphQL for this project\" — adversarial evidence-based decision with order-independent scoring, logged to decisions.md",
-      "version": "0.4.35",
+      "description": "AZCLAUDE is a complete AI coding environment for Claude Code. It installs 37 commands, 9 auto-invoked skills, 15 specialized agents, 4 hooks, and a persistent memory system — in one command.\n\nKey features:\n• Memory across sessions — goals.md + checkpoints injected automatically before every session\n• Self-improving loop — /reflect fixes stale CLAUDE.md rules, /reflexes learns from tool-use patterns, /evolve creates agents from git evidence\n• Autonomous copilot mode — /copilot runs a three-tier team (orchestrator → problem-architect → milestone-builder) across sessions until the product ships\n• Spec-driven workflow — /constitute writes project rules, /spec writes structured ACs, /analyze detects plan drift and ghost milestones, /blueprint traces every milestone to a spec\n• Security layer — 111-rule environment scan (/sentinel), pre-write secret blocking, pre-ship credential audit\n• Progressive levels 0–10 — start with CLAUDE.md, grow into multi-agent pipelines and self-evolving environments\n• Zero dependencies — no npm packages, no external APIs, no vector databases. Plain markdown files and Claude Code's native architecture.\n• Smart install — npx azclaude-copilot@latest auto-detects first install vs upgrade vs verify. Context-aware onboarding shows the right next command for your project state.\n\nExample use cases:\n• /setup — scan an existing project, detect stack + domain + scale, fill CLAUDE.md, generate project-specific skills and agents automatically\n• /copilot \"Build a compliance SaaS with trilingual support\" — walk away, come back to working code across multiple sessions\n• /sentinel — run a scored security audit (0–100, grade A–F) across hooks, permissions, MCP servers, agent configs, and secrets\n• /evolve — detect gaps in the environment, generate new skills and agents from git co-change evidence, report score delta (e.g. 42/100 → 68/100)\n• /constitute — write your project's constitution (non-negotiables, architectural commitments, definition of done) — gates all future AI actions\n• /analyze — cross-artifact consistency check: ghost milestones, spec vs. code drift, unplanned commits\n• /reflect — find stale, missing, or contradicting rules in CLAUDE.md and propose exact fixes\n• /debate \"REST vs GraphQL for this project\" — adversarial evidence-based decision with order-independent scoring, logged to decisions.md",
+      "version": "0.4.37",
       "source": {
         "source": "github",
         "repo": "haytamAroui/AZ-CLAUDE-COPILOT",

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "azclaude",
-  "version": "0.4.35",
-  "description": "AZCLAUDE is a complete AI coding environment for Claude Code. It installs 36 commands, 9 auto-invoked skills, 15 specialized agents, 4 hooks, and a persistent memory system — in one command.\n\nKey features:\n• Memory across sessions — goals.md + checkpoints injected automatically before every session\n• Self-improving loop — /reflect fixes stale CLAUDE.md rules, /reflexes learns from tool-use patterns, /evolve creates agents from git evidence\n• Autonomous copilot mode — /copilot runs a three-tier team (orchestrator → problem-architect → milestone-builder) across sessions until the product ships\n• Spec-driven workflow — /constitute writes project rules, /spec writes structured ACs, /analyze detects plan drift and ghost milestones, /blueprint traces every milestone to a spec\n• Security layer — 111-rule environment scan (/sentinel), pre-write secret blocking, pre-ship credential audit\n• Progressive levels 0–10 — start with CLAUDE.md, grow into multi-agent pipelines and self-evolving environments\n• Zero dependencies — no npm packages, no external APIs, no vector databases. Plain markdown files and Claude Code's native architecture.\n• Smart install — npx azclaude-copilot@latest auto-detects first install vs upgrade vs verify. Context-aware onboarding shows the right next command for your project state.\n\nExample use cases:\n• /setup — scan an existing project, detect stack + domain + scale, fill CLAUDE.md, generate project-specific skills and agents automatically\n• /copilot \"Build a compliance SaaS with trilingual support\" — walk away, come back to working code across multiple sessions\n• /sentinel — run a scored security audit (0–100, grade A–F) across hooks, permissions, MCP servers, agent configs, and secrets\n• /evolve — detect gaps in the environment, generate new skills and agents from git co-change evidence, report score delta (e.g. 42/100 → 68/100)\n• /constitute — write your project's constitution (non-negotiables, architectural commitments, definition of done) — gates all future AI actions\n• /analyze — cross-artifact consistency check: ghost milestones, spec vs. code drift, unplanned commits\n• /reflect — find stale, missing, or contradicting rules in CLAUDE.md and propose exact fixes\n• /debate \"REST vs GraphQL for this project\" — adversarial evidence-based decision with order-independent scoring, logged to decisions.md",
+  "version": "0.4.37",
+  "description": "AZCLAUDE is a complete AI coding environment for Claude Code. It installs 37 commands, 9 auto-invoked skills, 15 specialized agents, 4 hooks, and a persistent memory system — in one command.\n\nKey features:\n• Memory across sessions — goals.md + checkpoints injected automatically before every session\n• Self-improving loop — /reflect fixes stale CLAUDE.md rules, /reflexes learns from tool-use patterns, /evolve creates agents from git evidence\n• Autonomous copilot mode — /copilot runs a three-tier team (orchestrator → problem-architect → milestone-builder) across sessions until the product ships\n• Spec-driven workflow — /constitute writes project rules, /spec writes structured ACs, /analyze detects plan drift and ghost milestones, /blueprint traces every milestone to a spec\n• Security layer — 111-rule environment scan (/sentinel), pre-write secret blocking, pre-ship credential audit\n• Progressive levels 0–10 — start with CLAUDE.md, grow into multi-agent pipelines and self-evolving environments\n• Zero dependencies — no npm packages, no external APIs, no vector databases. Plain markdown files and Claude Code's native architecture.\n• Smart install — npx azclaude-copilot@latest auto-detects first install vs upgrade vs verify. Context-aware onboarding shows the right next command for your project state.\n\nExample use cases:\n• /setup — scan an existing project, detect stack + domain + scale, fill CLAUDE.md, generate project-specific skills and agents automatically\n• /copilot \"Build a compliance SaaS with trilingual support\" — walk away, come back to working code across multiple sessions\n• /sentinel — run a scored security audit (0–100, grade A–F) across hooks, permissions, MCP servers, agent configs, and secrets\n• /evolve — detect gaps in the environment, generate new skills and agents from git co-change evidence, report score delta (e.g. 42/100 → 68/100)\n• /constitute — write your project's constitution (non-negotiables, architectural commitments, definition of done) — gates all future AI actions\n• /analyze — cross-artifact consistency check: ghost milestones, spec vs. code drift, unplanned commits\n• /reflect — find stale, missing, or contradicting rules in CLAUDE.md and propose exact fixes\n• /debate \"REST vs GraphQL for this project\" — adversarial evidence-based decision with order-independent scoring, logged to decisions.md",
   "author": {
     "name": "haytamAroui",
     "url": "https://github.com/haytamAroui"

package/README.md

@@ -63,7 +63,7 @@ AZCLAUDE inverts this. **You start with almost nothing. The environment builds i
 npx azclaude-copilot@latest   # one command. that's it.
 ```
 
-No agent files to write. No skills to configure. No prompt engineering. `npx azclaude-copilot` installs 36 commands, 4 hooks, memory structure, and a manifest. The rest is generated from your actual codebase as you work. Run the same command again later — it auto-detects whether to skip, install, or upgrade.
+No agent files to write. No skills to configure. No prompt engineering. `npx azclaude-copilot` installs 37 commands, 4 hooks, memory structure, and a manifest. The rest is generated from your actual codebase as you work. Run the same command again later — it auto-detects whether to skip, install, or upgrade.
 
 **What the environment looks like across sessions:**
 
@@ -119,7 +119,7 @@ npx azclaude-copilot@latest
 ```
 
 That's it. One command, no flags. Auto-detects whether this is a fresh install or an upgrade:
-- **First time** → full install (36 commands, 4 hooks, 15 agents, 10 skills, memory, reflexes)
+- **First time** → full install (37 commands, 4 hooks, 15 agents, 10 skills, memory, reflexes)
 - **Already installed, older version** → auto-upgrades everything to latest templates
 - **Already up to date** → verifies, no overwrites
 
@@ -131,7 +131,7 @@ npx azclaude-copilot@latest doctor   # 32 checks — verify everything is wired
 
 ## What You Get
 
-**36 commands** · **9 auto-invoked skills** · **15 agents** · **4 hooks** · **memory across sessions** · **learned reflexes** · **self-evolving environment**
+**37 commands** · **9 auto-invoked skills** · **15 agents** · **4 hooks** · **memory across sessions** · **learned reflexes** · **self-evolving environment**
 
 ```
 .claude/
@@ -649,7 +649,7 @@ M1 (schema) → done
 /parallel M2 M3 M4 M5    # dispatch these milestones simultaneously
 ```
 
-**Three-layer safety:** `/blueprint` checks directory isolation + shared-utility imports before writing plan.md (Layer 1 — no agents spawned). `problem-architect` returns exact `Files Written:` and `Parallel Safe:` per milestone after plan.md (Layer 2). The orchestrator checks file overlap again at dispatch time (Layer 3 — final gate, cannot be bypassed).
+**Four-layer safety:** Before creating any milestones, `/blueprint` runs a **Task Classifier** (Layer 0) — groups coupled work (same schema table, same config file, same utility module) into single milestones so conflicts are impossible by design. Then: directory isolation + shared-utility grep (Layer 1, no agents spawned). `problem-architect` returns exact `Files Written:` and `Parallel Safe:` per milestone (Layer 2). Orchestrator re-checks file overlap at dispatch time (Layer 3 — unconditional final gate).
 
 See `docs/parallel-feature.md` for the complete reference.
 
@@ -677,7 +677,7 @@ AZCLAUDE recommends MCP servers based on your stack and wires them into daily-us
 
 ---
 
-## All 36 Commands
+## All 37 Commands
 
 ### Build and Ship
 
@@ -709,6 +709,8 @@ AZCLAUDE recommends MCP servers based on your stack and wires them into daily-us
 | `/issues` | Convert plan.md milestones to GitHub Issues. Deduplicates, creates labels, writes issue numbers back to plan.md for traceability. |
 | `/parallel` | Run multiple milestones simultaneously. Worktree isolation per agent. Auto-merges after all complete. Three-layer file collision safety. |
 | `/mcp` | Recommend and install MCP servers based on detected stack. Wires Context7, Sequential Thinking, GitHub, Playwright, Brave Search, Supabase. |
+| `/driven` | Generate `.claude/code-rules.md` — 6-question interview → DO/DO NOT coding contract. Read by every /add and /fix before writing code. |
+| `/verify` | Audit existing code against `code-rules.md`. Reports violations at `file:line`. Auto-fix mode. Falls back to per-stack rule libraries when no contract exists. |
 
 ### Think and Improve
 
@@ -863,11 +865,11 @@ Run `/level-up` at any time to see your current level and build the next one.
 
 ## Verified
 
-1526 tests. Every template, command, capability, agent, hook, and CLI feature verified.
+1578 tests. Every template, command, capability, agent, hook, and CLI feature verified.
 
 ```bash
 bash tests/test-features.sh
-# Results: 1526 passed, 0 failed, 1526 total
+# Results: 1578 passed, 0 failed, 1578 total
 ```
 
 ---

package/bin/cli.js

@@ -8,7 +8,7 @@ const { execSync }  = require('child_process');
 
 const TEMPLATE_DIR = path.join(__dirname, '..', 'templates');
 const CORE_COMMANDS     = ['setup', 'fix', 'add', 'audit', 'test', 'blueprint', 'ship', 'pulse', 'explain', 'snapshot', 'persist'];
-const EXTENDED_COMMANDS = ['dream', 'refactor', 'doc', 'loop', 'migrate', 'deps', 'find', 'create', 'reflect', 'hookify', 'sentinel', 'clarify', 'spec', 'analyze', 'constitute', 'tasks', 'issues', 'driven', 'mcp'];
+const EXTENDED_COMMANDS = ['dream', 'refactor', 'doc', 'loop', 'migrate', 'deps', 'find', 'create', 'reflect', 'hookify', 'sentinel', 'clarify', 'spec', 'analyze', 'constitute', 'tasks', 'issues', 'driven', 'mcp', 'verify'];
 const ADVANCED_COMMANDS = ['evolve', 'debate', 'level-up', 'copilot', 'reflexes', 'parallel'];
 const COMMANDS          = [...CORE_COMMANDS, ...EXTENDED_COMMANDS, ...ADVANCED_COMMANDS];
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "azclaude-copilot",
-  "version": "0.4.35",
-  "description": "AI coding environment — 36 commands, 10 skills, 15 agents, memory, reflexes, evolution. Install: npx azclaude-copilot@latest, then open Claude Code.",
+  "version": "0.4.37",
+  "description": "AI coding environment — 37 commands, 10 skills, 15 agents, memory, reflexes, evolution. Install: npx azclaude-copilot@latest, then open Claude Code.",
   "bin": {
     "azclaude": "bin/cli.js",
     "azclaude-copilot": "bin/copilot.js"

package/templates/CLAUDE.md

@@ -40,6 +40,7 @@ Extended (load command file on use):
   - /tasks: dependency graph + parallel wave groups from plan.md
   - /issues: convert plan.md milestones to GitHub Issues
 - Standards: /driven → generates .claude/code-rules.md (coding contract for /add and /fix)
+  - /verify → audits existing code against code-rules.md (file:line violations + auto-fix)
 - MCP: /mcp → recommends and installs MCP servers based on your stack
 
 Advanced (Level 5+):
@@ -64,4 +65,4 @@ When priorities conflict:
 3. {{PRIORITY_3}}
 
 ## Available Commands
-/dream · /setup · /fix · /add · /audit · /test · /blueprint · /evolve · /debate · /snapshot · /persist · /level-up · /ship · /pulse · /explain · /loop · /refactor · /doc · /migrate · /deps · /find · /create · /reflect · /hookify · /spec · /clarify · /analyze · /constitute · /tasks · /issues · /driven · /mcp · /parallel
+/dream · /setup · /fix · /add · /audit · /test · /blueprint · /evolve · /debate · /snapshot · /persist · /level-up · /ship · /pulse · /explain · /loop · /refactor · /doc · /migrate · /deps · /find · /create · /reflect · /hookify · /spec · /clarify · /analyze · /constitute · /tasks · /issues · /driven · /mcp · /parallel · /verify

package/templates/capabilities/manifest.md

@@ -58,6 +58,16 @@ Load only the files that match the current task. Never load the full list.
 | intelligence/pipeline.md | 3+ agents must chain output — context bleed is a risk | ~350 |
 | intelligence/experiment.md | Trying a risky approach that must not touch main branch — "try this safely" | ~80 |
 
+## Code Rules — per-stack rule libraries (load matching stack only)
+| File | When to load | Tokens |
+|------|-------------|--------|
+| shared/rules/typescript.md | Writing or verifying TypeScript code — load for /add, /fix, /verify when TS detected | ~250 |
+| shared/rules/react.md | Writing or verifying React/Next.js components — load when JSX/TSX detected | ~250 |
+| shared/rules/python.md | Writing or verifying Python/FastAPI/Django code — load when .py detected | ~250 |
+| shared/rules/node.md | Writing or verifying Node.js/Express backend code — load when Node stack detected | ~250 |
+
+**When to load:** `/verify` (rule source), `/driven` (default rule generation), `/add` and `/fix` (when no code-rules.md exists and stack is detected). Load only the matching stack file, never all four.
+
 ## Spec-Driven Workflow — load in sequence
 | Command | Purpose | Loads |
 |---------|---------|-------|

package/templates/capabilities/shared/rules/node.md

@@ -0,0 +1,70 @@
+# Node.js / Express Code Rules — Curated DO/DO NOT Reference
+
+**Load when**: stack contains Node.js, Express, Fastify, or similar backend JS/TS; generating code-rules.md for Node projects; or verifying Node/Express files.
+
+---
+
+## Async Patterns
+
+- DO: use `async/await` throughout — no callback-style code in new files
+- DO: always `await` Promises or chain `.catch()` — unhandled rejections crash Node
+- DO: wrap `await` calls in `try/catch` at the service boundary
+- DO NOT: mix `async/await` and `.then()/.catch()` in the same function
+- DO NOT: use `Promise.all` without handling individual rejections — use `Promise.allSettled` when partial failure is acceptable
+
+## Route Structure
+
+- DO: split routes into separate files by resource — `routes/users.ts`, `routes/orders.ts`
+- DO: use a router factory pattern — `export function usersRouter(deps: Deps): Router`
+- DO: validate all request input at the route entry — use zod, joi, or class-validator
+- DO: return semantically correct HTTP status codes:
+  - `201` for successful resource creation
+  - `204` for successful delete with no body
+  - `400` for validation failures
+  - `404` for not found
+  - `409` for conflicts
+  - `422` for unprocessable entity
+- DO NOT: put business logic in route handlers — delegate to a service layer
+- DO NOT: return stack traces in error responses — log server-side, return a generic message
+
+## Middleware
+
+- DO: register middleware in order: security → logging → parsing → auth → routes → errors
+- DO: error-handling middleware uses 4 parameters exactly: `(err, req, res, next)`
+- DO: always call `next(err)` on errors in async middleware — never swallow silently
+- DO NOT: call both `next()` and `res.send()` in the same middleware path
+- DO NOT: use synchronous file I/O in middleware (`fs.readFileSync`) — blocks the event loop
+
+## Database and Queries
+
+- DO: use parameterized queries or an ORM — never concatenate user input into SQL
+- DO: define a data access layer (repository) — routes and services never call the DB directly
+- DO: use database transactions for multi-step writes
+- DO NOT: select `*` — list columns explicitly in queries
+- DO NOT: put connection logic inside route handlers — use a shared pool or ORM connection
+
+## Security
+
+- DO: load secrets from `process.env` — never hardcode keys, tokens, or passwords in source
+- DO: validate and sanitize all user input before use
+- DO: set security headers — use `helmet` for Express
+- DO: apply rate limiting to all public endpoints
+- DO NOT: log request bodies containing passwords or tokens
+- DO NOT: expose internal error messages to clients — wrap in a safe error response
+
+## Configuration
+
+- DO: validate all required env vars at startup — fail fast with a clear message if missing
+  ```ts
+  const PORT = Number(process.env.PORT) || 3000;
+  if (!process.env.DATABASE_URL) throw new Error("DATABASE_URL required");
+  ```
+- DO: use a config module — centralize all `process.env` access in one file
+- DO NOT: use `process.env.X` scattered throughout the codebase
+
+## Testing
+
+- DO: test routes with supertest against the real Express app — not mocked handlers
+- DO: use a test database — never run tests against production or development databases
+- DO: reset database state between tests using transactions or table truncation
+- DO NOT: mock the database layer in route integration tests — it hides real issues

package/templates/capabilities/shared/rules/python.md

@@ -0,0 +1,70 @@
+# Python Code Rules — Curated DO/DO NOT Reference
+
+**Load when**: stack contains Python, FastAPI, Django, or Flask; generating code-rules.md for Python projects; or verifying Python files.
+
+---
+
+## Type Annotations
+
+- DO: annotate all public function signatures — parameters and return type
+- DO: use `Optional[X]` (or `X | None` in Python 3.10+) for nullable values
+- DO: use `TypeVar` for generic functions rather than `Any`
+- DO: use `TypedDict` or `dataclasses` for structured dicts
+- DO NOT: use bare `Any` from typing — use `object` or a proper type
+- DO NOT: omit return type on public functions — `-> None` is explicit and correct
+
+## Functions and Classes
+
+- DO NOT: use mutable default arguments — `def f(x: list = None)` with `if x is None: x = []`
+  - Bad: `def append(item, lst=[])`
+  - Good: `def append(item, lst: list | None = None) -> list`
+- DO: use dataclasses for data-only classes — `@dataclass(frozen=True)` for immutable
+- DO: use `@staticmethod` and `@classmethod` correctly — don't use `self` if not needed
+- DO: keep functions under 30 lines — extract helpers when longer
+- DO NOT: use wildcard imports — `from module import *` pollutes the namespace
+
+## Error Handling
+
+- DO: catch specific exception types — `except ValueError` not `except Exception`
+- DO: never use bare `except:` — it catches `SystemExit` and `KeyboardInterrupt`
+- DO: re-raise with context when wrapping — `raise ServiceError("msg") from original_error`
+- DO: use custom exception classes that inherit from `Exception` for domain errors
+- DO NOT: silence exceptions with `pass` — log and re-raise or handle explicitly
+
+## Imports and Modules
+
+- DO: use absolute imports — `from myapp.users.service import UserService`
+- DO: group imports: stdlib → third-party → local, separated by blank lines
+- DO: use `pathlib.Path` not `os.path` for all file system operations
+- DO NOT: use circular imports — restructure dependencies to break the cycle
+- DO NOT: import inside functions (exception: breaking circular deps or lazy loading)
+
+## String Formatting
+
+- DO: use f-strings for string interpolation — `f"Hello, {name}!"`
+- DO NOT: use `%` formatting or `.format()` in new code
+- DO: use triple-quoted strings for multiline strings
+- DO NOT: concatenate strings in a loop — use `"".join(parts)` or a list
+
+## Context Managers and Resources
+
+- DO: use `with` for all file I/O, database connections, and lock acquisition
+- DO: implement `__enter__`/`__exit__` (or `@contextmanager`) for custom resources
+- DO NOT: leave files or connections open without explicit close or `with` block
+
+## FastAPI (if applicable)
+
+- DO: define Pydantic models for all request bodies and responses
+- DO: use `Annotated` for dependency injection — `Depends()` in type position
+- DO: return typed response models — `response_model=UserResponse`
+- DO: use `HTTPException` with specific status codes and detail messages
+- DO NOT: return raw dicts from route functions — use Pydantic response models
+- DO NOT: put business logic in route handlers — delegate to service layer
+- DO NOT: access `request.body()` directly when a Pydantic body model suffices
+
+## Testing
+
+- DO: use `pytest` fixtures for setup, not `setUp`/`tearDown` methods
+- DO: name test functions `test_{what}_{condition}_{expected_outcome}`
+- DO: use `pytest.raises` as context manager for exception testing
+- DO NOT: test implementation details — test behavior and outcomes

package/templates/capabilities/shared/rules/react.md

@@ -0,0 +1,62 @@
+# React Code Rules — Curated DO/DO NOT Reference
+
+**Load when**: stack contains React or Next.js, generating code-rules.md for React projects, or verifying React/JSX files.
+
+---
+
+## Component Structure
+
+- DO: write function components exclusively — no class components
+- DO: one component per file; filename matches exported component name (PascalCase)
+- DO: keep components under 150 lines — extract sub-components or hooks when larger
+- DO: co-locate test file with component — `Button.tsx` + `Button.test.tsx` same directory
+- DO NOT: export multiple components from a single file (exception: compound components)
+- DO NOT: use `React.FC` type — write `function Foo(props: FooProps)` instead
+
+## Props
+
+- DO: define prop types with `interface` above the component — `interface ButtonProps { ... }`
+- DO: use destructuring in the function signature — `function Button({ label, onClick }: ButtonProps)`
+- DO: provide default values at destructuring — `function Card({ size = 'md' }: CardProps)`
+- DO NOT: pass more than 5-7 props — extract sub-components or use a config object
+- DO NOT: prop-drill beyond 2 levels — use Context, composition, or state management
+
+## Hooks
+
+- DO: name custom hooks with `use` prefix and extract to `hooks/` directory
+- DO: list ALL dependencies in useEffect/useMemo/useCallback dependency arrays — no omissions
+- DO: use `useCallback` for functions passed as props to memoized children
+- DO NOT: call hooks inside conditions, loops, or nested functions
+- DO NOT: suppress exhaustive-deps lint rule — fix the dependency, not the lint
+- DO NOT: use useEffect to sync state with props — use derived state or useMemo
+
+## Event Handlers
+
+- DO: define event handlers as named `const handleX = () => {}` above the JSX return
+- DO: type events explicitly — `(e: React.ChangeEvent<HTMLInputElement>) => void`
+- DO NOT: use inline arrow functions in JSX props for performance-sensitive components
+  - Bad: `<Button onClick={() => handleClick(id)} />`
+  - Good: `const handleClick = useCallback(() => onClickId(id), [id, onClickId])`
+
+## State and Data
+
+- DO: derive values from state with `useMemo` — avoid redundant state variables
+- DO: handle loading, error, and empty states before rendering data
+- DO: use `null` for "not yet loaded", `undefined` for "optional field absent"
+- DO NOT: use array index as `key` — use stable unique IDs
+- DO NOT: mutate state directly — always return a new value
+- DO NOT: store derived values in state — compute them in the render or with useMemo
+
+## Performance
+
+- DO: wrap expensive child renders in `React.memo` when parent re-renders frequently
+- DO: use lazy loading for routes and heavy components — `React.lazy(() => import(...))`
+- DO NOT: premature memoization — profile first, optimize second
+- DO NOT: put complex objects/arrays inline in JSX (recreated on every render)
+
+## Next.js (if applicable)
+
+- DO: use Server Components by default — add `"use client"` only when needed
+- DO: co-locate data fetching with the component that needs it (Server Component pattern)
+- DO NOT: fetch data in client components when a Server Component can do it
+- DO NOT: use `getServerSideProps` or `getStaticProps` in new code — use App Router conventions

package/templates/capabilities/shared/rules/typescript.md

@@ -0,0 +1,59 @@
+# TypeScript Code Rules — Curated DO/DO NOT Reference
+
+**Load when**: stack contains TypeScript, generating code-rules.md for TypeScript projects, or verifying TypeScript files.
+
+---
+
+## Type Safety
+
+- DO: annotate all public function return types explicitly — `function getUser(): User | null`
+- DO: use `unknown` for values you don't control (API responses, JSON.parse results)
+- DO: use `interface` for object shapes; `type` for unions, intersections, mapped types
+- DO: use `satisfies` operator to validate literal types without widening — `const config = {...} satisfies Config`
+- DO NOT: use `any` — replace with `unknown`, a proper type, or a generic
+- DO NOT: use non-null assertion `!` without a comment explaining why null is impossible
+- DO NOT: use `as` type casting except at data ingestion boundaries (and document why)
+- DO NOT: use `object` or `{}` as a type — name the shape explicitly
+
+## Null Handling
+
+- DO: use optional chaining `?.` and nullish coalescing `??` for safe access
+- DO: return `null` (not `undefined`) from functions that can produce no value — it's explicit
+- DO NOT: check `=== null && === undefined` separately — use `== null` or `??`
+
+## Imports and Modules
+
+- DO: use named exports — avoid default exports (makes refactoring and grep harder)
+- DO: use barrel files (`index.ts`) only for public API surface, not internal re-exports
+- DO NOT: use namespace imports `import * as X` — prevents tree-shaking
+- DO NOT: import types with `import` — use `import type` for type-only imports
+
+## Classes and Functions
+
+- DO: prefer pure functions over classes for business logic
+- DO: use `readonly` on class properties and array types that must not be mutated
+- DO: implement interfaces explicitly — `class AuthService implements IAuthService`
+- DO NOT: use `namespace` — use ES modules
+- DO NOT: use `enum` — use `const` objects with `as const` (`{ A: 'a', B: 'b' } as const`)
+
+## Async
+
+- DO: always handle Promise rejections — wrap in try/catch or chain `.catch()`
+- DO: type async function returns as `Promise<T>` not `Promise<any>`
+- DO NOT: mix async/await and `.then()/.catch()` in the same function
+- DO NOT: use `async` on functions that don't await anything
+
+## Strictness (strict mode)
+
+Enable in `tsconfig.json`:
+```json
+{
+  "strict": true,
+  "noImplicitReturns": true,
+  "noUncheckedIndexedAccess": true,
+  "exactOptionalPropertyTypes": true
+}
+```
+
+- DO NOT: add `// @ts-ignore` or `// @ts-expect-error` without a bug tracker link
+- DO NOT: disable `strictNullChecks` — it exists to catch the most common runtime errors

package/templates/commands/blueprint.md

@@ -114,9 +114,9 @@ If constitution found → scan plan steps against non-negotiables:
 - Flag any plan step that could violate a rule
 - Add a note to flagged steps: `⚠ Constitution check: may conflict with "{rule}" — verify before implementing`
 
-If code-rules found → read `## Architecture` section:
-- The plan must respect the declared architecture pattern (Clean Architecture / DDD / MVC / etc.)
-- If a plan step would introduce a pattern that conflicts with the architecture rule — flag it
+If code-rules found → read the file header line (`# Architecture: {pattern}`):
+- The plan must respect the declared architecture pattern (Clean Architecture / DDD / MVC / feature-based / etc.)
+- If a plan step would introduce a pattern that conflicts with the declared architecture — flag it
 - Add note: `⚠ Code rules: this step should follow {architecture pattern} — verify approach before implementing`
 
 Then run `/tasks` to show dependency waves:
@@ -127,69 +127,50 @@ Next: Run /tasks to see which plan steps can run in parallel
 
 ---
 
-## Step 4: Approval Gate
-
-**ExitPlanMode**
-
-Present the plan and STOP. Do not write any code.
-
-Ask the user: **"Approve this plan? (yes / change step N / cancel)"**
+## Parallel Planning — Task Classifier + Wave Assignment (ALL modes)
 
-- `yes` → create TaskCreate for each step, then state: "Run /add to execute each task."
-- `change step N` → revise that step, re-present, ask again
-- `cancel` → discard, no tasks created
+**Runs in both interactive and copilot mode.**
+Produces the milestone set and wave structure that Step 3c visualizes.
+In copilot mode, the orchestrator dispatches directly from this output.
 
-Tasks are only created after explicit approval. This is the point of /blueprint.
+**Mode detection:**
+```bash
+[ -f .claude/copilot-intent.md ] && echo "COPILOT_MODE" || echo "INTERACTIVE_MODE"
+```
 
----
+### Task Classifier — Zero-Conflict Milestone Design (REQUIRED before wave assignment)
 
-## Feature-Scoped Mode (Optional)
-
-When $ARGUMENTS points to a spec file (`.claude/specs/*.md`) OR contains a named feature:
+**Run this BEFORE creating milestones.** Groups coupled work together so parallel dispatch is safe by construction — not by detection after the fact.
 
+**Step 0: Greenfield check**
 ```bash
-# Detect spec file
-[ -f "$ARGUMENTS" ] && echo "spec-mode" || echo "inline-mode"
-
-# Determine next feature number
-NEXT_N=$(ls .claude/features/ 2>/dev/null | grep -c '^' || echo 0)
-N=$(printf '%02d' $((NEXT_N + 1)))
-SLUG=$(basename "$ARGUMENTS" .md 2>/dev/null || echo "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd 'a-z0-9-' | cut -c1-40)
-FEATURE_DIR=".claude/features/${N}-${SLUG}"
+SRC_COUNT=$(find src/ app/ lib/ -type f 2>/dev/null | wc -l 2>/dev/null || echo 0)
+echo "source_files=$SRC_COUNT"
 ```
+If source_files < 10 → greenfield project. Force Wave 1 = all foundation work (schema, config, shared utils, types) as a SINGLE milestone regardless of feature count. Parallel only unlocks from Wave 2 onward, after the foundation exists and greps have real files to scan.
 
-If spec file provided → create a feature-scoped directory:
-```bash
-mkdir -p "$FEATURE_DIR"
-cp "$ARGUMENTS" "$FEATURE_DIR/spec.md"
-```
+**Step 1: List raw work items**
+From the intent/spec, enumerate ALL features, endpoints, models, UI pages, and background jobs as raw items. Do not group yet — just list everything the project needs.
 
-Write the plan to `$FEATURE_DIR/plan.md` (same format as `.claude/plan.md`).
-Also write a summary entry to `.claude/plan.md` linking to the feature:
-```markdown
-## Feature: {N}-{slug}
-Files: .claude/features/{N}-{slug}/plan.md
-Status: pending
-```
+**Step 2: Coupling analysis — merge rule**
+For each pair of raw work items, check if they share ANY of:
+- Same database table (both CREATE or ALTER the same table)
+- Same config file (`package.json`, `tsconfig.json`, `prisma/schema.prisma`, `docker-compose.yml`, `go.mod`, `Cargo.toml`)
+- Same utility module (both CREATE or MODIFY files in `utils/`, `shared/`, `common/`, `lib/`, `helpers/`)
+- Same API contract (one produces an endpoint, the other consumes it within the same feature boundary)
 
-This keeps the global plan.md as the tracker while feature details live in their own directory.
-Each feature directory is self-contained: `spec.md` + `plan.md` + any generated artifacts.
+If any coupling exists → merge those two items into ONE milestone. Repeat until no same-wave pair shares any resource.
 
-**When NOT to use feature mode:** quick fixes, single-file changes, copilot mode (uses global plan.md).
+**Step 3: Independence check — split rule**
+Work items that share NONE of the above → separate milestones, `Parallel: yes` candidate.
 
----
+**Result:** Every milestone is either:
+- **Fat milestone** — all coupled work together. One agent handles everything that would otherwise conflict. Larger task, zero parallel risk.
+- **Thin milestone** — fully independent. Parallel-safe by construction, not by detection.
 
-## Copilot Mode — Structured plan.md Output
+Proceed to Layer 1 with these merged milestones — not with raw work items.
 
-When running inside `/copilot` (detected by: `.claude/copilot-intent.md` exists):
-- Skip the approval gate (Step 4) — copilot operates autonomously
-- Write the plan to `.claude/plan.md` in the structured format defined in `plan-tracker.md`
-- Read `.claude/capabilities/shared/plan-tracker.md` for the exact format
-- Each milestone = one logical unit of work (1-3 files, one commit)
-- Include `Depends:` for milestones that require prior work
-- Include `Files:` with expected paths
-- Include `Commit:` with conventional commit format
-- Write `## Summary` with counts at the bottom
+---
 
 ### Parallel Optimization Pass — Layer 1 (REQUIRED before writing plan.md)
 
@@ -231,7 +212,7 @@ both need to CREATE or MODIFY files there → set `Parallel: no` for both and ad
 **Do NOT spawn problem-architect here.** The grep is sufficient for Layer 1. Problem-architect
 runs after plan.md is written and handles the cases Layer 1 misses.
 
-**Step 4: Set Dirs: and Parallel: fields, write plan.md**
+**Step 4: Set Dirs: and Parallel: fields**
 
 ```
 - Dirs:     top-level directories this milestone exclusively owns
@@ -249,6 +230,140 @@ Wave 3: M6 (integration/E2E) — Parallel: no
 
 ---
 
+## Step 3c: Parallel Dispatch Visualization
+
+After classifier + Layer 1 complete, render the dispatch map:
+
+```
+══════════════════════════════════════════════════════
+  Parallel Dispatch Plan
+══════════════════════════════════════════════════════
+
+  Wave 1 (sequential — foundation)
+  ┌─────────────────────────────────────────────────┐
+  │  M1: {title}                                    │
+  │      Dirs: {dirs}                               │
+  │      Parallel: no  (foundation — must run first)│
+  └─────────────────────────────────────────────────┘
+                         │
+                         ▼
+  Wave 2 (parallel — {N} agents simultaneously)
+  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
+  │ M2: {title}  │ │ M3: {title}  │ │ M4: {title}  │
+  │ {dirs}       │ │ {dirs}       │ │ {dirs}        │
+  │ Parallel: ✓  │ │ Parallel: ✓  │ │ Parallel: ✓  │
+  └──────────────┘ └──────────────┘ └──────────────┘
+                         │
+                         ▼
+  (continue for each wave)
+
+  ══════════════════════════════════════════════════
+  Summary
+  ──────────────────────────────────────────────────
+  Total milestones:    {N}
+  Waves:               {N}
+  Max parallel:        {N} agents (Wave {N})
+  Sequential estimate: {total} sessions (~{total×30}min)
+  Parallel estimate:   {waves} waves  (~{waves×30}min)
+  Time saved:          ~{pct}%
+
+  Merged by classifier:
+    • {item A} + {item B} → {MN}  ({reason — e.g. shared schema.prisma})
+
+  Split for parallelism:
+    • {item} split from {other item}  ({reason — e.g. different dirs, no shared files})
+  ══════════════════════════════════════════════════
+```
+
+**Rules:**
+- Show every wave, even single-milestone waves
+- Side-by-side boxes for parallel milestones in the same wave; single wide box for sequential
+- "Sequential estimate" = `total milestones × 30min`; "Parallel estimate" = `wave count × 30min`
+- Time saved % = `(sequential - parallel) / sequential × 100`
+- "Merged by classifier" lists only merges that changed the plan (not items that were always single)
+- "Split for parallelism" lists items the classifier separated into different milestones
+
+**In copilot mode:** write the visualization as a comment block at the top of plan.md:
+```markdown
+<!-- Parallel Dispatch Plan
+Wave 1 (seq): M1 — foundation
+Wave 2 (parallel, 4 agents): M2 M3 M4 M5
+Wave 3 (parallel, 3 agents): M6 M7 M8
+Wave 4 (seq): M9 — integration
+Sequential: ~270min | Parallel: ~120min | Saved: ~56%
+-->
+```
+
+**In interactive mode:** show the visualization before the approval gate.
+Let the user adjust wave grouping: "move M5 to Wave 3" → adjust Depends:, re-render, re-present.
+
+---
+
+## Step 4: Approval Gate
+
+**ExitPlanMode**
+
+Present the plan and STOP. Do not write any code.
+
+Ask the user: **"Approve this plan? (yes / change step N / cancel)"**
+
+- `yes` → create TaskCreate for each step, then state: "Run /add to execute each task."
+- `change step N` → revise that step, re-present, ask again
+- `cancel` → discard, no tasks created
+
+Tasks are only created after explicit approval. This is the point of /blueprint.
+
+---
+
+## Feature-Scoped Mode (Optional)
+
+When $ARGUMENTS points to a spec file (`.claude/specs/*.md`) OR contains a named feature:
+
+```bash
+# Detect spec file
+[ -f "$ARGUMENTS" ] && echo "spec-mode" || echo "inline-mode"
+
+# Determine next feature number
+NEXT_N=$(ls .claude/features/ 2>/dev/null | grep -c '^' || echo 0)
+N=$(printf '%02d' $((NEXT_N + 1)))
+SLUG=$(basename "$ARGUMENTS" .md 2>/dev/null || echo "$ARGUMENTS" | tr '[:upper:]' '[:lower:]' | tr ' ' '-' | tr -cd 'a-z0-9-' | cut -c1-40)
+FEATURE_DIR=".claude/features/${N}-${SLUG}"
+```
+
+If spec file provided → create a feature-scoped directory:
+```bash
+mkdir -p "$FEATURE_DIR"
+cp "$ARGUMENTS" "$FEATURE_DIR/spec.md"
+```
+
+Write the plan to `$FEATURE_DIR/plan.md` (same format as `.claude/plan.md`).
+Also write a summary entry to `.claude/plan.md` linking to the feature:
+```markdown
+## Feature: {N}-{slug}
+Files: .claude/features/{N}-{slug}/plan.md
+Status: pending
+```
+
+This keeps the global plan.md as the tracker while feature details live in their own directory.
+Each feature directory is self-contained: `spec.md` + `plan.md` + any generated artifacts.
+
+**When NOT to use feature mode:** quick fixes, single-file changes, copilot mode (uses global plan.md).
+
+---
+
+## Copilot Mode — plan.md Format + Layer 2 Validation
+
+When running inside `/copilot` (detected by: `.claude/copilot-intent.md` exists):
+- Skip the approval gate (Step 4) — copilot operates autonomously
+- Task Classifier + Layer 1 already ran in the "Parallel Planning" section above
+- Write the plan to `.claude/plan.md` using the classified milestones
+- Read `.claude/capabilities/shared/plan-tracker.md` for the exact format
+- Each milestone = one logical unit of work (1-3 files, one commit)
+- Include `Depends:` for milestones that require prior work
+- Include `Files:` with expected paths
+- Include `Commit:` with conventional commit format
+- Write `## Summary` with counts at the bottom
+
 ### Problem-Architect Validation — Layer 2 (after plan.md is written)
 
 Layer 2 refines Layer 1 with exact file-level analysis. Catches shared utilities that

package/templates/commands/driven.md

@@ -65,7 +65,7 @@ Use **AskUserQuestion**: "`.claude/code-rules.md` already exists. Regenerate fro
 
 ---
 
-## Step 2: Detect Stack
+## Step 2: Detect Stack + Load Rule Library
 
 Read `CLAUDE.md` Stack field. If empty or missing, run detection:
 
@@ -80,6 +80,16 @@ State the detected stack before starting the interview. Example:
 Detected stack: React 19, TypeScript, Node/Express, PostgreSQL
 ```
 
+**Load per-stack rule library as the default rule baseline:**
+- TypeScript detected → read `capabilities/shared/rules/typescript.md`
+- React detected → read `capabilities/shared/rules/react.md`
+- Python detected → read `capabilities/shared/rules/python.md`
+- Node/Express detected → read `capabilities/shared/rules/node.md`
+
+These rule libraries provide the curated DO/DO NOT defaults for each section of `code-rules.md`.
+When the user selects "Default" in any interview question (Step 3), use the matching rules from the loaded library as the generated content for that section.
+When the user provides custom answers, use those instead — the library is a fallback, not a requirement.
+
 ---
 
 ## Step 3: Interview — 6 Questions

package/templates/commands/verify.md

@@ -0,0 +1,217 @@
+---
+name: verify
+description: >
+  Audit existing code against the project's coding rules (.claude/code-rules.md).
+  Finds rule violations at file:line level, reports them, and optionally auto-fixes.
+  Triggers on: "check my code", "verify code quality", "does this follow our rules",
+  "check coding style", "audit coding standards", "find violations", "lint against rules",
+  "check this file against rules", "are we following conventions", "code quality check",
+  "verify standards", "rules check", "style violations", "rule violations".
+  NOT triggered by: dependency audits (use /deps), security audit (use /sentinel),
+  full project audit (use /audit), governance check (use /constitute).
+argument-hint: "[file/dir/pattern — default: git changed files]"
+disable-model-invocation: true
+allowed-tools: Read, Bash, Glob, Grep
+---
+
+# /verify — Audit Code Against Project Rules
+
+$ARGUMENTS
+
+---
+
+## Purpose
+
+Check existing files against `.claude/code-rules.md`.
+Report every violation at `file:line` precision.
+Optionally auto-fix violations.
+
+This is NOT a linter replacement — it is a semantic rule checker.
+Use it: before a PR, after a big refactor, when onboarding new code.
+
+---
+
+## Step 1: Load Rules
+
+```bash
+# Load project coding contract
+cat .claude/code-rules.md 2>/dev/null | head -5
+
+# Detect stack if no code-rules.md
+grep -i "stack:" CLAUDE.md 2>/dev/null | head -2
+```
+
+**If `.claude/code-rules.md` exists:**
+Read the full file — extract every `DO:` and `DO NOT:` rule by section.
+Build a rule checklist:
+```
+Section: TypeScript
+  R1: DO: explicit return types on all public functions
+  R2: DO NOT: use `any` — replace with `unknown` or a proper type
+  ...
+```
+
+**If no `code-rules.md`:**
+State: "No `.claude/code-rules.md` found — run `/driven` to create your project coding contract."
+Then load the matching per-stack capability as a fallback:
+- TypeScript detected → load `capabilities/shared/rules/typescript.md`
+- React detected → load `capabilities/shared/rules/react.md`
+- Python detected → load `capabilities/shared/rules/python.md`
+- Node/Express detected → load `capabilities/shared/rules/node.md`
+
+State which rules are being checked and that they are defaults — not project-specific.
+
+---
+
+## Step 2: Identify Target Files
+
+**If $ARGUMENTS provided:**
+```bash
+# Expand argument to file list
+if [ -f "$ARGUMENTS" ]; then
+  echo "single-file"
+elif [ -d "$ARGUMENTS" ]; then
+  find "$ARGUMENTS" -type f -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.js" | head -50
+else
+  # Treat as glob pattern
+  ls $ARGUMENTS 2>/dev/null | head -50
+fi
+```
+
+**If no $ARGUMENTS (default — git changed files):**
+```bash
+git diff --name-only HEAD 2>/dev/null | grep -E "\.(ts|tsx|js|jsx|py)$" | head -30
+```
+
+If no git diff and no argument → scan all source files:
+```bash
+find src/ lib/ app/ -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.js" \) 2>/dev/null | head -30
+```
+
+State the file list before proceeding.
+
+---
+
+## Step 3: Check Each Rule
+
+For each file × each rule in code-rules.md:
+
+**DO NOT rules (search for violations):**
+Map each "DO NOT" to a search pattern, then grep:
+```bash
+# Example — DO NOT: use `any`
+grep -n ":\s*any\b\|<any>\|as any" {file} 2>/dev/null
+
+# Example — DO NOT: use `var`
+grep -n "^\s*var " {file} 2>/dev/null
+
+# Example — DO NOT: use `console.log` in production code
+grep -n "console\.log" {file} 2>/dev/null
+```
+
+**DO rules (check absence — structural)**:
+These require reading the file, not just grepping.
+For example:
+- "DO: explicit return types" → read exported functions, check if return type is present
+- "DO: handle loading/error states" → read component, check for loading/error branch
+- "DO: parameterized queries" → check that DB calls don't use string concatenation
+
+Use Grep and Read tools — don't spawn agents for Step 3.
+
+**Violation format:**
+```
+{file}:{line}  →  violates [{section}] {rule}
+```
+
+Example output:
+```
+src/auth/login.ts:23  →  violates [TypeScript] DO NOT: use `any`
+src/auth/login.ts:45  →  violates [TypeScript] DO NOT: use non-null assertion `!`
+src/components/Form.tsx:12  →  violates [React] DO NOT: use index as `key`
+```
+
+---
+
+## Step 4: Report
+
+After checking all files:
+
+```
+Code Rules Verification — {date}
+Source: .claude/code-rules.md
+Files checked: {N}
+Rules checked: {N}
+
+Violations Found: {total}
+─────────────────────────────────
+{file}:{line}  →  [{section}] {rule}
+...
+
+Most violated rule: {rule} ({N} occurrences)
+Clean files: {N}/{total}
+```
+
+**If 0 violations:**
+```
+✓ All {N} files pass project coding rules.
+Files: {N} | Rules: {N} | Zero violations.
+```
+
+---
+
+## Step 5: Fix Offer
+
+If violations found, ask (use **AskUserQuestion**):
+
+"Found {N} violations across {M} files.
+
+Options:
+  a) Auto-fix — I'll fix each violation now (may require reading context)
+  b) Show fix plan — list what would change, I'll implement on approval
+  c) Export — write violations to .claude/verify-report.md
+  d) Skip — I'll fix manually"
+
+**If option a — Auto-fix:**
+For each violation:
+1. Read the file section around the violation
+2. Apply the minimal fix that satisfies the rule
+3. Verify the fix doesn't break adjacent logic
+4. Show the diff before writing
+
+After all fixes:
+```bash
+# Confirm nothing is broken
+npm test 2>&1 | tail -5  # or pytest or whatever is the test runner
+```
+
+Report: "Fixed {N} violations. {M} files changed. Tests: {result}."
+
+**If option c — Export report:**
+Write `.claude/verify-report.md`:
+```markdown
+# Code Rules Verification Report — {date}
+
+## Summary
+Files: {N} | Violations: {N} | Rules: {N}
+
+## Violations
+| File | Line | Section | Rule |
+|------|------|---------|------|
+| {file} | {line} | {section} | {rule} |
+
+## Most Violated Rules
+1. {rule} — {N} occurrences
+2. ...
+```
+
+---
+
+## When to Run `/verify`
+
+| Trigger | Command |
+|---------|---------|
+| Before opening a PR | `/verify` (checks git diff) |
+| After a big refactor | `/verify src/` |
+| Audit a specific file | `/verify src/auth/login.ts` |
+| Full codebase scan | `/verify src/` |
+| After `/driven` changes rules | `/verify` to see existing violations |