---
name: ultraqa
description: Adversarial QA pass that tests behavior, failures, and regressions. Use with /ultraqa after implementation when shallow checks are not enough.
---

# UltraQA

Use `/ultraqa` after implementation when shallow checks are not enough.

## When to use

- Changes are complete but you're not confident they're correct
- The change touches critical paths (auth, payments, data integrity)
- You need to verify edge cases, error paths, and regressions

## Do not use when

- A simple `npm test` is sufficient — use `/verify`
- You're still implementing — finish first, then QA

## Steps

Read `[OMP SESSION]` from SessionStart context, then register the QA run first:
`omp ultraqa start "<goal>" --max-cycles 5 --session-id "<session>"`. This
tracks the cycle count, binds nested execution to the active `/goal`, enforces
the cap, and lets `omp ultraqa status`/`cancel` see the run.

### Cycle 1 (and each subsequent cycle)

Number every cycle explicitly: "Cycle 1", "Cycle 2", etc.

1. **Identify test surface** — what changed, what could break
2. **Run existing tests** — baseline must pass before adversarial testing
3. **Test happy path** — primary use case works
4. **Test edge cases** — empty inputs, boundary values, concurrent access
5. **Test error paths** — timeouts, bad data, missing deps
6. **Test regressions** — did anything that previously worked now break?

### After each cycle

- Record the outcome: `omp ultraqa cycle fail` (issues found) or `omp ultraqa cycle pass` (clean). This records the verdict only; the agent-stop hook is the sole writer of the cycle counter and enforces the cap.
- If issues found → fix and start next cycle
- If clean → report PASS and run `omp ultraqa cancel` to clear the run
- Track which issues were found and fixed per cycle

## Early exit conditions

- **5 cycles reached** (enforced by the agent-stop hook) — stop, report remaining issues as known gaps
- **Same failure 3 consecutive cycles** — stop, this is a design issue not a bug. Report it for `/ralplan`
- **Critical regression found** — stop immediately, report before fixing anything else

## Severity routing

- **Critical** (data loss, security, crash) → immediate stop, fix before continuing
- **Major** (broken feature, wrong output) → fix in current cycle
- **Minor** (cosmetic, non-blocking) → log and continue, fix at end if time permits

## Rules

- Prefer runnable checks over inspection — run tests, don't just read code. For web UI flows, exercise the real page with `/qa-browse` rather than inspecting markup.
- If tests don't exist, write minimal ones that cover the change
- Route fixes back to `/ralph` or `/ultrawork` if they're substantial

## Output

- `Cycles` — how many iterations, what was found/fixed in each
- `Scenarios` — what was tested (happy, edge, error, regression)
- `Results` — PASS/FAIL with trend across cycles
- `Regressions` — anything that used to work but now doesn't
- `Known gaps` — remaining issues after max cycles