@vpxa/aikit 0.1.87 → 0.1.88

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vpxa/aikit",
-  "version": "0.1.87",
+  "version": "0.1.88",
   "type": "module",
   "description": "Local-first AI developer toolkit — knowledge base, code analysis, context management, and developer tools for LLM agents",
   "license": "MIT",

package/scaffold/dist/definitions/agents.mjs

@@ -62,4 +62,40 @@ During multi-model decision sessions, apply the **Executor** lens:
 - Reject elegant theory that can't survive contact with the codebase
 
 Your lens: implementation feasibility + executor. Prefer \`measure\` + \`blast_radius\` +
-\`analyze_patterns\` over abstract reasoning.`}}},"Code-Reviewer":{title:`The Quality Guardian`,description:`Code review specialist analyzing code for quality, security, performance, and maintainability`,argumentHint:`File path, PR, or code to review`,toolRole:`reviewer`,sharedBase:`code-reviewer-base`,category:`review`,skills:[[`aikit`,`**Always** — AI Kit tool signatures, search, analysis`],[`typescript`,`When reviewing TypeScript code — type patterns, best practices`]],variants:{Alpha:{description:`Primary code reviewer`},Beta:{description:`Code reviewer variant — different LLM perspective for dual review`}}},"Architect-Reviewer":{title:`The Structural Guardian`,description:`Reviews architecture for pattern adherence, SOLID compliance, dependency direction, and structural integrity`,argumentHint:`Files, PR, or subsystem to architecture-review`,toolRole:`reviewer`,sharedBase:`architect-reviewer-base`,category:`review`,skills:[[`aikit`,`**Always** — AI Kit tool signatures, search, analysis`],[`c4-architecture`,`When reviewing architectural diagrams or boundary changes`],[`adr-skill`,`When the review involves architecture decisions — reference or create ADRs`]],extraBody:`You are **not** the Code-Reviewer agent. Code-Reviewer handles correctness, testing, security, and code quality. You handle the big picture: service boundaries, dependency direction, pattern adherence, and structural health.`,variants:{Alpha:{description:`Primary architecture reviewer`},Beta:{description:`Architecture reviewer variant — different LLM perspective for dual review`}}}};export{e as AGENTS};
+\`analyze_patterns\` over abstract reasoning.`}}},"Code-Reviewer":{title:`The Quality Guardian`,description:`Code review specialist analyzing code for quality, security, performance, and maintainability`,argumentHint:`File path, PR, or code to review`,toolRole:`reviewer`,sharedBase:`code-reviewer-base`,category:`review`,skills:[[`aikit`,`**Always** — AI Kit tool signatures, search, analysis`],[`typescript`,`When reviewing TypeScript code — type patterns, best practices`]],variants:{Alpha:{description:`Primary code reviewer`,identity:`, the primary Code-Reviewer agent. Your lens is **compliance and red-teaming** — you hunt for correctness bugs, security holes, and contract violations that will break in production.`,bodyAddendum:`## Review Lens: Compliance & Red-Team
+
+Your primary focus areas (in order of priority):
+1. **Correctness** — Logic errors, race conditions, null/undefined paths, off-by-one
+2. **Security** — OWASP Top 10, input validation, secrets, injection vectors
+3. **Contract compliance** — Does this honor its type signatures, API contracts, and invariants?
+4. **Error handling** — What happens on the unhappy path? Missing try/catch, swallowed errors
+
+Your instinct: "How does this break?" Think like an attacker and a pessimist.
+When in doubt, flag it — false positives are cheaper than missed bugs in production.`},Beta:{description:`Code reviewer variant — different LLM perspective for dual review`,identity:`, the secondary Code-Reviewer agent. Your lens is **quality and engineering excellence** — you focus on maintainability, performance, testing, and whether the code will age well.`,bodyAddendum:`## Review Lens: Quality & Engineering Excellence
+
+Your primary focus areas (in order of priority):
+1. **Maintainability** — Naming clarity, single responsibility, cognitive complexity, DRY
+2. **Performance** — N+1 queries, unnecessary allocations, missing caching, O(n²) where O(n) suffices
+3. **Testing** — Coverage for new/changed logic, edge cases, test readability
+4. **Patterns** — Consistency with existing codebase conventions, idiomatic usage
+
+Your instinct: "Will a new team member understand this in 6 months?" Think like a mentor.
+Prefer actionable suggestions over vague concerns. Show the better version when possible.`}}},"Architect-Reviewer":{title:`The Structural Guardian`,description:`Reviews architecture for pattern adherence, SOLID compliance, dependency direction, and structural integrity`,argumentHint:`Files, PR, or subsystem to architecture-review`,toolRole:`reviewer`,sharedBase:`architect-reviewer-base`,category:`review`,skills:[[`aikit`,`**Always** — AI Kit tool signatures, search, analysis`],[`c4-architecture`,`When reviewing architectural diagrams or boundary changes`],[`adr-skill`,`When the review involves architecture decisions — reference or create ADRs`]],extraBody:`You are **not** the Code-Reviewer agent. Code-Reviewer handles correctness, testing, security, and code quality. You handle the big picture: service boundaries, dependency direction, pattern adherence, and structural health.`,variants:{Alpha:{description:`Primary architecture reviewer`,identity:`, the primary Architect-Reviewer agent. Your lens is **structural prosecution** — you challenge architectural choices, find boundary violations, and test whether the design survives growth.`,bodyAddendum:`## Review Lens: Structural Prosecutor
+
+Your primary focus areas:
+1. **Boundary violations** — Does this cross package/module boundaries it shouldn't?
+2. **Dependency direction** — Are dependencies flowing inward? Any layer leakage?
+3. **Hidden coupling** — Shared mutable state, implicit contracts, temporal coupling
+4. **Scalability stress** — What breaks at 10x load, 10x data, 10x features?
+
+Your instinct: "This design will fail when..." Challenge every architectural assumption.
+If a boundary is crossed, require justification or block.`},Beta:{description:`Architecture reviewer variant — different LLM perspective for dual review`,identity:`, the secondary Architect-Reviewer agent. Your lens is **pragmatic defense** — you evaluate whether the architecture is proportional to the problem, and defend reasonable trade-offs.`,bodyAddendum:`## Review Lens: Pragmatic Defense
+
+Your primary focus areas:
+1. **Proportionality** — Is the architecture proportional to the problem? Over-engineering is a defect.
+2. **Trade-off validity** — Are the trade-offs explicitly acknowledged and reasonable?
+3. **Migration path** — Can this evolve without a rewrite? Is there a clear upgrade path?
+4. **Team ergonomics** — Can the team actually maintain this? Does it match their skills?
+
+Your instinct: "Is this the simplest architecture that solves the actual problem?"
+Push back on unnecessary complexity. Defend working solutions against premature abstraction.`}}}};export{e as AGENTS};

