@wazir-dev/cli 1.0.0 → 1.2.0

package/skills/init-pipeline/SKILL.md

@@ -1,119 +1,117 @@
 ---
 name: wz:init-pipeline
-description: Initialize the Wazir pipeline with interactive setup. Creates project directories, selects mode, and configures the pipeline.
+description: Initialize the Wazir pipeline — zero-config by default, auto-detects host and project stack. No mandatory questions.
 ---
 
 # Initialize Pipeline
 
-Set up the Wazir pipeline for this project. All questions use numbered interactive options — one question at a time.
+Set up the Wazir pipeline for this project. **Zero-config by default** — everything is auto-detected and sensibly defaulted. No questions unless the user explicitly asks for interactive mode.
 
-## Step 0: Check Wazir CLI
+## Command Routing
+Follow the Canonical Command Matrix in `hooks/routing-matrix.json`.
+- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
+- Small commands (git status, ls, pwd, wazir CLI) → native Bash
+- If context-mode unavailable, fall back to native Bash with warning
+
+## Codebase Exploration
+1. Query `wazir index search-symbols <query>` first
+2. Use `wazir recall file <path> --tier L1` for targeted reads
+3. Fall back to direct file reads ONLY for files identified by index queries
+4. Maximum 10 direct file reads without a justifying index query
+5. If no index exists: `wazir index build && wazir index summarize --tier all`
+
+## Zero-Config Flow (Default)
+
+### Step 1: Check Wazir CLI
 
 Run `which wazir` to check if the CLI is installed.
 
 **If not installed**, present:
 
-> **The Wazir CLI is not installed. It's required for event capture, validation, and indexing.**
+> **The Wazir CLI is not installed. Install with:**
 >
-> **How would you like to install it?**
->
-> 1. **npm** (Recommended) — `npm install -g wazir`
+> 1. **npm** (Recommended) — `npm install -g @wazir-dev/cli`
 > 2. **Local link** — `npm link` from the Wazir project root
-> 3. **Skip** — Continue without the CLI (some features will be unavailable)
-
-If the user picks 1, run `npm install -g wazir` and verify with `wazir --version`.
-If the user picks 2, run `npm link` from the project root and verify.
-If the user picks 3, warn that `wazir capture`, `wazir validate`, and `wazir index` commands will not work, then continue.
 
-**If installed**, run `wazir doctor --json` to verify repo health and continue.
+### Step 2: Auto-Initialize
 
-## Step 1: Create Project Directories
+Run `wazir init` (default: auto mode). This automatically:
 
-```bash
-mkdir -p .wazir/input .wazir/state .wazir/runs
-```
+1. **Creates directories:** `.wazir/input/`, `.wazir/state/`, `.wazir/runs/`
+2. **Detects host:** Claude Code / Codex / Gemini / Cursor from environment variables and file markers
+3. **Detects project stack:** Language, framework, and stack from package files
+4. **Detects context-mode MCP:** Checks for core tools (`execute`, `fetch_and_index`, `search`)
+5. **Writes config** with sensible defaults:
+   - `model_mode: "claude-only"` (override: `wazir config set model_mode multi-model`)
+   - `default_depth: "standard"` (override per-run: `/wazir deep ...`)
+   - `default_intent: "feature"` (inferred per-run from request text)
+   - `team_mode: "sequential"` (always)
+6. **Auto-exports** for the detected host
 
-## Step 2: Choose Pipeline Mode
+**No questions asked.** The pipeline is ready to use immediately.
 
-Present this question:
+### Step 3: Confirm
 
-> **How should Wazir run in this project?**
+> **Wazir initialized.**
 >
-> 1. **Claude only** (Recommended) — Everything runs in Claude Code. Single model, slash commands only.
-> 2. **Multi-model** — Still Claude Code, but routes tasks by complexity (Haiku for micro, Sonnet for standard, Opus for complex).
-> 3. **Multi-tool** — Claude Code + external tools for reviews.
-
-Wait for the user to answer before continuing.
-
-## Step 3: If Multi-Tool, Choose Tools
-
-Only ask this if the user selected option 3:
-
-> **Which external tools should Wazir use for reviews?**
+> Host: [detected host] | Stack: [detected language/framework]
 >
