liteagents 2.9.0 → 2.10.0

package/packages/opencode/command/test-generate.md

@@ -1,18 +1,67 @@
 ---
 name: test-generate
-description: Generate tests [file]
-usage: /test-generate <code-section>
-argument-hint: [file-to-test]
+description: Generate and run tests [file]
+usage: /test-generate <file>
+argument-hint: [file or symbol to test]
+allowed-tools: Read, Edit, Write, Grep, Glob, Bash(npm test *), Bash(npx jest *), Bash(npx vitest *), Bash(pnpm test *), Bash(yarn test *), Bash(pytest *), Bash(python *), Bash(go test *), Bash(cargo test *), Bash(make test *)
 ---
-Generate tests for $ARGUMENTS.
-
-## Include
-- Happy path (expected usage)
-- Edge cases (empty, null, boundaries)
-- Error scenarios (invalid input, failures)
-- Integration points (mocks for external deps)
-
-## Requirements
-- Match existing test patterns in this project
-- Use the testing framework already in use
-- Clear test names: "should [expected] when [condition]"
+Generate tests for $ARGUMENTS, then run them. This is a generate → run →
+verify loop, not just file generation.
+
+## 1. Discover
+- Detect the test framework already in use (look for `jest.config*`,
+  `vitest.config*`, `pytest.ini` / `pyproject.toml [tool.pytest]`, Go's
+  `_test.go` convention, `Cargo.toml [dev-dependencies]`, etc.). **Never
+  add a new framework or runner.**
+- Skim 1–2 existing test files near the target to mirror style, fixtures,
+  setup/teardown, assertion style, and naming convention.
+
+## 2. Generate
+Cover:
+- **Happy path** (expected usage)
+- **Edges** (empty / null / boundary / malformed)
+- **Errors** (invalid input, IO / network / DB failures)
+
+Match existing patterns:
+- Same framework, same fixture style, same naming convention.
+- Reuse existing setup/teardown helpers; do **not** add new mock libraries
+  or new test-runner config.
+- Do **not** add test-only public methods or exports to production code to
+  make a test possible — if the test wants a hook the prod code doesn't
+  expose, stop and ask (`test-traps` territory).
+
+## 3. Run
+Execute the project's real test command, scoped to just the new tests
+(`-t <name>`, `--testPathPattern`, `pytest path/to/test.py`, `go test
+./pkg`, etc.). Report:
+- Pass / fail counts.
+- Any failure with the assertion message and `file:line`.
+
+## 4. Verify the tests BITE
+A test that passes is not the same as a test that **exercises** the code.
+For each new test, confirm:
+- It would fail if the function under test returned the wrong value.
+  Mentally swap a broken impl — does the assertion actually catch it?
+- It isn't `expect(true).toBe(true)`, `expect(fn).toBeDefined()`, or a
+  mock asserting itself.
+- It isn't passing only because the setup masked the real call.
+
+Mark each new test **biting** or **superficial** (with reason).
+Superficial tests count as a failure to ship — either fix or delete.
+
+## 5. Report
+- Files added / modified.
+- Pass / fail.
+- Biting vs superficial breakdown.
+- What was deliberately **not** tested, and why (third-party shims,
+  trivial getters/setters, generated code). Documented gaps beat fake
+  coverage.
+
+**Stop and ask** when:
+- A meaningful test would require a non-obvious design change to
+  production code (don't pollute prod to make tests pass — present the
+  options instead).
+- The existing test setup has multiple reasonable patterns and it's
+  unclear which to mirror.
+- An existing dependency would need to be mocked in a way the project
+  doesn't currently do (introducing a new mock style is a design choice).

package/packages/{ampcode/commands/testing-anti-patterns.md → opencode/command/test-traps.md}

@@ -1,11 +1,11 @@
 ---
-name: testing-anti-patterns
+name: test-traps
 description: Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies
-usage: /testing-anti-patterns <testing-scenario>
+usage: /test-traps <testing-scenario>
 auto_trigger: true
 ---
 
-# Testing Anti-Patterns
+# Test Traps
 
 ## Overview
 
