| name | adversarial-verification |
| description | Use when verifying implementation work and the failure mode is superficial approval, code-reading in place of execution, or over-trusting a passing test suite without trying to break the change |
Adversarial Verification
Overview
Your goal is not to confirm the implementation works. Your goal is to try to break it.
This skill follows the built-in verification agent in src/tools/AgentTool/built-in/verificationAgent.ts and the coordinator guidance in src/coordinator/coordinatorMode.ts.
Opening Stance
Start from skepticism:
- a passing test suite is context, not proof
- polished UI is not proof
- code review is not proof
- implementer-provided evidence is not enough
Verification begins when you execute the change directly.
Mandatory Baseline
- Read the local build and test conventions.
- Run the build if applicable.
- Run the test suite if applicable.
- Run linters or type-checkers if configured.
- Exercise the changed behavior directly.
Do not stop at step 4. The direct exercise is the whole point.
Required Adversarial Probe
Every verification pass must include at least one probe aimed at failure, not success:
- concurrency
- boundary values
- idempotency
- malformed input
- missing or orphaned references
- restart or persistence behavior
If all you checked was the happy path, verification is incomplete.
Rules
- Reading code is not verification. Run it.
- "Tests already pass" is not verification. Verify independently.
- "Looks correct" is not verification. Run it.
- Do not issue PASS without command evidence.
- If a check has no executed command and observed output, it is a skip, not a pass.
Evidence Format
For each significant check, record:
- what you are verifying
- exact command run
- output observed
- expected versus actual when relevant
- PASS or FAIL
Common Probes
API or backend
- parallel requests
- invalid payloads
- duplicate mutation
- nonexistent resource identifiers
Frontend
- real browser or automation when available
- console errors
- broken subresources
- refresh persistence
- controls that render but do nothing
CLI
- malformed input
- empty input
- boundary flags
- stdout, stderr, and exit code
Failure Discipline
Before reporting FAIL, make sure the issue is real and actionable.
Check whether it is:
- already handled elsewhere
- documented as intentional
- impossible to change without breaking a hard external contract
Do not use those checks to excuse real bugs. Use them to avoid false alarms.
Anti-Patterns
- PASS based on code reading
- PASS based only on unit tests
- PARTIAL because you felt unsure
- re-running only the implementer's happy-path steps
- waving away suspicious output as unrelated without evidence
Done Condition
You have applied this skill correctly when your verification includes direct execution, at least one adversarial probe, and evidence strong enough that another reviewer could reproduce your conclusion.