-> 1. **Codex** — Send reviews to OpenAI Codex
-> 2. **Gemini** — Send reviews to Google Gemini
-> 3. **Both** — Use Codex and Gemini as secondary reviewers
-
-Wait for the user to answer before continuing.
+> Next: `/wazir <what you want to build>`
 
-## Step 4: Write Config
+---
 
-Create/update `.wazir/state/config.json`:
+## Interactive Flow (Power Users)
 
-- Set `model_mode` to the selected mode (`claude-only`, `multi-model`, or `multi-tool`)
-- If `multi-tool`, set `multi_tool.tools` to the selected tools (e.g. `["codex"]`, `["gemini"]`, or `["codex", "gemini"]`)
+Triggered by `wazir init --interactive`. For users who want manual control.
 
-Example for claude-only:
-```json
-{
-  "model_mode": "claude-only"
-}
-```
+### Pipeline Mode
 
-Example for multi-tool with codex:
-```json
-{
-  "model_mode": "multi-tool",
-  "multi_tool": {
-    "tools": ["codex"]
-  }
-}
-```
+> **How should Wazir run in this project?**
+>
+> 1. **Single model** (Recommended) — slash commands only
+> 2. **Multi-model** — routes sub-tasks to cheapest capable model (Haiku/Sonnet/Opus)
+> 3. **Multi-tool** — current model + external tools for reviews
 
-## Step 5: Runtime-Specific Setup
+**If multi-model selected:** The model router (`tooling/src/adapters/model-router.js`) assigns automatically:
+- **Haiku** for mechanical tasks (URL fetching, file ops, compression)
+- **Sonnet** for comprehension tasks (implementation, reviews, learning extraction)
+- **Opus** for judgment tasks (orchestration, design, spec hardening, final review)
 
-Based on `multi_tool.tools`:
+Override via `model_overrides` in config.
 
-- If **codex** is selected: Create `AGENTS.md` in project root:
-  ```
-  # Wazir Pipeline
+### External Tools (if multi-tool)
 
-  Agent protocols are at `~/.claude/agents/` (global).
+> **Which external tools for reviews?**
+>
+> 1. **Codex** (Recommended)
+> 2. **Gemini**
+> 3. **Both**
 
-  ## Running the Pipeline
-  1. Clarifier: read and follow `~/.claude/agents/clarifier.md` — tasks are in `.wazir/input/`
-  2. Orchestrator: read and follow `~/.claude/agents/orchestrator.md` — start from task 1
-  3. Opus Reviewer: read and follow `~/.claude/agents/opus-reviewer.md` — run all phases
+If Codex selected:
+> **Codex model?**
+>
+> 1. **gpt-5.3-codex-spark** (Recommended) — Fast review loops
+> 2. **gpt-5.4** — Deeper analysis
 
-  ## Review Mode
-  This project uses Codex as a secondary reviewer. Review artifacts are in `.wazir/reviews/`.
-  ```
+---
 
-- If **gemini** is selected: Create `GEMINI.md` in project root with the same content adapted for Gemini.
+## Install Paths
 
-- If **both**: Create both files.
+| Path | Command | Who |
+|------|---------|-----|
+| Plugin marketplace | `/plugin install wazir` | Claude Code users |
+| npx (zero install) | `npx @wazir-dev/cli` | Any Node project |
+| Global install | `npm i -g @wazir-dev/cli` | Power users |
+| Clone + link | `git clone && npm link` | Contributors |
 
-## Step 6: Confirm
+## Deep When You Need It
 
-List all files created and show the selected mode. Then present:
+- `wazir config set <key> <value>` — override any default
+- `wazir doctor` — see what's configured
+- `wazir stats` — see what Wazir saved you
+- `wazir init --interactive` — full manual setup
 
-> **Pipeline initialized. You can now use:**
->
-> - `/wazir <your request>` — Run the full pipeline end-to-end
-> - `/clarifier` — Run Phase 0 + Phase 1 only (research, clarify, plan)
-> - `/executor` — Run Phase 2 only (autonomous execution)
-> - `/reviewer` — Run Phase 3 only (final review and scoring)
+**Principle:** Like git — `git init` is one command, `git config` is deep. Instant start, deep when you need it.
 
 ## Interaction Rules
 

package/skills/prepare-next/SKILL.md

@@ -5,16 +5,87 @@ description: Use after a run or execution slice completes to produce a clean nex
 
 # Prepare Next
 
