ultraqa
An autonomous agent skill that iteratively performs quality checks and fixes until the target project state is satisfied.
Install
mkdir -p .claude/skills/ultraqa && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4563" && unzip -o skill.zip -d .claude/skills/ultraqa && rm skill.zipInstalls to .claude/skills/ultraqa
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
QA cycling workflow - test, verify, fix, repeat until goal metKey capabilities
- →Executes autonomous QA cycles
- →Performs build, lint, and test checks
- →Resolves linting errors iteratively
- →Verifies typecheck status
- →Uses a deterministic fix-and-retry loop
How it works
Runs an automated feedback loop where commands are executed, results parsed, and failures addressed until the exit criteria are met.
Inputs & outputs
When to use ultraqa
- →Automating test suite verification
- →Running build checks after code changes
- →Resolving linting errors programmatically
About this skill
UltraQA Skill
[ULTRAQA ACTIVATED - AUTONOMOUS QA CYCLING]
Overview
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
Relationship to /goal, Ralph, Team, and Ultragoal
UltraQA owns repeated quality-gate cycling only. Use the deterministic conflict policies refuse, adopt_existing, and artifact_only rather than non-deterministic warning handling. Use it after the target behavior is known and the remaining question is whether tests, build, lint, typecheck, or another explicit QA condition passes. If Claude Code /goal is active, UltraQA may produce visible command evidence for that goal, but must not describe the /goal evaluator as independently running commands or reading files. If Ralph or Team is active, UltraQA is a verification/fix sub-loop under that authority rather than a competing session loop. If no active loop is safe, record QA expectations and evidence in artifact-only Ultragoal notes instead of claiming automatic execution.
Goal Parsing
Parse the goal from arguments. Supported formats:
| Invocation | Goal Type | What to Check |
|---|---|---|
/oh-my-claudecode:ultraqa --tests | tests | All test suites pass |
/oh-my-claudecode:ultraqa --build | build | Build succeeds with exit 0 |
/oh-my-claudecode:ultraqa --lint | lint | No lint errors |
/oh-my-claudecode:ultraqa --typecheck | typecheck | No TypeScript errors |
/oh-my-claudecode: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:Task(subagent_type="oh-my-claudecode:qa-tester", model="sonnet", prompt="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
Task(subagent_type="oh-my-claudecode:architect", model="opus", prompt="DIAGNOSE FAILURE: Goal: [goal type] Output: [test/build output] Provide root cause and specific fix recommendations.") -
FIX ISSUES: Apply architect's recommendations
Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="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
Track state in .omc/ultraqa-state.json:
{
"active": true,
"goal_type": "tests",
"goal_pattern": null,
"cycle": 1,
"max_cycles": 5,
"failures": ["3 tests failing: auth.test.ts"],
"started_at": "2024-01-18T12:00:00Z",
"session_id": "uuid"
}
Cancellation
User can cancel with /oh-my-claudecode: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
IMPORTANT: Delete state files on completion - do NOT just set active: false
When goal is met OR max cycles reached OR exiting early:
# Delete ultraqa state file
rm -f .omc/state/ultraqa-state.json
This ensures clean state for future sessions. Stale state files with active: false should not be left behind.
Parallel session caveats
- Multi-repo workspace anchor: drop a
.omc-workspacemarker at the parent directory so multiple sessions across sub-repos share one.omc/. Resolution order:OMC_STATE_DIR > .omc-workspace > git > cwd. Seedocs/REFERENCE.md. - Session id source: OMC_SESSION_ID env var wins in CLI contexts; hook payload data.session_id wins in hook contexts.
- Plan id (when applicable): UltraQA state is session-scoped. Mutual-exclusion with ralph applies only within the same session.
- Parallel verdict: supported (session-scoped state)
Begin ULTRAQA cycling now. Parse the goal and start cycle 1.
When not to use it
- →Non-automated environments
- →Manual exploratory testing
Prerequisites
Limitations
- →Limited to a maximum of 5 cycles
- →Requires well-defined error conditions
How it compares
Functions as a continuous sub-loop that persists until quality conditions are satisfied, unlike a one-off command runner.
Compared to similar skills
ultraqa side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| ultraqa (this skill) | 1 | 2mo | Review | Advanced |
| dev | 2 | 6mo | Review | Advanced |
| overnight-development | 1 | 27d | Review | Intermediate |
| nx-run-tasks | 1 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Yeachan-Heo
View all by Yeachan-Heo →You might also like
dev
atopile
LLM-focused workflow for working in this repo: compile Zig, run the orchestrated test runner, consume test-report.json/html artifacts, and discover/debug ConfigFlags.
overnight-development
jeremylongshore
Automates software development overnight using git hooks to enforce test-driven Use when appropriate context detected. Trigger with relevant phrases based on skill purpose.
nx-run-tasks
nrwl
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
deepgram-ci-integration
jeremylongshore
Configure Deepgram CI/CD integration for automated testing and deployment. Use when setting up continuous integration pipelines, automated testing, or deployment workflows for Deepgram integrations. Trigger with phrases like "deepgram CI", "deepgram CD", "deepgram pipeline", "deepgram github actions", "deepgram automated testing".
gsd-add-tests
phorde
Generate tests for a completed phase based on UAT criteria and implementation
spec-driven-workflow
CafeSemCafeina
The build workflow for avaliador-tech-recruiter — risk-ordered tiers with a protected mock-mode floor, a Ready spec required before any unit is implemented, eval gates (L0 contract / L1 policy / L2 fixtures) as the merge filter, package partitioning for parallel agents, atomic Conventional Commits,