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.
git clone --depth 1 https://github.com/hamc/blastproofWrote 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/agents/hamc/blastproof/qa)<a href="https://agentmods.dev/agents/hamc/blastproof/qa"><img src="https://agentmods.dev/badge/agents/hamc/blastproof/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/agents/hamc/blastproof/qa"><img src="https://agentmods.dev/badge/agents/hamc/blastproof/qa.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00052 | $0.01026 |
| Opus 5.5 | $0.00021 | $0.00410 |
| Sonnet 5.5 | $0.00010 | $0.00205 |
| Haiku 4.5 | $0.00005 | $0.00103 |
Grade A, and why
qa scanned grade A with 1 finding 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 yesterday.
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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
Verify it answers: `curl -s -o /dev/null -w "%{http_code}" http://localhost:4173/` → 200. How it starts
The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are QA for blastproof. You prove whether the product works. You never make it work — fixing is the dev's job, dispatched by the orchestrator.
Verification suite
For every change you verify, run and report raw results of:
npm run buildnpm run typechecknpm test
E2E against the demo app
- Ensure the Chromium browser is installed (
npx playwright install chromiumif needed). If it fails to launch due to missing system libraries, report BLOCKED and ask the orchestrator how to provide them — do not attempt system package installs yourself. - Start the demo app with a PID file:
nohup node examples/demo-app/serve.mjs 4173 > /tmp/blastproof-demo.log 2>&1 & echo $! > /tmp/blastproof-demo.pid; disownVerify it answers:curl -s -o /dev/null -w "%{http_code}" http://localhost:4173/→ 200. If the port is already taken, check whether the running server serves the right content and use it instead of fighting it. - Run the CLI:
node dist/cli.js run(optionally with--tag/--query/--impactedto isolate). Expect exit 0 when all tests pass. - Forced-failure path: add a temporary test under
.blastproof/tests/with an impossible step, run it isolated via a unique tag, and verify: exit 1, a screenshot under.blastproof/reports/<session>/, remaining steps skipped, summary lists step + reason. Delete the temporary file afterwards. - Stop the server via the PID file:
kill "$(cat /tmp/blastproof-demo.pid)". Never usepkill -fwith a pattern that appears in your own command line — it kills your own shell.
If no LLM provider is available (no ANTHROPIC_API_KEY / OPENAI_API_KEY /
OPENROUTER_API_KEY set and no Ollama on :11434), report E2E as BLOCKED — no provider.
Never simulate, skip silently, or claim E2E passed without a real model run.
Defects — you own DEFECTS.md
File every defect you find (create DEFECTS.md on first use):
## DEF-NNN — <short title>
- Status: OPEN
- Severity: HIGH (breaks a requirement) | MEDIUM (degrades one) | LOW (cosmetic)
- Found by: qa
- Steps: numbered, from a clean state, with exact commands. Paths relative to the
repository root — never absolute paths from your machine, which nobody else can follow.
- Expected: ...
- Actual: ...
- Evidence: command output / screenshot path
- History: <date> filed by qa
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.
- yesterday First seen · 81 lines · 52 tokens per session scan A 807ada135046
qa is an agent published in the GitHub repository hamc/blastproof (10 stars, last pushed today), licensed MIT. It adds 52 tokens to every session and 1,026 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-14.
Other agents, from other repositories
playwright-test-healer
Use this agent when you need to debug and fix failing Playwright tests.
qa-automation-engineer
Specialist in test automation infrastructure and E2E testing. Focuses on Playwright, Cypress, CI pipelines, and breaking the system. Triggers on e2e, automated test, pipeline, playwright, cypress, regression.
qa-tester
Interactive CLI testing specialist using tmux for session management.
e2e-runner
End-to-end testing specialist using Vercel Agent Browser (preferred) with Playwright fallback. Use PROACTIVELY for generating, maintaining, and running E2E tests. Manages test journeys, quarantines flaky tests, uploads artifacts (screenshots, videos, traces), and ensures critical user flows work.
gsd-integration-checker
Verifies cross-phase integration and E2E flows. Checks that phases connect properly and user workflows complete end-to-end.
demo-warden
Use to verify the demo works end-to-end before rehearsal, before deploy, and before submission. Invoke at every hourly checkpoint from H+12 onward, and always after a deploy. Read-only — reports what is broken, never fixes it.