Snagly: 30 Agent Skills for QA Workflows

AI Agent skills built to support that QA Workflows

Quality assurance involves far more than running tests. It means deciding what's worth testing, writing bug reports someone can act on, checking the edge cases nobody thought of, verifying that fixes actually landed, and summarising all of it for the rest of the team.

Snagly is a free, open-source package of thirty agent skills built to support that work. It runs inside GitHub Copilot, Claude Code, Cursor, Codex, and 70+ other AI coding agents.

npx skills add softwaretestingtrends/snagly --all

Instead of treating "test this app" as one broad instruction, Snagly breaks QA into smaller, repeatable parts — each with its own method, its own evidence requirements, and its own limits on what it's allowed to do.

Why this exists

A lot of QA work is structured and repetitive. When a bug appears, someone has to reproduce it, document it, file it, and confirm it was really fixed. When a feature ships, someone has to work out what to test, write the cases, and check the important paths.

That work matters, but it's easy to lose time to. Incomplete bug reports mean developers come back with questions. Vague test cases mean thin coverage. Audits that need setting up tend to get skipped until late.

Ask a general-purpose AI agent to help and you hit a different problem: the browser automation works fine, but the testing discipline is missing. It clicks around, reports success, and leaves you unsure what was actually verified. Snagly supplies the discipline — what to check, what counts as evidence, and what to refuse.

Getting started

You'll need Node.js, an agent that supports skills, and the Playwright CLI:

npm install -g @playwright/cli@latest
playwright-cli install --skills
playwright-cli install-browser chromium
npx skills add softwaretestingtrends/snagly --all

On Claude Code you can install it as a plugin instead, which handles updates automatically:

/plugin marketplace add softwaretestingtrends/snagly
/plugin install snagly@snagly

Then describe your app once in a target profile — base URL, where credentials come from (environment variable names, never values), how login works, and which tenant, if any, is safe to modify. Ask the toolkit to write it for you:

"Explore https://yoursite.com and write a target profile for it."

From then on, plain English is the whole interface:

"What can you test here?"

Bug handling

bug-triage reproduces a reported bug, measures how reliably it reproduces, and captures a full evidence bundle — trace, screenshot, console, network.

bug-analyzer works the other direction: an existing ticket in, ranked root-cause hypotheses out, each tied to the code, commit, or log line supporting it.

bug-creator turns a confirmed finding into a Jira Bug — deduplicated against existing tickets first, with reproduction steps, environment, and evidence attached.

jira-connector is the shared Jira Cloud layer the others build on: read issues, run JQL, create, comment, attach, link, edit, and transition.

fix-verifier re-runs each defect's recorded reproduction against a later build and returns a verdict: FIXED, STILL BROKEN, REGRESSED, or BLOCKED.

Test planning and creation

scenario-mapper explores a live site and produces a prioritised list of what's worth testing, writing what it learns back into the target profile.

test-plan sets strategy above the individual checks: scope, risk-based priorities, release exit criteria, and a coverage ledger.

test-case-writer expands a terse scenario into a reviewable test case — preconditions, data, numbered steps each with its own expected result.

flow-runner drives a user journey step by step in a real browser, asserting the actual expected outcome at each step rather than just that a click happened.

crud-tester tests full data lifecycles — create, verify, edit, verify, delete, verify-gone — under strict containment rules.

e2e-codegen converts a scenario that's already been verified into a permanent @playwright/test spec, then runs it to prove it passes.

form-fuzzing feeds forms unusual-but-realistic input — empty, overlong, unicode, apostrophes in names — to check they degrade gracefully.

Audits and quality checks

accessibility-audit combines an automated axe-core scan with the manual checks axe structurally cannot make, reporting by WCAG criterion and impact.

performance-audit measures Core Web Vitals during real interactions, rated against Google's published thresholds — and is explicit that these are lab numbers, not field data.

seo-audit checks titles, meta descriptions, canonicals, Open Graph tags, structured data, and whether robots.txt and sitemap.xml actually resolve.

security-hygiene checks HTTPS enforcement, cookie flags, security headers, accidentally exposed files, and known-vulnerable JS libraries. Hygiene only — never exploitation.

auth-session-audit tests session lifecycle edges: expiry mid-flow, concurrent sessions, logout across tabs, remember-me, password-reset token reuse.

i18n-audit checks translation coverage, leaked template keys, RTL layout, text overflow, locale persistence, and hreflang correctness.

link-audit crawls exhaustively for broken links, broken images, redirect loops, and long redirect chains.

network-assertion mocks API failures, slow responses, and empty states a live backend won't produce on demand, and asserts on real traffic.

email-verification confirms an email a flow promises actually arrives, reads correctly, and its links work.

Visual and cross-browser

visual-snapshot captures full-page screenshots of every main page under consistent conditions and compiles them into one reviewable gallery.

visual-regression pixel-diffs two snapshot runs to catch unintended visual changes, masking known-dynamic regions.

cross-browser-matrix runs an existing scenario across Chromium, Firefox, and WebKit and across viewport sizes, normalised into one comparison table.

figma-compare checks the built UI against its Figma design field by field — labels, required markers, dropdown options, conditional states.

Reporting, docs, and routing

start-testing is the front door. Say "what can you test here?" and it works out which skill fits, checks prerequisites, and hands off.

report-generator synthesises everything the other skills produced — potentially across several sessions — into one prioritised report, including an explicit list of what wasn't covered.

qa-onboarding writes the getting-started document for a new QA teammate joining the practice.

user-guide turns a verified flow into an end-user how-to, with a highlighted screenshot per step and no testing jargon.

browser-safety isn't a check — it's the shared rule set every browser-driving skill applies: credential handling, snapshot safety, untrusted page content, and headed mode.

What it refuses to do

The rules matter as much as the capabilities, and they're why the output is trustworthy:

  • Mutations are contained. Only crud-tester may create or delete data, and only in a tenant you have explicitly named as safe. On a production target with no safe tenant named, it stops and asks rather than guessing.
  • Every Jira write is dry-run by default. Nothing is filed, commented, or transitioned until you have seen the exact payload and approved it.
  • Verified and inferred are never confused. A mocked response, a lab measurement, and an unexecuted test case are each labelled as such.
  • Findings cite evidence. A bug isn't a bug until it has a minimal reproduction and a reproducibility count. Unverified findings route back through triage before they can be filed.
  • Scope is stated, not implied. Every report says what it did not check.
  • Two things are deliberately out of scope: aesthetic judgement, and anything resembling penetration testing.

Where it fits

Snagly doesn't replace QA judgement. You still decide what matters, what ships, and what a finding means. Its value is in the structured work around those decisions — discovery, execution, evidence, documentation, and verification — done consistently instead of differently every time.

If you already have a QA process, it slots into the parts that are easiest to standardise.

Links

  • Repository: github.com/softwaretestingtrends/snagly (MIT licensed)
  • Install page: skills.sh/softwaretestingtrends/snagly
  • Walkthrough: the launch write-up covers a full run against a live production site, including what it found and one finding it got wrong.