test-suite-generator

test-suite-generator is a skill for Claude Code from XRenSiu/claude-code-forge. It costs 294 tokens per session (9,893 once invoked), scanned A, original, MIT.

A test-generation skill that turns an EARS specification and a done-when.yaml contract into tests across several levels: file checks, unit, integration, end-to-end, and mutation testing. EARS is a structured way to write requirements; mutation testing changes code deliberately to check whether tests catch it.

In plain words
What is it for?
Use it to generate example-based and property-based unit tests, integration tests with real containers, browser or mobile end-to-end tests, and mutation-testing setup.
Why use it?
It creates executable checks from written requirements and helps reveal tests that pass without actually detecting broken behavior.

Skill for Claude Code

Written for Claude Code: user-invocable in frontmatter.

Needs its repository: it runs a file that does not travel with it, so clone the repository first. The line is bash plugins/ai-dlc/eval/smoke.sh --mutate <file> '<old-string>' '<new-string>'.

Part of the ai-dlc plugin — 30 skills, 5 agents shipped together

Good fit Use it to generate example-based and property-based unit tests, integration tests with real containers, browser or mobile end-to-end tests, and mutation-testing setup.

Compare 6 skills from other repositories ↓
Install

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.

Clone the repo
git clone --depth 1 https://github.com/XRenSiu/claude-code-forge
agentmods
npx agentmods add skills/xrensiu/claude-code-forge/test-suite-generator

Made for: Claude Code.

Or install ai-dlc, the plugin that ships this one along with the rest of its 30 skills, 5 agents.

Wrote 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.

agentmods badge for test-suite-generator

README.md
[![agentmods](https://agentmods.dev/badge/skills/xrensiu/claude-code-forge/test-suite-generator/github.svg)](https://agentmods.dev/skills/xrensiu/claude-code-forge/test-suite-generator)
Your own site
<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.

agentmods 80×15 button for test-suite-generator

Your own site · 80×15
<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>
Per session 294 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 9,893 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 1mo ago against content hash 92ad02c3f78f, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

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.

The scan reads SKILL.md. This mod also ships 5 executable files (scripts/capture_red_baseline.py, scripts/check_verbatim_names.py, scripts/derive_counts.py, …), listed below but not scanned — reading those needs a real analyzer, not pattern matching.

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.

plugins/ai-dlc/skills/test-suite-generator/SKILL.md · 408 lines

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)

  1. 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's requires_human_verification verdict, not to a fake LLM rubric here. This skill does NOT emit fitness rubrics in v1.0.0 (former 4-F was retired).
  2. 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.
  3. PBT property type is recovered from the test name. Under schema v1 (Appendix C of done-when-pipeline.md), every leaf entry under behavior.*.property_based / behavior.*.example_based / e2e_tests is a bare string — there is no property_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. Read references/pbt-property-types.md to 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.
  4. 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.
  5. Mutation testing is mandatory, not optional. A done_when that only enforces coverage ≥ 80% will incentivize the implementer to write assert True to inflate the number. Mutation kill rate ≥ 70% is the gate that closes that loop. Always emit a mutation.config file (4-E).
  6. 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.
  7. 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.
  8. 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.
  9. 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). Python def test_* is naturally fine; TS/JS test('…') / it('…') is the trap because it accepts arbitrary strings. Human-readable descriptions go in comments, describe() blocks, or annotations — never in the test() 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) grep contract names against produced files, and any paraphrase breaks traceability.
  10. Existence script is fail-fast (set -e), not count-all. The script in §4-A MUST exit on the first failing check. Wrapping checks in if … then PASS=… else FAIL=… fi defeats errexit — that pattern is forbidden. See §4-A for the required idiom and the explicit list of forbidden patterns.
  11. 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 to done_when.yaml.existence: as a route: entry — otherwise the test suite implicitly demands a bigger contract than the contract makes explicit (spec drift). If done_when.yaml was emitted by /acceptance-spec and does not list these endpoints, either (a) push back upstream ("the contract is missing test-hook endpoints X, Y, Z — regenerate via /acceptance-spec to 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.
  12. 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 this SKILL.md's YAML frontmatter at generation time. Do NOT paste a version literal lifted from references/sub-modules/*.md templates (those use a <skill-version> placeholder for this exact reason). The downstream audit signal is: artifact self-report mismatch with plugin.json ⇒ skill source bug. See §4-B "Version-string substitution rule" for the canonical reminder.

Read the full file on GitHub · 408 lines

Changes

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.

  1. 1mo ago Changed · +1 lines 92ad02c3f78f
  2. 1mo ago Changed · +8 lines 4f903b91edc8
  3. 1mo ago Changed · +81 lines 880553997a37
  4. 2mo ago First seen · 318 lines · 294 tokens per session scan A 954c697c1600

Subscribe to this mod's changes

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.

Related

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…

Jeffallan/claude-skills · 104 tokens

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.

CharlesWiltgen/Axiom · 38 tokens

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.

adobe/skills · 61 tokens

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.

CloudAI-X/claude-workflow-v2 · 48 tokens

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'…

curiositech/some_claude_skills · 133 tokens

JMeter Load Testing

Load and performance testing skill using Apache JMeter, covering test plans, thread groups, assertions, listeners, timers, and distributed testing.

PramodDutta/qaskills · 32 tokens