skill
Verify the running thing works. Browser walks for web, request replay for APIs, shell smoke for CLIs, consumer builds for libraries, tool-call replay for MCP. "Tests pass" is not QA. Use when: "run QA", "verify the feature", "test this", "check the app", "exploratory test", "QA this PR", "smoke test", "manual testing", "capture evidence". For generated repo QA skills, use /create-repo-skill qa. Trigger: /qa.
/qa
Source: skills/qa/SKILL.md
Verify the running thing works. Browser walks for web, request replay for APIs, shell smoke for CLIs, consumer builds for libraries, tool-call replay for MCP. "Tests pass" is not QA. Use when: "run QA", "verify the feature", "test this", "check the app", "exploratory test", "QA this PR", "smoke test", "manual testing", "capture evidence". For generated repo QA skills, use /create-repo-skill qa. Trigger: /qa.
Verify primitive in the Harness Kit operating loop.
This generated excerpt gives readers the beginning of the live primitive contract before they jump to GitHub.
**Every app has a QA path.** The question this skill answers first is not
"how do I drive a browser?" — it's "what shape is this app, and what does
verifying it actually look like here?" A CLI is QA'd with shell
invocations and exit-code audits. An API is QA'd by replaying requests
against a preview deploy. A Next.js app is QA'd by walking golden paths
in a browser. A library is QA'd by installing it into a sandbox consumer.
An MCP server is QA'd by replaying tool calls through the harness that
registered it. None of these are optional; all of them are QA.
The skill's job is to route to the right shape, then either defer to a
project-local QA skill that encodes this repo's actual paths, or run a
quick protocol on the fly.
## Hardening Hook
Route to `/hardening acceptance` when QA relies on examples whose values should
matter: Gherkin scenarios, API fixtures, CLI transcripts, golden files,
seeded workflows, screenshots with asserted data, or contract examples. QA can
still pass without it when the check directly drives the live behavior, but the
report must name whether acceptance mutation was run, waived as not useful, or
left as residual risk.
## Completion Gate
Every QA pass/fail report includes:
See `harnesses/shared/AGENTS.md` (Completion Evidence) for the shared evidence
core; this phase keeps QA-specific local fields.
```markdown
## Completion Gate
- Exact end-user behavior verified: user or operator behavior exercised through the running surface.
- App shape and live path chosen: browser, API, CLI, library, MCP, hybrid, or other concrete surface.
- Value proposition exercised: specific promised outcome the QA walk covered.
- Persona outcome observed: persona-specific success or failure observed in the run.
- Live repo evidence read: package/config/docs/routes/commands/tests used to choose the QA path.
...