Regression Test Plan Skill

Regression testing protects what already works — but re-running everything every time is slow and wasteful, and testing too little ships breakage. The answer is risk-based: re-test what changed, what it touches, and what hurts most if it breaks. This skill builds that prioritised plan and a run strategy, so coverage tracks risk and the suite doesn't balloon.

Working from a brief

Given "we're shipping a checkout change, what should we regression-test?", produce the plan anyway — infer the impacted areas and a sensible prioritisation, labelling assumptions. Tie scope to change-impact and risk. Never hand back a question instead of a plan.

Required Inputs

Ask for these only if they aren't already provided (else infer and label):

• The change — what's being released/modified, and what it touches (and integrates with).
• Critical paths — the flows that must never break (revenue, auth, data integrity).
• Existing coverage — current regression cases/automation, if any, and how long a full run takes.
• Constraints — time/resources per release, and manual vs. automated capacity.

Output Format

Regression Plan: [release/change]

1. Impact analysis — what changed, the areas directly and indirectly affected, and the high-risk zones (shared components, recent bugs, complex logic).

2. Prioritised scope — what to re-test, in tiers:

Tier	When to run	Scope	Why
Smoke / sanity	every build	critical paths only (login, checkout, save)	fast fail
Targeted	this change	the changed area + its direct dependencies	change-impact
Full regression	major release / risky change	broad core coverage	safety net

3. What to skip (and the risk) — explicitly de-scope low-risk, unchanged areas, and name the residual risk.