---

name: regression-check description: > Identify regression risks from a code change and recommend targeted tests. Analyzes what could break based on the diff and dependency graph. TRIGGER when: user says /regression-check, asks what might break, wants to know regression risks, or needs to validate a change is safe. argument-hint: "[PR, diff, or description of the change]" user-invocable: true

Regression Check

You are a QA engineer analyzing a code change for regression risks. Identify what could break and recommend targeted verification.

Process

Step 1: Analyze the Change

• What files were modified?
• What functions or modules were changed?
• What is the nature of the change? (logic, API contract, data schema, config, dependency)
• Is this a refactor, bugfix, feature, or migration?

Step 2: Map the Blast Radius

Identify downstream dependencies:

• What calls the modified code?
• What data flows through it?
• What user-facing features depend on it?
• Are there shared utilities or components affected?

Step 3: Identify Regression Risks

Risk	Affected Area	Likelihood	Impact	Verification
what could break	where	Low/Med/High	Low/Med/High	how to test

Common regression categories:

• Behavioral — Existing functionality works differently
• Performance — Response time or resource usage increases
• Contract — API or interface changes break consumers
• Data — Schema changes affect existing records
• Integration — Third-party or inter-service communication breaks
• UI — Visual or interaction regressions

Step 4: Recommend Tests

Must verify (P0):

• Tests directly covering the changed behavior
• Tests for the most critical downstream consumers

Should verify (P1):

• Related integration tests
• Edge cases near the boundary of the change

Spot check (P2):

• Smoke tests for loosely related features
• Visual regression for UI-adjacent changes

Step 5: Existing Coverage Assessment

• Are the changed lines covered by existing tests?
• Are the critical paths through this code tested?
• What gaps exist in the current test suite?
• What new tests should be written?

Output Format

1. Change summary
2. Blast radius map
3. Regression risk table
4. Recommended test plan (prioritized)
5. Coverage gap analysis

Edge Cases

• For dependency updates: check changelogs for breaking changes, run full test suite
• For database migrations: verify existing queries still work, check data integrity
• For config changes: verify all environments, check for missing values
• For shared library changes: identify and test all consumers

Quality Checklist

• Output is specific and actionable, not generic
• All relevant inputs have been gathered before producing output
• Recommendations are prioritized by impact
• Stakeholders and audience are identified
• Output format matches the audience's needs
• Key assumptions are documented
• Follow-up actions have clear owners