qa-only

name	qa-only
description	Run browser-first QA in OpenCode, capture evidence, and write a structured report without modifying source code or suggesting fixes.
compatibility	opencode
metadata	{"host":"opencode","migration_phase":"11","mode":"report-only"}

What This Skill Does

This is the first OpenCode-native /qa-only slice for gstack. It runs browser-driven QA, captures evidence, and writes a structured report.

In this v1 slice:

• test the target like a user
• capture screenshots and console evidence
• classify issues by severity and category
• compute a health score
• write outputs under .gstack/qa-reports/

Do not modify source code in this v1 QA workflow. Do not run a fix loop. Do not create commits. Do not suggest fixes in the report. Use /qa when the user wants the test-fix-verify loop.

Required Inputs

You need an explicit target URL or local page path for this version.

• Good: http://localhost:3000
• Good: http://127.0.0.1:4173/qa-eval.html --quick
• Good: https://staging.example.com/settings

If no target is provided, ask for one using the host's normal user-question tool.

Prerequisites

Load the browse skill first and use it to determine the local browser binary setup.

Use these shared repo assets:

• report template: qa/templates/qa-report-template.md
• issue taxonomy: qa/references/issue-taxonomy.md

Write outputs here:

• report: .gstack/qa-reports/qa-report-{slug}.md
• screenshots: .gstack/qa-reports/screenshots/
• baseline: .gstack/qa-reports/baseline.json

Execution Contract

• stay local and do not load unrelated skills
• in this v1 slice, write reports only; do not modify source code
• if the request gives exact report or baseline output paths, use those exact paths instead of generating alternate filenames
• create screenshot artifacts under .gstack/qa-reports/screenshots/
• in quick mode, keep the report bounded to 2-4 high-confidence issues

Modes

Quick

Use when the request includes --quick.

• verify the page loads
• capture an annotated screenshot
• check console --errors
• inspect top navigation and obvious actions
• report only the highest-confidence issues

For this v1 slice, keep quick mode bounded. Run this exact sequence unless one command clearly fails:

mkdir -p .gstack/qa-reports/screenshots
$B goto <target-url>
$B snapshot -i -a -o .gstack/qa-reports/screenshots/initial.png
$B console --errors
$B links
$B viewport 375x812
$B snapshot -a -o .gstack/qa-reports/screenshots/mobile.png

If the mobile capture step fails, continue with the annotated screenshot and state that mobile capture was skipped.

Full

Default when --quick is not present.

• orient on the target page
• inspect interactive elements with snapshot -i
• test core links, controls, and forms
• check console and visible page state after interactions
• use responsive checks when the page appears user-facing
• document 3-10 high-confidence issues with evidence

Workflow

1. Initialize

• ensure .gstack/qa-reports/screenshots exists
• copy the structure of qa/templates/qa-report-template.md
• record target URL, mode, timestamp, branch, and commit if available
• if the request gives explicit report or baseline output paths, use those exact paths

2. Orient

• navigate to the target
• run an annotated snapshot for the landing page
• run console --errors
• map obvious links and interactive elements

3. Explore

Use qa/references/issue-taxonomy.md as the classification source.

For each page or major state you inspect:

• look for layout breaks, clipped text, missing images, and obvious accessibility issues
• click buttons and links that are visible and safe to test
• test forms with harmless sample values when appropriate
• use snapshot -D after meaningful interactions
• re-check console errors after interactions

4. Document

Document issues as you find them. Do not batch everything at the end.

Use literal issue IDs in order: ISSUE-001, ISSUE-002, ISSUE-003, and so on.

Each issue needs:

• title
• severity
• category
• page URL
• short expected-vs-actual description
• reproduction steps
• screenshot evidence

Use categories and severity labels from qa/references/issue-taxonomy.md.

5. Score

Compute a simple health score using the same categories as qa/templates/qa-report-template.md.

Minimum categories to score:

• Console
• Links
• Visual
• Functional
• UX
• Performance
• Accessibility

Use conservative scoring. Do not invent precision you cannot support with evidence.

6. Write Outputs

Write the final report under .gstack/qa-reports/ and keep screenshot paths relative to that report.

If the request gives an exact report path, write to that exact file path.

Also write a small baseline.json with:

{
  "url": "<target>",
  "healthScore": 0,
  "issues": []
}

If the request gives an exact baseline path, write to that exact file path.

If you could not complete the full flow, still write a partial report and clearly mark what was covered versus skipped. If any browser command fails after partial evidence has already been captured, still write the report and baseline with the evidence you do have.

In quick mode, each issue heading must start with its literal issue ID, for example ### ISSUE-001: Broken link.

If the repository has no test framework or test directories, note this in the report summary: No test framework detected. Run /qa to bootstrap one and enable regression test generation.

Rules

• Prefer direct browser evidence over speculation
• Re-check console after interactions, not just after first load
• Use snapshot -D whenever an interaction should visibly change page state
• After creating screenshots, read them so the user can see the evidence
• Keep the report honest: only include issues you actually observed
• Do not modify code, tests, configs, or docs in this v1 QA workflow
• Do not suggest fixes or implementation changes in the report
• Do not claim regression comparisons unless you actually compared against a baseline