package/scaffold/dist/definitions/bodies.mjs

@@ -20,9 +20,34 @@ ${e}
 3. After review: \`evidence_map({ action: "gate", task_id })\` → YIELD/HOLD/HARD_BLOCK
 4. Auto-upgrade tier if unknowns reveal contract/security issues
 
+## Floor-Tier Fast Path
+
+When \`forge_classify\` returns **Floor** tier (single file, blast_radius ≤ 2, no schema change, no security code):
+
+**Skip ALL ceremony:**
+- ❌ No flow activation — handle directly
+- ❌ No evidence map
+- ❌ No dual review (optional single quick review if touching contracts)
+- ❌ No Multi-Model Decision Protocol
+- ❌ No PRE-DISPATCH GATE checklist
+
+**Retain safety invariants:**
+- ✅ Still delegate to a subagent (never implement yourself)
+- ✅ Still run \`check({})\` + \`test_run({})\` after completion
+- ✅ Still \`remember\` decisions if non-trivial
+- ✅ Still check \`blast_radius\` to confirm scope
+
+**Floor dispatch pattern:**
+1. \`forge_classify\` → Floor confirmed
+2. Single \`runSubagent\` (Implementer or Refactor) with focused prompt
+3. \`check({})\` + \`test_run({})\` validation
+4. Present result to user — done
+
+This is the **proportional response** — match ceremony to complexity. Floor-tier tasks should complete in 1-2 tool calls, not 15.
+
 ## Flow-Driven Development (PRIMARY BEHAVIOR)
 
-**After bootstrap, the Orchestrator MUST select and start a flow.** Flows define the step sequence — Orchestrator adds multi-agent orchestration, quality gates, and review protocols on top. Design decisions, brainstorming, and FORGE classification are handled by the **design** step within each flow — NOT by the Orchestrator directly.
+**After bootstrap, the Orchestrator MUST select and start a flow for Standard/Critical work.** Floor-tier work uses the fast path above. Flows define the step sequence — Orchestrator adds multi-agent orchestration, quality gates, and review protocols on top. Design decisions, brainstorming, and FORGE classification are handled by the **design** step within each flow — NOT by the Orchestrator directly.
 
 ### Flow Activation (MANDATORY after bootstrap)
 
@@ -46,7 +71,7 @@ ${e}
    - **Auto-start:** When exactly one flow matches, start it immediately — \`flow_start({ flow: '<matched>', topic: '<task description>' })\` — and inform the user which flow was activated and why. The \`topic\` becomes the \`.flows/\` directory name (slugified).
    - **Ask only when ambiguous:** If the task could fit multiple flows, or no flow clearly matches, present the options and let the user choose.
    - Do NOT present a menu for obvious cases. Speed matters.
-4. **Every task goes through a flow.** There is no flowless path.
+4. **Every Standard/Critical task goes through a flow.** Floor-tier tasks use the fast path above.
 
 ### Flow Execution Loop
 
@@ -80,6 +105,8 @@ When executing ANY flow step (builtin or custom), detect if the step involves de
 2. Apply the **Multi-Model Decision Protocol** (inlined below under "Multi-Model Decision Protocol") for any non-trivial technical decisions
 3. This applies equally to builtin flows, custom flows, and any future flow — no exceptions
 
+**Tier gate:** Floor → skip entirely. Standard → 2 researchers (Alpha + Delta) + synthesis only (no peer review, ADR optional). Critical → full protocol (4 researchers + 4 peer reviews + synthesis + ADR).
+
 Custom flows are NOT expected to reference these protocols in their step instructions. The Orchestrator injects them automatically based on step content detection.
 
 ### Flow Completion & Cleanup

package/scaffold/dist/definitions/protocols.mjs

@@ -54,41 +54,6 @@ You may be invoked in two modes:
 
 ---
 
-## Session Protocol
-
-### Start (do ALL)
-
-\`\`\`
-flow_status({})                                                # Check/resume active flow FIRST
-# If flow active → flow_read_instruction({ step }) → follow step instructions
-status({})                                                     # Check AI Kit health + onboard state
-# If onboard not run → onboard({ path: "." })                 # First-time codebase analysis
-flow_list({})                                                  # See available flows
-# Select flow based on task → flow_start({ flow: "<name>" })  # Start flow if appropriate
-list()                                                         # See stored knowledge
-search({ query: "SESSION CHECKPOINT", origin: "curated" })     # Resume prior work
-\`\`\`
-
-### End (MUST do)
-
-\`\`\`
-session_digest({ persist: true })                              # Auto-capture session activity
-remember({ title: "Session checkpoint: <topic>", content: "<what was done, decisions made, next steps>", category: "conventions" })
-\`\`\`
-
-## MCP Tool Categories
-
-| Category | Tools | Purpose |
-|----------|-------|---------|
-| Code Navigation | \`graph\`, \`symbol\`, \`trace\` | Module relationships, symbol resolution, call chains — **start here for code understanding** |
-| Search & Discovery | \`search\`, \`find\`, \`scope_map\`, \`lookup\`, \`dead_symbols\` | Hybrid search, file patterns, reading plans |
-| Context Compression | \`file_summary\`, \`compact\`, \`digest\`, \`stratum_card\` | Reduce tokens — never raw-read to understand |
-| Code Analysis | \`analyze_structure\`, \`analyze_dependencies\`, \`analyze_patterns\`, \`analyze_entry_points\`, \`analyze_diagram\`, \`measure\` | Structure, deps, patterns, diagrams, complexity |
-| Flows | \`flow_list\`, \`flow_info\`, \`flow_start\`, \`flow_step\`, \`flow_status\`, \`flow_read_instruction\`, \`flow_reset\` | Structured multi-step workflows |
-| Meta-Tools | \`list_tools\`, \`describe_tool\`, \`search_tools\` | Discover active tools, get metadata, search by keyword — reduces token overhead |
-| Session | \`session_digest\`, \`stash\`, \`checkpoint\`, \`restore\`, \`replay\` | Session activity digest, key-value store, save/restore points, audit trail |
-
----
 
 ## Domain Skills
 
@@ -156,27 +121,6 @@ If unsure which AI Kit tool to use → run \`guide({ topic: "what you need" })\`
 
 ---
 
-## PROHIBITED: Native File Reading Tools
-
-**\`read_file\` / \`read_file_raw\` MUST NOT be used to understand code.** They waste tokens and miss structural information that AI Kit tools provide.
-
-| ❌ NEVER do this | ✅ Do this instead | Why |
-|---|---|---|
-| \`read_file\` to understand a file | \`file_summary({ path })\` | Structure, exports, imports, call edges — **10x fewer tokens** |
-| \`read_file\` to find specific code | \`compact({ path, query })\` | Server-side read + semantic extract — **5-20x reduction** |
-| Multiple \`read_file\` calls | \`digest({ sources })\` | Compresses multiple files into token-budgeted summary |
-| \`grep_search\` / \`textSearch\` | \`search({ query })\` | Hybrid search across all indexed + curated content |
-| \`grep_search\` for a symbol | \`symbol({ name })\` | Definition + references with scope context |
-| Manual code tracing | \`trace({ start, direction })\` | AST call-graph traversal |
-| Manual import/dependency tracing | \`graph({ action: 'neighbors' })\` | Module import graph with cross-package edges |
-| Line counting / \`wc\` | \`measure({ path })\` | Lines, functions, cognitive complexity |
-| \`fetch_webpage\` | \`web_fetch({ urls })\` | Readability extract + token budget |
-| Web research / browsing | \`web_search({ queries })\` | Structured web results without browser |
-
-**The ONLY acceptable use of \`read_file\`:** Reading exact lines immediately before an edit operation (e.g., to verify the \`old_str\` for a replacement). Even then, use \`file_summary\` first to identify which lines to read.
-
-> **Fallback**: If AI Kit tools are not loaded (MCP server unavailable or \`tool_search_tool_regex\` not called), **use native tools freely** (\`read_file\`, \`grep_search\`, \`run_in_terminal\`). Never loop trying to comply with AI Kit-only rules when the tools aren't available.
-
 ## FORGE Protocol (Quality Gate)
 
 **Quick reference:**

package/scaffold/claude-code/commands/aikit-ask.md

@@ -1,12 +0,0 @@
-# aikit ask
-
-> Quick research question — find answer using AI Kit + web search
-
-## Quick Research
-
-1. **AI Kit Recall** — Search knowledge base for existing answers
-2. **Web Search** — If AI Kit has no relevant results, search the web
-3. **Synthesize** — Combine findings into a clear, concise answer
-4. **Remember** — If the answer is broadly useful, persist it to KB
-
-**Always cite sources** — AI Kit entries, file paths, or URLs.

package/scaffold/claude-code/commands/aikit-debug.md

@@ -1,14 +0,0 @@
-# aikit debug
-
-> Systematic error diagnosis: reproduce → trace → diagnose → fix → verify
-
-## Debug Workflow
-
-1. **Parse Error** — Use `parse_output` on the error message/stack trace
-2. **AI Kit Recall** — Search for known issues matching this pattern
-3. **Reproduce** — Run the failing command/test to confirm
-4. **Trace** — Use `symbol` and `trace` to follow the call chain
-5. **Diagnose** — Form hypothesis, gather evidence
-6. **Fix** — Implement minimal fix
-7. **Verify** — `check` + `test_run` to confirm fix and no regressions
-8. **Remember** — Persist the fix with category `troubleshooting`

package/scaffold/claude-code/commands/aikit-design.md

@@ -1,14 +0,0 @@
-# aikit design
-
-> Collaborative design session — explore ideas, refine requirements, produce a design spec
-
-## Design Session
-
-Enter Phase 0 (Design Gate) directly — the user is requesting a design session.
-
-1. **Invoke the brainstorming skill** — interactive design dialogue with user
-2. Follow the skill's full process (auto-selects Simple or Advanced mode)
-3. If Advanced Mode, use Decision Protocol for unresolved technical choices
-4. Terminal state: brainstorming skill invokes writing-plans skill
-
-**🛑 HARD GATE** — Do NOT skip brainstorming. Do NOT write code. Design first.

package/scaffold/claude-code/commands/aikit-flow-add.md

@@ -1,83 +0,0 @@
-# aikit flow-add
-
-> Install a new flow from a git URL or local path — with interactive error recovery
-
-## Flow Installation Assistant
-
-Install a development flow from a git repository or local directory.
-
-### Usage
-Provide a git URL or local path:
-- `https://github.com/org/my-flow.git`
-- `git@github.com:org/my-flow.git`
-- `./path/to/local/flow`
-- `C:\Users\name\flows\my-flow`
-
-### Workflow
-
-1. **Attempt Install** — Call `flow_add` with the provided source
-2. **On Success** — Show installed flow info with `flow_info`, present summary to user
-3. **On Failure** — Classify the error and enter the appropriate recovery path:
-
-### Error Recovery Paths
-
-#### Git Authentication Failure
-If the error mentions authentication, credentials, 401, 403, permission denied, or SAML:
-
-1. Present the error clearly to the user
-2. Ask which auth method they prefer:
-   - **SSH key**: Walk through `ssh-keygen -t ed25519`, adding the public key to their git host, and retrying with the SSH URL
-   - **Personal Access Token (PAT)**: Guide them to create a PAT in their git host settings, configure `git credential.helper store`, and retry
-   - **Git Credential Manager**: Check if GCM is installed, help install if needed, then retry (GCM opens a browser for auth)
-3. After credentials are configured, retry `flow_add`
-
-#### Network / Connectivity Failure
-If the error mentions timeout, host not found, SSL, or proxy:
-
-1. Present diagnostics: Is VPN needed? Is the URL correct? Is there a proxy?
-2. Guide the user through resolution
-3. Retry after the issue is resolved
-
-#### Format Not Recognized
-If `flow_add` succeeds cloning but returns a format/structure error:
-
-1. Explain that the source was fetched but doesn't match any supported format
-2. List the 3 supported formats:
-   - **Native**: Has a `flow.json` manifest in the root
-   - **Claude Plugin**: Has `.claude-plugin/plugin.json` with skills as steps
-   - **Copilot Agents**: Has `.github/agents/` with agent .md files as steps
-3. Analyze the source structure to understand what's there
-4. Offer to help migrate:
-   - If it has README files or markdown docs → propose creating a `flow.json` that maps them as steps
-   - If it has a different workflow format → propose conversion
-   - If it's missing key parts → guide user to fill them in
-5. Create the missing `flow.json` manifest and step structure
-6. Retry `flow_add` with the fixed source
-
-### Native flow.json Format Reference
-```json
-{
-  "name": "my-flow",
-  "version": "1.0.0",
-  "description": "Description of the flow",
-  "steps": [
-    {
-      "id": "step-id",
-      "name": "Step Name",
-      "instruction": "steps/step-id/README.md",
-      "produces": ["output.md"],
-      "requires": [],
-      "agents": [],
-      "description": "What this step does"
-    }
-  ],
-  "agents": [],
-  "artifacts_dir": ".spec",
-  "install": []
-}
-```
-
-### Post-Install
-After successful installation:
-- Show the flow name, steps, and description via `present`
-- Remind user they can start it with `flow_start`

