---
name: regression-checker
description: Check a repository or recent changes for regressions in tests, imports, CLI commands, data schemas, configs, docs, scripts, and deployment assumptions. Use for pre-push checks, nightly checks, smoke tests, and automation reports.
---

# Regression Checker

Use this skill when the user asks to verify that recent changes did not break a codebase, experiment pipeline, deployment path, or documentation.

## Default behavior

Do not start with broad refactors. First inspect and test.

Prefer cheap, targeted checks before expensive runs.

If tests are unavailable or too costly, perform static and smoke checks and clearly label coverage limits.

## Check sequence

1. Establish scope
   - current branch
   - changed files
   - recent commits
   - affected modules
   - user-specified subsystem

2. Static sanity checks
   - syntax/import errors
   - missing files
   - renamed paths
   - config schema drift
   - CLI argument mismatch
   - hard-coded local paths
   - dependency updates needed

3. Lightweight execution
   - `--help` for modified CLI scripts
   - import smoke tests
   - unit tests for affected modules
   - dry-run or small-sample mode if available

4. Data and experiment compatibility
   - dataset field names
   - shape/order conventions
   - sidecar file requirements
   - checkpoint/config compatibility
   - train/inference path divergence

5. Documentation sync
   - README commands
   - config examples
   - run scripts
   - comments that contradict code

6. Report
   - pass/fail
   - commands run
   - evidence
   - risk not covered by tests

## Output format

```markdown
# Regression Check

## Scope
- Branch/commit:
- Changed files:
- Subsystems:

## Summary
- Verdict:
- Confidence:
- Main risk:

## Checks Run
| Check | Command | Result | Notes |
|---|---|---|---|

## Findings
1. **[Severity] Title**
   - Evidence:
   - Impact:
   - Minimal fix:
   - Validation:

## Not Covered
- ...

## Recommended Next Commands
```bash
...
```
```

## Automation mode

For recurring automation:
- produce a short report when all checks pass
- produce a detailed report only when failures or suspicious changes appear
- never apply fixes unless the automation explicitly requests it
- if a check is too expensive, note the skipped check and suggest a cheaper proxy