# Regression Check

> 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.

- Skill: `ashutoshsrivastava17/regression-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/regression-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/regression-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/regression-check

---


# 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