Skip to main content
skill CX Codex

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.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add avelikiy/great_cto --skill test-strategy -a claude-code
Open on GitHub

What 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-code

2Manually: put the files in place

~/.claude/skills/test-strategy/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/test-strategy/

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.

From the same set11

verticals A skill for Claude, Codex, Cursor and other agents: hands the agent the domain brief for one SMB industry before it writes a spec or code. CX Codex +1 ★ 107repo stars signing-preflight Checks before the first commit that the signing key is loaded and unlocked, and asks the operator to unlock it up front. CX Codex +1 ★ 107repo stars prose-style A writing contract for agent output: conclusion first, evidence over adjectives. Useful when a person reads the report, not a parser. CX Codex +1 ★ 107repo stars pm-planning Turns an approved architecture document into a Beads task list with dependencies, time-boxes and acceptance criteria. Built for the pm agent handing work to senior-dev. CX Codex +1 ★ 107repo stars observability-baseline Bakes error capture in Sentry, request-id structured logs and /healthz plus /readyz endpoints into a freshly generated service. Useful when the app is still being scaffolded and you don't want the first prod failure to go unseen. CX Codex +1 ★ 107repo stars great_cto The skill turns Claude into a pipeline orchestrator: you describe the task in plain words and the right agents run on their own. Useful when one agent drives a whole project. CX Codex +1 ★ 107repo stars deploy-landed The skill checks that the revision being served is the commit you meant, that its env reached the running process, and that the product actually works. Useful after any deploy or restart. CX Codex +1 ★ 107repo stars cost-model Pins down one format for the cost section in plans and architecture docs. Useful when a report claims savings and someone will ask how you got the number. CX Codex +1 ★ 107repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor