Test smarter with Snagly: 30 open-source QA skills for AI coding agents

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 — 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.

📺 Watch the full walkthrough — installed from an empty folder, run against production, ~20 minutes.

What it is

Snagly is a free, MIT-licensed set of 30 skills for AI coding agents — GitHub Copilot, 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 is the front door — say "what can you test here?" and it routes you to the right skill, checking prerequisites before handing off.
• Discovery & strategy: 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.
• Execution: 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 verified flow into a permanent @playwright/test spec.
• The defect loop: 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.
• Specialized checks: 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.
• Site-wide audits: 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 & design: 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.
• Synthesis: 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.

The opinions baked in

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.

Getting started

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.

What it found on my own site

Here's the part I can't fake. My own site, in production, nothing fixed beforehand:

• A sitemap that doesn't exist. My robots.txt has been pointing search engines at a 404 for months.
• A critical accessibility bug on the signup page. The show/hide password toggles had no accessible name, so screen-reader users couldn't tell what they did — on the page where people create accounts.
• Nine pages sharing one title tag and one meta description, no canonicals, no Open Graph tags. That last one is why links to my site had been rendering blank previews.
• A pricing bug nobody would find by hand. One course is currently free. Shopify charges zero, correctly. The button on my own site still said $24.99 — caught only because it compared what the button claims against what checkout actually does.
• A background 406 on every enrolled course page, invisible in the UI, failing on every single load.

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.

The finding that was wrong

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.

Why the name

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.)

What's next

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 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 — 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