qa-only

Overview of qa-only skill

qa-only is a report-only QA skill for cases where you want a web app tested, bugs documented, and evidence captured without any fixes being made. The qa-only skill is best for QA reviewers, product owners, and agents that need a clean bug-report workflow instead of a test-fix-verify loop. If your goal is “find issues and write them up,” qa-only is the right fit; if you want code changes, use /qa instead.

What qa-only is for

This skill focuses on structured QA output: health scoring, screenshots, repro steps, and a clear bug report. It is designed for “just check for bugs” and “test but don’t fix” requests, so it reduces ambiguity when the user wants evidence, not implementation.

Why qa-only is different

The main value of the qa-only skill is restraint. It routes the agent into reporting behavior and avoids accidental repair work, which matters when the deliverable is a review artifact, triage note, or handoff report. That makes qa-only for Qa especially useful in environments where fix actions are out of scope or risky.

Fit and misfit

Use qa-only when you need a QA pass on an existing application, especially for bug discovery, regression spotting, or a written assessment. Do not install it as a general testing assistant if you need code edits, refactors, or iterative bug fixing; the qa-only guide is intentionally report-first, not repair-first.

How to Use qa-only skill

Install and verify the skill

Use the repo-based install flow: npx skills add garrytan/gstack --skill qa-only. After install, confirm the skill files are present and readable in your skills directory before relying on it in production work. The qa-only install is useful only if your agent can actually load the skill context during QA runs.

Give it the right starting prompt

A strong qa-only usage prompt should specify the app, the test target, what “bug report only” means, and the boundaries. Good inputs look like: “Run qa-only on the checkout flow in staging, report visible bugs only, include repro steps and screenshot notes, do not suggest fixes.” Weak inputs like “QA this app” leave too much room for the model to guess scope and severity.

Read these files first

Start with SKILL.md, then inspect SKILL.md.tmpl to understand how the generated workflow is assembled. Because this repo does not ship extra rules/, resources/, or scripts, the two skill files are the real source of truth for behavior, triggers, and constraints. That is the fastest path if you want to understand qa-only before adopting it.

Use it in a practical QA workflow

A good qa-only guide workflow is: define the area to test, capture the expected behavior, let the skill run a focused review, then turn the output into a bug list or QA memo. If the first result is too broad, narrow the scope to one user journey, one device/browser, or one release candidate. The skill is strongest when the task is bounded and the report format is explicit.

qa-only skill FAQ

Is qa-only only for browser apps?

Mostly yes. qa-only is aimed at web application QA and bug reporting, so it fits UI flows, staging environments, and user journeys that can be observed and documented. It is less useful for backend-only validation or tasks where no visible product behavior exists.

How is it different from a normal prompt?

A normal prompt can ask for QA, but qa-only skill adds a consistent reporting posture and clearer behavior around “do not fix.” That reduces back-and-forth when the team needs a clean issue report rather than a mixed analysis-plus-implementation result.

Is qa-only beginner friendly?

Yes, if the user can name the app, the environment, and the goal. The main beginner mistake is underspecifying scope; the qa-only guide works best when you tell it what to test, what evidence to collect, and what not to do. Without that, the report may be too general to act on.

When should I not use qa-only?

Do not use qa-only if your real need is debugging, patching, or end-to-end fix verification. It is also a poor fit if you need deep test automation setup, infrastructure work, or anything that depends on write access to code changes.

How to Improve qa-only skill

Give tighter scope and stronger acceptance signals

The best way to improve qa-only output is to define one clear target and one clear success condition. For example: “Test the login form on mobile Safari, report broken validation, include steps, expected vs actual, and screenshot references.” That gives the skill a measurable frame instead of a vague audit request.

Add the evidence the report should include

If you want a more useful qa-only report, ask for specific artifacts: reproduction steps, affected URL or route, severity, frequency, and whether the issue is blocking, cosmetic, or intermittent. This is better than asking for “find bugs” because it forces structured findings that another person can act on quickly.

Watch for common failure modes

The most common failure mode is overbroad coverage: the agent tries to test everything and the report becomes shallow. Another failure mode is mixing fix intent into a report-only task, which weakens the qa-only purpose. If that happens, restate the request as “report only, no fixes, no code changes” and narrow the test surface.

Iterate from first report to second pass

Use the first pass to discover likely issues, then run a second qa-only pass on the most important bug paths. This is especially useful when the first report reveals one critical flow, but you want deeper confirmation on edge cases, browser differences, or repro reliability. Iteration is where qa-only becomes a dependable QA habit instead of a one-off prompt.