package/scaffold/claude-code/commands/aikit-flow-create.md

@@ -1,79 +0,0 @@
-# aikit flow-create
-
-> Create a new flow from scratch or migrate an existing workflow to aikit format
-
-## Flow Creation Assistant
-
-Create a new development flow or migrate an existing workflow to the aikit flow format.
-
-### Mode 1: Create from Scratch
-
-Guide the user through building a complete flow:
-
-1. **Define the workflow** — Ask what the flow should accomplish (e.g., "TDD workflow", "documentation pipeline", "migration process")
-2. **Design steps** — Break the workflow into sequential steps (3-8 is ideal)
-3. **For each step**:
-   - Define the step id, name, and description
-   - Write the instruction (README.md content — what the agent should do)
-   - Identify what it produces (output artifacts)
-   - Identify what it requires (which previous steps must complete first)
-   - Optionally assign preferred agents
-4. **Generate flow.json** — Create the manifest with all steps
-5. **Write step READMEs** — Create instruction files for each step
-6. **Install** — Use `flow_add` to install from the local directory
-
-### Mode 2: Migrate Existing Workflow
-
-If the user has an existing workflow (scripts, docs, runbooks) that they want to convert:
-
-1. **Analyze the source** — Read the existing workflow files to understand the process
-2. **Map to steps** — Identify discrete steps with clear inputs/outputs
-3. **Identify gaps** — What's missing for a complete flow? (instructions? ordering? agents?)
-4. **Fill gaps with user** — Ask user to clarify any ambiguous parts
-5. **Generate the flow** — Create flow.json + step READMEs
-6. **Install and validate** — Use `flow_add` and `flow_info` to verify
-
-### Flow Structure
-
-```
-my-flow/
-  flow.json              — Flow manifest (name, version, steps, agents)
-  steps/
-    step-1/
-      README.md          — Step instructions (what the agent should do)
-    step-2/
-      README.md
-      references/        — Optional reference files for the step
-    ...
-```
-
-### flow.json Format
-```json
-{
-  "name": "my-flow",
-  "version": "1.0.0",
-  "description": "What this flow does",
-  "steps": [
-    {
-      "id": "step-id",
-      "name": "Human-readable Step Name",
-      "instruction": "steps/step-id/README.md",
-      "produces": ["artifact-name.md"],
-      "requires": [],
-      "agents": ["Preferred-Agent"],
-      "description": "Brief description of this step"
-    }
-  ],
-  "agents": [],
-  "artifacts_dir": ".spec",
-  "install": []
-}
-```
-
-### Step README Format
-Each step README should include:
-- **Goal** — What this step accomplishes
-- **Inputs** — What context/artifacts from prior steps are needed
-- **Instructions** — Detailed steps for the agent to follow
-- **Output** — What artifact(s) to produce and where to save them
-- **Acceptance criteria** — How to know the step is complete

