Use test-plan-generator

Generate a risk-based test plan for a feature, PR, or release

Generate a risk-based test plan for a feature, PR, or release — risks ranked by likelihood × impact, test cases pushed to the lowest pyramid level that catches the failure, every acceptance criterion mapped to a test, and an explicit "not tested" list.

Reach for it when the user asks for a test plan, test cases, a QA strategy for a change, "how should we test this", or pre-release test coverage.

Install it

npx skilldrop-cli install test-plan-generator                 # Claude Code, your user folder
npx skilldrop-cli install test-plan-generator --project       # Claude Code, this repo
npx skilldrop-cli install test-plan-generator --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Write a test plan for this feature"
• "What should we test before this release, ranked by risk?"
• "Map these acceptance criteria to test cases"
• "Generate a risk-based QA plan for this PR"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Split this epic into user stories with acceptance criteria"
• "Review my code and tell me which tests are missing"
• "Run the Sonar scan on my branch"

If another skill answers instead, ask for this one by name: "use test-plan-generator".

Check what you get

A good result:

• Risk table precedes test cases, and effort tracks priority. A plan that gives equal depth to every area was written by coverage habit, not risk.
• Every test case has a concrete expected result. ✅ "Then the response is 422 with error code DUPLICATE_SKU" — ❌ "Then an appropriate error is shown".
• Every AC appears in the coverage table. Uncovered ACs are listed as gaps at the top of the plan, never silently absent.
• The "Not tested" section is non-empty. A plan that tests everything is a plan that prioritized nothing — naming accepted risks is the deliverable.
• Pyramid placement is justified by failure location, not by what's easiest to write. Each e2e case states why no lower level could catch it.

Use something else when

• Writing the test code itself — hand the plan to feature-implement-loop or a human
• Adversarial review of code already written — that's devils-advocate
• Static-analysis or quality-gate findings — that's sonar-review
• A trivial change (typo, copy edit) — the plan would cost more than the risk

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: devils-advocate, feature-implement-loop, sonar-review, user-story-splitter

Edit this page on GitHub · View source