---
name: analyzing-regression-scope
description: 'Analyzes diffs, changed files, hotfixes, and release candidates to find which features a change could break, where regression risk spreads, and what must be retested first. Use when scoping retest after a change, reviewing QA impact for a pull request, or building a minimal confidence suite for release validation. For a rule-based mapping from diff tags to the quality checks a pull request needs, use scoping-change-relevance.'
argument-hint: 'Diff, changed files, PR summary, release notes, critical flows, and any known risk areas'
user-invocable: true
---

# Analyzing Regression Scope

Use this skill when the real question is not "how do we test everything?" but "what must we retest now, and why?"
It is built for risk-aware retest planning after code changes, configuration shifts, dependency updates, or release packaging.

## When to Use

- analyze regression scope after a bug fix or feature change
- decide what must be retested for a hotfix
- prepare a release confidence suite from a diff or PR
- explain QA impact of shared component or config changes
- separate must-retest areas from nice-to-have regression coverage

## Operating Principles

- **Change surface first** - understand what changed before proposing retest coverage.
- **Risk spreads through dependencies** - shared modules, auth, data mapping, and configuration often widen impact.
- **Direct is not the whole story** - the changed file is only the start; adjacent behaviors matter too.
- **Small believable packs beat fake completeness** - a focused confidence suite is better than a giant list nobody will execute.
- **Unknown impact stays visible** - if propagation is unclear, log it as an open question instead of bluffing.

## Workflow

### Phase 0: Frame the input

Use the best available source:

- changed files
- a diff or PR summary
- release notes
- a hotfix description
- a list of touched components or endpoints

Capture any known critical journeys, environments, or roles that matter.

### Phase 1: Map the change surface

Break the change into four layers:

1. **Directly changed behavior** - the feature, endpoint, or component that was edited
2. **Adjacent behavior** - nearby flows that call, render, or depend on the changed surface
3. **Shared risk** - utilities, configuration, auth, layout, data mapping, or common services reused elsewhere
4. **State and data risk** - migrations, caching, permissions, synchronization, or environment-specific behavior

### Phase 2: Classify retest risk

Use a practical three-level scale:

| Risk | Use when |
| --- | --- |
| High | Direct change on a critical path, shared core module, data integrity flow, auth, checkout, notifications, or high-traffic workflow |
| Medium | Indirect dependency, shared helper, UI shell, validation logic, or meaningful edge-case exposure |
| Low | Isolated change with narrow blast radius and no obvious shared-path impact |

### Phase 3: Build the regression pack

Organize the result into four buckets:

- **Must retest** - confidence blockers; skipping these would be reckless
- **Should retest** - meaningful adjacent coverage if time allows
- **Can sample** - smoke-level checks instead of full retest
- **Can defer with caution** - lower-impact items worth tracking, not necessarily executing now

For every important area, include:

- why it is affected
- what to retest
- what data or environment setup is needed
- whether the coverage should stay manual or move into automation later

### Phase 4: Produce the report

Use `./resources/regression-scope-template.md` when possible.

A strong report includes:

- a short change summary
- a risk-ranked regression table
- a minimal confidence suite
- explicit open questions and blind spots

## Common Failure Modes

- equating changed files with full regression scope
- producing a huge retest list with no priority
- ignoring shared components, config, or auth ripple effects
- forgetting data setup or role-specific behavior
- treating uncertainty as low risk without explanation

## Resource Map

- `./resources/regression-scope-template.md` - structure for regression reports and confidence suites

## Related Skills

- `designing-functional-tests` - when the regression result should expand into manual scenarios or test cases
- `verifying-acceptance-criteria` - when the question becomes whether the feature now meets its stated contract
- `requirements-test-coverage-mapper` - when broader traceability matters more than tactical retest scope
- `code-review-advanced` - when the regression assessment should be paired with code-level risk review

## Definition of Done

This skill is complete when:

- the change surface is explained clearly
- high, medium, and low regression areas are separated
- the must-retest pack is believable and prioritized
- open questions and blind spots are explicit
- the output can guide a tester or release lead immediately