askill
ultraqa

ultraqaSafety 82Repository

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

2.3k stars
46.1k downloads
Updated 3/21/2026

Package Files

Loading files...
SKILL.md

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:

InvocationGoal TypeWhat to Check
/ultraqa --teststestsAll test suites pass
/ultraqa --buildbuildBuild succeeds with exit 0
/ultraqa --lintlintNo lint errors
/ultraqa --typechecktypecheckNo TypeScript errors
/ultraqa --custom "pattern"customCustom success pattern in output

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

Cycle Workflow

Cycle N (Max 5)

  1. 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]")
      
  2. CHECK RESULT: Did the goal pass?

    • YES → Exit with success message
    • NO → Continue to step 3
  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.")
    
  4. 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.")
    
  5. REPEAT: Go back to step 1

Exit Conditions

ConditionAction
Goal MetExit with success: "ULTRAQA COMPLETE: Goal met after N cycles"
Cycle 5 ReachedExit with diagnosis: "ULTRAQA STOPPED: Max cycles. Diagnosis: ..."
Same Failure 3xExit early: "ULTRAQA STOPPED: Same failure detected 3 times. Root cause: ..."
Environment ErrorExit: "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

  1. PARALLEL when possible - Run diagnosis while preparing potential fixes
  2. TRACK failures - Record each failure to detect patterns
  3. EARLY EXIT on pattern - 3x same failure = stop and surface
  4. CLEAR OUTPUT - User should always know current cycle and status
  5. 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.

Install

Download ZIP
Requires askill CLI v1.0+

AI Quality Score

82/100Analyzed 3 weeks ago

Metadata

Licenseunknown
Version-
Updated3/21/2026
PublisherYeachan-Heo

Tags

ci-cdgithub-actionslintingllmsecuritytesting