Install any skill in seconds. Free to start, no credit card required.
Get Started Free →kdlbs/qa
Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.
Passed 1 of 8 test cases with the skill, and 3 of 8 without it.
1 fixed3 passed either way14 still failing4 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
Run an adversarial QA pass on PR #310 which adds passwordless login via magic links. Start by establishing system expectations.
| Checked | Without skill | With skill |
|---|---|---|
| Identifies happy path user flow and system boundaries. | Missed | Passed |
| Maps external integration points and data flows. | Missed | Passed |
The instructions your model reads when the skill loads.
Run /qa only when the user explicitly requests adversarial validation or an
actionable PR/CI finding needs it. Do not add QA as a pre-PR quality gate:
task-defined tests and the two PR AI reviewers are the default evidence.
Verify that a feature works as intended after implementation. Assume bugs exist and hunt for them.
Mindset: you are not confirming it works — you are discovering where it breaks.
/tdd — Use when unit or integration coverage is missing./e2e — Use when a user-facing flow lacks browser coverage.Create these tasks immediately (use your task/todo tracking tool if available):
Mark each task in_progress when you begin it and completed when you finish it.
Mark task 1 as in_progress.
Read the task description, PR, or recent commits to understand what was built and what it should do. Identify:
test cases passed, vs 3 / 8 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.