liteagents 2.20.0 → 2.21.1

package/packages/opencode/command/security.md

@@ -1,12 +1,20 @@
 ---
 name: security
-description: Scan security [target]
+description: Security audit — recurring six, injection, auth, trust boundaries
 usage: /security
 argument-hint: [file, directory, or leave empty for full scan]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git log *), Bash(git grep *), Bash(rg *)
+allowed-tools: Read, Grep, Glob, Bash(git log *), Bash(git grep *), Bash(rg *)
 ---
-Audit $ARGUMENTS for security vulnerabilities. Adapt scope to what the target
-actually is — a library, CLI, web app, and service won't all have every
+Audit $ARGUMENTS for security vulnerabilities. **Reports, never edits** — it
+verifies every claim, then hands the findings to whoever asked.
+
+**Runs identically standalone or as stage 2 of `/branch-review`.** The only
+difference is where the report goes: to the orchestrator when called as a
+stage, to you when you run it directly. Same checks, same verify pass, same
+escalation. It does **not** spawn a worker of its own — run it inline; when
+`/branch-review` calls it, it is already inside that command's worker.
+
+Adapt scope to what the target actually is — a library, CLI, web app, and service won't all have every
 category. Skip what genuinely doesn't apply; never invent findings to fill a
 section.
 
@@ -58,22 +66,23 @@ End with: which of the six classes were checked and found **clean**, and any
 marked **N/A** for this target — so the scan's coverage is auditable, not just
 its hits.
 
-## After the scan — verify, then fix
+## After the scan — verify, then escalate
 
-Findings are claims, not facts. Validate before acting; validate again after.
+Findings are claims, not facts. Validate every one before reporting it; an
+unverified finding wastes more time than a missed one.
 
-**Verify each claim.** Re-read the cited `file:line` in context. Confirm the
-risk actually holds here — not in the abstract. Mark each **confirmed**, **false
-positive** (with reason), or **uncertain**.
+**Verify each claim — adversarially.** Re-read the cited `file:line` in full
+context and **try to break the claim, not to confirm it**: is there a gate
+upstream, a framework default, a caller that already validates? A pass that
+sets out to confirm reliably misses what an adversarial pass finds. Mark each
+**confirmed**, **false positive** (with reason), or **uncertain** (with what
+would settle it).
 
-**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
-change to a public API / response / caller contract. Apply directly. After
-each edit, re-read the changed region and confirm it closes the gap without
-breaking nearby logic. A fix isn't done until you've grounded it the same way
-you grounded the claim.
+**Never fix.** Not even a confirmed, one-line, obvious fix. Describe the
+minimal remediation and hand it back — applying it is a separate, separately
+authorized action.
 
-**Stop and ask** when any of these hold (HITL gates — not all the time, only
-here):
+**Flag these explicitly** — they need a human decision, not a recommendation:
 - the finding is **uncertain** after grounding (you'd need info you don't have),
 - the fix has **multiple reasonable shapes** (e.g. reject-vs-sanitize,
   index-vs-paginate) — present options with tradeoffs, not a chosen path,
