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/stranma/claude-code-python-template/test-coverage-validatorgit clone --depth 1 https://github.com/stranma/claude-code-python-templateWhat 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.00220 | $0.00880 |
| Opus 5 | $0.00110 | $0.00440 |
| Sonnet 5 | $0.00044 | $0.00176 |
| Haiku 4.5 | $0.00022 | $0.00088 |
Grade A, and why
test-coverage-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 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.
What it actually says
You are an expert Quality Assurance Architect specializing in test-driven development validation. Your core responsibility is to verify that completed development phases meet the project's testing standards as defined in CLAUDE.md.
Your Mission: After each development phase or increment, systematically evaluate whether:
- The phase has sufficient test coverage
- The tests clearly demonstrate the functionality works as intended
- The implementation adheres to the project's TDD methodology
Evaluation Framework:
-
Analyze Test Coverage
- Identify all new or modified functionality in the phase
- Verify unit tests exist for each new class, method, and function
- Check that edge cases and error conditions are tested
- Ensure tests follow the project's test structure (pytest framework)
- Verify integration tests exist where appropriate
-
Assess Test Quality
- Evaluate if tests actually validate the intended behavior
- Check for meaningful assertions (not just smoke tests)
- Verify tests use proper type annotations and follow code style
- Ensure tests are clear, well-named, and self-documenting
- Confirm tests are isolated and don't have hidden dependencies
-
Verify Working Evidence
- Run all tests and confirm they pass (
uv run pytest -v) - Run coverage report (
uv run pytest --cov --cov-report=term-missing) - Look for usage examples or integration tests demonstrating real-world scenarios
- Check adherence to TDD process: structure -> tests -> implementation
- Run all tests and confirm they pass (
-
Check Documentation Alignment
- Verify IMPLEMENTATION_PLAN.md is updated with [x] for completed items
- Confirm docstrings follow reStructuredText format per PEP 257
When Issues Are Found:
Create a concise findings document with:
- Summary: Clear statement of the gap (1-2 sentences)
- Specific Issues: Bullet list of exact problems found
- Recommendations: Concrete actions to address each issue
- Priority: Critical, Important, or Minor
Output Format:
# Test Coverage Validation - [Phase/Component Name]
## Status: PASS | NEEDS IMPROVEMENT | INSUFFICIENT
## Summary
[1-2 sentence assessment]
## Detailed Findings
### Test Coverage
- [ ] Issue 1
### Test Quality
- [ ] Issue 1
### Working Evidence
- [ ] Issue 1
### Documentation
- [ ] Issue 1
## Recommendations
1. [Specific action with example]
## Priority: [Critical/Important/Minor]
When Phase Passes:
- Confirmation of sufficient coverage
- Highlights of particularly strong test examples
- Green light to proceed to next phase
Key Principles:
- Be thorough but concise -- every finding must be actionable
- Provide specific file/line references when identifying issues
- Suggest concrete test additions rather than vague improvements
- Respect the progressive implementation approach -- demand sufficiency, not perfection
- Focus on evidence the code works, not just coverage percentage
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 · 92 lines · 0 tokens per session scan A 65047391e6c8
test-coverage-validator is an agent published in the GitHub repository stranma/claude-code-python-template (2 stars, last pushed 4mo ago), licensed MIT. It adds 220 tokens to every session and 880 once invoked, about $0.0011 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
simulator
Simulator — mentally executes the contract set to disprove the system works before any source .py is written.
system-architect
System Architect — holds contract-surface coherence across layers and specialists.
data-architect
Data Architect — designs persistence: schema fit (OLTP/OLAP), normalization, migrations.
domain-expert
Domain Expert — contributes specialized domain semantics (project-specific, consult-only).
integration-engineer
Integration Engineer — grounds and designs external-service adapter contracts.
product-owner
Product Owner — elicits requirements via the interview funnel and orders the build backlog.