@@ -253,6 +253,79 @@ TDD cycle:
 4. THEN claim complete
 ```
 
+## Anti-Pattern 6: Timeout-Based Waiting
+
+**The violation:**
+```typescript
+// Wait an arbitrary amount of time, then check
+await new Promise(r => setTimeout(r, 50));
+const result = getResult();
+expect(result).toBeDefined();
+```
+
+```python
+time.sleep(0.5)
+assert get_result() is not None
+```
+
+**Why this is wrong:**
+- Passes on fast machines, fails in CI under load (or vice versa).
+- Either too short (flaky) or too long (slow suite) — every value is wrong somewhere.
+- Hides the actual condition the test cares about.
+- A real bug in the async machinery looks identical to a "too-short sleep."
+
+**The fix — poll for the actual condition:**
+```typescript
+await waitFor(() => getResult() !== undefined);
+const result = getResult();
+expect(result).toBeDefined();
+```
+
+| Scenario | Pattern |
+|----------|---------|
+| Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` |
+| Wait for state | `waitFor(() => machine.state === 'ready')` |
+| Wait for count | `waitFor(() => items.length >= 5)` |
+| Wait for file | `waitFor(() => fs.existsSync(path))` |
+| Complex condition | `waitFor(() => obj.ready && obj.value > 10)` |
+
+Minimal generic poller:
+```typescript
+async function waitFor<T>(
+  condition: () => T | undefined | null | false,
+  description = 'condition',
+  timeoutMs = 5000
+): Promise<T> {
+  const start = Date.now();
+  while (true) {
+    const result = condition();
+    if (result) return result;
+    if (Date.now() - start > timeoutMs) {
+      throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
+    }
+    await new Promise(r => setTimeout(r, 10));
+  }
+}
+```
+
+See `example.ts` for domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) drawn from a real debugging session.
+
+**Polling pitfalls:**
+- **Polling too fast** (`setTimeout(check, 1)`) wastes CPU. **Fix:** poll every ~10ms.
+- **No timeout** means a never-met condition hangs the suite forever. **Fix:** always include a timeout with a descriptive error.
+- **Stale data** — if you read state once before the loop, you'll never see updates. **Fix:** call the getter *inside* the loop.
+
+**When an arbitrary timeout IS correct:**
+```typescript
+// Tool ticks every 100ms; observe 2 ticks of partial output.
+await waitForEvent(manager, 'TOOL_STARTED'); // condition first
+await new Promise(r => setTimeout(r, 200));  // then a documented, calculated wait
+// 200ms = 2 ticks at the documented 100ms cadence
+```
+Requirements: (1) wait for the triggering condition first, (2) the delay is based on a *known* interval (not a guess), (3) a comment explains why a sleep is correct here.
+
+**Real-world impact** (debugging session, 2025-10-03): 15 flaky tests across 3 files, pass rate 60% → 100%, suite 40% faster, race conditions gone.
+
 ## When Mocks Become Too Complex
 
 **Warning signs:**
@@ -284,6 +357,7 @@ TDD cycle:
 | Mock without understanding | Understand dependencies first, mock minimally |
 | Incomplete mocks | Mirror real API completely |
 | Tests as afterthought | TDD - tests first |
+| Timeout-based waiting | Poll for the actual condition with `waitFor()` |
 | Over-complex mocks | Consider integration tests |
 
 ## Red Flags

package/packages/{ampcode/commands/root-cause-tracing.md → opencode/command/trace-back.md}

@@ -1,11 +1,11 @@
 ---
-name: root-cause-tracing
+name: trace-back
 description: Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
-usage: /root-cause-tracing <issue-description>
+usage: /trace-back <issue-description>
 auto_trigger: false
 ---
 
-# Root Cause Tracing
+# Trace Back
 
 ## Overview
 

package/packages/opencode/command/{verification-before-completion.md → verify-done.md}

@@ -1,11 +1,11 @@
 ---
-name: verification-before-completion
+name: verify-done
 description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
-usage: /verification-before-completion <work-to-verify>
+usage: /verify-done <work-to-verify>
 auto_trigger: true
 ---
 
