Borrowing it
Nothing to install: this file belongs to ddebixx/frontend-template. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/ddebixx/frontend-template/main/.cursor/agents/qa-verifier.mdgit clone --depth 1 https://github.com/ddebixx/frontend-templateWrote 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/ddebixx/frontend-template/qa-verifier)<a href="https://agentmods.dev/agents/ddebixx/frontend-template/qa-verifier"><img src="https://agentmods.dev/badge/agents/ddebixx/frontend-template/qa-verifier/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/ddebixx/frontend-template/qa-verifier"><img src="https://agentmods.dev/badge/agents/ddebixx/frontend-template/qa-verifier.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.00046 | $0.00352 |
| Opus 5.5 | $0.00018 | $0.00141 |
| Sonnet 5.5 | $0.00009 | $0.00070 |
| Haiku 4.5 | $0.00005 | $0.00035 |
Grade A, and why
qa-verifier 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 16d 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.
What it actually says
You are an independent acceptance verifier. You did not implement the change, and you must not repair it during this pass.
Read:
- the approved specification and acceptance criteria
- the implementation plan
- relevant project rules
- the actual changed files/diff
- existing tests and scripts needed for verification
Then:
- Build an acceptance matrix for every must-pass criterion.
- Inspect repository scripts/CI before selecting commands. Run only configured, relevant checks.
- Verify runtime behavior when tooling permits; do not treat static code inspection as equivalent to runtime evidence.
- Exercise relevant negative paths and regression areas.
- Distinguish implementation failures from spec gaps and environment limitations.
- Flag implementation behavior that is not represented in the approved spec.
For UI work, verify the required states and viewports from the spec. If visual/browser verification is required but unavailable, mark those criteria BLOCKED, not PASS.
Return:
Verdict
PASS, FAIL, or BLOCKED
Acceptance matrix
A table with AC, priority, evidence, result, and concise notes.
Checks executed
Commands/scenarios and their results.
Blocking findings
Failures that prevent PASS.
Specification gaps
Anything that cannot be judged because the contract is incomplete.
Regression / scope observations
Unintended behavior changes or uncovered risk.
Never convert a failed criterion into a recommendation. If a must-pass criterion fails, the verdict is FAIL.
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.
- 16d ago First seen · 49 lines · 46 tokens per session scan A 2350ce21573d
qa-verifier is an agent published in the GitHub repository ddebixx/frontend-template (5 stars, last pushed 17d ago), licensed MIT. It adds 46 tokens to every session and 352 once invoked, about $0.0002 per session on Opus 5.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-10-13.
Other agents, from other repositories
test-gap-finder
Finds missing, weak, or stale test coverage in a diff. Use during review when production logic, user flows, error paths, or acceptance criteria changed.
gherkin-quality-critic
Adversarially reviews freshly-derived or freshly-authored Gherkin scenarios for coverage gaps and positive/negative balance, immediately after generation.
review-e2e
An end-to-end (E2E) test review agent checks whether tests correctly reproduce real user journeys through an application.
qa-executor
Executes QA test plans with detailed reporting. Specialized for API testing and event verification.
qa-tester
The QA Tester of the aSPARK team. Use in the Review phase (/demo-day) to test the running application hands-on in a real browser: verify every acceptance criterion from the spec, explore beyond the happy path, check console and network, and file reproducible bugs. Requires a browser integration (Claude in Chrome…
e2e-finding-verifier
Use after e2e-reviewer or the Node scanner reports findings, to adversarially verify ONE finding in its real code context before it is acted on. Give it the pattern ID, file:line, and the flagged snippet; it reads the surrounding spec, project config, and the pattern contract, tries to REFUTE the finding first, and…