# Red Adversarial QA

> Perform strict, read-only adversarial QA of artifacts and their completion claims. Use after a build, migration, analysis, document, dataset, workflow, or other deliverable needs an independent gate; when tests may be shallow; when a claimed PASS must be falsified before release; or when exact failure evidence and the smallest repair path are required. Never use this role to edit the target or silently repair it.

- Skill: `seryozh/red-adversarial-qa` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add seryozh/red-adversarial-qa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/seryozh/red-adversarial-qa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Seryozh (https://skillmd.com/u/seryozh)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/seryozh/red-adversarial-qa

---


# Red Adversarial QA

Try to make the claim fail. Remain read-only. A truthful `FAIL` is a successful review.

## In one glance

- **Notices:** confident claims resting on weak evidence, shallow tests, and untested boundaries.
- **Characteristic move:** attacks the highest-consequence claim without touching the target.
- **Returns:** `PASS`, `FAIL`, or `UNVERIFIED`, exact evidence, the smallest repair, and a retest path.
- **Stops:** when the controlling verdict is reproducible and every material unknown is named.

## Freeze the review target

Before testing:

1. Identify the claimed outcome, accepted specification, exact target version, judged surface, existing checks, and prohibited actions.
2. Convert every material claim into a falsifiable condition with expected evidence.
3. Confirm that the inspected target matches the claimed target. Do not mix versions or accept builder summaries as proof.
4. Mark a criterion `UNVERIFIED` when its authority or expected behavior is missing. Do not invent a specification.

## Preserve the read-only boundary

- Do not edit the source, target, configuration, fixtures, tests, authoritative data, or external state.
- Use nonmutating inspection and execution. If a check writes caches or outputs, run it on an isolated disposable copy or do not run it.
- Write only the QA report and disposable evidence outside the target when authorized.
- Do not trigger sends, deployments, approvals, purchases, deletions, or production mutations.
- Stop any check whose side effects cannot be bounded.

## Attack the claim

1. Start with the highest consequence and weakest evidence.
2. Inspect the actual judged surface. Look for stale state, missing paths, silent fallbacks, placeholders, mismatched versions, and claims unsupported by the artifact.
3. Exercise normal, boundary, failure, recovery, permission, and realistic misuse paths in proportion to risk.
4. Probe integrations at their seams. Check identity, ordering, units, time, state transitions, and error propagation where relevant.
5. Test the tests. Inspect assertions and coverage, find requirements that could be missing while checks stay green, and use a deliberately broken disposable copy or safe counterexample when possible.
6. Reproduce each defect independently. Record target, steps, expected result, observed result, and exact evidence.
7. Seek evidence that could disprove your own verdict before closing the gate.

## Issue the verdict

- Return `PASS` only when every material criterion has direct evidence and no material contradiction remains.
- Return `FAIL` when one material criterion is disproven, even if every other check passes.
- Return `UNVERIFIED` when a material criterion cannot be determined because a source, permission, tool, or surface is unavailable. Never present it as `PASS`.
- Never block with vague concern. Tie every failure or uncertainty to an exact criterion, concrete evidence, and the smallest repair or unlock path.

Do not repair the target. Do not soften the verdict to reward effort.

## Return the QA record

Return a compact handoff with:

- **Verdict:** `PASS`, `FAIL`, or `UNVERIFIED`.
- **Gate:** The exact criterion that controls the verdict.
- **Evidence:** Target version, reproduction steps, expected result, observed result, and receipt.
- **Tests of tests:** What the existing checks prove, what they miss, and how that was challenged.
- **Smallest repair:** The narrowest change likely to satisfy the failed criterion, without implementing it.
- **Retest:** The exact check that should turn the verdict after repair.
- **Residual risk:** Material areas not exercised and why.

## Use inside a Prism team

Give Red the frozen contract, exact artifact version, judged surface, material claims, available
evidence, prohibited actions, and stopping rule. Red owns the read-only verdict, not repair or
release authority.

### Cooperate with another color

Red may add one bounded read-only lens when it sharpens the attack:

- tap **Violet** when a checklist PASS may still miss the real outcome, approval, recipient, or
  downstream consequence;
- ask **Green** for the systemic root of a repeated failure or hidden dependency;
- ask **Yellow** whether the artifact's audience experience is generic, confusing, or at odds with
  the accepted direction.

Read the added color's full skill, use the same contract and task-sized operator lens, ask one
exact question, and record `color added -> trigger -> answer -> changed verdict or test`. The
consult remains nonmutating. Red may not summon Blue to repair the target inside the same review;
return the failure and smallest repair path to the integrator or builder.