-# Verification Before Completion
+# Verify Done
 
 ## Auto-Trigger
 

package/packages/opencode/opencode.jsonc

@@ -113,58 +113,38 @@
     }
   },
   "command": {
-    "systematic-debugging": {
-      "template": "{file:./command/systematic-debugging.md}",
+    "debug-method": {
+      "template": "{file:./command/debug-method.md}",
       "description": "Systematic four-phase debugging framework - investigate root cause before any fixes"
     },
-    "verification-before-completion": {
-      "template": "{file:./command/verification-before-completion.md}",
+    "verify-done": {
+      "template": "{file:./command/verify-done.md}",
       "description": "Verify work meets requirements before marking complete - prevents incomplete deliverables"
     },
     "skill-creator": {
       "template": "{file:./command/skill-creator.md}",
       "description": "Create reusable skills with proper structure, validation, and documentation"
     },
-    "test-driven-development": {
-      "template": "{file:./command/test-driven-development.md}",
+    "tdd-flow": {
+      "template": "{file:./command/tdd-flow.md}",
       "description": "Write test first, watch it fail, write minimal code to pass - ensures tests actually verify behavior"
     },
-    "testing-anti-patterns": {
-      "template": "{file:./command/testing-anti-patterns.md}",
+    "test-traps": {
+      "template": "{file:./command/test-traps.md}",
       "description": "Identify and avoid common testing anti-patterns that create fragile, useless tests"
     },
-    "root-cause-tracing": {
-      "template": "{file:./command/root-cause-tracing.md}",
+    "trace-back": {
+      "template": "{file:./command/trace-back.md}",
       "description": "Trace issues to their root cause using systematic investigation techniques"
     },
-    "condition-based-waiting": {
-      "template": "{file:./command/condition-based-waiting.md}",
-      "description": "Implement robust waiting mechanisms based on conditions rather than fixed delays"
-    },
     "brainstorming": {
       "template": "{file:./command/brainstorming.md}",
       "description": "Facilitate structured brainstorming sessions with proven techniques and frameworks"
     },
-    "code-review": {
-      "template": "{file:./command/code-review.md}",
-      "description": "Conduct thorough code reviews with focus on quality, security, and maintainability"
-    },
     "docs-builder": {
       "template": "{file:./command/docs-builder/SKILL.md}",
       "description": "Create comprehensive project documentation with structured /docs hierarchy"
     },
-    "debug": {
-      "template": "{file:./command/debug.md}",
-      "description": "Debug an issue systematically using structured investigation techniques"
-    },
-    "explain": {
-      "template": "{file:./command/explain.md}",
-      "description": "Explain code for someone new to the codebase"
-    },
-    "git-commit": {
-      "template": "{file:./command/git-commit.md}",
-      "description": "Analyze changes and create intelligent git commits"
-    },
     "live-canvas": {
       "template": "{file:./command/live-canvas.md}",
       "description": "Design UI variations and collect click-to-annotate feedback from the browser (batch mode only on Opencode)"
@@ -177,8 +157,8 @@
       "template": "{file:./command/refactor.md}",
       "description": "Refactor code while maintaining behavior and tests"
     },
-    "review": {
-      "template": "{file:./command/review.md}",
+    "diff-review": {
+      "template": "{file:./command/diff-review.md}",
       "description": "Comprehensive code review including quality, tests, and architecture"
     },
     "security": {
@@ -189,10 +169,6 @@
       "template": "{file:./command/ship.md}",
       "description": "Pre-deployment verification checklist"
     },
-    "friction": {
-      "template": "{file:./command/friction.md}",
-      "description": "Analyze session logs for failure patterns and behavioral signals"
-    },
     "remember": {
       "template": "{file:./command/remember.md}",
       "description": "Consolidate stashes + friction into project memory"
@@ -203,7 +179,7 @@
     },
     "test-generate": {
       "template": "{file:./command/test-generate.md}",
-      "description": "Generate comprehensive test suites for existing code"
+      "description": "Generate tests, run them, and verify each test actually exercises the code (not just passes)"
     },
     "subagent-spawning": {
       "template": "{file:./command/subagent-spawning.md}",

package/packages/subagentic-manual.md

@@ -31,10 +31,10 @@ Install for your platform:
 
 | Platform | Installation | What's Included |
 |----------|--------------|-----------------|
-| **Claude Code** | `cp -r claude/* ~/.claude/` | 11 subagents + 11 skills + 12 commands + live-canvas-channel plugin |
-| **Droid** | `cp -r droid/* ~/.factory/` | 23 commands (subagent references) |
-| **Ampcode** | `cp -r ampcode/* ~/.config/amp/` | 11 subagents + 11 skills + 12 commands |
-| **OpenCode** | `cp -r opencode/* ~/.config/opencode/` | 23 commands (subagent references) |
+| **Claude Code** | `cp -r claude/* ~/.claude/` | 11 subagents + 9 skills + 8 commands + live-canvas-channel plugin |
+| **Droid** | `cp -r droid/* ~/.factory/` | 17 commands (subagent references) |
+| **Ampcode** | `cp -r ampcode/* ~/.config/amp/` | 11 subagents + 9 skills + 8 commands |
+| **OpenCode** | `cp -r opencode/* ~/.config/opencode/` | 17 commands (subagent references) |
 
 **Key Difference**:
 - **Claude Code / Ampcode** implement full subagent system with orchestrator
@@ -50,12 +50,12 @@ Install for your platform:
 - 3 Workflow Agents (PRD, Tasks, Implementation)
 - 8 Specialist Agents (UX, QA, Architecture, Product, Development, etc.)
 
-**11 Skills** - Auto-triggering + manual workflow components
-- test-driven-development, testing-anti-patterns, verification-before-completion (auto-trigger)
-- brainstorming, code-review, systematic-debugging, docs-builder, live-canvas, etc.
+**10 Skills** - Auto-triggering + manual workflow components
+- tdd-flow, test-traps, verify-done (auto-trigger)
+- brainstorming, debug-method, docs-builder, live-canvas, etc.
 
-**12 Commands** - Simple workflow helpers
-- debug, explain, friction, git-commit, optimize, refactor, remember, review, security, ship, stash, test-generate
+**8 Commands** - Simple workflow helpers
+- optimize, refactor, remember, diff-review, security, ship, stash, test-generate
 
 **Orchestration System**
 - Automatic intent matching to 9 workflow patterns
@@ -64,7 +64,7 @@ Install for your platform:
 
 ### Droid/OpenCode (Commands Only)
 
-**23 Commands** - All workflow capabilities in command form
+**18 Commands** - All workflow capabilities in command form
 - Combines skills + commands into unified command set
 - Same functionality, different invocation model (no auto-triggering)
 - Includes reference documentation for subagents
@@ -102,38 +102,32 @@ Install for your platform:
 
 ## Commands Reference
 
-### Claude Code / Ampcode: 23 Total (11 Skills + 12 Commands)
+### Claude Code / Ampcode: 18 Total (9 Skills + 9 Commands)
 
 **Auto-Triggering Skills (3)**
-- `test-driven-development` - Write test first, watch fail, minimal passing code
-- `testing-anti-patterns` - Prevent mocking anti-patterns and test pollution
-- `verification-before-completion` - Run verification before claiming done
+- `tdd-flow` - Write test first, watch fail, minimal passing code
+- `test-traps` - Prevent mocking anti-patterns and test pollution
+- `verify-done` - Run verification before claiming done
 
-**Manual Skills (8)**
+**Manual Skills (6)**
 - `brainstorming` - Refine rough ideas through collaborative questioning
-- `code-review` - Review implementation against requirements
-- `condition-based-waiting` - Replace timeouts with condition polling
 - `docs-builder` - Create structured /docs hierarchy
 - `live-canvas` - Design UI variations with click-to-annotate browser feedback. **Claude Code ships a companion MCP channel plugin (`live-canvas-channel`) that enables live mode — each overlay Save streams into the session in real time.** Other tools run in batch mode only. One-time setup required: see `packages/claude/skills/live-canvas/README.md`.
-- `root-cause-tracing` - Trace bugs backward through call stack
+- `trace-back` - Trace bugs backward through call stack
 - `skill-creator` - Guide for creating new skills
-- `systematic-debugging` - Four-phase debugging framework
+- `debug-method` - Four-phase debugging framework
 
-**Simple Commands (12)**
-- `debug` - Systematic investigation techniques
-- `explain` - Explain code for newcomers
-- `friction` - Analyze session logs for failure patterns and behavioral signals
-- `git-commit` - Intelligent commit creation
+**Simple Commands (8)**
 - `optimize` - Performance analysis
 - `refactor` - Maintain behavior while improving code
 - `remember` - Consolidate stashes + friction into project memory
-- `review` - Comprehensive code review
+- `diff-review` - Review a file, branch, or range; verifies findings before fixing
 - `security` - Vulnerability scanning
 - `ship` - Pre-deployment checklist
 - `stash` - Save session context for compaction recovery or handoffs
 - `test-generate` - Test suite generation
 
-### Droid/OpenCode: 23 Commands
+### Droid/OpenCode: 17 Commands
 
 Same functionality as skills+commands, but:
 - All invoked as commands (no auto-triggering)
@@ -142,24 +136,34 @@ Same functionality as skills+commands, but:
 - `live-canvas` runs in batch mode only (no channel plugin — that's Claude Code specific)
 
 **Command Categories**:
-- **Development & Testing (9)**: test-driven-development, testing-anti-patterns, test-generate, code-review, systematic-debugging, root-cause-tracing, debug, condition-based-waiting, verification-before-completion
-- **Code Operations (6)**: refactor, optimize, explain, review, security, ship
-- **Session & Memory (7)**: brainstorming, skill-creator, docs-builder, git-commit, stash, friction, remember
+- **Development & Testing (6)**: tdd-flow, test-traps, test-generate, debug-method, trace-back, verify-done
+- **Code Operations (5)**: refactor, optimize, diff-review, security, ship
+- **Session & Memory (5)**: brainstorming, skill-creator, docs-builder, stash, remember
 - **Design (1)**: live-canvas
 
 ---
 
 ## Hot Memory
 
-Lightweight session memory that learns from your usage patterns across sessions.
+Lightweight session memory that learns from your usage patterns across sessions. **`/stash` is
+the only command you actively run — it drives the whole pipeline.** Once a few stashes pile up
+it nudges you to run `/remember`, which does everything else: friction analysis, consolidation,
+and wiring the memory into your agent config file.
 
 ```
-/stash → /friction → /remember
+/stash → (nudge at 5+ unprocessed) → /remember
 ```
 
-1. **`/stash`** - Snapshot current session context to `.claude/stash/`. Use before compaction, handoffs, or ending complex work.
-2. **`/friction`** - Analyze session logs for failure patterns. Scores sessions, clusters failures by signal and tool sequence, outputs actionable antigens to `.claude/friction/`.
-3. **`/remember`** - Consolidate stashes + friction into `.claude/memory/MEMORY.md`. Extracts facts, episodes, and behavioral preferences. References into CLAUDE.md via `@MEMORY.md`.
+1. **`/stash`** - Snapshot current session context to the tool's `…/stash/`. Use before
+   compaction, handoffs, or ending complex work. After saving it counts the unprocessed backlog
+   (`stash files − .processed entries`) and, at 5+, nudges you to run `/remember`. No counter is
+   stored; running `/remember` clears the backlog.
+2. **`/remember`** - Runs friction analysis first (best-effort — scores sessions across *all* your
+   projects from the tool's global sessions root, clusters failures into antigens), then
+   consolidates stashes + antigens into `…/memory/MEMORY.md` and injects `@MEMORY.md` into the
+   **per-tool agent config — `CLAUDE.md` (Claude Code), `AGENTS.md` (Droid / OpenCode), or
+   `AGENT.md` (Ampcode)** — so every future session loads it. Each package writes to its own
+   tool's config file; the global probe list only governs which logs friction *reads*.
 
 **Result:** Project-local memory that accumulates across sessions — no external dependencies, no databases, just markdown.
 
@@ -201,7 +205,7 @@ Orchestrator: "Start systematic implementation?" [Yes/No]
 **Bypass Options**:
 - Direct agent: `@quality-assurance review this code`
 - Role syntax: `As system-architect, design the API layer`
-- Skills: `/test-driven-development login-feature`
+- Skills: `/tdd-flow login-feature`
 
 ### 9 Pre-Defined Workflow Patterns
 
@@ -220,9 +224,9 @@ Each pattern includes conditional decision points requiring user approval.
 ### Droid/OpenCode: Direct Command Invocation
 
 No orchestrator - invoke commands directly:
-- `/debug <issue>`
+- `/diff-review <file-or-branch>`
 - `/refactor <code-section>`
-- `/test-driven-development <feature>`
+- `/tdd-flow <feature>`
 
 Subagent workflows require manual coordination.
 
@@ -257,8 +261,8 @@ Subagent workflows require manual coordination.
 ~/.claude/
 ├── CLAUDE.md           # Registry + orchestrator workflows
 ├── agents/             # 11 subagent implementations (*.md)
-├── skills/             # 11 skills (subdirectories with SKILL.md)
-└── commands/           # 12 commands (*.md)
+├── skills/             # 9 skills (subdirectories with SKILL.md)
+└── commands/           # 8 commands (*.md)
 ```
 
 **Features**:
@@ -272,8 +276,8 @@ Subagent workflows require manual coordination.
 ~/.config/amp/
 ├── AGENT.md            # Reference doc (subagents + commands)
 ├── agents/             # 11 subagent implementations (*.md)
-├── skills/             # 11 skills (subdirectories with SKILL.md)
-└── commands/           # 12 commands (*.md)
+├── skills/             # 9 skills (subdirectories with SKILL.md)
+└── commands/           # 8 commands (*.md)
 ```
 
 **Features**:
@@ -285,7 +289,7 @@ Subagent workflows require manual coordination.
 ```
 ~/.factory/
 ├── AGENTS.md           # Reference doc (subagents + commands)
-└── commands/           # 23 commands (*.md)
+└── commands/           # 17 commands (*.md)
 ```
 
 **Features**:
@@ -297,7 +301,7 @@ Subagent workflows require manual coordination.
 ```
 ~/.config/opencode/
 ├── AGENTS.md           # Reference doc (subagents + commands)
-└── command/            # 23 commands (*.md)
+└── command/            # 17 commands (*.md)
 ```
 
 **Features**:
@@ -326,10 +330,10 @@ color: purple
 **Skills** (`skills/*/SKILL.md`):
 ```yaml
 ---
-id: test-driven-development
-name: test-driven-development
+id: tdd-flow
+name: tdd-flow
 description: Write test first, watch it fail, write minimal code to pass
-usage: /test-driven-development <feature-or-behavior-to-test>
+usage: /tdd-flow <feature-or-behavior-to-test>
 auto_trigger: true
 ---
 ```
@@ -337,11 +341,11 @@ auto_trigger: true
 **Commands** (`commands/*.md`):
 ```yaml
 ---
-id: debug
-name: debug
-description: Debug an issue systematically using structured investigation techniques
-usage: /debug <issue-description>
-argument-hint: [description of the problem]
+id: refactor
+name: refactor
+description: Refactor code while maintaining behavior and tests
+usage: /refactor <code-section>
+argument-hint: [file-or-function]
 ---
 ```
 

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

@@ -1,107 +0,0 @@
----
-name: code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - reviews implementation against plan or requirements before proceeding
-usage: /code-review <review-scope> <focus-areas>
-auto_trigger: false
----
-
-# Requesting Code Review
-
-Review code thoroughly to catch issues before they cascade.
-
-**Core principle:** Review early, review often.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Conduct code review:**
-
-Review implementation against requirements and plan
-
-**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
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-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)
-
-[Conduct code 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
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with Workflows
-
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-
-**Executing Plans:**
-- Review after each batch (3 tasks)
-- Get feedback, apply, continue
-
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: requesting-code-review/code-reviewer.md