# Test smarter with Snagly: 30 open-source QA skills for AI coding agents > Source: > Published: 2026-08-05 03:54:05+00:00 If you've experimented with AI-driven testing, you've probably lived this cycle: you ask an AI agent to "test the checkout flow," and it does *something* — clicks around, declares success, and leaves you unsure what was actually verified. The next day you ask again and it does something different. The browser automation works; the *testing discipline* is missing. That gap is what **Snagly** is for. Rather than describe it, I pointed it at [softwaretestingtrends.com](https://softwaretestingtrends.com) — my own production site, nothing fixed beforehand — and recorded the whole thing. It found eleven issues, including a critical accessibility bug on my own signup page. One of its findings turned out to be wrong, and I'll come back to that, because it matters more than the ones it got right. 📺 — installed from an empty folder, run against production, ~20 minutes.[Watch the full walkthrough] Snagly is a free, MIT-licensed set of 30 skills for AI coding agents — [GitHub Copilot](https://github.com/features/copilot), [Claude Code](https://claude.com/claude-code), Cursor, Codex and 70+ others — that turn "an AI that can drive a browser" into "an AI that tests like a QA professional." A skill, if you haven't met them yet, is a reusable instruction set that teaches the agent a specific working method — when to use it, what rigor it requires, what evidence to capture, and what it must never do. Each skill in Snagly has one job, and they hand off to each other the way a real testing practice does: `start-testing` `scenario-mapper` explores your site and produces a prioritized list of test scenarios; `test-case-writer` expands any of them into a reviewable spec; `test-plan` sets strategy, cadence, and release exit criteria; `qa-onboarding` writes the guide for your next hire.`flow-runner` drives real user journeys step by step, asserting outcomes (not just that clicks happened) and capturing evidence the moment anything fails. `crud-tester` is the only skill allowed to mutate data — under strict rules we'll get to. `e2e-codegen` converts a `@playwright/test` spec.`bug-triage` reproduces a suspected bug and establishes a minimal repro with an evidence bundle; `bug-creator` files it in Jira — deduplicated against existing tickets first; `fix-verifier` re-runs the repro on later builds and tells you FIXED, STILL BROKEN, or REGRESSED. `bug-analyzer` works the other direction: an existing ticket in, ranked root-cause hypotheses out.`network-assertion` (mock API failures and assert on real traffic), `cross-browser-matrix` , `auth-session-audit` , `form-fuzzing` , `email-verification` — each executing one kind of check properly.`accessibility-audit` (axe-core plus the manual checks axe can't do), `performance-audit` (Core Web Vitals), `seo-audit` , `i18n-audit` , `link-audit` , and `security-hygiene` .`visual-snapshot` captures a reviewable gallery of every page; `visual-regression` pixel-diffs two captures; `figma-compare` checks the built UI against its Figma design, field by field.`report-generator` turns everything the other skills produced — across sessions, across a whole testing cycle — into one prioritized report you can send to your team.Under the hood, the browser work runs on Playwright (via the Playwright MCP server or `@playwright/cli` ), the design side uses the Figma MCP server, and the Jira family talks to Jira Cloud through a dependency-free Python client. Tools are easy; discipline is hard. The value of these skills is less in what they *do* and more in what they *refuse to do*. A few principles run through the whole toolkit: **Evidence over vibes.** Every finding cites what was actually observed — the screenshot, the console error, the network response. A bug isn't a bug until it has a minimal repro and a reproducibility count. `bug-creator` will actively route an unverified finding back through `bug-triage` before filing, because one withdrawn false positive costs more credibility than ten good tickets earn. **Verified and inferred are never confused.** A mocked API response, a lab performance number, and a test case nobody has executed yet are all clearly labeled as such. `e2e-codegen` refuses to generate test code from a scenario that's never actually been run — that would bake untested assumptions into something that looks authoritative. **Mutations are contained.** Only one skill is allowed to create, edit, or delete data, and only in a tenant you've explicitly named as safe. Every record it creates carries a run marker, and cleanup is itself a test. Every Jira write in the toolkit is dry-run by default — nothing is filed, commented, or transitioned until you've seen the exact payload and said yes. **Explicit about what wasn't covered.** Every run report states its scope and its gaps rather than implying completeness. And two things are deliberately out of scope: aesthetic judgment (not checkable the way everything else is) and anything resembling penetration testing — the fuzzing and hygiene skills draw a hard line at injection payloads and exploit attempts. **Knowledge compounds.** A target profile (`targets/*.yaml` ) records everything the toolkit learns about your app — the login quirks, the safe tenant, the known console noise, the field that rejects "+" in phone numbers — so every run makes the next run cheaper instead of rediscovering the same facts. You'll need Node.js, an agent that supports skills, and the Playwright CLI (`npm install -g @playwright/cli@latest` , then `playwright-cli install --skills` ). Then install Snagly: ``` npx skills add softwaretestingtrends/snagly --all ``` On Claude Code you can install it as a plugin instead, which handles updates for you: ``` /plugin marketplace add softwaretestingtrends/snagly /plugin install snagly@snagly ``` Point it at your app by copying `targets/example.yaml` into your project and filling in the base URL, where credentials live (env vars — never in the file), and the login recipe. Then just ask: "What can you test here?" `start-testing` takes it from there — you don't have to know which of the thirty skills you need. Here's the part I can't fake. My own site, in production, nothing fixed beforehand: `robots.txt` has been pointing search engines at a 404 for months.And a result I didn't expect: performance came back **clean**. Core Web Vitals good across the board, with an unprompted note that these were lab numbers, not the field data Google grades against. A tool that only ever finds problems isn't measuring anything. One report said the login and signup pages had no visible focus indicator — a real WCAG failure if true. I tabbed through, and I could plainly see an orange focus ring. It was a false positive, and the cause is instructive. The check read computed styles after focusing elements *programmatically*, which doesn't reliably trigger `:focus-visible` . Frameworks that build their focus ring from CSS variables — Tailwind, in my case — read as fully transparent in that state while actually rendering perfectly. The tool measured a ring that hadn't been asked to appear yet. I shipped a fix the same day: that check may no longer report a failure from computed styles at all. It has to press Tab for real and compare a focused screenshot against an unfocused one. I'm telling you this because it's the honest answer to the question you should be asking about any AI testing tool: *what happens when it's wrong?* Here, a human caught it in thirty seconds, and the toolkit got permanently better. Nineteen of Snagly's improvements so far came from exactly this — using it for real and fixing what broke. The full prerequisites (including the optional Figma, Jira, and email-testing setups) are in the [README](https://github.com/softwaretestingtrends/snagly). If you've worked a release the traditional way, you know the **snag list** — the running register of every defect, rough edge, and "that's not quite right" that stands between a build and a sign-off. Snagly is a toolkit for building that list *properly*: every snag caught with evidence, reproduced before it's reported, tracked until it's verified fixed. (And yes, it's still in service of the Software Testing Trends motto — *learn smarter, test better*.) Snagly is MIT-licensed and open to contributions — new skills, better target-profile patterns, gotchas from your own Jira or app under test. [Star the repo](https://github.com/softwaretestingtrends/snagly) to follow releases (each one is tagged and versioned; updating is one `/plugin marketplace update snagly` away). It's also been submitted to the Claude Code community plugin marketplace — once listed there, it'll be browsable directly from `/plugin` with no marketplace-add step. Part two is coming: I fix the issues above, then put Snagly back on the site to verify the fixes independently and close the Jira tickets it opened. I'm also putting together a deeper guide on running an AI-augmented QA practice — how to adapt these skills to your own app, build new ones, and roll this out to a team. If you want that when it's ready, [subscribe here](https://www.youtube.com/@softwaretestingtrends) — and if you take Snagly for a spin this week, I'd genuinely love to hear what broke, what surprised you, and what's missing. *— Ambreen Khan, Software Testing Trends*