{"slug": "test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents", "title": "Test smarter with Snagly: 30 open-source QA skills for AI coding agents", "summary": "Snagly, a free MIT-licensed set of 30 skills for AI coding agents, aims to transform AI-driven testing from ad-hoc browser automation into disciplined QA practice. In a live test against its own production site, Snagly found eleven issues, including a critical accessibility bug, though one finding was incorrect. The toolkit, compatible with GitHub Copilot, Claude Code, Cursor, and others, emphasizes evidence-based verification and structured workflows.", "body_md": "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.\n\nThat gap is what **Snagly** is for.\n\nRather 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.\n\n📺\n\n— installed from an empty folder, run against production, ~20 minutes.[Watch the full walkthrough]\n\nSnagly 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.\n\nEach skill in Snagly has one job, and they hand off to each other the way a real testing practice does:\n\n`start-testing`\n\n`scenario-mapper`\n\nexplores your site and produces a prioritized list of test scenarios; `test-case-writer`\n\nexpands any of them into a reviewable spec; `test-plan`\n\nsets strategy, cadence, and release exit criteria; `qa-onboarding`\n\nwrites the guide for your next hire.`flow-runner`\n\ndrives real user journeys step by step, asserting outcomes (not just that clicks happened) and capturing evidence the moment anything fails. `crud-tester`\n\nis the only skill allowed to mutate data — under strict rules we'll get to. `e2e-codegen`\n\nconverts a `@playwright/test`\n\nspec.`bug-triage`\n\nreproduces a suspected bug and establishes a minimal repro with an evidence bundle; `bug-creator`\n\nfiles it in Jira — deduplicated against existing tickets first; `fix-verifier`\n\nre-runs the repro on later builds and tells you FIXED, STILL BROKEN, or REGRESSED. `bug-analyzer`\n\nworks the other direction: an existing ticket in, ranked root-cause hypotheses out.`network-assertion`\n\n(mock API failures and assert on real traffic), `cross-browser-matrix`\n\n, `auth-session-audit`\n\n, `form-fuzzing`\n\n, `email-verification`\n\n— each executing one kind of check properly.`accessibility-audit`\n\n(axe-core plus the manual checks axe can't do), `performance-audit`\n\n(Core Web Vitals), `seo-audit`\n\n, `i18n-audit`\n\n, `link-audit`\n\n, and `security-hygiene`\n\n.`visual-snapshot`\n\ncaptures a reviewable gallery of every page; `visual-regression`\n\npixel-diffs two captures; `figma-compare`\n\nchecks the built UI against its Figma design, field by field.`report-generator`\n\nturns 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`\n\n), the design side uses the Figma MCP server, and the Jira family talks to Jira Cloud through a dependency-free Python client.\n\nTools 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:\n\n**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`\n\nwill actively route an unverified finding back through `bug-triage`\n\nbefore filing, because one withdrawn false positive costs more credibility than ten good tickets earn.\n\n**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`\n\nrefuses to generate test code from a scenario that's never actually been run — that would bake untested assumptions into something that looks authoritative.\n\n**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.\n\n**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.\n\n**Knowledge compounds.** A target profile (`targets/*.yaml`\n\n) 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.\n\nYou'll need Node.js, an agent that supports skills, and the Playwright CLI (`npm install -g @playwright/cli@latest`\n\n, then `playwright-cli install --skills`\n\n). Then install Snagly:\n\n```\nnpx skills add softwaretestingtrends/snagly --all\n```\n\nOn Claude Code you can install it as a plugin instead, which handles updates for you:\n\n```\n/plugin marketplace add softwaretestingtrends/snagly\n/plugin install snagly@snagly\n```\n\nPoint it at your app by copying `targets/example.yaml`\n\ninto your project and filling in the base URL, where credentials live (env vars — never in the file), and the login recipe. Then just ask:\n\n\"What can you test here?\"\n\n`start-testing`\n\ntakes it from there — you don't have to know which of the thirty skills you need.\n\nHere's the part I can't fake. My own site, in production, nothing fixed beforehand:\n\n`robots.txt`\n\nhas 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.\n\nOne 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.\n\nIt 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`\n\n. 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.\n\nI 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.\n\nI'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.\n\nThe full prerequisites (including the optional Figma, Jira, and email-testing setups) are in the [README](https://github.com/softwaretestingtrends/snagly).\n\nIf 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*.)\n\nSnagly 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`\n\naway). It's also been submitted to the Claude Code community plugin marketplace — once listed there, it'll be browsable directly from `/plugin`\n\nwith no marketplace-add step.\n\nPart 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.\n\nI'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.\n\n*— Ambreen Khan, Software Testing Trends*", "url": "https://wpnews.pro/news/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents", "canonical_source": "https://dev.to/ambytious/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents-1571", "published_at": "2026-08-05 03:54:05+00:00", "updated_at": "2026-08-05 04:14:55.735963+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products", "ai-tools", "ai-safety"], "entities": ["Snagly", "GitHub Copilot", "Claude Code", "Cursor", "Codex", "Playwright", "Figma", "Jira"], "alternates": {"html": "https://wpnews.pro/news/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents", "markdown": "https://wpnews.pro/news/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents.md", "text": "https://wpnews.pro/news/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents.txt", "jsonld": "https://wpnews.pro/news/test-smarter-with-snagly-30-open-source-qa-skills-for-ai-coding-agents.jsonld"}}