predict

name	predict
description	Analyzes diffs for regression risk and blast radius, generates risk-scored impact report. Triggers: PR review, code change risk, breaking change, blast radius, regression check.
effort	medium
disable-model-invocation	true
argument-hint	[change description]
agent	predictive-analyst
context	fork
allowed-tools	Read, Grep, Glob

Predict Command

$ARGUMENTS

Triggers the Predictive Analyst to assess the impact and regression risk of proposed changes.

Usage

/predict [path_or_diff]
# /predict src/auth              : analyze all files under src/auth
# /predict --diff                : analyze uncommitted changes (git diff)
# /predict src/api/routes.ts     : analyze a single file

Protocol

1. Scope: Identify Target Files

• If path provided: collect all files under that path
• If --diff: run git diff --name-only to get changed files
• List each file with its last-modified date and line count

2. Trace: Build Dependency Graph

For each target file, find dependents:

# Find files that import/require the target
grep -rl "import.*from.*[target]" --include="*.ts" --include="*.py" --include="*.js" .
grep -rl "require.*[target]" --include="*.js" --include="*.ts" .

Build a graph: changed file, direct dependents, transitive dependents (1 level)

3. Assess: Calculate Risk Score

Score each changed file on a 1 to 5 scale:

Factor	Weight	Scoring
Dependent count	30%	0 deps = 1, 1 to 3 = 2, 4 to 10 = 3, 11 to 20 = 4, 21+ = 5
Test coverage	30%	Has dedicated test = 1, partial = 3, none = 5
Change surface	20%	< 10 lines = 1, 10 to 50 = 2, 50 to 200 = 3, 200+ = 5
Shared/core file	20%	Leaf = 1, mid-layer = 3, core/shared = 5

Overall risk = weighted average rounded to nearest integer.

4. Report: Generate Impact Prediction

Output a markdown report:

## Impact Prediction: [scope]

| File | Risk | Dependents | Test Coverage | Notes |
|------|------|------------|---------------|-------|
| src/auth/login.ts | 4/5 | 12 files | partial | Core auth flow |

### High-Risk Changes (score >= 4)
- [file]: [why it's high risk and what to watch]

### Recommended Actions
- [ ] Add tests for [untested file]
- [ ] Review [high-dependent file] with extra scrutiny
- [ ] Run integration tests covering [affected area]

Rules

• MUST base risk scores on measurable signals (dependent count, coverage, diff size) — not vibes or adjective scales
• MUST name at least one specific action per high-risk file — "review carefully" is not an action
• NEVER predict regressions beyond what the signals justify. A single file with 20 dependents is a signal; a generic "this might break things" is noise.
• NEVER skip the test-coverage factor — a high-dependent file with 100% coverage is lower risk than a low-dependent file with none
• CRITICAL: the report ranks files by weighted risk score, not alphabetically. Readers will stop after the first 5 entries.
• MANDATORY: state the confidence level explicitly. Predictions from a 5-line diff are HIGH confidence; predictions from 500-line refactors are LOW.

Gotchas

• grep -rl "import.*from.*[target]" is easily fooled by comments and string literals. Use the language's real AST tools (ts-morph, ast-grep, pyflakes) for accurate dependency graphs on anything beyond trivial diffs.
• Dynamic imports (importlib.import_module, require(variable), JavaScript await import()) are invisible to grep. Flag explicitly when the target uses them.
• Test coverage reported by CI may exclude generated code, migrations, and __init__.py. "Has dedicated test = score 1" assumes a real assertion exists — check the test file rather than just the path match.
• A 5-line diff in a "core" file is often more dangerous than a 500-line diff in a leaf file. The change_surface weight alone is misleading; combine with shared/core weight for meaningful signals.
• Predictions about regressions are calibrated against the current test suite, not unknown production behaviors. A "low-risk" verdict means "tests likely pass", not "users will not notice".

When NOT to Use

• For executing a change after prediction — use /fix, /refactor, or the relevant skill
• For PR review of logic quality — use /review
• For CI pipeline risk analysis — use /ci-cd-patterns
• For code quality metrics (complexity, duplication) — use /analyze
• For a brand-new codebase with no change history — this skill needs dependents to measure; use /explore first