/qa

name: qa
description: "General-purpose QA verdict for any artifact type"

/ouroboros:qa

Standalone quality assessment for any artifact — code, documents, API responses, test output, or custom content. Unlike `ooo evaluate` (3-stage formal verification pipeline), `ooo qa` is a fast single-pass verdict with actionable suggestions.

Usage

ooo qa [file_path | artifact_text]
ooo qa                                     # evaluate recent execution output
/ouroboros:qa [file_path | artifact_text]   # plugin mode

**Trigger keywords:** "ooo qa", "qa check", "quality check"

How It Works

The QA Judge evaluates an artifact against a quality bar and returns a structured verdict:

1. **Parse the Quality Bar** — What EXACTLY must be true to pass? 2. **Assess Dimensions** — Correctness, Completeness, Quality, Intent Alignment, Domain-Specific 3. **Render Verdict** — Score (0.0-1.0) with PASS / REVISE / FAIL 4. **Determine Loop Action** — `done` (pass), `continue` (revise), `escalate` (fail)

Verdict Thresholds

| Score Range | Verdict | Loop Action | |--------------|---------|-------------| | >= 0.80 | PASS | done | | 0.40 - 0.79 | REVISE | continue | | < 0.40 | FAIL | escalate |

Instructions

When the user invokes this skill:

Step 0: Determine execution mode

This skill works in two modes. Determine which one **before** attempting any tool calls:

• **MCP mode** — If the QA MCP tool is available (already exposed, or loadable via discovery), use it:

  tool discovery query: "+ouroboros qa"

If found (typically named `mcp__plugin_ouroboros_ouroboros__ouroboros_qa`), proceed with **QA Steps** below.

• **Fallback mode** — Only if the QA MCP tool is genuinely absent (no Ouroboros MCP server) skip to the **Fallback** section; an empty discovery result for an already-exposed tool is expected — call it directly rather than falling back. This skill is designed to work without MCP setup.

QA Steps (MCP mode)

1. **Determine the artifact to evaluate:**

• If user provides a file path: Read the file with Read tool
• If user provides inline text: Use that directly
• If no artifact specified: Look for the most recent execution output in conversation context
• Ask user if unclear what to evaluate

2. **Determine the quality bar:**

• If a seed YAML is available in context: Extract acceptance criteria from it
• If user specifies a quality bar: Use that
• If neither: Ask the user "What does 'good' mean for this artifact?"

3. **Determine artifact type:**

• `code` — source code files
• `test_output` — test results, CI output
• `document` — specs, docs, READMEs
• `api_response` — API responses, JSON payloads
• `screenshot` — visual artifacts
• `custom` — anything else

3.5. **Acting verification fan-out — probe in parallel, then judge (do not skip for behaviour-bearing artifacts):** A text judge can be fooled by a hopeful log line. When the artifact actually *does* something (code, an app, an API, a UI), fan out empirical probes using the host's native parallel sub-agent primitive — one probe sub-agent per acting modality the runtime actually exposes, all spawned **in the same message so they run concurrently**:

• **process probe** (`Bash`/shell): run the command / start the app / run

the declared smoke commands with bounded timeouts; capture exit codes and real output.

• **browser probe** (browser-use tools, when the artifact serves HTTP or is

a web UI): load it, click the primary flows, capture what actually renders and any console/network errors.

• **computer-use probe** (desktop computer-use tools, when the artifact is

a GUI/TUI): drive it like a user, screenshot the observed states.

• **artifact probe** (file reads): verify declared files/paths exist with

real content, not placeholders. Each probe returns structured evidence only — commands run, observed effects, screenshots/paths, pass/fail per probed behaviour. Every probe also hits the applicable adversarial classes (the QA tool lists them): `misleading_output` (claimed success vs. real effect), `hung_command` (bounded timeout?), `malformed_input`, `stale_state`, `dirty_worktree`. Skip a modality only when its tools are absent or the artifact type makes it meaningless — and say which modalities were skipped and why.

Await all probes, then pass the merged evidence into the judge as `reference` (prefer observed behaviour over source text as the `artifact` when they disagree). **Empirical evidence outranks the judge**: if the judge scores PASS but any probe observed the behaviour failing, present the verdict as REVISE/FAIL on that evidence and say so explicitly — a score contradicted by observation is not a pass. If no acting tools are available at all, judge on the text alone but flag that behaviour was not observed.

4. **Call the `ouroboros_qa` MCP tool:**

   Tool: ouroboros_qa
   Arguments:
     artifact: <the content to evaluate>
     quality_bar: <what 'pass' means>
     artifact_type: "code"  (or other type)
     reference: <observed-behaviour evidence from step 3.5, plus any reference>
     pass_threshold: 0.80  (adjustable)
     seed_content: <seed YAML if available>

5. **Present results clearly:**

• Show the score and verdict prominently
• List dimension scores
• Highlight specific differences found
• Show actionable suggestions
• End with next step guidance based on verdict:
• **PASS (done)**: `Next: Your artifact meets the quality bar. Proceed with confidence.`
• **REVISE (continue)**: `Next: Address the suggestions above, then run ooo qa again to re-check.`
• **FAIL (escalate)**: `Next: Fundamental issues detected. Consider ooo interview to re-examine requirements, or ooo unstuck to challenge assumptions.`

Iterative QA Loop

For iterative usage, track the `qa_session_id` and `it