Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add vinnie357/claude-skills --skill qagit clone --depth 1 https://github.com/vinnie357/claude-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vinnie357/claude-skills/qa)<a href="https://agentmods.dev/skills/vinnie357/claude-skills/qa"><img src="https://agentmods.dev/badge/skills/vinnie357/claude-skills/qa/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/vinnie357/claude-skills/qa"><img src="https://agentmods.dev/badge/skills/vinnie357/claude-skills/qa.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Rogue Agent · line 95 Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.Fix: Prevent the skill from modifying its own code, SKILL.md, or configuration files. Treat skill files as read-only at runtime.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00076 | $0.01883 |
| Opus 5 | $0.00038 | $0.00941 |
| Sonnet 5 | $0.00015 | $0.00377 |
| Haiku 4.5 | $0.00008 | $0.00188 |
Grade A, and why
qa scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA Workflow
A team-driven validation loop that exercises a running application against a Gherkin user story, treats every Then clause as a TDD assertion, and files behavior deltas as bees issues via the existing bees-manager agent.
Inputs
The /qa command expects:
- A path to a Gherkin user story under
docs/user-stories/<slug>.mdin the target repo. Paths outside that directory are rejected. - Optional
--fixflag to enable the fix loop after deltas are filed.
The /qa:new-story command expects a kebab-case slug; the file at docs/user-stories/<slug>.md must not already exist.
The accepted Gherkin dialect, parsing rules, and rejection criteria live in references/gherkin-format.md.
Stack Detection
The qa-lead agent probes the repo before decomposing work:
mix.exspresent → Phoenix path.qa-tidewavevalidates backend assertions.package.json+playwright.config.{ts,js,mjs}→ UI present.qa-playwrightdrives scenarios.- Neither → generic.
qa-backenduses HTTP/CLI/log probing through Bash. - Mixed (e.g. Phoenix + UI) → spawn both UI and backend workers; correlate by scenario name.
Full probe tree in references/stack-detection.md.
Worker Decomposition
One Scenario: block per worker. The lead assigns workers by the assertion targets in the Then clauses:
| Scenario type | Worker | Tools |
|---|---|---|
| UI flow (clicks, form fill, navigation) | qa-playwright | Playwright MCP browser tools |
| Phoenix runtime / DB / log assertions | qa-tidewave | Tidewave MCP tools |
| HTTP API / CLI / generic backend | qa-backend | Bash, WebFetch |
| Scenario asserts both UI and backend | qa-playwright + qa-tidewave (or qa-backend) | Both, correlated by scenario name |
The lead never runs validation itself — it spawns workers via the Task tool and aggregates their reports.
TDD Mapping
Each Scenario: is a TDD assertion against running application behavior. The standard Red-Green-Refactor loop maps directly onto Gherkin:
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 116 lines · 76 tokens per session scan A b87c4af9be24
qa is a skill published in the GitHub repository vinnie357/claude-skills (25 stars, last pushed 2d ago), licensed MIT. It adds 76 tokens to every session and 1,883 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other skills, from other repositories
nw-ad-critique-dimensions
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof.
nw-bdd-methodology
BDD patterns for acceptance test design - Given-When-Then structure, scenario writing rules, pytest-bdd implementation, anti-patterns, and living documentation.
testing
TDD/BDD testing principles. Use when writing tests, reviewing test coverage, setting up testing, or discussing test strategy and test architecture.
review-screenshot
A standard workflow for taking screenshots to check a user interface, using a dedicated review process for different verification modes.
testing-expert
Expert-level software testing with unit tests, integration tests, E2E tests, TDD/BDD, and testing best practices. Use when the user mentions TDD, BDD, unit tests, integration tests, or end-to-end tests, or when the task involves Testing Fundamentals, Unit Testing, Integration Testing, or End-to-End Testing.
test-writer
Write thorough tests following TDD and BDD principles.