@@ -82,5 +91,12 @@ here):
 - it touches **auth / crypto / session / token** primitives — even an "obvious"
   fix here warrants confirmation.
 
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why + options)
-· **false-positive** (why) · **uncertain** (what's needed to decide).
+Final report: **confirmed** (with remediation described) · **needs a decision**
+(why + the options and their tradeoffs) · **false positive** (why) ·
+**uncertain** (what is needed to decide).
+
+**Escalate, never assume.** Anything you cannot decide, cannot verify, or that
+this spec does not cover → say so plainly in the report rather than guessing.
+When running as a stage of `/branch-review`, that report goes to the
+orchestrator; standalone, it goes to the user. Never widen scope, never fix a
+side issue you noticed along the way.

package/packages/opencode/command/ship.md

@@ -1,14 +1,24 @@
 ---
 name: ship
-description: Check pre-deployment
+description: Mechanical pre-deploy gate — tests, build, tree state
 usage: /ship
 allowed-tools: Read, Grep, Glob, Bash(git *), Bash(npm *), Bash(pnpm *), Bash(yarn *), Bash(pytest *), Bash(python *), Bash(go *), Bash(cargo *), Bash(make *)
 ---
-Pre-deploy / pre-merge gate. **Detect the stack first** (look for
-`package.json`, `pyproject.toml`/`setup.cfg`, `go.mod`, `Cargo.toml`,
-`Makefile`) and run only the checks that actually exist — never assume a
-script (`lint`, `build`, `migrate`) is present. Report each item as
-**pass / fail / N/A**.
+Mechanical pre-deploy / pre-merge gate. Every item here is answerable by
+**running a command** and reading its exit code — no code judgment. Code
+judgment belongs to `/branch-review` (which runs `/security` in full as its
+second stage); this gate does not duplicate it.
+
+**Detect the stack first** (look for `package.json`,
+`pyproject.toml`/`setup.cfg`, `go.mod`, `Cargo.toml`, `Makefile`) and run only
+the checks that actually exist — never assume a script (`lint`, `build`,
+`migrate`) is present.
+
+## Evidence rule
+Report each item as **pass / fail / N/A**, and record **the exact command and
+its exit code**. A check you did not run is a **fail**, never a pass. **N/A
+requires a stated reason** ("no build script in `package.json`") — N/A must
+never stand in for "didn't get to it."
 
 ## Checklist
 - [ ] **Tests pass** — run the project's real test command (`npm test`,
@@ -17,24 +27,17 @@ script (`lint`, `build`, `migrate`) is present. Report each item as
 - [ ] **Build succeeds** — only if the project has a build step.
 - [ ] **No debug leftovers** — stray `console.log` / `print` / `debugger` /
       `dbg!` / commented-out blocks / blocker `TODO`s in the changed files.
-- [ ] **No hardcoded secrets** — scan the diff. Secrets load from env / a
-      secret store; `.env` is gitignored and only a value-less `.env.example`
-      is tracked.
-- [ ] **Error handling complete** — every new IO / network / DB call has a
-      failure path; nothing fails silently; no internal detail leaks to clients.
-- [ ] **Authorization** — new endpoints/actions check **ownership + role**,
-      not just authentication (no IDOR via id-swapping).
-- [ ] **Rate limiting** — new externally reachable routes, including
-      authenticated writes, are bounded.
-- [ ] **Data access scoped & scales** — new queries are constrained to the
-      requesting principal (no cross-tenant leak) and avoid obvious N+1 /
-      unindexed scans on hot paths.
-- [ ] **Migrations ready** — only if the project has a schema / migrations.
-- [ ] **Docs & config in sync** — `.env.example`, README, and any
-      threat-model / PRD updated for new config or new attack surface.
-- [ ] **Clean tree, correct branch, in sync with `origin`.**
-
-For any security-sensitive change in the diff, run **`/security`** on the
-changed files before shipping.
+- [ ] **No hardcoded secrets** — grep the diff for keys, tokens, credentials;
+      confirm `.env` is gitignored and only a value-less `.env.example` is
+      tracked. *This is the one check `/security` also makes, kept
+      deliberately: it is a grep with a binary answer, and a leaked key is the
+      one failure worth catching twice.*
+- [ ] **Migrations ready** — only if the project has a schema / migrations:
+      they apply cleanly and are ordered.
+- [ ] **Docs & config in sync** — `.env.example`, README, and any PRD /
+      context doc updated for new config or new usage.
+- [ ] **Clean tree, correct branch, in sync with `origin`** — and never on
+      `main`.
 
-Report: **Ready 🚀** or **Blocked 🛑** with the specific failing items.
+Report: **Ready 🚀** or **Blocked 🛑** with the specific failing items and the
+command output that proves each one.

package/packages/opencode/command/stash.md

@@ -8,12 +8,18 @@ argument-hint: [optional stash name]
 Save session context for compaction recovery or handoffs.
 
 **Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- **Mid-tier model, not hardcoded.** The write-up subagent (step 2) uses a mid-tier model —
-  capable of semantic judgment, cheaper/faster than your top reasoning tier (e.g. Claude's
-  Sonnet vs Opus). Use whatever your tool designates as that balanced default; never hardcode
-  a vendor-specific model name.
+- **Write only what the brief contains.** The subagent expands the brief into a file; it does
+  not research, re-derive, or infer. Every fact, number, SHA, path, and identifier in the
+  stash comes from the brief verbatim — never invent, never round, never fill a gap with a
+  plausible guess. Missing detail stays missing.
+- **Escalate, never assume.** Anything the subagent cannot do, cannot verify, or that this
+  spec does not cover → report it back to the orchestrator (the main session) rather than
+  improvising. Never widen scope beyond writing the file and counting the backlog.
+- **Mid-tier model, not hardcoded.** Run the worker on your tool's balanced default tier —
+  judgment-capable, cheaper and faster than your top reasoning tier. **Not the
+  cheapest/fastest tier**: on judgment work it measurably degrades (misclassification rates
+  several times higher). Never hardcode a vendor-specific model name; use whatever your tool
+  designates as that default.
 - **Background dispatch where supported.** Run the write-up subagent in the background
   (non-blocking) so the session isn't held up waiting on formatting/file I/O. Fall back to
   writing inline (today's behavior) if your tool has no subagent or background-dispatch

package/packages/opencode/opencode.jsonc

@@ -157,21 +157,21 @@
       "template": "{file:./command/refactor.md}",
       "description": "Refactor code while maintaining behavior and tests"
     },
-    "diff-review": {
-      "template": "{file:./command/diff-review.md}",
-      "description": "Comprehensive code review including quality, tests, and architecture"
+    "branch-review": {
+      "template": "{file:./command/branch-review.md}",
+      "description": "Pre-merge review: general review + full security audit, verify pass, no fixes"
     },
     "security": {
       "template": "{file:./command/security.md}",
-      "description": "Security vulnerability scan and analysis"
+      "description": "Security audit — recurring six, injection, auth, trust boundaries; reports, never fixes"
     },
     "ship": {
       "template": "{file:./command/ship.md}",
-      "description": "Pre-deployment verification checklist"
+      "description": "Mechanical pre-deploy gate — tests, build, tree state"
     },
     "release": {
       "template": "{file:./command/release.md}",
-      "description": "Deliver a feature end-to-end: verify, docs, merge, tag (publish stays manual)"
+      "description": "Verify, sweep docs, cut a version — then hand back the merge/tag/publish sequence"
     },
     "remember": {
       "template": "{file:./command/remember.md}",

package/packages/subagentic-manual.md

@@ -56,7 +56,7 @@ Install for your platform:
 - brainstorming, debug-method, live-canvas, skill-creator, trace-back
 
 **10 Commands** - Workflow helpers
-- docs-builder, optimize, refactor, remember, diff-review, security, ship, release, stash, test-generate
+- docs-builder, optimize, refactor, remember, branch-review, security, ship, release, stash, test-generate
 
 **Orchestration System**
 - Automatic intent matching to 9 workflow patterns
@@ -123,10 +123,10 @@ Install for your platform:
 - `optimize` - Performance analysis
 - `refactor` - Maintain behavior while improving code
 - `remember` - Consolidate stashes + friction into project memory
-- `diff-review` - Review a file, branch, or range; verifies findings before fixing
+- `branch-review` - Review a branch + full security audit; verifies findings, reports without fixing
 - `security` - Vulnerability scanning
 - `ship` - Pre-deployment checklist
-- `release` - Deliver a feature end-to-end: verify → docs → merge → tag (publish stays manual)
+- `release` - Prepare a release: verify → docs → bump → commit, then report the merge/tag/publish sequence for you to authorize
 - `stash` - Save session context for compaction recovery or handoffs
 - `test-generate` - Test suite generation
 
@@ -139,7 +139,7 @@ Same functionality as skills+commands, but:
 
 **Command Categories**:
 - **Development & Testing (6)**: tdd-flow, test-traps, test-generate, debug-method, trace-back, verify-done
-- **Code Operations (6)**: refactor, optimize, diff-review, security, ship, release
+- **Code Operations (6)**: refactor, optimize, branch-review, security, ship, release
 - **Session & Memory (5)**: brainstorming, skill-creator, docs-builder, stash, remember
 - **Design (1)**: live-canvas
 
@@ -236,7 +236,7 @@ Each pattern includes conditional decision points requiring user approval.
 ### Droid/OpenCode: Direct Command Invocation
 
 No orchestrator - invoke commands directly:
-- `/diff-review <file-or-branch>`
+- `/branch-review <file-or-branch> [level]`
 - `/refactor <code-section>`
 - `/tdd-flow <feature>`
 

package/packages/ampcode/commands/diff-review.md

@@ -1,78 +0,0 @@
----
-name: diff-review
-description: Review diff [file, branch, or range]
-usage: /diff-review
-argument-hint: [file, branch (e.g. main), range (main..HEAD), or empty]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git diff *), Bash(git log *), Bash(git show *), Bash(git status *), Bash(git grep *), Bash(git rev-parse *), Bash(git merge-base *), Bash(rg *)
----
-Review $ARGUMENTS. Interpret in this order:
-1. **Empty** → staged diff (`git diff --staged`); if empty, working-tree diff
-   (`git diff`).
-2. **A range** like `main..HEAD` or `origin/main...HEAD` → `git diff <range>`.
-3. **A single ref** (branch / tag / SHA — confirm with `git rev-parse
-   --verify`) → diff that ref's merge-base against `HEAD` (i.e. everything on
-   the current branch since it diverged: `git diff $(git merge-base <ref>
-   HEAD)..HEAD`). This is the common "review my branch before merging" path.
-4. **A file or directory path** → that target.
-5. Otherwise → ask.
-
-The diff is the subject; widen to surrounding code only as needed to judge a
-hunk. For multi-commit ranges, also skim `git log <range>` to understand
-intent before judging.
-
-## Check For
-- **Bugs needing a fix.** Logic errors, off-by-one, null/undefined paths,
-  races, wrong defaults, broken edge cases. Concrete failure modes only — not
-  vibes.
-- **Dead code.** Unreferenced functions / vars / imports / params, unreachable
-  branches, commented-out blocks, legacy paths the diff just obsoleted.
-  `git grep` the symbol before flagging — easy to be wrong.
-- **Loose ends.** TODO / FIXME / XXX added by this diff, half-finished
-  branches, silently swallowed errors, stub bodies, mocked-out paths,
-  "temporary" names, abandoned feature flags.
-- **Correctness.** Edge cases, error handling, type / contract violations,
-  broken invariants.
-- **Security.** OWASP Top 10, auth, data exposure. (`/security` for depth.)
-- **Performance.** N+1, blocking calls in hot paths, unbounded loops, indexes
-  the diff actually touches.
-- **Maintainability.** Complexity, naming, duplication — only when material.
-
-## Output Format
-### 🚨 Critical (blocks merge)
-### ⚠️ Warnings (should fix)
-### 💡 Suggestions (nice to have)
-
-Each finding: **Location** (`file:line`), **What's wrong**, **Why it matters**,
-**Concrete fix** — not "consider improving".
-
-## After the review — verify, then fix
-
-Findings are claims, not facts. Validate before acting; validate again after.
-
-**Verify each claim.** Re-read the cited `file:line` in context. For
-dead-code or unused-symbol claims, `git grep` the name across the repo before
-trusting it. Mark each **confirmed**, **false positive** (with reason), or
-**uncertain**.
-
-**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
-change to a public API / response / caller contract. Apply directly. After
-each edit, re-read the changed region and confirm it does what you intended
-without breaking nearby logic. A fix isn't done until you've grounded it the
-same way you grounded the claim.
-
-**Stop and ask** when any of these hold (HITL gates — not all the time, only
-here):
-- the finding is **uncertain** after grounding,
-- the fix has **multiple reasonable shapes** (e.g. delete-vs-keep-behind-flag,
-  extract-vs-inline, patch-vs-rewrite) — present options with tradeoffs, not a
-  chosen path,
-- it **affects downstream** (signatures, response shape, schema, any caller
-  contract) or removes a public/exported symbol, or
-- the "dead code" looks intentionally kept (stub for upcoming work, framework
-  hook, documented extension point) — confirm before deleting.
-
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why +
-options) · **false-positive** (why) · **uncertain** (what's needed to decide).
-
-End with a one-line verdict: **Ready to merge? Yes / No / With fixes** — and
-the reason in a sentence.

package/packages/claude/commands/diff-review.md

@@ -1,78 +0,0 @@
----
-name: diff-review
-description: Review diff [file, branch, or range]
-usage: /diff-review
-argument-hint: [file, branch (e.g. main), range (main..HEAD), or empty]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git diff:*), Bash(git log:*), Bash(git show:*), Bash(git status:*), Bash(git grep:*), Bash(git rev-parse:*), Bash(git merge-base:*), Bash(rg:*)
----
-Review $ARGUMENTS. Interpret in this order:
-1. **Empty** → staged diff (`git diff --staged`); if empty, working-tree diff
-   (`git diff`).
-2. **A range** like `main..HEAD` or `origin/main...HEAD` → `git diff <range>`.
-3. **A single ref** (branch / tag / SHA — confirm with `git rev-parse
-   --verify`) → diff that ref's merge-base against `HEAD` (i.e. everything on
-   the current branch since it diverged: `git diff $(git merge-base <ref>
-   HEAD)..HEAD`). This is the common "review my branch before merging" path.
-4. **A file or directory path** → that target.
-5. Otherwise → ask.
-
-The diff is the subject; widen to surrounding code only as needed to judge a
-hunk. For multi-commit ranges, also skim `git log <range>` to understand
-intent before judging.
-
-## Check For
-- **Bugs needing a fix.** Logic errors, off-by-one, null/undefined paths,
-  races, wrong defaults, broken edge cases. Concrete failure modes only — not
-  vibes.
-- **Dead code.** Unreferenced functions / vars / imports / params, unreachable
-  branches, commented-out blocks, legacy paths the diff just obsoleted.
-  `git grep` the symbol before flagging — easy to be wrong.
-- **Loose ends.** TODO / FIXME / XXX added by this diff, half-finished
-  branches, silently swallowed errors, stub bodies, mocked-out paths,
-  "temporary" names, abandoned feature flags.
-- **Correctness.** Edge cases, error handling, type / contract violations,
-  broken invariants.
-- **Security.** OWASP Top 10, auth, data exposure. (`/security` for depth.)
-- **Performance.** N+1, blocking calls in hot paths, unbounded loops, indexes
-  the diff actually touches.
-- **Maintainability.** Complexity, naming, duplication — only when material.
-
-## Output Format
-### 🚨 Critical (blocks merge)
-### ⚠️ Warnings (should fix)
-### 💡 Suggestions (nice to have)
-
-Each finding: **Location** (`file:line`), **What's wrong**, **Why it matters**,
-**Concrete fix** — not "consider improving".
-
-## After the review — verify, then fix
-
-Findings are claims, not facts. Validate before acting; validate again after.
-
-**Verify each claim.** Re-read the cited `file:line` in context. For
-dead-code or unused-symbol claims, `git grep` the name across the repo before
-trusting it. Mark each **confirmed**, **false positive** (with reason), or
-**uncertain**.
-
-**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
-change to a public API / response / caller contract. Apply directly. After
-each edit, re-read the changed region and confirm it does what you intended
-without breaking nearby logic. A fix isn't done until you've grounded it the
-same way you grounded the claim.
-
-**Stop and ask** when any of these hold (HITL gates — not all the time, only
-here):
-- the finding is **uncertain** after grounding,
-- the fix has **multiple reasonable shapes** (e.g. delete-vs-keep-behind-flag,
-  extract-vs-inline, patch-vs-rewrite) — present options with tradeoffs, not a
-  chosen path,
-- it **affects downstream** (signatures, response shape, schema, any caller
-  contract) or removes a public/exported symbol, or
-- the "dead code" looks intentionally kept (stub for upcoming work, framework
-  hook, documented extension point) — confirm before deleting.
-
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why +
-options) · **false-positive** (why) · **uncertain** (what's needed to decide).
-
-End with a one-line verdict: **Ready to merge? Yes / No / With fixes** — and
-the reason in a sentence.

package/packages/droid/commands/diff-review.md

@@ -1,78 +0,0 @@
----
-name: diff-review
-description: Review diff [file, branch, or range]
-usage: /diff-review
-argument-hint: [file, branch (e.g. main), range (main..HEAD), or empty]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git diff *), Bash(git log *), Bash(git show *), Bash(git status *), Bash(git grep *), Bash(git rev-parse *), Bash(git merge-base *), Bash(rg *)
----
-Review $ARGUMENTS. Interpret in this order:
-1. **Empty** → staged diff (`git diff --staged`); if empty, working-tree diff
-   (`git diff`).
-2. **A range** like `main..HEAD` or `origin/main...HEAD` → `git diff <range>`.
-3. **A single ref** (branch / tag / SHA — confirm with `git rev-parse
-   --verify`) → diff that ref's merge-base against `HEAD` (i.e. everything on
-   the current branch since it diverged: `git diff $(git merge-base <ref>
-   HEAD)..HEAD`). This is the common "review my branch before merging" path.
-4. **A file or directory path** → that target.
-5. Otherwise → ask.
-
-The diff is the subject; widen to surrounding code only as needed to judge a
-hunk. For multi-commit ranges, also skim `git log <range>` to understand
-intent before judging.
-
-## Check For
-- **Bugs needing a fix.** Logic errors, off-by-one, null/undefined paths,
-  races, wrong defaults, broken edge cases. Concrete failure modes only — not
-  vibes.
-- **Dead code.** Unreferenced functions / vars / imports / params, unreachable
-  branches, commented-out blocks, legacy paths the diff just obsoleted.
-  `git grep` the symbol before flagging — easy to be wrong.
-- **Loose ends.** TODO / FIXME / XXX added by this diff, half-finished
-  branches, silently swallowed errors, stub bodies, mocked-out paths,
-  "temporary" names, abandoned feature flags.
-- **Correctness.** Edge cases, error handling, type / contract violations,
-  broken invariants.
-- **Security.** OWASP Top 10, auth, data exposure. (`/security` for depth.)
-- **Performance.** N+1, blocking calls in hot paths, unbounded loops, indexes
-  the diff actually touches.
-- **Maintainability.** Complexity, naming, duplication — only when material.
-
-## Output Format
-### 🚨 Critical (blocks merge)
-### ⚠️ Warnings (should fix)
-### 💡 Suggestions (nice to have)
-
-Each finding: **Location** (`file:line`), **What's wrong**, **Why it matters**,
-**Concrete fix** — not "consider improving".
-
-## After the review — verify, then fix
-
-Findings are claims, not facts. Validate before acting; validate again after.
-
-**Verify each claim.** Re-read the cited `file:line` in context. For
-dead-code or unused-symbol claims, `git grep` the name across the repo before
-trusting it. Mark each **confirmed**, **false positive** (with reason), or
-**uncertain**.
-
-**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
-change to a public API / response / caller contract. Apply directly. After
-each edit, re-read the changed region and confirm it does what you intended
-without breaking nearby logic. A fix isn't done until you've grounded it the
-same way you grounded the claim.
-
-**Stop and ask** when any of these hold (HITL gates — not all the time, only
-here):
-- the finding is **uncertain** after grounding,
-- the fix has **multiple reasonable shapes** (e.g. delete-vs-keep-behind-flag,
-  extract-vs-inline, patch-vs-rewrite) — present options with tradeoffs, not a
-  chosen path,
-- it **affects downstream** (signatures, response shape, schema, any caller
-  contract) or removes a public/exported symbol, or
-- the "dead code" looks intentionally kept (stub for upcoming work, framework
-  hook, documented extension point) — confirm before deleting.
-
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why +
-options) · **false-positive** (why) · **uncertain** (what's needed to decide).
-
-End with a one-line verdict: **Ready to merge? Yes / No / With fixes** — and
-the reason in a sentence.

package/packages/opencode/command/diff-review.md

@@ -1,78 +0,0 @@
----
-name: diff-review
-description: Review diff [file, branch, or range]
-usage: /diff-review
-argument-hint: [file, branch (e.g. main), range (main..HEAD), or empty]
-allowed-tools: Read, Edit, Grep, Glob, Bash(git diff *), Bash(git log *), Bash(git show *), Bash(git status *), Bash(git grep *), Bash(git rev-parse *), Bash(git merge-base *), Bash(rg *)
----
-Review $ARGUMENTS. Interpret in this order:
-1. **Empty** → staged diff (`git diff --staged`); if empty, working-tree diff
-   (`git diff`).
-2. **A range** like `main..HEAD` or `origin/main...HEAD` → `git diff <range>`.
-3. **A single ref** (branch / tag / SHA — confirm with `git rev-parse
-   --verify`) → diff that ref's merge-base against `HEAD` (i.e. everything on
-   the current branch since it diverged: `git diff $(git merge-base <ref>
-   HEAD)..HEAD`). This is the common "review my branch before merging" path.
-4. **A file or directory path** → that target.
-5. Otherwise → ask.
-
-The diff is the subject; widen to surrounding code only as needed to judge a
-hunk. For multi-commit ranges, also skim `git log <range>` to understand
-intent before judging.
-
-## Check For
-- **Bugs needing a fix.** Logic errors, off-by-one, null/undefined paths,
-  races, wrong defaults, broken edge cases. Concrete failure modes only — not
-  vibes.
-- **Dead code.** Unreferenced functions / vars / imports / params, unreachable
-  branches, commented-out blocks, legacy paths the diff just obsoleted.
-  `git grep` the symbol before flagging — easy to be wrong.
-- **Loose ends.** TODO / FIXME / XXX added by this diff, half-finished
-  branches, silently swallowed errors, stub bodies, mocked-out paths,
-  "temporary" names, abandoned feature flags.
-- **Correctness.** Edge cases, error handling, type / contract violations,
-  broken invariants.
-- **Security.** OWASP Top 10, auth, data exposure. (`/security` for depth.)
-- **Performance.** N+1, blocking calls in hot paths, unbounded loops, indexes
-  the diff actually touches.
-- **Maintainability.** Complexity, naming, duplication — only when material.
-
-## Output Format
-### 🚨 Critical (blocks merge)
-### ⚠️ Warnings (should fix)
-### 💡 Suggestions (nice to have)
-
-Each finding: **Location** (`file:line`), **What's wrong**, **Why it matters**,
-**Concrete fix** — not "consider improving".
-
-## After the review — verify, then fix
-
-Findings are claims, not facts. Validate before acting; validate again after.
-
-**Verify each claim.** Re-read the cited `file:line` in context. For
-dead-code or unused-symbol claims, `git grep` the name across the repo before
-trusting it. Mark each **confirmed**, **false positive** (with reason), or
-**uncertain**.
-
-**Fix what's confirmed and unambiguous** — minimal shape, one obvious way, no
-change to a public API / response / caller contract. Apply directly. After
-each edit, re-read the changed region and confirm it does what you intended
-without breaking nearby logic. A fix isn't done until you've grounded it the
-same way you grounded the claim.
-
-**Stop and ask** when any of these hold (HITL gates — not all the time, only
-here):
-- the finding is **uncertain** after grounding,
-- the fix has **multiple reasonable shapes** (e.g. delete-vs-keep-behind-flag,
-  extract-vs-inline, patch-vs-rewrite) — present options with tradeoffs, not a
-  chosen path,
-- it **affects downstream** (signatures, response shape, schema, any caller
-  contract) or removes a public/exported symbol, or
-- the "dead code" looks intentionally kept (stub for upcoming work, framework
-  hook, documented extension point) — confirm before deleting.
-
-Final report: **confirmed-and-fixed** · **confirmed-but-asking** (why +
-options) · **false-positive** (why) · **uncertain** (what's needed to decide).
-
-End with a one-line verdict: **Ready to merge? Yes / No / With fixes** — and
-the reason in a sentence.