How do I install the Test Strategy Designer skill?

Run npx skillmds@latest add willianbs/test-strategy-designer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Test Strategy Designer safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Test Strategy Designer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Test Strategy Designer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Test Strategy Designer?

willianbs (@willianbs) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Test Strategy Designer by willianbs

Name: Test Strategy Designer
Author: willianbs

Test Strategy Designer

Designs a risk-based test strategy mapped to acceptance criteria without writing test code unless asked. Use after planning and before or during implementation. Emits TEST_STRATEGY. Never chases 100% coverage or tests implementation details by default.

willianbs d769538 2 files · 3.6 KB Updated Sep 17, 2026

File contents

Purpose

Define what must be tested, at which level, and what blocks CI—so correctness and regressions are intentional, not accidental.

When to Use / When NOT to Use

Use when: feature has ACs; HighRisk change; after delivery-planner; before large implementer work.

Do not use when: user only wants a single unit test written (feature-implementer / tdd); pure docs.

Preconditions

Prefer SPEC_STATUS with AC IDs + PLAN/TASK_GRAPH. If missing, derive provisional ACs and mark them provisional.

Inputs / Outputs

Inputs: AC list, PLAN/TASK_GRAPH, CONTEXT_PACK, risk notes.

Outputs: TEST_STRATEGY

Upstream / Downstream

Upstream: spec-validator, delivery-planner.

Downstream: feature-implementer, quality-gate, defect-analyst (regression).

Core Principles

Risk-based, not coverage-vanity.
Behavior over implementation details.
Pyramid by default; justify every E2E.
Security/perf tests mandatory when risk ≥ High for those domains.
Flakes are defects—define quarantine/ownership.
CI blocking set ≠ nightly set.
Do not write tests unless asked.

Process

Ingest AC IDs and risk (auth, money, data, concurrency).
Build matrix: each AC_ID → unit / integration / e2e / manual / monitoring.
Choose pyramid defaults for the stack found in CONTEXT_PACK; justify deviations.
Mocking strategy — what to fake vs real.
CI blocking vs nightly/scheduled.
Required security tests (authz negative cases) if auth/PII/payments.
Required perf smoke if latency/SLO sensitive.
Flake policy — quarantine, owner, max retries.
Production validation hooks if relevant (feature flag, metric).

Evidence Requirements

Every AC_ID appears in the matrix. “No test needed” requires rationale.

Stop Conditions / Failure Modes

Condition	Action
ACs not testable	Hand back to spec-validator (`Revise`)
Only E2E proposed for everything	`Revise` pyramid

Severity + Confidence

Untested Critical AC → strategy Decision Block until covered in matrix.

Output Contract

## TEST_STRATEGY
Matrix:
  AC-1: unit, integration
Pyramid notes: ...
CI blocking: ...
Nightly: ...
Security/perf required: ...
Flake policy: ...
Decision: Proceed | ProceedWithConditions | Revise | Block

Handoffs

feature-implementer — execute strategy
quality-gate — verify CI blocking evidence
defect-analyst — when failures appear

Never

Never demand 100% line coverage as a goal.
Never write brittle tests coupled to private implementation unless asked.
Never skip negative authz cases for auth changes.

---name: test-strategy-designerdescription: Designs a risk-based test strategy mapped to acceptance criteria without writing test code unless asked. Use after planning and before or during implementation. Emits TEST_STRATEGY. Never chases 100% coverage or tests implementation details by default.---# PurposeDefine what must be tested, at which level, and what blocks CI—so correctness and regressions are intentional, not accidental.# When to Use / When NOT to Use**Use when:** feature has ACs; HighRisk change; after delivery-planner; before large implementer work.**Do not use when:** user only wants a single unit test written (feature-implementer / tdd); pure docs.# PreconditionsPrefer `SPEC_STATUS` with AC IDs + `PLAN`/`TASK_GRAPH`. If missing, derive provisional ACs and mark them provisional.# Inputs / Outputs**Inputs:** AC list, `PLAN`/`TASK_GRAPH`, `CONTEXT_PACK`, risk notes.**Outputs:** `TEST_STRATEGY`# Upstream / Downstream**Upstream:** spec-validator, delivery-planner.**Downstream:** feature-implementer, quality-gate, defect-analyst (regression).# Core Principles1. Risk-based, not coverage-vanity.2. Behavior over implementation details.3. Pyramid by default; justify every E2E.4. Security/perf tests mandatory when risk ≥ High for those domains.5. Flakes are defects—define quarantine/ownership.6. CI blocking set ≠ nightly set.7. Do not write tests unless asked.# Process1. Ingest AC IDs and risk (auth, money, data, concurrency).2. Build matrix: each AC_ID → unit / integration / e2e / manual / monitoring.3. Choose pyramid defaults for the stack found in CONTEXT_PACK; justify deviations.4. Mocking strategy — what to fake vs real.5. CI blocking vs nightly/scheduled.6. Required security tests (authz negative cases) if auth/PII/payments.7. Required perf smoke if latency/SLO sensitive.8. Flake policy — quarantine, owner, max retries.9. Production validation hooks if relevant (feature flag, metric).# Evidence RequirementsEvery AC_ID appears in the matrix. “No test needed” requires rationale.# Stop Conditions / Failure Modes| Condition | Action ||-----------|--------|| ACs not testable | Hand back to spec-validator (`Revise`) || Only E2E proposed for everything | `Revise` pyramid |# Severity + ConfidenceUntested Critical AC → strategy Decision `Block` until covered in matrix.# Output Contract```## TEST_STRATEGYMatrix: AC-1: unit, integrationPyramid notes: ...CI blocking: ...Nightly: ...Security/perf required: ...Flake policy: ...Decision: Proceed | ProceedWithConditions | Revise | Block```# Handoffs- **feature-implementer** — execute strategy- **quality-gate** — verify CI blocking evidence- **defect-analyst** — when failures appear# Never- Never demand 100% line coverage as a goal.- Never write brittle tests coupled to private implementation unless asked.- Never skip negative authz cases for auth changes.

Frequently asked questions