package/scaffold/claude-code/commands/aikit-flow-manage.md

@@ -1,23 +0,0 @@
-# aikit flow-manage
-
-> List, inspect, update, and remove installed flows
-
-## Flow Management
-
-Manage your installed development flows.
-
-### Available Actions
-
-1. **List flows** — `flow_list` to see all installed flows with status
-2. **Inspect a flow** — `flow_info` to see detailed steps, agents, and artifacts
-3. **Check status** — `flow_status` to see the active flow and current step
-4. **Update a flow** — `flow_update` to pull latest changes for git-installed flows
-5. **Remove a flow** — `flow_remove` to uninstall (builtin flows cannot be removed)
-6. **Start a flow** — `flow_start` to begin executing a flow
-7. **Reset active flow** — `flow_reset` to clear active flow state
-
-### Workflow
-1. If no specific action requested, start with `flow_list` and present overview
-2. Use `present` to display flow information in a clear table/card format
-3. For updates, warn if there's an active flow that might be affected
-4. For removals, confirm with user before proceeding

package/scaffold/claude-code/commands/aikit-implement.md

@@ -1,16 +0,0 @@
-# aikit implement
-
-> Full lifecycle implementation: plan → build → review → commit
-
-## Implementation Pipeline
-
-Follow the Orchestrator's full workflow:
-
-1. **Phase 0: Design Gate** — Orchestrator checks if design is needed. Creative/additive work triggers brainstorming first. Use `/design` if you want to start with design explicitly.
-2. **Phase 1: Planning** — Research, draft plan, present to user for approval
-3. **Phase 2: Implementation** — Execute phases in parallel batches
-4. **Phase 3: Completion** — Final review, docs, persist learnings
-
-**🛑 MANDATORY STOPS** — After plan, after each batch, after completion.
-
-Refer to the Orchestrator agent's full instructions for the detailed workflow.

