QA Campaign — Testing skill for Claude Code

qa-campaign

A Claude Code skill for running a **pre-release QA campaign** on a product you can drive from the command line — and, more importantly, a set of rules that stop the campaign from lying to you.

It was used on one production release: a dozen gated processes, **79 defects found, 77 fixed** (the other two were product decisions). Every fix was verified in the running app; most carry a regression test that was watched fail before it was trusted, and the ones that don't say so.

What it actually gives you

The scripts are the cheap half. The valuable half is in [`SKILL.md`](SKILL.md) — fourteen rules, each of which earned its place on a real campaign:

• Gates, not a checklist. A flat list of N scenarios × M devices is never executed; a short list of gates with a hard stop at each one is.
• Inventory before catalogue — and then the absence sweeps, because deriving tests from the code enumerates what the app has and is structurally blind to what it lacks. That is where the dead "Privacy Policy" button and the settings screen that never names your server come from.
• Never one oracle. The screen, the client's own store, the server, and a reference implementation — and a rule for what to do when they disagree. The interesting defects live in the gap between two of them: an optimistic UI reporting success for a write the server refused is invisible to any single one.
• Seen red, always. A regression test does not exist until you have watched it fail.
• The harness is under test too. When your tool reports a defect, its first suspect is itself — a false positive costs more than a miss, because it trains you to ignore the tool. And it must never print a silent all-clear.

Before you run it

A campaign is not a read-only audit. It **installs and drives builds on real devices**, **signs in and writes to a server**, **changes your source** (fixes, tests, and deliberate breaks it undoes after), and **deletes the test