Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/XRenSiu/claude-code-forgenpx agentmods add skills/xrensiu/claude-code-forge/test-suite-generatorWrote 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/skills/xrensiu/claude-code-forge/test-suite-generator)<a href="https://agentmods.dev/skills/xrensiu/claude-code-forge/test-suite-generator"><img src="https://agentmods.dev/badge/skills/xrensiu/claude-code-forge/test-suite-generator/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/skills/xrensiu/claude-code-forge/test-suite-generator"><img src="https://agentmods.dev/badge/skills/xrensiu/claude-code-forge/test-suite-generator.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.00294 | $0.09893 |
| Opus 5.5 | $0.00118 | $0.03957 |
| Sonnet 5.5 | $0.00059 | $0.01979 |
| Haiku 4.5 | $0.00029 | $0.00989 |
Grade A, and why
test-suite-generator 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 — 408 lines — stays where its author put it; the contents beside it link to each section on GitHub.
test-suite-generator — EARS spec → full test pyramid
You are invoked to turn an upstream acceptance-spec output (a specs/<feature>/ directory containing spec.md and done_when.yaml) into the actual test files that an independent agent can execute to verify implementation.
Say once at the start, then start working:
"I'm using the test-suite-generator skill. I'll walk five sub-steps (existence → unit → integration → e2e → mutation), one batch at a time. Each generated test traces back to a REQ-ID via
based_on:."
Do not narrate further — just walk the sub-steps.
Iron rules (re-read before every sub-step)
- Verifiable beats judgeable. Programmatic checks (assertion-based tests, AST inspection, mutation kill rate) beat LLM-as-judge on speed, cost, consistency. Per HTML v2 §3 principle I (and §3.5 corollary): most claims that feel like they need an LLM judge can be re-designed as programmatic checks — "README quickstart works" → really run it; "agent can call API from docs alone" → spin a clean session; "types are correct" → run
tsc/mypy. The ~10% genuinely-unautomatable cases are routed to/pm-reviewer'srequires_human_verificationverdict, not to a fake LLM rubric here. This skill does NOT emit fitness rubrics in v1.0.0 (former 4-F was retired). - One batch at a time. Generate → write to disk → run → iterate. Then proceed. Never generate all six batches in one pass — empirically, LLM test generation quality collapses past a few dozen tests in a single prompt. The doc that motivates this skill names this as Pitfall #2; do not be the next person to step on it.
- PBT property type is recovered from the test name. Under schema v1 (Appendix C of
done-when-pipeline.md), every leaf entry underbehavior.*.property_based/behavior.*.example_based/e2e_testsis a bare string — there is noproperty_type:sub-field on the entry. Parse the test name suffix to infer the property archetype (one of:invariant/idempotent/reversible/boundary/monotonic/state_machine). E.g.test_cancel_is_idempotent→ idempotent pattern. Readreferences/pbt-property-types.mdto know which pattern to emit. If a property-based name does not encode a recognisable archetype, the requirement is not a good PBT candidate — emit an example-based test instead and tell the user the name should be revised upstream. - No mocks for integration tests. Use testcontainers (or equivalent) to spin up real Postgres / Redis / Kafka / etc. Mocks hide interface drift, which is exactly the failure mode that catches AI-generated code most often. If the language lacks testcontainers, fall back to docker-compose; do not fall back to mocks.
- Mutation testing is mandatory, not optional. A done_when that only enforces coverage ≥ 80% will incentivize the implementer to write
assert Trueto inflate the number. Mutation kill rate ≥ 70% is the gate that closes that loop. Always emit amutation.configfile (4-E). - Every generated test carries
based_on:. Either as a comment header in the test file (# based_on: REQ-001, REQ-003), or as part of the test name when the language convention favors it. Tests without traceability cannot be culled when a REQ is dropped, and cannot be explained when they fail. - No inventing requirements. If a property occurs to you that isn't in any REQ, do not add a test for it. Either push back upstream ("REQ-NNN seems to imply X — should that be a separate REQ?") or skip it. Tests must derive from the spec, not from your own intuition about what a good system does.
- Pyramid ratio rebalanced for AI-coding. Per the source doc, AI-written code is more likely to fail at module boundaries (interface mismatches, protocol confusions). Target ~50% unit / ~35% integration / ~15% e2e — not the traditional 70/20/10. Push slightly more weight into integration than you might be used to.
- Verbatim test names from
done_when.yaml. The string the framework records as the test identifier must equal the YAML entry character-for-character (prefix, underscores, suffix). Pythondef test_*is naturally fine; TS/JStest('…')/it('…')is the trap because it accepts arbitrary strings. Human-readable descriptions go in comments,describe()blocks, or annotations — never in thetest()first argument. See §4-D for the full rule + forbidden-pattern examples; this exists because downstream Step 5-6 review skills (/qa-reviewer,/pm-reviewer)grepcontract names against produced files, and any paraphrase breaks traceability. - Existence script is fail-fast (
set -e), not count-all. The script in §4-A MUST exit on the first failing check. Wrapping checks inif … then PASS=… else FAIL=… fidefeatserrexit— that pattern is forbidden. See §4-A for the required idiom and the explicit list of forbidden patterns. - Test-only API endpoints must be registered as existence claims. Any endpoint the test suite calls but that is not part of the user-facing contract (
/api/_test/*,/api/_internal/*, hidden test-hook query/body fields like_force_surface_outcomes) MUST be added todone_when.yaml.existence:as aroute:entry — otherwise the test suite implicitly demands a bigger contract than the contract makes explicit (spec drift). Ifdone_when.yamlwas emitted by/acceptance-specand does not list these endpoints, either (a) push back upstream ("the contract is missing test-hook endpoints X, Y, Z — regenerate via/acceptance-specto include them") or (b) add the entries here and note the augmentation in the manifest you emit at the end of the skill. Never ship a test suite that calls undeclared endpoints. See §4-A for the existence list and §4-C for the test-hook conventions. - Self-report version comes from this SKILL.md frontmatter, not a hardcoded literal. Every emitted file's "Generated by test-suite-generator/X.Y.Z" header MUST be filled in by reading the
version:value from thisSKILL.md's YAML frontmatter at generation time. Do NOT paste a version literal lifted fromreferences/sub-modules/*.mdtemplates (those use a<skill-version>placeholder for this exact reason). The downstream audit signal is: artifact self-report mismatch withplugin.json⇒ skill source bug. See §4-B "Version-string substitution rule" for the canonical reminder.
What ships with it
19 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- eval/gate.json 2.5 KB
- eval/report.md 1.1 KB
- references/anti-cheating-mutation.md 5.0 KB
- references/done-when-schema-validator.md 6.2 KB
- references/ears-to-test-matrix.md 5.4 KB
- references/examples/README.md 2.0 KB
- references/pbt-property-types.md 9.0 KB
- references/step-5-audit-checklist.md 6.9 KB
- references/sub-modules/e2e-generator.md 8.2 KB
- references/sub-modules/existence-extractor.md 10 KB
- references/sub-modules/integration-generator.md 11 KB
- references/sub-modules/mutation-config.md 5.8 KB
- references/sub-modules/unit-test-generator.md 19 KB
- references/tooling-by-language.md 5.9 KB
- scripts/capture_red_baseline.py 9.9 KB runs code
- scripts/check_verbatim_names.py 5.7 KB runs code
- scripts/derive_counts.py 8.6 KB runs code
- scripts/gen_existence.py 10 KB runs code
- scripts/verify_red_green.py 8.5 KB runs code
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 92ad02c3f78f
- 1mo ago Changed · +8 lines 4f903b91edc8
- 1mo ago Changed · +81 lines 880553997a37
- 2mo ago First seen · 318 lines · 294 tokens per session scan A 954c697c1600
test-suite-generator is a skill published in the GitHub repository XRenSiu/claude-code-forge (2 stars, last pushed 1mo ago), licensed MIT. It adds 294 tokens to every session and 9,893 once invoked, about $0.0012 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-31.
Other skills, from other repositories
test-master
Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation…
axiom-testing
Use when writing ANY test, debugging flaky tests, making tests faster, or choosing Swift Testing vs XCTest. Covers unit tests, UI tests, async testing, test architecture.
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.
designing-tests
Designs and implements testing strategies for any codebase. Use when adding tests, improving coverage, setting up testing infrastructure, debugging test failures, or when asked about unit tests, integration tests, or E2E testing.
test-automation-expert
Comprehensive test automation specialist covering unit, integration, and E2E testing strategies. Expert in Jest, Vitest, Playwright, Cypress, pytest, and modern testing frameworks. Guides test pyramid design, coverage optimization, flaky test detection, and CI/CD integration. Activate on 'test strategy', 'unit tests'…
JMeter Load Testing
Load and performance testing skill using Apache JMeter, covering test plans, thread groups, assertions, listeners, timers, and distributed testing.