Oh-my-codex ultraqa

QA cycling workflow - test, verify, fix, repeat until goal met

install

source · Clone the upstream repo

git clone https://github.com/Yeachan-Heo/oh-my-codex

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/Yeachan-Heo/oh-my-codex "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/ultraqa" ~/.claude/skills/yeachan-heo-oh-my-codex-ultraqa && rm -rf "$T"

manifest: skills/ultraqa/SKILL.md

source content

UltraQA Skill

[ULTRAQA ACTIVATED - AUTONOMOUS QA CYCLING]

Overview

GPT-5.4 Guidance Alignment

Default to concise, evidence-dense progress and completion reporting unless the user or risk level requires more detail.
Treat newer user task updates as local overrides for the active workflow branch while preserving earlier non-conflicting constraints.
If correctness depends on additional inspection, retrieval, execution, or verification, keep using the relevant tools until the QA cycle is grounded.
Continue through clear, low-risk, reversible next steps automatically; ask only when the next step is materially branching, destructive, or preference-dependent.

You are now in ULTRAQA mode - an autonomous QA cycling workflow that runs until your quality goal is met.

Cycle: qa-tester → architect verification → fix → repeat

Goal Parsing

Parse the goal from arguments. Supported formats:

Invocation	Goal Type	What to Check
`/ultraqa --tests`	tests	All test suites pass
`/ultraqa --build`	build	Build succeeds with exit 0
`/ultraqa --lint`	lint	No lint errors
`/ultraqa --typecheck`	typecheck	No TypeScript errors
`/ultraqa --custom "pattern"`	custom	Custom success pattern in output

If no structured goal provided, interpret the argument as a custom goal.

Cycle Workflow

Cycle N (Max 5)

RUN QA: Execute verification based on goal type

```
--tests
```
: Run the project's test command
```
--build
```
: Run the project's build command
```
--lint
```
: Run the project's lint command
```
--typecheck
```
: Run the project's type check command
```
--custom
```
: Run appropriate command and check for pattern

--interactive

: Use qa-tester for interactive CLI/service testing:

delegate(role="qa-tester", tier="STANDARD", task="TEST:
Goal: [describe what to verify]
Service: [how to start]
Test cases: [specific scenarios to verify]")

CHECK RESULT: Did the goal pass?
- YES → Exit with success message
- NO → Continue to step 3

ARCHITECT DIAGNOSIS: Spawn architect to analyze failure

delegate(role="architect", tier="THOROUGH", task="DIAGNOSE FAILURE:
Goal: [goal type]
Output: [test/build output]
Provide root cause and specific fix recommendations.")

FIX ISSUES: Apply architect's recommendations

delegate(role="executor", tier="STANDARD", task="FIX:
Issue: [architect diagnosis]
Files: [affected files]
Apply the fix precisely as recommended.")

REPEAT: Go back to step 1

Exit Conditions

Condition	Action
Goal Met	Exit with success: "ULTRAQA COMPLETE: Goal met after N cycles"
Cycle 5 Reached	Exit with diagnosis: "ULTRAQA STOPPED: Max cycles. Diagnosis: ..."
Same Failure 3x	Exit early: "ULTRAQA STOPPED: Same failure detected 3 times. Root cause: ..."
Environment Error	Exit: "ULTRAQA ERROR: [tmux/port/dependency issue]"

Observability

Output progress each cycle:

[ULTRAQA Cycle 1/5] Running tests...
[ULTRAQA Cycle 1/5] FAILED - 3 tests failing
[ULTRAQA Cycle 1/5] Architect diagnosing...
[ULTRAQA Cycle 1/5] Fixing: auth.test.ts - missing mock
[ULTRAQA Cycle 2/5] Running tests...
[ULTRAQA Cycle 2/5] PASSED - All 47 tests pass
[ULTRAQA COMPLETE] Goal met after 2 cycles

State Tracking

Use

omx_state

MCP tools for UltraQA lifecycle state.

On start:

state_write({mode: "ultraqa", active: true, current_phase: "qa", iteration: 1, started_at: "<now>"})

On each cycle:

state_write({mode: "ultraqa", current_phase: "qa", iteration: <cycle>})

On diagnose/fix transitions:

state_write({mode: "ultraqa", current_phase: "diagnose"})

state_write({mode: "ultraqa", current_phase: "fix"})

On completion:

state_write({mode: "ultraqa", active: false, current_phase: "complete", completed_at: "<now>"})

For resume detection:
```
state_read({mode: "ultraqa"})
```

Scenario Examples

Good: The user says

continue

after the workflow already has a clear next step. Continue the current branch of work instead of restarting or re-asking the same question.

Good: The user changes only the output shape or downstream delivery step (for example

make a PR

). Preserve earlier non-conflicting workflow constraints and apply the update locally.

Bad: The user says

continue

, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.

Cancellation

User can cancel with

/cancel

which clears the state file.

Important Rules

PARALLEL when possible - Run diagnosis while preparing potential fixes
TRACK failures - Record each failure to detect patterns
EARLY EXIT on pattern - 3x same failure = stop and surface
CLEAR OUTPUT - User should always know current cycle and status
CLEAN UP - Clear state file on completion or cancellation

STATE CLEANUP ON COMPLETION

When goal is met OR max cycles reached OR exiting early, run

$cancel

or call:

state_clear({mode: "ultraqa"})

Use MCP state cleanup rather than deleting files directly.

Begin ULTRAQA cycling now. Parse the goal and start cycle 1.