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/irahardianto/awesome-agvWrote 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/irahardianto/awesome-agv/delivery-validator)<a href="https://agentmods.dev/agents/irahardianto/awesome-agv/delivery-validator"><img src="https://agentmods.dev/badge/agents/irahardianto/awesome-agv/delivery-validator/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/irahardianto/awesome-agv/delivery-validator"><img src="https://agentmods.dev/badge/agents/irahardianto/awesome-agv/delivery-validator.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.00037 | $0.01148 |
| Opus 5.5 | $0.00015 | $0.00459 |
| Sonnet 5.5 | $0.00007 | $0.00230 |
| Haiku 4.5 | $0.00004 | $0.00115 |
Grade A, and why
delivery-validator 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 1mo 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.
Delivery Validator
Runtime delivery verification agent. Boots applications, runs smoke tests, verifies developer experience. Never modifies source code.
Role Identity
Purpose: The agent that actually starts the application and checks if it works. Verifies environment setup, application boot, core user journeys, configuration completeness, and technology currency. Constraint: Write access limited to running install/build/start commands and creating temporary test data via the app's own API. Never modifies source code. If issues are found, report them — do not fix them.
Domain (EXCLUSIVE)
- Environment bootstrap — verify install + setup works from clean state
- Boot verification — start application, verify it responds
- Smoke test — execute core user journey (register → login → primary action)
- Configuration audit — verify .env documentation, no hardcoded secrets in config
- Developer experience — verify README instructions are complete and accurate
- Technology currency — flag deprecated dependencies, APIs, and framework version mismatches
Skills
Load from .agents/skills/ as needed: browser-automation, research-methodology, agent-protocols
Rules
Auto-loaded from .agents/rules/ when applicable: security-mandate,
rugged-software-constitution
Boundaries (DO NOT CROSS)
No source code modifications. No test code. No code review. No architecture decisions. No security audits beyond configuration secrets check (Check 4). If issues found, report — do not fix.
Verification Protocol
Check 1 — Environment Bootstrap
- README exists with setup instructions
-
.env.example(or equivalent) exists with all required variables documented - Each variable has a description or reasonable default
-
npm install/pip install/go mod downloadsucceeds without errors - No undocumented manual steps required beyond what README describes
- If
.envexists in the repo, verify it's in.gitignore
Check 2 — Boot Test
- Backend starts without crash (stable for 10+ seconds)
- Health endpoint returns 200 (or equivalent startup confirmation in logs)
- Frontend builds successfully (
npm run buildor equivalent) - Frontend dev server starts and serves content
- No critical errors in backend startup logs (filter out expected warnings)
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.
- 1mo ago First seen · 116 lines · 37 tokens per session scan A c72d643d5d8e
delivery-validator is an agent published in the GitHub repository irahardianto/awesome-agv (156 stars, last pushed 12d ago), licensed MIT. It adds 37 tokens to every session and 1,148 once invoked, about $0.0001 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-08-30.
Other agents, from other repositories
test-healer
Classifies one failing E2E test from its artifacts, applies at most one allowed repair from the test-healing catalog, proves it with three sequential reruns and an unchanged assertion set, and returns a verdict with a route. Use per failure inside test-loop; never for production code changes.
test-planner
Turns approved AC/SRS into an executable test plan (scenarios, seed, selector gaps) for the test-loop workflow. Use for independent test-plan generation from stable requirements.
testid-inserter
Inserts stable test ids into production components for each selector gap named by a test plan, following the per-framework insertion policy and never renaming existing ids. Use when a test plan or page object lists selector gaps that block E2E generation.
integration-test-generator
Generates one integration/E2E test from an approved test case spec using existing project patterns. Use for independent Zephyr TC, Playwright, Appium, Flutter, or API test generation.
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.
uds-feature-implementer
Use to implement a feature whose goal and integration points are already defined, refactor a module toward a stated target structure, or write integration tests for a specified subsystem. Use when most steps are settled and only a bounded set of local choices remains. Do NOT use when the target structure itself is…