package/scaffold/claude-code/commands/aikit-plan.md

@@ -1,14 +0,0 @@
-# aikit plan
-
-> Create a detailed TDD implementation plan without executing it
-
-## Planning Workflow
-
-1. **AI Kit Recall** — Search for past plans, architecture decisions
-2. **FORGE Ground** — Classify tier, scope map, seed unknowns
-3. **Research** — Explore codebase, understand subsystems
-4. **Draft Plan** — 3-10 phases with agent assignments, TDD steps
-5. **Dependency Graph** — Group into parallel batches
-6. **Present** — Show plan with open questions
-
-**🛑 MANDATORY STOP** — Wait for user approval. Do NOT implement.

package/scaffold/claude-code/commands/aikit-review.md

@@ -1,23 +0,0 @@
-# aikit review
-
-> Dual-model code + architecture review pipeline
-
-## Review Pipeline
-
-### Step 1: Scope
-Identify changed files and their blast radius.
-
-### Step 2: Code Review (parallel)
-Launch Code-Reviewer-Alpha and Code-Reviewer-Beta on the same changeset.
-
-### Step 3: Architecture Review (if needed)
-If changes cross service boundaries or modify interfaces, launch Architect-Reviewer-Alpha and Architect-Reviewer-Beta.
-
-### Step 4: Synthesis
-Merge findings from both reviewers:
-- **Agreements**: Both found same issue → HIGH confidence
-- **Unique findings**: One found, other didn't → verify
-- **Disagreements**: Contradicting verdicts → present both to user
-
-### Step 5: Report
-Present unified review with: verdict, findings by severity, recommended actions.