-Create a next-run handoff that captures:
+## Model Annotation
+When multi-model mode is enabled:
+- **Haiku** for file operations (write-handoff, compress-archive)
+- **Sonnet** for learning extraction (extract-learnings)
 
-- current status
-- completed work
-- unresolved blockers
-- required approvals
-- explicitly accepted learnings only
+## Command Routing
+Follow the Canonical Command Matrix in `hooks/routing-matrix.json`.
+- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
+- Small commands (git status, ls, pwd, wazir CLI) → native Bash
+- If context-mode unavailable, fall back to native Bash with warning
 
-Rules:
+## Codebase Exploration
+1. Query `wazir index search-symbols <query>` first
+2. Use `wazir recall file <path> --tier L1` for targeted reads
+3. Fall back to direct file reads ONLY for files identified by index queries
+4. Maximum 10 direct file reads without a justifying index query
+5. If no index exists: `wazir index build && wazir index summarize --tier all`
 
-- do not mutate `input/`
-- do not auto-load proposed or unreviewed learnings into the next run
-- write the handoff using the `templates/artifacts/next-run-handoff.md` structure
+Create a next-run handoff that captures the run outcome and sets up the next session.
+
+## When to Run
+
+One of:
+
+1. **Full completion** — All 4 phases are done, review is accepted, learnings are proposed. Prepare the next feature's starting point.
+2. **Partial completion** — The session is ending before the pipeline finishes. Prepare a mid-pipeline handoff so the next session can resume.
+3. **Slice boundary** — The approved plan is being executed in multiple slices. Prepare the handoff between slices.
+
+## Step 1: Gather Run State
+
+Read from the current run directory:
+
+- `run-config.yaml` — run identity, intent, depth
+- `reviews/review.md` — final review verdict and score (if complete)
+- `reviews/` — all review pass logs
+- `artifacts/` — task completion evidence
+- `clarified/` — spec, design, plan artifacts
+- Git log since branch creation: `git log --oneline main..HEAD`
+
+## Step 2: Write Handoff
+
+Write to `.wazir/runs/<run-id>/handoff.md` using this structure:
+
+```markdown
+# Handoff — <run-id>
+
+**Status:** [Completed | Partial | Slice N of M]
+**Branch:** <branch-name>
+**Date:** YYYY-MM-DD
+
+## What Was Done
+[List of completed tasks with commit hashes]
+
+## Commits
+[git log --oneline of all commits in this run]
+
+## Test Results
+[Test count, pass/fail, validator status]
+
+## Review Score
+[Verdict, score, key findings if applicable]
+
+## What's Next
+[Pending items, deferred work, follow-up tasks]
+
+## Open Bugs
+[Any known issues discovered during this run]
+
+## Learnings From This Run
+[Key insights — what worked, what didn't]
+```
+
+## Step 3: Run Summary
+
+```bash
+wazir capture summary --run <run-id>
+```
+
+## Rules
+
+- Do NOT mutate `input/` — it belongs to the user
+- Do NOT auto-load proposed or unreviewed learnings into the next run
+- Do NOT carry forward stale context — each new run reads fresh state
+- Do NOT compress or delete files the user might need — only archive verbose intermediate logs

package/skills/receiving-code-review/SKILL.md

@@ -5,12 +5,33 @@ description: Use when receiving code review feedback, before implementing sugges
 
 # Code Review Reception
 
+## Command Routing
+Follow the Canonical Command Matrix in `hooks/routing-matrix.json`.
+- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
+- Small commands (git status, ls, pwd, wazir CLI) → native Bash
+- If context-mode unavailable, fall back to native Bash with warning
+
+## Codebase Exploration
+1. Query `wazir index search-symbols <query>` first
+2. Use `wazir recall file <path> --tier L1` for targeted reads
+3. Fall back to direct file reads ONLY for files identified by index queries
+4. Maximum 10 direct file reads without a justifying index query
+5. If no index exists: `wazir index build && wazir index summarize --tier all`
+
 ## Overview
 
 Code review requires technical evaluation, not emotional performance.
 
 **Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
 
