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
1---2name: predict3description: "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."4effort: medium5disable-model-invocation: true6argument-hint: "[change description]"7agent: predictive-analyst8context: fork9allowed-tools: Read, Grep, Glob10---1112# Predict Command1314$ARGUMENTS1516Triggers the Predictive Analyst to assess the impact and regression risk of proposed changes.1718## Usage1920```bash21/predict [path_or_diff]22# /predict src/auth : analyze all files under src/auth23# /predict --diff : analyze uncommitted changes (git diff)24# /predict src/api/routes.ts : analyze a single file25```2627## Protocol2829### 1. Scope: Identify Target Files3031- If path provided: collect all files under that path32- If `--diff`: run `git diff --name-only` to get changed files33- List each file with its last-modified date and line count3435### 2. Trace: Build Dependency Graph3637For each target file, find dependents:3839```bash40# Find files that import/require the target41grep -rl "import.*from.*[target]" --include="*.ts" --include="*.py" --include="*.js" .42grep -rl "require.*[target]" --include="*.js" --include="*.ts" .43```4445Build a graph: `changed file, direct dependents, transitive dependents (1 level)`4647### 3. Assess: Calculate Risk Score4849Score each changed file on a 1 to 5 scale:5051| Factor | Weight | Scoring |52|--------|--------|---------|53| Dependent count | 30% | 0 deps = 1, 1 to 3 = 2, 4 to 10 = 3, 11 to 20 = 4, 21+ = 5 |54| Test coverage | 30% | Has dedicated test = 1, partial = 3, none = 5 |55| Change surface | 20% | < 10 lines = 1, 10 to 50 = 2, 50 to 200 = 3, 200+ = 5 |56| Shared/core file | 20% | Leaf = 1, mid-layer = 3, core/shared = 5 |5758**Overall risk** = weighted average rounded to nearest integer.5960### 4. Report: Generate Impact Prediction6162Output a markdown report:6364```markdown65## Impact Prediction: [scope]6667| File | Risk | Dependents | Test Coverage | Notes |68|------|------|------------|---------------|-------|69| src/auth/login.ts | 4/5 | 12 files | partial | Core auth flow |7071### High-Risk Changes (score >= 4)72- [file]: [why it's high risk and what to watch]7374### Recommended Actions75- [ ] Add tests for [untested file]76- [ ] Review [high-dependent file] with extra scrutiny77- [ ] Run integration tests covering [affected area]78```7980## Rules8182- **MUST** base risk scores on measurable signals (dependent count, coverage, diff size) — not vibes or adjective scales83- **MUST** name at least one specific action per high-risk file — "review carefully" is not an action84- **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.85- **NEVER** skip the test-coverage factor — a high-dependent file with 100% coverage is lower risk than a low-dependent file with none86- **CRITICAL**: the report ranks files by weighted risk score, not alphabetically. Readers will stop after the first 5 entries.87- **MANDATORY**: state the confidence level explicitly. Predictions from a 5-line diff are HIGH confidence; predictions from 500-line refactors are LOW.8889## Gotchas9091- `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.92- Dynamic imports (`importlib.import_module`, `require(variable)`, JavaScript `await import()`) are invisible to grep. Flag explicitly when the target uses them.93- 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.94- 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.95- 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".9697## When NOT to Use9899- For **executing** a change after prediction — use `/fix`, `/refactor`, or the relevant skill100- For PR review of logic quality — use `/review`101- For CI pipeline risk analysis — use `/ci-cd-patterns`102- For code quality metrics (complexity, duplication) — use `/analyze`103- For a brand-new codebase with no change history — this skill needs dependents to measure; use `/explore` first