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 commands/halflength-ampleness75/claude-code-recipes/test-gengit clone --depth 1 https://github.com/halflength-ampleness75/claude-code-recipesWrote 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/commands/halflength-ampleness75/claude-code-recipes/test-gen)<a href="https://agentmods.dev/commands/halflength-ampleness75/claude-code-recipes/test-gen"><img src="https://agentmods.dev/badge/commands/halflength-ampleness75/claude-code-recipes/test-gen.svg" alt="Measured on agentmods" 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.00013 | $0.00907 |
| Opus 5 | $0.00006 | $0.00453 |
| Sonnet 5 | $0.00003 | $0.00181 |
| Haiku 4.5 | $0.00001 | $0.00091 |
Grade A, and why
test-gen 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 5d 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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Generate a thorough test suite for the file or module specified in $ARGUMENTS.
Step 1 — Analyze the Target
Read the file specified in $ARGUMENTS. If a file path is not provided, ask the user which file to test.
Identify:
- All exported functions, classes, and methods
- Input parameters and their types
- Return types and possible return values
- Side effects (I/O, network calls, database access, global state)
- Error conditions (thrown exceptions, rejected promises, error returns)
- Edge cases (empty inputs, boundary values, null/undefined, concurrency)
- Dependencies that will need mocking
Step 2 — Detect the Testing Framework
Search the project for testing configuration:
- Check
package.jsonforjest,vitest,mocha,@testing-library/* - Check for
jest.config.*,vitest.config.*,.mocharc.* - Check for
pytest.ini,pyproject.toml [tool.pytest],conftest.py - Check for
_test.gofiles,Cargo.toml [dev-dependencies] - Look at existing test files to match the project's testing patterns
Match the project's existing conventions: import style, describe/it vs test(), assertion library, file naming (*.test.ts vs *.spec.ts vs test_*.py), and directory structure (__tests__/ vs co-located).
Step 3 — Plan Test Cases
Organize tests into these categories:
Happy Path Tests
- Test each function with typical, valid inputs
- Test the primary use case end-to-end
- Verify correct return values and side effects
Edge Case Tests
- Empty strings, empty arrays, empty objects
- Zero, negative numbers, very large numbers
- Boundary values (min/max of ranges, off-by-one)
- Unicode, special characters, very long strings
- Single-element collections, collections at capacity
Error Scenario Tests
- Invalid input types (if not caught by type system)
- Missing required parameters
- Network/I/O failures (timeouts, connection refused)
- Permission errors, not-found errors
- Concurrent access or race conditions if applicable
Integration Points (if applicable)
- Mock external dependencies (HTTP clients, databases, file system)
- Verify correct interaction with dependencies (call count, arguments)
- Test error propagation from dependencies
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.
- 5d ago First seen · 101 lines · 13 tokens per session scan A 1fc270128a46
test-gen is a command published in the GitHub repository halflength-ampleness75/claude-code-recipes (2 stars, last pushed today), licensed MIT. It adds 13 tokens to every session and 907 once invoked, about $0.0001 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 commands, from other repositories
test-suite
Run comprehensive test suite with coverage analysis.
run-all-tests-and-fix
Execute the full test suite and systematically fix any failures, ensuring code quality and functionality.
generate-widget
Génération Widget Flutter avec Tests.
pull-repos
Pull all repos (parent + marketplace clones + configured project repos).
security-scan
Run security audit on codebase.
help
Explain Ralph Wiggum technique and available commands.