A Claude Code Skill for QA Testing: Stop Shipping "QA Passed" Bugs

"QA passed" is the most expensive two words in a shipping log. The agent ran a pass, skimmed the happy path, confirmed its own work, and reported green — and then a real user opened the app and found something in an hour. The problem isn't that the agent can't test. It's that a one-shot "test the app" prompt has no exit condition, no memory of the failures that bit the last app, and no incentive to try and prove itself wrong. A QA-testing skill for Claude Code fixes exactly that: it turns the vague instruction into a loop with hard rules about when it's allowed to stop. This page is about the one AgentSource ships for the job — the Deep QA Audit Loop, $9 — and the two shipping skills that come after it once QA is actually clean. Every one carries a captured field report: real output from a documented run, readable before you pay.

What a QA skill is (and what "test the app" isn't)

A skill is a plain-markdown SKILL.md package — a folder of instructions the agent loads and follows, nothing to compile. The QA one encodes a discipline you'd otherwise have to remember to enforce by hand, every time, on every app. Three things separate it from a bare "test it" prompt:

• Exit conditions. The loop runs four passes — a broad sweep, a page-by-page end-to-end trace, an adversarial fix-verification pass, then a targeted re-audit — and it doesn't stop after a fixed number of rounds. It stops at zero critical bugs, or it keeps going. "I ran a pass" is not the same claim as "there are no criticals left," and only the second one is worth shipping on.
• A memory of real failures. The skill carries a catalog of bug classes — degenerate thresholds, type-discriminator fan-out, fire-and-forget writes, and more — each with the grep pattern that catches it, and each traced to the real (anonymized) incident that produced it. It hunts for failures it has already seen, not just whatever the model happens to notice on a given read.
• Adversarial verification. Pass 3 tries to refute its own fixes instead of admiring them. A verifier that returns silence is treated as a noisy measurement, never as a pass — because "no error printed" and "the fix works" are different facts.

The field report: a 365-day streak on a brand-new account

The proof that matters isn't the feature list — it's the captured run. The Deep QA Audit Loop's field report is a real Layer 3 (data & display) finding from a nutrition-tracking app in the same factory that produced these skills.

The app compared logged intake against a user-set daily target in 13 separate call sites (>= dailyTarget). For a brand-new user the target is 0 until calibration finishes — and anything >= 0 is always true. So every one of those 13 sites read "goal met" for someone who had done nothing: the streak calculator celebrated a 365-day "PERFECT" streak off one stray log, the daily ring rendered 100% complete on day one, the weekly report marked all seven days hit, and the badge triggers fired on the same false positives.

The part that earns the "loop, not a pass" framing: an earlier audit had already found this exact bug — and guarded exactly one of the 13 sites. The other 12 shipped across two-plus releases. The lesson the skill writes down from that: when you find a threshold bug, grep the threshold variable across the whole codebase in one pass; fixing the first site you see does not mean the rest are guarded. The fix in the report is a single hasCalibratedTarget guard at the shared computation layer so all 13 consumers gate on the same signal — plus an honest "set your target to start tracking" empty state where the false celebrations used to render. Then Pass 3 drove a fresh install (streak 0, empty state, no badge) and ran a refutation probe — target set, met, reset to 0 mid-streak — to confirm the guard doesn't retroactively wipe legitimate history. That's the finding format the loop produces, one of seven layers it runs.

The seven layers, briefly

A full run treats the app the same way across every layer: structural gaps, integration bugs, data and display edge cases (where the streak bug lived), crashes and security, UX flow, a live smoke test, and store-policy compliance folded in as a hard gate. The closing scorecard reports per-pass found / fixed / remaining counts and an explicit YES/NO on every exit condition — so "done" is a state you can read, not a vibe.

After QA is clean: the two shipping skills

Zero criticals is the gate, not the finish line — shipping has its own failure modes. Two skills pick up where the audit ends:

• App Review Pre-Submit Checklist ($9). The final gate before archive and upload. Every check in it exists because a real submission failed — the store-compliance layer catches documented rejection patterns before Apple does, not after a week in review.
• iOS Paywall Playbook ($9). The other thing that fails silently in production: the paywall. It's the monetization surface most likely to ship subtly broken, and it's the one worth its own audit before you submit.

Buy the set: the App Store Kit

Individually the QA loop, the pre-submit checklist, and the paywall playbook are $9 each. The App Store Kit issues all three for $29 alongside the keyword engine, screenshot playbook, and review-response skill — the whole ship-and-list arc in one requisition. If you're auditing before an App Store submission, that's the set that covers you from "find the bugs" through "pass review."

A closing note on what it doesn't do: it doesn't rubber-stamp. The loop is built to keep finding work until the exit conditions are genuinely met, and its field report is the actual captured audit — a real HIGH-severity bug, a real fix, a real adversarial re-check — not a marketing claim about thoroughness. You're buying proven gear, readable before you pay. Read the full field report, then decide.