test-strategy · avelikiy — Claude Code skill: a test plan that survives review
A skill for QA engineers that turns "90% coverage" into a defensible plan: what to test, why that set, and a signal that the tests actually catch bugs.
npx skills add avelikiy/great_cto --skill test-strategy -a claude-codeWhat test-strategy does
The test-strategy skill gives a method for planning tests on medium and large features. Instead of writing more tests on reflex, it forces four decisions: the unit/integration/e2e ratio for the project archetype, which equivalence classes and boundaries to cover, what mutation score proves the tests bite, and how to handle flaky tests.
The pyramid is chosen by archetype, not habit. A library gets 80% unit / 15% integration / 5% e2e; commerce with money paths gets 50% / 35% / 15%. AI systems get their own column: 50% unit, 20% integration, 10% e2e, plus 20% evals. Deviations from the table need a written justification in the plan.
The real signal is mutation score, not line coverage. A module with 90% line coverage and 30% mutation score has tests without assertions: they execute code but never fail. So the target is mutation score ≥ 60% on changed logic-dense files, with the result recorded in the report.
Flaky tests get quarantined, not tolerated. Skip them, file a bug with an owner and a deadline, find the root cause before re-enabling. A test that fails randomly trains the team to ignore red and hurts the whole suite more than a missing test.
The output is docs/qa-reports/TEST-STRATEGY-{slug}.md. The QA gate checks that the file exists for medium and large features. Typos and renames do not need this skill: the overhead is not worth it.
What it helps with
- pick a unit/integration/e2e ratio by project archetype instead of guessing
- partition inputs into equivalence classes and boundaries rather than enumerate values
- verify that tests fail when logic breaks, using mutation score
- quarantine flaky tests and drive them to a root cause
- produce a plan that justifies the chosen test set, not just the coverage percentage
Example prompts for the agent
- Build a test strategy for the discount calculation feature in the cart
- Check whether the current coverage percentage in the payment module means anything, then plan mutation testing
- What boundary cases and equivalence classes should I cover for the CSV parser?
How to install test-strategy
1Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a claude-code2Manually: put the files in place
~/.claude/skills/test-strategy/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/test-strategy/
1Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a codex2Manually: put the files in place
.agents/skills/test-strategy/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a cursor2Manually: put the files in place
.cursor/skills/test-strategy/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install avelikiy/great_cto test-strategy2Manually: put the files in place
.github/skills/test-strategy/SKILL.md1Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a gemini-cli2Platform CLI
gemini skills install https://github.com/avelikiy/great_cto --path skills/test-strategyManually: put the files in place
.devin/skills/test-strategy/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add avelikiy/great_cto --skill test-strategy -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about test-strategy
How do I install test-strategy in Claude Code?
Run npx skills add avelikiy/great_cto --skill test-strategy -a claude-code. The skill lands at ~/.claude/skills/test-strategy/SKILL.md.
What does test-strategy do?
It provides a test planning method: an archetype-based pyramid, case selection through equivalence classes and boundaries, mutation score as the quality signal, and a quarantine policy for flaky tests. The result is a TEST-STRATEGY-{slug}.md file.
Why is mutation score better than plain coverage?
Line coverage shows that code ran. Mutation score checks that a test would fail if the logic broke: a mutator flips operators and conditions, and the tests must catch it. High coverage with low mutation score means assertion-free tests.
Source text
SKILL.md · MIT
---
name: test-strategy
description: Coverage-design method for qa-engineer — pyramid ratios per archetype, equivalence/boundary/property case selection, mutation score as the real coverage signal, and a flake-quarantine policy. Turns "coverage is 90%" (a number with no method) into a defensible test plan. Emits TEST-STRATEGY-{slug}.md, which the QA gate checks exists.
when_to_use: |
Apply when:
- qa-engineer is planning tests for a medium/large feature (>1 file, real behaviour risk)
- a coverage % is being reported and you need to know whether it MEANS anything
- deciding what to test (not just measuring what's covered)
Do NOT apply to:
- nano / tiny changes (typo, rename) — overhead exceeds value
- pure docs changes
effort: medium
allowed-tools: Read, Write, Grep, Glob, Bash
paths:
- "tests/**"
- "docs/qa-reports/**"
---
# test-strategy
Coverage % is a number with no method. This skill makes the QA plan defensible:
**what** to test, **why** that set, and a **real** signal that the tests bite.
qa-engineer emits `docs/qa-reports/TEST-STRATEGY-{slug}.md` capturing the four
decisions below; the QA gate checks the file exists for medium/large features.
## 1. Pyramid ratio — pick by archetype (not by reflex)
The right unit:integration:e2e mix depends on where the risk lives.
| Archetype | unit | integration | e2e | why |
|-----------|------|-------------|-----|-----|
| library / devtools / cli | 80% | 15% | 5% | logic-dense, few I/O seams |
| web-app / saas | 60% | 30% | 10% | request→db→render seams dominate |
| commerce / fintech / marketplace | 50% | 35% | 15% | money paths need cross-component proof |
| data-platform / streaming | 45% | 45% | 10% | correctness lives in pipelines, not units |
| ai-system / agent-product | 50% | 20% | 10% + **evals 20%** | behaviour is the contract → eval set (see [[decision-eval]]) |
State the chosen ratio in TEST-STRATEGY and justify any deviation.
## 2. Case selection — equivalence / boundary / property
Don't enumerate inputs; **partition** them.
- **Equivalence classes** — one representative per class of behaviour (valid, invalid, empty, max). Testing 5 valid ids ≠ testing 5 classes.
- **Boundaries** — the bug lives at the edge: 0, 1, n-1, n, n+1, off-by-one, empty, overflow, the threshold itself.
- **Property-based** — for pure/transform logic, assert invariants over generated input (round-trip `decode(encode(x))===x`, idempotency, ordering) instead of hand-picked cases. Use fast-check / Hypothesis where the logic warrants it.
## 3. Mutation score — the only coverage that proves the tests bite
Line/branch coverage proves code *ran*, not that a test would *fail* if it broke.
**Mutation testing** (Stryker / mutmut / cargo-mutants) flips operators/conditions
and checks a test catches it. A "90% covered" module with 30% mutation score has
assertion-free tests. Target: mutation score ≥ 60% on changed logic-dense files;
report it in TEST-STRATEGY when the change is logic-heavy. Coverage % is the cheap
proxy; mutation score is the truth.
## 4. Flake quarantine — a flaky test is worse than no test
A test that fails ~randomly trains the team to ignore red. Policy:
- A test that fails non-deterministically is **quarantined** (skipped + tracked in a Beads bug), not left to rot the signal.
- Quarantine is time-boxed: a bug with an owner and a deadline, not `it.skip` forever.
- Root-cause before re-enabling (shared state, timing, real network, ordering).
- This is the same discipline the eval runner needs (see the eval `flaky` flag in
`tests/eval/runner.mjs` — stddev > 0.1 is a flake signal).
## Output: TEST-STRATEGY-{slug}.md
```
# TEST-STRATEGY-{slug}
- Archetype + chosen pyramid ratio (+ justification for any deviation)
- Equivalence classes & boundaries enumerated per changed unit
- Property-based candidates (which logic, which invariants)
- Mutation-score target + result (for logic-dense changes)
- Quarantine list (flaky tests + their tracking bug)
```
Done = the plan answers "why THIS set of tests", not just "how much is covered".
© avelikiy · MIT · avelikiy/great_cto
Similar skills
All skills for Testing and QA →test-strategy by other authors comes first.