How do I install the Test Design skill?

Run npx skillmds@latest add jbaehne/test-design 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 Design safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Test Design?

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 Design free to use?

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

Who published Test Design?

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

Test Design by jbaehne — Agent Skill

Name: Test Design
Rating: 4.2 (5 reviews)
Author: jbaehne

Test Design

Design risk-based tests for changed behavior and separate meaningful gaps from tests that only mirror the implementation. Use when asked which tests to add or how to verify a change. Do not use to issue a merge ruling or to claim checks passed without running them.

jbaehne Updated Sep 22, 2026

File contents

Test design

Tie tests to risks in the change. A test that only restates the current implementation is not evidence the behavior is right.

Repository test layout, frameworks, and commands override this skill. If you do not yet know them, use repository-archaeology first. Do not introduce a second test stack when the repository already has one.

Map risk to evidence

Prioritize, in order: correctness, security and privacy, data loss, compatibility and migrations, operational failure, then lesser gaps.

For each material risk, say which level can actually catch it. Use a level only when it fits the repository:

unit — isolated behavior and boundaries
integration — real collaborators the change depends on
contract — an interface another system relies on
migration — data or schema transformation, including rollback
property — invariants across inputs, when examples would miss them
performance — only when the change has a performance requirement
end-to-end — a user or operator path that lower levels cannot see

For each risk worth testing, name the critical positive case, the negative or failure case, and the boundary that would invalidate the approach. Skip levels that would not change confidence.

Recommend or add tests

If the user authorized test changes, add the smallest tests that fail when the intended behavior breaks. Otherwise recommend them and do not edit.

Do not weaken, skip, or delete existing checks to make a run pass. Do not claim a command passed unless you ran it and saw the result. If the environment cannot run a command, record it as not run and why.

Testing is not a merge ruling. Do not issue APPROVE or REQUEST CHANGES from this skill.

Output

## Risk to test
- Risk — level — case that would catch it

## Cases
- Positive:
- Negative or failure:
- Boundary:

## Tests
- Added: `path` — risk it covers
- Recommended, not added: what and why it was not added

## Commands
- `command`: passed — what it verified
- `command`: failed — what failed
- Not run: `command` — reason

## Coverage gaps
- Remaining risk and why it is still open

When handing off, record verification in ../_sdlc/evidence.yaml. Do not set state.verified because tests were designed. Set it only when the relevant commands ran and passed for this revision.

Suite boundaries: ../_sdlc/LIFECYCLE.md.

---name: test-designdescription: Design risk-based tests for changed behavior and separate meaningful gaps from tests that only mirror the implementation. Use when asked which tests to add or how to verify a change. Do not use to issue a merge ruling or to claim checks passed without running them.---# Test designTie tests to risks in the change. A test that only restates the current implementation is not evidence the behavior is right.Repository test layout, frameworks, and commands override this skill. If you do not yet know them, use `repository-archaeology` first. Do not introduce a second test stack when the repository already has one.## Map risk to evidencePrioritize, in order: correctness, security and privacy, data loss, compatibility and migrations, operational failure, then lesser gaps.For each material risk, say which level can actually catch it. Use a level only when it fits the repository:- unit — isolated behavior and boundaries- integration — real collaborators the change depends on- contract — an interface another system relies on- migration — data or schema transformation, including rollback- property — invariants across inputs, when examples would miss them- performance — only when the change has a performance requirement- end-to-end — a user or operator path that lower levels cannot seeFor each risk worth testing, name the critical positive case, the negative or failure case, and the boundary that would invalidate the approach. Skip levels that would not change confidence.## Recommend or add testsIf the user authorized test changes, add the smallest tests that fail when the intended behavior breaks. Otherwise recommend them and do not edit.Do not weaken, skip, or delete existing checks to make a run pass. Do not claim a command passed unless you ran it and saw the result. If the environment cannot run a command, record it as not run and why.Testing is not a merge ruling. Do not issue `APPROVE` or `REQUEST CHANGES` from this skill.## Output```markdown## Risk to test- Risk — level — case that would catch it## Cases- Positive:- Negative or failure:- Boundary:## Tests- Added: `path` — risk it covers- Recommended, not added: what and why it was not added## Commands- `command`: passed — what it verified- `command`: failed — what failed- Not run: `command` — reason## Coverage gaps- Remaining risk and why it is still open```When handing off, record `verification` in [`../_sdlc/evidence.yaml`](../_sdlc/evidence.yaml). Do not set `state.verified` because tests were designed. Set it only when the relevant commands ran and passed for this revision.Suite boundaries: [`../_sdlc/LIFECYCLE.md`](../_sdlc/LIFECYCLE.md).

Frequently asked questions