/verify

description: Verify code, architecture, or bug fixes using Chain-of-Verification

/verify Command (Software Engineering)

FIRST: Check for Empty Input

If the user runs `/verify` with no question (empty arguments or only whitespace), **OUTPUT the following help text directly to the user** (copy it verbatim as your response), then STOP:

## /verify - Chain of Verification

Verify code, architecture, or bug fixes by checking against requirements, not implementation.

**Usage:**
/verify <question>
/verify --quick <question>           # Fast check (haiku, 1 executor)
/verify --thorough <question>        # Deep check (opus, 4+ executors)
/verify --focus=security <question>  # Prioritize security tasks

**Options:**
| Flag | Short | Description |
|------|-------|-------------|
| --quick | -q | Fast verification, minimal depth |
| --thorough | -t | Comprehensive verification |
| --focus=X | -f X | Focus area: security, performance, api, testing, error-handling, style, scalability |

**Examples:**
- /verify How do I debounce in React?
- /verify --quick Is this null check right?
- /verify -t -f security Review the auth flow

**When to use:** Complex code, architecture decisions, bug investigations, API questions
**Skip for:** Typos, simple renames, obvious answers

**Do NOT proceed with verification if no question was provided. Just output the help above.**

---

Verify code, architecture decisions, and bug fixes using the Software Engineering Chain of Verification (SE-CoVe) pattern.

Usage

/verify <software engineering question or problem>
/verify --quick "Is this null check correct?"
/verify --thorough "Review this authentication flow"
/verify --focus=security "Analyze the login endpoint"

Command-Line Options

| Flag | Short | Description | |------|-------|-------------| | `--quick` | `-q` | Fast verification with minimal depth | | `--thorough` | `-t` | Comprehensive verification with maximum depth | | `--focus=X` | `-f X` | Prioritize a specific verification area | | (no flags) | | Standard verification (default) |

Focus Areas

• `security` - Authentication, authorization, input validation, injection vulnerabilities
• `performance` - Caching, async operations, memory usage, optimization
• `api` - Contracts, versioning, error responses, backwards compatibility
• `testing` - Test coverage, edge cases, integration tests, mock correctness
• `error-handling` - Exception handling, recovery strategies, logging, user feedback
• `style` - Naming conventions, code organization, documentation, types
• `scalability` - Horizontal scaling, bottlenecks, resource limits, connection pooling

Depth Configuration

| Preset | Executors | Test Execution | Doc Checks | Use Case | |--------|-----------|----------------|------------|----------| | `quick` | 1 | No | 1 source max | Simple questions, quick sanity checks | | `standard` | 2-3 | If critical | 2-3 sources | Most verifications (default) | | `thorough` | 4+ | Yes | Comprehensive | Complex features, security-critical code |

Model Selection by Depth

| Agent | quick | standard | thorough | |-------|-------|----------|----------| | baseline | haiku | opus | opus | | planner | haiku | opus | opus | | executor | haiku | haiku | opus | | synthesizer | haiku | opus | opus |

Description

This command implements a software engineering adaptation of the Chain of Verification pattern. The key insight: verification should check against **requirements**, not the (possibly flawed) implementation—the same principle as TDD.

When to Use

**Good candidates** (user manually invokes `/verify`):

• Complex code generation tasks
• Architectural decisions
• Evasive bug investigations
• Library/API usage questions
• Any time you'd normally use plan mode

**Skip verification for**:

• Trivial changes (typos, simple renames)
• Questions with obvious answers
• Creative/exploratory coding

How It Works

Execute a 4-step verification process using Task tool agents:

1. **Baseline** (opus): Generate solution with extracted technical claims 2. **Planner** (opus): Create verification tasks from claims (self-contained, no implementation details) 3. **Executor** (haiku): Execute tasks independently—**NEVER sees the draft solution** 4. **Synthesizer** (opus): Compare draft against verification, produce corrected solution

Orchestration Flow

1. User runs: /verify [options] "question"
   Example: /verify --thorough --focus=security "Review auth flow"
   (If no question provided, help was already shown - see top of file)

2. PARSE OPTIONS from the command:
   - Extract flags: --quick/-q, --thorough/-t, --focus=X/-f X
   - Determine depth: "quick", "standard" (default), or "thorough"
   - Extract focus area if provided: security, performance, api
   - Extract the question (everything after flags)

3. SELECT MODELS based on depth:
   - quick: haiku for all agents
   - standard: opus for baseline/planner/synthesizer, haiku for executor
   - thorough: opus for all agents

4. You (orchestrator) spawn cove-baseline agent
   → Model: based on depth selection
   → Receives: user's question
   → Returns: draft code + technical claims
   → You STORE this result

5. You spawn cove-planner agent
   → Model: based on depth selection
   → Receives: question + draft solution + depth + focus area (if any)
   → Returns: verification tasks (tests, doc checks, codebase searches)
   → Task count adjusted by depth
   → You EXTRACT the tasks

6. You spawn cove-executor agent(s)
   → Model: based on depth selection
   → Receives: ONLY the verification tasks (NO DRAFT!) + depth level
   → Count based on depth: quick=1, standard=2-3, thorough=4+
   → Returns: test code, documentation findings, codebase patterns, reasoning
   → This is where bugs get caught

   **Parallel Track Execution (thorough mode)**:
   In thorough mode, if the planner outputs tasks organized by verification tracks
   (Correctness, Security, Performance, Style), spawn one executor pe