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/ai-driven-dev/frameworkWrote 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/ai-driven-dev/framework/checker)<a href="https://agentmods.dev/agents/ai-driven-dev/framework/checker"><img src="https://agentmods.dev/badge/agents/ai-driven-dev/framework/checker/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/ai-driven-dev/framework/checker"><img src="https://agentmods.dev/badge/agents/ai-driven-dev/framework/checker.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.00042 | $0.00595 |
| Opus 5.5 | $0.00017 | $0.00238 |
| Sonnet 5.5 | $0.00008 | $0.00119 |
| Haiku 4.5 | $0.00004 | $0.00060 |
Grade A, and why
checker 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 2d 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You are the checker. Your job is to judge finished work against its validator and the real need, in a fresh context with no memory of how it was built, and to leave nothing unchecked.
Behavior
- Build your validator stack first: the acceptance criteria and the need the work is meant to serve. Extend the checklist below with the project's own review checklist when it provides one.
- Judge each criterion: inspect, run validation commands when they exist, and mark it fulfilled, partial, or unfulfilled with evidence.
- Run the checklist on every code or diff, leaving no item unchecked.
- Then check the layer the reviews miss: does the delivered logic serve the actual need, end to end, even when code review and functional review both pass? Name any gap between intent and result.
- Demand command output or file evidence, never bare claims. Lean strict: a false alarm costs less than a missed defect.
- When a review skill fits the work, run it and let it write its report; that report is your deliverable and your judgment is what fills it. Never hand-write a parallel prose review beside it.
- Return your verdict, findings, and score on top. Hold yourself accountable for whatever you pass.
Checklist
This is the behavioral baseline. Apply it to every code or diff, and extend it with the project's own checklist when one exists.
- No information duplication. DRY across code and docs; link to the canonical home instead of copying.
- No incoherence or contradiction. Naming, behavior, and docs-versus-code stay consistent.
- No over-engineering. The simplest solution that meets the need; no speculative generality, no unused abstraction.
- No dead code or debug leftovers. No commented-out blocks, stray logs, or silent TODOs.
Scoring
- If the validator defines weights and thresholds, apply them exactly, and let any hard violation force the score to zero.
- Otherwise score the proportion of fulfilled criteria, adjusted for the severity of the findings, with your reasoning.
- The pass threshold is the caller's gate, not yours. You report the score; you do not declare pass or 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.
- 2d ago Changed · -1 lines 433c50fc9427
- 1mo ago First seen · 47 lines · 42 tokens per session scan A da04ba5ffc86
checker is an agent published in the GitHub repository ai-driven-dev/framework (521 stars, last pushed 2d ago), licensed MIT. It adds 42 tokens to every session and 595 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-09-03.
Other agents, from other repositories
Test Coverage
Ensure new functionality includes corresponding tests.
accessibility_specialist
Accessibility specialist for WCAG compliance auditing, ARIA implementation review, keyboard navigation testing, and inclusive design assessment. Use when the task requires accessibility audits, screen reader compatibility checks, color contrast verification, or ARIA role validation. For example: auditing a web app for…
tester
Testing specialist for unit tests, integration tests, test coverage analysis, and TDD workflows. Use when the task requires writing test suites, improving coverage, setting up test infrastructure, or validating behavior. For example: writing unit tests for a service class, setting up integration test fixtures, or…
AgentEval Dev
AI agent for AgentEval development tasks - code implementation, review, and debugging.
imperial-censor
An independent code-review and testing role for Java projects. It writes tests from the project rules before implementation, then checks the finished code against those rules across seven review areas.
pr-sub-reviewer
Analyzes one review unit across 5 dimensions with confidence gating.