Test strategy designer

Skill willianbs/skills/test-strategy-designer

AI Engineering Operating System

Install

npx -y skills add willianbs/skills --skill test-strategy-designer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

20 days oldThe repository was created 20 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

2.9 KB, 635 tokens by cl100k_base, as published. Nobody here has run it

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.