+## Loop Tracking
+
+When receiving review findings, the fix-and-re-review cycle follows the review loop pattern:
+- **Pipeline mode** (`.wazir/runs/latest/` exists): track iterations via `wazir capture loop-check`. If the cap is reached (exit 43), escalate to the user with current state and evidence.
+- **Standalone mode** (no `.wazir/runs/latest/`): the loop runs for `pass_counts[depth]` passes (quick=3, standard=5, deep=7) with no cap guard. Track iteration count manually.
+
+Reference `docs/reference/review-loop-pattern.md` for the full loop contract.
+
 ## The Response Pattern
 
 ```

package/skills/requesting-code-review/SKILL.md

@@ -5,9 +5,22 @@ description: Use when completing tasks, implementing major features, or before m
 
 # Requesting Code Review
 
+## Command Routing
+Follow the Canonical Command Matrix in `hooks/routing-matrix.json`.
+- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
+- Small commands (git status, ls, pwd, wazir CLI) → native Bash
+- If context-mode unavailable, fall back to native Bash with warning
+
+## Codebase Exploration
+1. Query `wazir index search-symbols <query>` first
+2. Use `wazir recall file <path> --tier L1` for targeted reads
+3. Fall back to direct file reads ONLY for files identified by index queries
+4. Maximum 10 direct file reads without a justifying index query
+5. If no index exists: `wazir index build && wazir index summarize --tier all`
+
 Dispatch wz:code-reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
 
-**Core principle:** Review early, review often.
+**Core principle:** Review early, review often. Review follows the loop pattern in `docs/reference/review-loop-pattern.md`. Dispatch the reviewer with explicit `--mode` and depth-aware loop parameters.
 
 ## When to Request Review
 
@@ -23,22 +36,36 @@ Dispatch wz:code-reviewer subagent to catch issues before they cascade. The revi
 
 ## How to Request
 
-**1. Get git SHAs:**
+**1. Get git SHAs and scope the review:**
+
+Use `--uncommitted` for uncommitted changes, `--base <sha>` for committed changes.
+
 ```bash
+# For committed changes:
 BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
 HEAD_SHA=$(git rev-parse HEAD)
+codex review --base $BASE_SHA
+
+# For uncommitted changes:
+codex review --uncommitted
 ```
 
-**2. Dispatch code-reviewer subagent:**
+**2. Dispatch code-reviewer subagent with loop config:**
 
 Use Task tool with wz:code-reviewer type, fill template at `./code-reviewer.md`
 
+Include explicit loop parameters:
+- `--mode` (e.g., `task-review`, `final`)
+- Depth-aware dimensions and cap from `phase_policy`
+- Review pass number (for log filenames)
+
 **Placeholders:**
 - `{WHAT_WAS_IMPLEMENTED}` - What you just built
 - `{PLAN_OR_REQUIREMENTS}` - What it should do
 - `{BASE_SHA}` - Starting commit
 - `{HEAD_SHA}` - Ending commit
 - `{DESCRIPTION}` - Brief summary
+- `{REVIEW_MODE}` - Explicit review mode (e.g., task-review)
 
 **3. Act on feedback:**
 - Fix Critical issues immediately
@@ -46,6 +73,10 @@ Use Task tool with wz:code-reviewer type, fill template at `./code-reviewer.md`
 - Note Minor issues for later
 - Push back if reviewer is wrong (with reasoning)
 
+### Codex Error Handling
+
+If codex exits non-zero during review, log the error, mark the pass as codex-unavailable, and use self-review findings only. Do not treat a Codex failure as a clean pass.
+
 ## Example
 
 ```
@@ -56,12 +87,13 @@ You: Let me request code review before proceeding.
 BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
 HEAD_SHA=$(git rev-parse HEAD)
 
-[Dispatch wz:code-reviewer subagent]
+[Dispatch wz:code-reviewer subagent with --mode task-review]
   WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
   PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
   BASE_SHA: a7981ec
   HEAD_SHA: 3df7661
   DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
+  REVIEW_MODE: task-review
 
 [Subagent returns]:
   Strengths: Clean architecture, real tests
@@ -82,7 +114,7 @@ You: [Fix progress indicators]
 - Fix before moving to next task
 
 **Executing Plans:**
-- Review after each batch (3 tasks)
+- Review after each task (per-task review checkpoint)
 - Get feedback, apply, continue
 
 **Ad-Hoc Development:**
@@ -96,6 +128,7 @@ You: [Fix progress indicators]
 - Ignore Critical issues
 - Proceed with unfixed Important issues
 - Argue with valid technical feedback
+- Dispatch review without explicit `--mode`
 
 **If reviewer wrong:**
 - Push back with technical reasoning