---
name: ironbee-verification
description: >
  MANDATORY verification after code changes. Activates when implementing features, fixing
  bugs, modifying UI components, API endpoints, styles, refactoring, or any task that changes
  application behavior. After editing code you MUST verify the changes before reporting task
  completion — and you verify by DELEGATING to the ironbee-verifier custom agent, never inline.
---

# IronBee Verification

> **Delegate — do NOT verify inline.** You verify by spawning the **`ironbee-verifier` custom agent** via `spawn_agent` with `agent_type="ironbee-verifier"` **and `fork_turns="none"`** (the default `fork_turns="all"` silently drops the agent_type → a generic toolless agent; not a generic "act as" agent either) and relaying its verdict. The verifier owns the devtools tools; you (the main agent) don't have them.

## Rule
No task is complete until your changes are verified through **real tools** — and you verify by
**delegating to the `ironbee-verifier` custom agent**, never inline. You do not have the
verification tools (browser / runtime / backend devtools); the verifier does. After delegating,
relay its verdict; on fail, fix the reported issues and re-delegate until it passes.

## How to verify — delegate
1. Finish your code edits.
2. Spawn the `ironbee-verifier` custom agent: call `spawn_agent` with `agent_type="ironbee-verifier"`
   AND `fork_turns="none"` (REQUIRED — the default `fork_turns="all"` silently drops the agent_type,
   giving a generic agent without the verification tools; not a generic "act as" agent either) with a
   prompt like *"Verify the recent changes"* (optionally describe what changed, or pass a
   scenario). It drives the verification tools, exercises every active cycle, and submits the
   single verdict in this **shared session** — then returns a short summary.
   **Wait for it in the same turn — do NOT background the verifier.** Let it run to completion
   and read its verdict before you respond. If the verifier is backgrounded, your turn can end
   (and the Stop gate fire) before its verdict is recorded, leaving your changes unverified.
3. **Relay the verdict.** If it FAILED: fix the issues it reported. Optionally record what you
   fixed so the next pass verdict can describe it:
   ```
   echo '{"fixes":["what you repaired"]}' | ironbee hook record-fix
   ```
   Then re-delegate. Repeat until it passes.

The Stop gate enforces this: it blocks completion until a verdict exists for your changes. Since
you can't verify inline, delegation is the only path forward.

## BANNED
- Trying to run the verification tools yourself (`bdt_*` / `ndt_*` / `bedt_*`) or
  `ironbee hook verification-start` / `submit-verdict` — those are the verifier's job. Delegate.
- Using the generic `spawn_agent` tool / a plain fork to "be" the verifier — that spawns a
  DEFAULT agent without the devtools. Spawn the `ironbee-verifier` custom agent via `spawn_agent` with `agent_type="ironbee-verifier"` and `fork_turns="none"`.
- Reporting a task complete without delegating verification of your changes.
- Claiming verification passed based on code reading, assumptions, or prior knowledge.
- Backgrounding the verifier custom agent (or ending your turn before it returns its verdict) —
  wait for it to finish in the same turn.

## Subagent teams
- Implementation subagents write code; they do NOT verify.
- Verification is ALWAYS delegated to the dedicated `ironbee-verifier` custom agent — it owns the
  per-cycle browser/node/backend flows and the verification tools. Each session's verification
  is isolated via session-specific verdict files.