/do-and-judge

name: do-and-judge
description: Execute a task with sub-agent implementation and LLM-as-a-judge verification with automatic retry loop

do-and-judge

Task

Execute a single task by dispatching an implementation sub-agent, verifying with an independent judge, and iterating with feedback until passing or max retries exceeded.

Arguments

| Argument | Format | Default | Description | |----------|--------|---------|-------------| | `task` | Free-form text | **Required** | Task description to execute | | `--model` | `haiku\|sonnet\|opus` | *auto-selected* | Explicit user override for **all** sub-agents: implementation, meta-judge, and judge. When omitted, you MUST select the model per the [Model Selection Policy](#model-selection-policy) — there is no fixed fallback tier. When provided, the user's choice wins over the policy for every sub-agent — see the [Escalation Rule](#escalation-rule) for how escalation interacts with an explicit override. | | `--strict` | `--strict` | `false` | Disable the [Iteration Discretion Rule](#iteration-discretion-rule) - the task passes ONLY when `score >= 4.0`, otherwise retry until max retries is reached. |

Example: `/do-and-judge Refactor the UserService class to use dependency injection --strict`

Context

This command implements a **single-task execution pattern** with **meta-judge → LLM-as-a-judge verification**. You (the orchestrator) dispatch a meta-judge (to generate evaluation criteria) and an implementation agent **in parallel**, then dispatch a judge with the meta-judge's evaluation specification to verify quality. If verification fails, you launch new implementation agent with judge feedback and iterate until passing (score ≥4, or accepted per the [Iteration Discretion Rule](#iteration-discretion-rule)) or max retries (3) exceeded.

Key benefits:

• **Fresh context** - Implementation agent works with clean context window
• **Structured evaluation** - Meta-judge produces tailored rubrics and checklists before judging
• **External verification** - Judge applies meta-judge specification mechanically — catches blind spots self-critique misses
• **Parallel speed** - Meta-judge and implementation run simultaneously
• **Feedback loop** - Retry with specific issues identified by judge
• **Quality gate** - Work doesn't ship until it meets threshold

**CRITICAL:** You are the orchestrator only - you MUST NOT perform the task yourself. IF you read, write or run bash tools you failed task imidiatly. It is single most critical criteria for you. If you used anyting except sub-agents you will be killed immediatly!!!! Your role is to:

1. Analyze the task and select the model per the [Model Selection Policy](#model-selection-policy) — `sonnet`/`haiku` by default, `opus` only when earned 2. Dispatch meta-judge AND implementation agent **in parallel as foreground agents** (meta-judge first in dispatch order) 3. Dispatch judge agent with meta-judge's evaluation specification 4. Parse verdict and iterate if needed (max 3 retries) 5. Report final results or escalate

RED FLAGS - Never Do These

**NEVER:**

• Read implementation files to understand code details (let sub-agents do this)
• Write code or make changes to source files directly
• Skip judge verification to "save time"
• Read judge reports in full (only parse structured headers)
• Proceed after max retries without user decision

**ALWAYS:**

• Use Task tool to dispatch sub-agents for ALL implementation work
• Dispatch meta-judge and implementation agent in parallel (meta-judge FIRST in dispatch order)
• Wait for BOTH meta-judge and implementation to complete before dispatching judge
• Pass meta-judge evaluation specification to the judge agent
• Include `CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`` in prompts to meta-judge and judge agents
• Parse only VERDICT/SCORE/ISSUES from judge output
• Iterate with feedback if verification fails

Model Selection Policy

Picking the model is the **single highest-leverage decision** you make — more than any prompt wording, it decides whether the task comes back correct and how long it takes. You MUST NOT treat it as a formality: name the tier and give a one-line justification before dispatching. Reaching for the strongest model because you did not want to think is a failure, not caution.

**Tier default:** `sonnet` and `haiku` are the default. `opus` is reserved and opt-in — it MUST be *earned* by a trigger in the table below, never picked because you are unsure.

Selection Rules

| Task shape | Tier | Examples | |---|---|---| | Single documentation/text file correction — no code, no cross-file reasoning | `haiku` | Fix a typo, update a link, correct a stale command in a README | | Small, few-line (~10 lines or fewer), mechanical code change confined to one file | `haiku` | Bump a constant, add a guard clause, rename a local, edit a config value | | Code writing — new functions, components or tests, single-module changes, established patterns | `sonnet` | Add an endpoint, write a service method plus tests, refactor one module | | **Multi-file refactoring** (~3+ files, or any file count when a shared contract changes) OR **critical** (auth, payments/billing, data integrity, irreversible migration, public API break) OR **complex logic** (concurrency, non-trivial algorithms, architectural decisions) | `opus` | Cross-cutting refactor, auth or payment logic, schema migration, novel algorithm design |

**Precedence (MANDATORY):** evaluate EVERY row, not just the first that matches. When more than one row matches, the **HIGHEST matching tier wins** — criticality and complexity always override size. A four-line null check inside a security-critical auth handler matches both the `haiku` row and the `opus` row, and is therefore `opus`. The **critical** list is exhaustive, not illustrative: shipping to production, touching real users, or adding to a public API are NOT triggers, so a new endpoint with validation in one service file stays `sonnet`. **Mechani