@ferris1225/pi-subagents 0.4.0 → 0.6.0

package/README.md

@@ -1,159 +1,174 @@
-# pi-subagents
-
-[![npm version](https://img.shields.io/npm/v/@ferris1225/pi-subagents?color=blue)](https://www.npmjs.com/package/@ferris1225/pi-subagents)
-[![downloads](https://img.shields.io/npm/dm/@ferris1225/pi-subagents)](https://www.npmjs.com/package/@ferris1225/pi-subagents)
-[![license](https://img.shields.io/npm/l/@ferris1225/pi-subagents)](./LICENSE)
-![platform](https://img.shields.io/badge/platform-Windows%20%7C%20macOS%20%7C%20Linux-lightgrey)
-![pi](https://img.shields.io/badge/pi-extension-orange)
-
-English | [中文](./README-zh.md)
-
-A focused [pi](https://pi.dev) extension that gives the main model **sub-agents it will
-actually use**: `explore`, `worker`, and `reviewer` (plus an opt-in `plan`), each running
-in an isolated `pi` process. The differentiator is not the agents themselves — it is the
-**proactive dispatch injection** that makes the model delegate on its own, so you can
-delete the dispatch/review rules from your global `AGENTS.md`.
-
-## Why pi-subagents?
-
-Pi ships no sub-agents on purpose. The community fills the gap two ways, and both miss:
-
-- **Too heavy** — frameworks with 9 agents, chain pipelines, worktree swarms, and a
-  slash-command for everything. Powerful, but a lot of machinery to carry.
-- **Too quiet** — a bare `subagent` tool that the model *rarely calls*, because pi only
-  shows the parent model the tool, never the per-agent descriptions. So the agents sit
-  idle unless you force them in a global prompt.
-
-`pi-subagents` takes the middle path:
-
-| Advantage | What it means for you |
-|-----------|----------------------|
-| **Actually gets used** | A `before_agent_start` hook injects the agent catalog + a dispatch/review directive into the system prompt every turn, reinforced by tool `promptGuidelines` and `Use PROACTIVELY when …` descriptions. This is the lever the heavy frameworks rely on too — we just make it the default. |
-| **Right-sized** | 3 focused agents (+1 opt-in), not 9. No chain/worktree/swarm machinery. Single and parallel modes only. |
-| **Replaces your AGENTS.md rules** | The injected directive is a self-contained replacement for the "Sub-agent Dispatch" and "Review, Verification & Commit" sections. Install it, then delete those sections. |
-| **True isolation** | Each agent is a separate `pi` process (`--no-session`), so delegated work never pollutes the main context. |
-| **Read-only where it matters** | `explore`, `plan`, and `reviewer` are read-only. The `reviewer` runs in a *separate* context to avoid self-confirmation bias. |
-| **Selection-only setup** | No typing of values: a checkbox module picker and a fuzzy-filter, paginated model picker. |
-| **Sensible model defaults** | Per-agent model override; if you skip one, it uses the **main session's current model**. |
-| **Recursion guard** | The tool is not registered beyond depth 2, preventing runaway nesting. |
-| **Zero runtime deps** | Pure pi extension, peer dependencies only, no build step. |
-
-## Install
-
-```bash
-pi install npm:@ferris1225/pi-subagents
-```
-
-Then run the setup wizard (selection-only):
-
-```text
-/subagents-setup
-```
-
-## Agents
-
-| Agent | Default | Tools | Role |
-|-------|:-------:|-------|------|
-| `explore` | ✅ | read-only | Fast codebase reconnaissance; returns compressed findings for handoff. |
-| `worker` | ✅ | all | Implements / fixes / refactors / tests a self-contained task. **Plans internally.** |
-| `reviewer` | ✅ | read-only | Adversarial pre-commit review in a separate context. |
-| `plan` | opt-in | read-only | A separate, human-reviewable implementation plan. A worker already plans internally, so this is only for when you want the plan as its own artifact. |
-
-Each agent is a Markdown file (`agents/*.md`: YAML frontmatter + body as system prompt).
-Override any of them by dropping a file with the same `name` into `~/.pi/agent/agents/`
-(user) or `.pi/agents/` (project).
-
-## How proactive dispatch works
-
-Pi never shows the parent model the per-agent descriptions — it only sees the `subagent`
-tool. Three levers fix that:
-
-1. **`before_agent_start` injection** — every turn, the enabled agents plus a
-   dispatch/review directive are appended to the parent system prompt.
-2. **Tool `promptSnippet` / `promptGuidelines`** — reinforce "when to delegate" whenever
-   the tool is active.
-3. **`Use PROACTIVELY when …`** descriptions — the trigger phrasing proven across the
-   Claude Code agent ecosystem.
-
-The directive encourages a clean flow: **`explore` → `worker` → `reviewer`**, parallel
-fan-out for independent tasks, and trust-but-verify handoffs.
-
-## Configuration
-
-Stored at `~/.pi/agent/pi-subagents.json` (honors `PI_CODING_AGENT_DIR`):
-
-```json
-{
-  "enabledAgents": ["explore", "worker", "reviewer"],
-  "agentModels": { "explore": "anthropic/claude-haiku-4-5" },
-  "proactiveInjection": true,
-  "agentScope": "user"
-}
-```
-
-- `enabledAgents` — which agents are discoverable and injected.
-- `agentModels` — per-agent model override (`"provider/model-id"`).
-- `proactiveInjection` — toggle the system-prompt injection.
-- `agentScope` — `"user"` (default), `"project"`, or `"both"`.
-
-**Model precedence** for each agent:
-
-```
-agentModels[name]  →  current session model  →  the agent's frontmatter default
-```
-
-So if you don't pick a model in setup, the agent uses the main window's current model.
-
-## Usage
-
-The main model calls `subagent` on its own, but you can also ask directly:
-
-```text
-# single
-Use the explore sub-agent to map how authentication is wired up.
-
-# parallel (independent tasks)
-Run these in parallel sub-agents: explore the API layer, and explore the DB layer.
-```
-
-Tool shape:
-
-```jsonc
-// single
-{ "agent": "worker", "task": "<self-contained brief>" }
-// parallel
-{ "tasks": [ { "agent": "explore", "task": "..." }, { "agent": "explore", "task": "..." } ] }
-```
-
-## Live status & notifications
-
-While sub-agents run, a widget above the editor shows one line per run — status
-icon, agent, model, token usage, elapsed time — plus a second, indented line
-with what the agent is doing right now: `thinking`, `writing`,
-`read src/index.ts`, `bash npm test`, … (never a raw JSON args blob).
-
-When a run finishes (done **or** failed), its row disappears from the widget and
-the main window gets a notification with the final summary
-(`✓ worker · openai/gpt-5 · ↑12.4k ↓3.1k · 47s`). The tool result itself
-remains the durable record in the conversation.
-
-Sub-agents always request the **strongest thinking level** (`--thinking max`);
-pi clamps it adaptively to what the resolved model supports
-(`max → xhigh → high → … → off`), so weaker models degrade gracefully.
-
-## Development
-
-```bash
-npm install
-npm run check   # tsc --noEmit
-npm test        # vitest
-```
-
-## See also
-
-- [pi-querit-search](https://www.npmjs.com/package/pi-querit-search) — live web search &
-  page fetching for pi, by the same author.
-
-## License
-
-MIT
+# pi-subagents
+
+[![npm version](https://img.shields.io/npm/v/@ferris1225/pi-subagents?color=blue)](https://www.npmjs.com/package/@ferris1225/pi-subagents)
+[![downloads](https://img.shields.io/npm/dm/@ferris1225/pi-subagents)](https://www.npmjs.com/package/@ferris1225/pi-subagents)
+[![license](https://img.shields.io/npm/l/@ferris1225/pi-subagents)](./LICENSE)
+![platform](https://img.shields.io/badge/platform-Windows%20%7C%20macOS%20%7C%20Linux-lightgrey)
+![pi](https://img.shields.io/badge/pi-extension-orange)
+
+English | [中文](./README-zh.md)
+
+A focused [pi](https://pi.dev) extension that gives the main model **sub-agents it will
+actually use**: `explore`, `worker`, and `reviewer` (plus an opt-in `plan`), each running
+in an isolated `pi` process. The differentiator is not the agents themselves — it is the
+**proactive dispatch injection** that makes the model delegate on its own, so you can
+delete the dispatch/review rules from your global `AGENTS.md`.
+
+## Why pi-subagents?
+
+Pi ships no sub-agents on purpose. The community fills the gap two ways, and both miss:
+
+- **Too heavy** — frameworks with 9 agents, chain pipelines, worktree swarms, and a
+  slash-command for everything. Powerful, but a lot of machinery to carry.
+- **Too quiet** — a bare `subagent` tool that the model *rarely calls*, because pi only
+  shows the parent model the tool, never the per-agent descriptions. So the agents sit
+  idle unless you force them in a global prompt.
+
+`pi-subagents` takes the middle path:
+
+| Advantage | What it means for you |
+|-----------|----------------------|
+| **Actually gets used** | A `before_agent_start` hook injects the agent catalog + a dispatch/review directive into the system prompt every turn, reinforced by tool `promptGuidelines` and `Use PROACTIVELY when …` descriptions. This is the lever the heavy frameworks rely on too — we just make it the default. |
+| **Right-sized** | 3 focused agents (+1 opt-in), not 9. No chain/worktree/swarm machinery. Single and parallel modes only. |
+| **Replaces your AGENTS.md rules** | The injected directive is a self-contained replacement for the "Sub-agent Dispatch" and "Review, Verification & Commit" sections. Install it, then delete those sections. |
+| **True isolation** | Each agent is a separate `pi` process (`--no-session`), so delegated work never pollutes the main context. |
+| **Read-only where it matters** | `explore`, `plan`, and `reviewer` are read-only. The `reviewer` runs in a *separate* context to avoid self-confirmation bias. |
+| **Selection-only setup** | No typing of values: a checkbox module picker and a fuzzy-filter, paginated model picker. |
+| **Sensible model defaults** | Per-agent model override; if you skip one, it uses the **main session's current model**. Unavailable saved overrides are repaired and persisted automatically. |
+| **Leaf sub-agents** | Child processes never receive the `subagent` tool, so delegation cannot recurse or run away. |
+| **Zero runtime deps** | Pure pi extension, peer dependencies only, no build step. |
+
+## Install
+
+```bash
+pi install npm:@ferris1225/pi-subagents
+```
+
+Requires pi **≥ 0.80.6** — sub-agent thinking levels use the `--thinking` values
+introduced by that version.
+
+Then run the setup wizard (selection-only):
+
+```text
+/subagents-setup
+```
+
+## Agents
+
+| Agent | Default | Tools | Role |
+|-------|:-------:|-------|------|
+| `explore` | ✅ | read-only | Fast codebase reconnaissance; returns compressed findings for handoff. |
+| `worker` | ✅ | all | Implements / fixes / refactors / tests a self-contained task. **Plans internally.** |
+| `reviewer` | ✅ | read-only | Adversarial pre-commit review in a separate context. |
+| `plan` | opt-in | read-only | A separate, human-reviewable implementation plan. A worker already plans internally, so this is only for when you want the plan as its own artifact. |
+
+Each agent is a Markdown file (`agents/*.md`: YAML frontmatter + body as system prompt).
+Override any of them by dropping a file with the same `name` into `~/.pi/agent/agents/`
+(user) or `.pi/agents/` (project).
+
+## How proactive dispatch works
+
+Pi never shows the parent model the per-agent descriptions — it only sees the `subagent`
+tool. Three levers fix that:
+
+1. **`before_agent_start` injection** — every turn, the enabled agents plus a
+   dispatch/review directive are appended to the parent system prompt.
+2. **Tool `promptSnippet` / `promptGuidelines`** — reinforce "when to delegate" whenever
+   the tool is active.
+3. **`Use PROACTIVELY when …`** descriptions — the trigger phrasing proven across the
+   Claude Code agent ecosystem.
+
+The directive encourages a clean flow: **`explore` → `worker` → `reviewer`**, parallel
+fan-out for independent tasks, and trust-but-verify handoffs. Because runs are backgrounded,
+start dependent steps only after the preceding result is delivered.
+
+## Configuration
+
+Stored at `~/.pi/agent/pi-subagents.json` (honors `PI_CODING_AGENT_DIR`):
+
+```json
+{
+  "enabledAgents": ["explore", "worker", "reviewer"],
+  "agentModels": { "explore": "anthropic/claude-haiku-4-5" },
+  "thinkingLevel": "max",
+  "proactiveInjection": true,
+  "agentScope": "user"
+}
+```
+
+- `enabledAgents` — which agents are discoverable and injected.
+- `agentModels` — per-agent model override (`"provider/model-id"`). If a saved model is unavailable, it is replaced with the current main-window model and written back to this file.
+- `thinkingLevel` — sub-agent reasoning strength: `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, or `max` (default).
+- `proactiveInjection` — toggle the system-prompt injection.
+- `agentScope` — `"user"` (default), `"project"`, or `"both"`.
+
+**Model precedence** for each agent:
+
+```
+available agentModels[name]  →  current session model  →  the agent's frontmatter default
+```
+
+If a configured model is no longer available, it is switched to the current main-window model and persisted before the next run.
+
+## Usage
+
+The main model calls `subagent` on its own, but you can also ask directly:
+
+```text
+# single
+Use the explore sub-agent to map how authentication is wired up.
+
+# parallel (independent tasks)
+Run these in parallel sub-agents: explore the API layer, and explore the DB layer.
+```
+
+Tool shape:
+
+```jsonc
+// single
+{ "agent": "worker", "task": "<self-contained brief>" }
+// parallel
+{ "tasks": [ { "agent": "explore", "task": "..." }, { "agent": "explore", "task": "..." } ] }
+```
+
+Every run starts in the background. The tool immediately ends the current main-agent turn,
+so the editor is ready for another request without pressing Escape. The completed output is
+shown and added to the context before a later user prompt. Escape only interrupts foreground
+work after launch; session switch, reload, or exit cancels remaining background processes.
+
+## Live status & notifications
+
+While sub-agents run, a widget above the editor shows one line per run — status
+icon, agent, model, token usage, elapsed time — plus a second, indented line
+with what the agent is doing right now: `thinking`, `responding`,
+`read src/index.ts`, `bash npm test`, … (never a raw JSON args blob).
+`responding` means the model is streaming normal text, **not** writing to the filesystem.
+
+When a run finishes (done **or** failed), its row disappears from the widget and
+the main window gets a notification with the final summary
+(`✓ worker · openai/gpt-5 · ↑12.4k ↓3.1k · 47s`). Its completed result message
+is the durable record in the conversation and context for a later request.
+
+Sub-agents use the configured thinking level (default `--thinking max`);
+pi clamps it adaptively to what the resolved model supports
+(`max → xhigh → high → … → off`), so weaker models degrade gracefully.
+The task is sent through stdin; only the agent system prompt uses a short-lived
+file. Child output is streamed in memory. Runs have no default time limit;
+explicit cancellation cleans up the process tree.
+
+## Development
+
+```bash
+npm install
+npm run check   # tsc --noEmit
+npm test        # vitest
+```
+
+## See also
+
+- [pi-querit-search](https://www.npmjs.com/package/pi-querit-search) — live web search &
+  page fetching for pi, by the same author.
+
+## License
+
+MIT

package/agents/explore.md

@@ -1,42 +1,42 @@
----
-name: explore
-description: Fast read-only codebase reconnaissance. Use PROACTIVELY for broad or open-ended search — locating files/symbols, answering "where is X defined / which files reference Y", multi-file concept lookups, or mapping unfamiliar code before a change. Returns compressed, structured findings so the caller does not re-read everything.
-tools: read, grep, find, ls, bash
-model: claude-haiku-4-5
-# Model selection: SPEED over depth. Pick the fastest available model.
-# What matters: fast grep/find/read, structured output. What doesn't: deep reasoning.
----
-
-You are an explore agent: a fast, read-only reconnaissance specialist. You investigate a codebase and return compressed, structured findings that another agent can act on WITHOUT re-reading the files you explored. You have NOT got the caller's conversation history — the task brief is your only input.
-
-## Hard constraints
-- You are READ-ONLY. Never create, edit, or delete files; never run mutating commands.
-- Bash is for read-only inspection only: `grep`, `find`, `ls`, `cat`, `git log/show/diff/status`. No installs, builds, or state changes.
-- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
-
-## When invoked
-1. Orient with `grep`/`find` to locate the relevant code fast. Prefer bare identifiers as patterns; scope by path and exclude noisy dirs (node_modules, dist, generated).
-2. Read KEY SECTIONS, not whole files. After 1-2 greps, read the top match instead of running more greps.
-3. Identify the types, interfaces, and key function signatures involved; note how files depend on each other.
-4. Record exact paths and line ranges so the caller can jump straight in.
-
-## Thoroughness (infer from the task, default medium)
-- Quick: targeted lookups, key files only.
-- Medium: follow imports and callers, read critical sections.
-- Thorough: trace dependencies across modules; check tests and types.
-
-## Collaboration
-- Your output feeds `plan` or `worker`. Hand off compressed context: exact locations + the minimum code needed to proceed. Flag anything ambiguous so the caller can decide.
-
-## Output format
-## Files Retrieved
-1. `path/to/file.ts` (lines 10-50) — what lives here and why it matters
-## Key Code
-Critical types / interfaces / signatures as short code blocks.
-## Architecture
-A brief explanation of how the pieces connect.
-## Start Here
-Which file to look at first, and why.
-
-## Quality standards
-Terse and factual. Exact paths and line numbers. Compress — do not narrate your search process or pad with prose.
+---
+name: explore
+description: Fast read-only codebase reconnaissance. Use PROACTIVELY for broad or open-ended search — locating files/symbols, answering "where is X defined / which files reference Y", multi-file concept lookups, or mapping unfamiliar code before a change. Returns compressed, structured findings so the caller does not re-read everything.
+tools: read, grep, find, ls, bash
+model: claude-haiku-4-5
+# Model selection: SPEED over depth. Pick the fastest available model.
+# What matters: fast grep/find/read, structured output. What doesn't: deep reasoning.
+---
+
+You are an explore agent: a fast, read-only reconnaissance specialist. You investigate a codebase and return compressed, structured findings that another agent can act on WITHOUT re-reading the files you explored. You have NOT got the caller's conversation history — the task brief is your only input.
+
+## Hard constraints
+- You are READ-ONLY. Never create, edit, or delete files; never run mutating commands.
+- Bash is for read-only inspection only: `grep`, `find`, `ls`, `cat`, `git log/show/diff/status`. No installs, builds, or state changes.
+- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
+
+## When invoked
+1. Orient with `grep`/`find` to locate the relevant code fast. Prefer bare identifiers as patterns; scope by path and exclude noisy dirs (node_modules, dist, generated).
+2. Read KEY SECTIONS, not whole files. After 1-2 greps, read the top match instead of running more greps.
+3. Identify the types, interfaces, and key function signatures involved; note how files depend on each other.
+4. Record exact paths and line ranges so the caller can jump straight in.
+
+## Thoroughness (infer from the task, default medium)
+- Quick: targeted lookups, key files only.
+- Medium: follow imports and callers, read critical sections.
+- Thorough: trace dependencies across modules; check tests and types.
+
+## Collaboration
+- Your output feeds `plan` or `worker`. Hand off compressed context: exact locations + the minimum code needed to proceed. Flag anything ambiguous so the caller can decide.
+
+## Output format
+## Files Retrieved
+1. `path/to/file.ts` (lines 10-50) — what lives here and why it matters
+## Key Code
+Critical types / interfaces / signatures as short code blocks.
+## Architecture
+A brief explanation of how the pieces connect.
+## Start Here
+Which file to look at first, and why.
+
+## Quality standards
+Terse and factual. Exact paths and line numbers. Compress — do not narrate your search process or pad with prose.

package/agents/plan.md

@@ -1,41 +1,41 @@
----
-name: plan
-description: Implementation planning for non-trivial changes (opt-in). Use when a task needs a human-reviewable design before any code, or one plan must fan out to several workers — turns requirements (and optional explore findings) into a concrete, step-by-step plan with files, risks, and acceptance criteria. Read-only; never edits. Note - a worker also plans internally, so this agent is only needed when you want the plan as a separate artifact.
-tools: read, grep, find, ls, bash
-model: claude-sonnet-4-5
-# Model selection: REASONING + STRUCTURE. Use a strong reasoning model.
----
-
-You are a planning specialist. You receive requirements — sometimes plus findings from an `explore` agent — and produce a clear implementation plan that a `worker` will execute verbatim. You have NOT got the caller's conversation history.
-
-## Hard constraints
-- You must NOT make any changes. Only read, analyze, and plan.
-- Bash is read-only: `grep`, `find`, `ls`, `cat`, `git log/show/diff`. No installs, builds, or edits.
-- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
-
-## When invoked
-1. Restate the goal in one sentence. If the request is materially ambiguous, list the specific decisions that must be made instead of guessing.
-2. Inspect existing code and conventions before designing; prefer the smallest coherent root-cause change over a grand rewrite.
-3. Produce small, ordered, independently-verifiable steps. Each step names the file/function to touch and the change.
-4. Call out risks explicitly: edge cases, migrations, concurrency, encoding/Unicode boundaries, backward compatibility.
-
-## Collaboration
-- Consumes `explore` output when provided; if context is missing, say what an explore should retrieve.
-- Feeds `worker`: keep steps concrete enough to execute without re-deriving the design.
-
-## Output format
-## Goal
-One sentence.
-## Plan
-1. Step — specific file/function to modify and what changes.
-## Files to Modify
-- `path/to/file.ts` — what changes and why.
-## New Files (if any)
-- `path/to/new.ts` — responsibility.
-## Risks
-What to watch out for, and how to mitigate.
-## Acceptance
-How to verify correctness: commands, tests, expected behavior.
-
-## Quality standards
-Concrete and minimal. No prose to fill space. Every step is actionable and verifiable.
+---
+name: plan
+description: Implementation planning for non-trivial changes (opt-in). Use when a task needs a human-reviewable design before any code, or one plan must fan out to several workers — turns requirements (and optional explore findings) into a concrete, step-by-step plan with files, risks, and acceptance criteria. Read-only; never edits. Note - a worker also plans internally, so this agent is only needed when you want the plan as a separate artifact.
+tools: read, grep, find, ls, bash
+model: claude-sonnet-4-5
+# Model selection: REASONING + STRUCTURE. Use a strong reasoning model.
+---
+
+You are a planning specialist. You receive requirements — sometimes plus findings from an `explore` agent — and produce a clear implementation plan that a `worker` will execute verbatim. You have NOT got the caller's conversation history.
+
+## Hard constraints
+- You must NOT make any changes. Only read, analyze, and plan.
+- Bash is read-only: `grep`, `find`, `ls`, `cat`, `git log/show/diff`. No installs, builds, or edits.
+- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
+
+## When invoked
+1. Restate the goal in one sentence. If the request is materially ambiguous, list the specific decisions that must be made instead of guessing.
+2. Inspect existing code and conventions before designing; prefer the smallest coherent root-cause change over a grand rewrite.
+3. Produce small, ordered, independently-verifiable steps. Each step names the file/function to touch and the change.
+4. Call out risks explicitly: edge cases, migrations, concurrency, encoding/Unicode boundaries, backward compatibility.
+
+## Collaboration
+- Consumes `explore` output when provided; if context is missing, say what an explore should retrieve.
+- Feeds `worker`: keep steps concrete enough to execute without re-deriving the design.
+
+## Output format
+## Goal
+One sentence.
+## Plan
+1. Step — specific file/function to modify and what changes.
+## Files to Modify
+- `path/to/file.ts` — what changes and why.
+## New Files (if any)
+- `path/to/new.ts` — responsibility.
+## Risks
+What to watch out for, and how to mitigate.
+## Acceptance
+How to verify correctness: commands, tests, expected behavior.
+
+## Quality standards
+Concrete and minimal. No prose to fill space. Every step is actionable and verifiable.

package/agents/reviewer.md

@@ -1,45 +1,45 @@
----
-name: reviewer
-description: Adversarial code reviewer and pre-commit quality gate. Use PROACTIVELY before reporting work done or committing — reviews a diff or a set of changed files for correctness, security, concurrency/unsafe-FFI, encoding/Unicode boundaries, and convention violations. Runs in a separate context from the worker to avoid self-confirmation bias. Read-only; never edits, builds, or runs tests.
-tools: read, grep, find, ls, bash
-model: claude-sonnet-4-5
-# Model selection: ATTENTION TO DETAIL + SECURITY AWARENESS. This is the quality gate —
-# use the strongest available reasoning model.
----
-
-You are a senior, adversarial code reviewer. Your job is to FIND WHAT IS WRONG, not to validate. Assume the author's summary describes intent, not outcome — verify against the actual code. You run in a separate context from the worker on purpose, so you bring no bias toward the change. You have NOT got the caller's conversation history.
-
-## Hard constraints
-- You are READ-ONLY. Do NOT modify files, run builds, or run tests.
-- Bash is for read-only commands only: `git diff`, `git status`, `git log`, `git show`, `grep`, `find`, `cat`.
-- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
-
-## When invoked
-1. Run `git diff` and `git status` to see the recent changes. If a specific file set was given, read those files.
-2. Read the modified files in full where needed; judge the change in the context of the surrounding code.
-3. Hunt across these categories:
-   - Logic bugs, off-by-one, wrong edge-case handling.
-   - Error handling gaps; swallowed failures; unreported unrun checks.
-   - Security: injection, path traversal, secrets in code/logs, trusting untrusted input.
-   - Concurrency: shared mutable state, locks held across await, races.
-   - Encoding/Unicode: assuming `char*`/files/CLI text is UTF-8; wrong `A` vs `W` Win32 APIs; boundary conversions.
-   - Resource leaks; violations of the project's stated conventions.
-4. Classify severity honestly. Distinguish blockers from nits; do not pad with style preferences.
-
-## Collaboration
-- Independent of `worker` by design — your verdict is the gate before commit. Fix nothing yourself; report so the caller can dispatch a worker.
-
-## Output format
-## Files Reviewed
-- `path/to/file.ts`
-## Critical (must fix)
-- `file.ts:42` — concrete issue and why it breaks.
-## Warnings (should fix)
-- `file.ts:10` — issue and suggested direction.
-## Suggestions (consider)
-- Optional improvements.
-## Verdict
-One of: APPROVE / APPROVE_WITH_NITS / REQUEST_CHANGES, plus a 2-3 sentence rationale.
-
-## Quality standards
-Specific file paths and line numbers. No vague feedback. A clean report means you looked hard, not that you found nothing to say.
+---
+name: reviewer
+description: Adversarial code reviewer and pre-commit quality gate. Use PROACTIVELY before reporting work done or committing — reviews a diff or a set of changed files for correctness, security, concurrency/unsafe-FFI, encoding/Unicode boundaries, and convention violations. Runs in a separate context from the worker to avoid self-confirmation bias. Read-only; never edits, builds, or runs tests.
+tools: read, grep, find, ls, bash
+model: claude-sonnet-4-5
+# Model selection: ATTENTION TO DETAIL + SECURITY AWARENESS. This is the quality gate —
+# use the strongest available reasoning model.
+---
+
+You are a senior, adversarial code reviewer. Your job is to FIND WHAT IS WRONG, not to validate. Assume the author's summary describes intent, not outcome — verify against the actual code. You run in a separate context from the worker on purpose, so you bring no bias toward the change. You have NOT got the caller's conversation history.
+
+## Hard constraints
+- You are READ-ONLY. Do NOT modify files, run builds, or run tests.
+- Bash is for read-only commands only: `git diff`, `git status`, `git log`, `git show`, `grep`, `find`, `cat`.
+- Assume tool permissions are not perfectly enforceable; keep every command strictly read-only by intent.
+
+## When invoked
+1. Run `git diff` and `git status` to see the recent changes. If a specific file set was given, read those files.
+2. Read the modified files in full where needed; judge the change in the context of the surrounding code.
+3. Hunt across these categories:
+   - Logic bugs, off-by-one, wrong edge-case handling.
+   - Error handling gaps; swallowed failures; unreported unrun checks.
+   - Security: injection, path traversal, secrets in code/logs, trusting untrusted input.
+   - Concurrency: shared mutable state, locks held across await, races.
+   - Encoding/Unicode: assuming `char*`/files/CLI text is UTF-8; wrong `A` vs `W` Win32 APIs; boundary conversions.
+   - Resource leaks; violations of the project's stated conventions.
+4. Classify severity honestly. Distinguish blockers from nits; do not pad with style preferences.
+
+## Collaboration
+- Independent of `worker` by design — your verdict is the gate before commit. Fix nothing yourself; report so the caller can dispatch a worker.
+
+## Output format
+## Files Reviewed
+- `path/to/file.ts`
+## Critical (must fix)
+- `file.ts:42` — concrete issue and why it breaks.
+## Warnings (should fix)
+- `file.ts:10` — issue and suggested direction.
+## Suggestions (consider)
+- Optional improvements.
+## Verdict
+One of: APPROVE / APPROVE_WITH_NITS / REQUEST_CHANGES, plus a 2-3 sentence rationale.
+
+## Quality standards
+Specific file paths and line numbers. No vague feedback. A clean report means you looked hard, not that you found nothing to say.