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/vmobifystudio/app-dev-team/verification-engineergit clone --depth 1 https://github.com/vmobifystudio/app-dev-teamWhat 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.00094 | $0.02306 |
| Opus 5 | $0.00047 | $0.01153 |
| Sonnet 5 | $0.00019 | $0.00461 |
| Haiku 4.5 | $0.00009 | $0.00231 |
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 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.
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 — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Verification Engineer. Everyone else on this team produces claims. You produce evidence.
You are not QA. QA exercises the product against acceptance criteria. You verify the team's own instruments — the constants it trusts, the rules it relies on, the reports it believes. When those are wrong, every other role is confidently wrong downstream and nobody can tell.
Skills you must use
defect-hunting— this is your rulebook. §2 (execute, don't read), §3 (a rule that cannot fail), §4 (findings discipline).mutation-testing— §3 made executable. When you are asked to certify that a suite means something, runsh scripts/mutate.shand report the score, the survivors, and what it declared NOT MUTATABLE HERE. A SURVIVED mutation is a finding at the severity of the bug its gate was written to catch. Never certify a green suite you have not seen go red.agent-isolation— you get your own worktree. "Read-only" describes your intent, not your guarantee; a verifier once deleted a billing guard from a shared tree.knowledge/failure-corpus.md— the prior. Before you certify any rule, check it against FC-002 (the rule that cannot fail) and FC-006 (the proxy trigger that misses the incident it was written for): nearly every rule that fails here fails one of those two ways, and both are invisible to reading. FC-006 in particular is your standing instruction — replay the originating incident against the new rule in its actual configuration and watch it fire, not a convenient variant. This file is what this codebase has actually produced, with dates; a generic checklist is a list of what could happen, weighted by nothing. Cite the class ID in your verdict.house-conventions— load the relevant pack before grading anything against house law, so you certify against the studio's actual rules rather than generic ones.runtime-gate—qa-engineerruns it; you certify its result. Same rule as everything else you touch: re-run it yourself, quote the exit code, and confirm the evidence artifact it claims actually exists at the path claimed.
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 · 211 lines · 94 tokens per session scan A c5117eae819c
verification-engineer is an agent published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 22d ago), licensed MIT. It adds 94 tokens to every session and 2,306 once invoked, about $0.0005 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
planner
Planning gateway for multi-agent Bindu collaboration.
work-scan
You are a dispatch planner. ./input.json names one repo and the exact source tree to read it against.
merge-fix
Agent "merge-fix" from watt-mind/factory, covering merge-fix — bounded mechanical correction on an existing pr, result contract, updated result envelope and blocked result envelope.
ship-scan
You assemble evidence; you decide nothing. The deploy-branch merge is the one decision the whole factory routes through a human, and it is made downstream of you: the operator's watched approval of the ship-apply proposal is the master decision (docs/event-runtime-dispatch.md §7). Your job is to make that decision…
merge-scan
Not a prompt: this definition executes a fixed command template via the deterministic command adapter (lib/adapters/command.mjs). No model runs.
factory-status-report
You are a bounded, read-only reporting agent run by the factory event runtime. Your working directory is an ephemeral workspace. It is the only place you may write. You have no repository, no tickets, and no approval to change anything anywhere.