| name | ulw-qa |
| description | [omh] Hermes UltraQA workflow: adversarial QA and fix loops. Use when the user says: ultraqa, adversarial qa, hostile scenarios, e2e qa, real-world qa, qa scenario, release qa, 장애 상황. |
Ultraqa
This is a Hermes-native ultraqa workflow skill.
Why This Exists
ultraqa exists to keep verification work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.
Do Not Use When
- The request is casual chat, a status-only acknowledgement, or another workflow has stronger routing evidence.
- The user needs implementation, review, CI, merge, or external publishing evidence that has not been delegated or observed.
Examples
Good example:
- Prompt: $ultraqa test the setup wizard with hostile install paths, stale config, and missing PATH cases.
- Expected behavior: Generate adversarial QA scenarios, expected signals, observed results, and fix-or-retry routing.
- Why: The request asks for verification pressure and hostile scenarios.
Bad example:
- Prompt: ultraqa: treat casual chat or unaccepted work as if this workflow already produced verified results.
- Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing
ultraqa.
- Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.
Completion Checklist
- The scenario, expected behavior, observed result, and pass/fail basis are named.
- Proposed fixes are separated from observed QA evidence.
- Missing or failed verification routes back to plan, fix, or a narrower test.
Recovery Notes
- If the expected behavior is unclear, route back to plan before running adversarial checks.
- If verification fails, return to fix or research with the failed signal instead of advancing.
Workflow Lane
- Current lane: Coding handoff (
idea-to-deploy, cto-loop, deploy-and-monitor, code-review, build-failure-triage, verification-gate, security-safety-review, ultrawork, +6 more) - coding owners, handoffs, review, CI, and merge evidence.
- If intent belongs to another lane, hand back to
oh-my-hermes or name the adjacent workflow.
- Shared product, routing, compatibility, and evidence rules:
omh-routing/references/skill-common-rail.md.
Use When
Use when the task needs adversarial test scenarios, verification, and fix loops.
Strong routing signals: `ultraqa`, `$ultraqa`, `adversarial qa`, `hostile scenarios`, `e2e qa`, `real-world qa`, `qa scenario`, `release qa`, `장애 상황`, `쿠버네티스 장애`, `적절히 진단`, `검증 체크리스트`, `릴리즈 전 gate`
Catalog Metadata
Category: verification
Phase: qa
Hermes role: reviewer
Quality tier: scenario-gated
Reasoning demand: standard
Quality bar:
- Do not start this engine as an automatic continuation of another skill's output: an accepted plan, a clarified brief, or a routing recommendation is planning evidence, not permission. Unless the user explicitly invoked this engine themselves, restate in one line what will start (engine, scope, selected executor) and wait for the user's explicit go-ahead first.
- Generate hostile scenarios from changed behavior and known risk areas.
- Report pass/fail evidence separately from proposed fixes.
- Delegate code mutations discovered by QA to the selected coding executor.
- When Hermes owns the coding path, read
hermes_coding_harness/v1 before saying build, verification, review, docs, or PR-prep evidence exists.
Handoff policy:
Hermes can design scenarios and report observed results; code fixes discovered by QA should become selected executor/runtime handoffs.
Required inputs:
- changed behavior
- acceptance criteria
- known risk areas
Expected outputs:
- adversarial scenarios
- pass/fail evidence
- fix recommendations
Artifact expectations:
- QA scenario evidence
- runtime verification summary
Safety rules:
- Do not imply hidden Hermes runtime behavior.
- Use the smallest verification that can prove the claim.
Runtime Evidence
Preferred harness for this skill: qa-specialist.
omh runtime record --skill ultraqa --harness qa-specialist --status started
Record observed delegation results; otherwise return not_available or not_observed.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- When wrapper metadata includes
memory_review_card/v1 or handoff_context_pack/v1, treat it as reviewed OMH-local or wrapper-supplied context only. Use conflict-free context summaries to shape plans and handoffs, but do not claim Hermes internal memory was read or changed.
Preserve workflow intent and stop conditions; verify before claiming completion.
Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.
