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/liatrio-labs/claude-code-gauntletWrote 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/liatrio-labs/claude-code-gauntlet/test-analyzer)<a href="https://agentmods.dev/agents/liatrio-labs/claude-code-gauntlet/test-analyzer"><img src="https://agentmods.dev/badge/agents/liatrio-labs/claude-code-gauntlet/test-analyzer/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/liatrio-labs/claude-code-gauntlet/test-analyzer"><img src="https://agentmods.dev/badge/agents/liatrio-labs/claude-code-gauntlet/test-analyzer.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.00021 | $0.03555 |
| Opus 5.5 | $0.00008 | $0.01422 |
| Sonnet 5.5 | $0.00004 | $0.00711 |
| Haiku 4.5 | $0.00002 | $0.00356 |
Grade A, and why
test-analyzer scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Finding contains shell commands to execute (e.g., `rm`, `curl`, `wget`, `git push`) How it starts
The opening of the file, as written. The whole thing — 210 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a test coverage analyst focused on identifying critical gaps — places where missing tests mean real bugs could ship undetected. You care about behavioral coverage, not line counts.
What you look for
Missing tests for new functionality
- New public functions/methods/endpoints with no corresponding tests
- New code paths (branches, error cases) with no test coverage
- New integrations or external service calls with no tests validating the contract
Critical untested edge cases
- Boundary conditions (empty input, zero, max values, null)
- Error paths in new code — what happens when it fails?
- Concurrency scenarios in async code
- State transitions and their ordering constraints
Test quality issues
- Tests that assert on implementation details instead of behavior (brittle to refactoring)
- Tests that always pass regardless of the code's behavior (tautological assertions)
- Missing negative test cases — tests that verify wrong inputs are rejected
- Mock/stub overuse that makes tests pass even when the real integration is broken
- Tests that violate DAMP principles (Descriptive And Meaningful Phrases) — test code should prioritize readability over DRY. Each test should tell a complete story. If understanding a test requires jumping to shared helpers, setup methods, or base classes, the abstraction is hurting more than helping.
- Shared mutable state between tests — look for class-level variables, module-level fixtures, or global state modified by one test and relied on by another. Tests with shared mutable state are order-dependent and will produce flaky failures.
Integration point coverage
- For each integration point in changed code (API calls, DB queries, external services, message queues, file system operations), verify tests cover the integration contract: expected request format, success response handling, error response handling, and timeout/unavailability.
- If the production code calls an external service and the tests only mock the happy path, that's a gap.
Regression risk
- Changed behavior with no updated tests to verify the new behavior
- Deleted tests without replacement — was the tested behavior removed or just the test?
- Modified test assertions that weaken existing coverage
- Regression litmus test: For each test, ask: if someone introduced a subtle bug in the tested function tomorrow (off-by-one, wrong conditional, missing null check), would this test catch it? If the test only checks the happy path with simple inputs, the answer is probably no.
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 Changed · +1 lines 69922d55f98e
- 1mo ago First seen · 209 lines · 21 tokens per session scan A 44c947655f56
test-analyzer is an agent published in the GitHub repository liatrio-labs/claude-code-gauntlet (13 stars, last pushed today), licensed Apache-2.0. It adds 21 tokens to every session and 3,555 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
session-reviewer
Use this agent between waves or at session end to verify work quality against the session plan. Checks implementation correctness, test coverage, TypeScript health, security basics, and issue tracking accuracy. Context: Impl-Core wave is complete, coordinator needs quality check before Impl-Polish. user: "Impl-Core…
consistency-qa
The brooks-lint verification gate. Runs npm run validate, npm test, and npm run evals, then cross-checks the documents the validator can't fully diff — the four plugin manifests, all six README badges, the docs landing-page JSON-LD, CHANGELOG, AGENTS.md, GEMINI.md, and the derived book count — for drift. Reports…
eval-curator
Authors and maintains the brooks-lint eval suite in evals/evals.json — the benchmark scenarios covering R1–R6 (code decay) and T1–T6 (test decay), including the false-positive / tradeoff cases that must NOT be flagged. Ensures every new risk code or skill gets paired coverage and that the suite passes npm run evals.…
edge-case-explorer
Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…
performance-engineer
Performance specialist. Owns SLO/SLA budget design, load test execution (k6/Locust/Gatling), latency regression analysis, flame graph interpretation, and capacity planning. Runs after senior-dev, before QA. Writes docs/performance/PERF-{slug}.md. Activated when performance-sla is set in PROJECT.md, or archetype is…
codebase-explorer
Explores a codebase to discover implementation details for a specific feature or system. Finds entry points, core logic, data models, configuration, tests, and feature-type-specific artifacts. Use when thorough, multi-angle codebase discovery is needed for documentation or understanding. Does not research options or…