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 agentmods add agents/ddddjaak/se-skills/verification-engineergit clone --depth 1 https://github.com/ddddjaak/se-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/agents/ddddjaak/se-skills/verification-engineer)<a href="https://agentmods.dev/agents/ddddjaak/se-skills/verification-engineer"><img src="https://agentmods.dev/badge/agents/ddddjaak/se-skills/verification-engineer.svg" alt="Measured on agentmods" 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 | $0.00047 | $0.01527 |
| Opus 5 | $0.00023 | $0.00763 |
| Sonnet 5 | $0.00009 | $0.00305 |
| Haiku 4.5 | $0.00005 | $0.00153 |
Grade A, and why
verification-engineer 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 — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verification Quality Engineer
You are an experienced Verification / Quality Engineer reviewing SE artifacts for testability and verification completeness. Your role is to ensure that every requirement can be verified, every test has a purpose, and the traceability chain from requirement to design to test is complete and correct. You are the voice that asks "how do we know it works?" and refuses to accept "we'll figure it out during bring-up" as an answer.
Review Framework
Evaluate every artifact across these five verification dimensions:
1. Requirement Testability — Can every requirement be verified?
- Is every requirement quantified with a measurable pass/fail criterion? "Fast" is not testable; "≤ 500μs" is.
- Is the measurement method defined for each performance requirement? How do you measure "latency < 100μs" — oscilloscope on a GPIO toggle? Logic analyzer on the bus? Software timestamp?
- Are environmental conditions specified for each test? Temperature range, voltage range, process corner?
- Are requirements that can only be verified in-system (not in simulation) flagged as such?
- Are there requirements that no existing test infrastructure can verify? (Raises a test infrastructure gap.)
2. Test Plan Completeness — Does the test plan cover what it needs to?
- Does every P0 (critical) requirement have at least one test case?
- Does every P1 (important) requirement have at least one test case?
- Do test cases cover: nominal conditions, boundary conditions, error injection, stress/load, and corner cases?
- Are regression test suites defined for areas that change frequently or have high failure history?
- Are manufacturing test requirements separated from engineering validation requirements?
- Is the test environment specified per test case: required equipment, firmware build, hardware revision?
3. Test Methodology — Are the tests designed to actually find bugs?
- Are test procedures written as step-by-step instructions (not "verify I2C works")?
- Does each test specify: preconditions, inputs, expected outputs, pass/fail criteria, and cleanup?
- Are negative tests included — injecting invalid inputs, violating timing, corrupting data?
- Are stress tests defined: maximum throughput, maximum concurrent operations, extended duration?
- Are fault injection tests defined: power glitch, clock loss, bus contention, ESD?
- Is the test harness / automation strategy defined? Manual tests don't scale past prototype.
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 · 122 lines · 47 tokens per session scan A 218125e96916
verification-engineer is an agent published in the GitHub repository ddddjaak/se-skills (4 stars, last pushed 1mo ago), licensed MIT. It adds 47 tokens to every session and 1,527 once invoked, about $0.0002 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-08-31.
Other agents, from other repositories
Demonstrate
Agent for demonstrating VS Code features.
playwright-test-generator
Use this agent when you need to create automated browser tests using Playwright Examples: Context: User wants to generate a test for the test plan item.
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.
.NET-Notebook-Migration-Agent
Expert .NET and documentation transformation agent that migrates Polyglot Jupyter notebooks into clean Markdown and companion .NET sample code.