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.4---56# Predict Command78$ARGUMENTS910Triggers the Predictive Analyst to assess the impact and regression risk of proposed changes.1112## Usage1314```bash15/predict [path_or_diff]16# /predict src/auth : analyze all files under src/auth17# /predict --diff : analyze uncommitted changes (git diff)18# /predict src/api/routes.ts : analyze a single file19```2021## Protocol2223### 1. Scope: Identify Target Files2425- If path provided: collect all files under that path26- If `--diff`: run `git diff --name-only` to get changed files27- List each file with its last-modified date and line count2829### 2. Trace: Build Dependency Graph3031For each target file, find dependents:3233```bash34# Find files that import/require the target35grep -rl "import.*from.*[target]" --include="*.ts" --include="*.py" --include="*.js" .36grep -rl "require.*[target]" --include="*.js" --include="*.ts" .37```3839Build a graph: `changed file, direct dependents, transitive dependents (1 level)`4041### 3. Assess: Calculate Risk Score4243Score each changed file on a 1 to 5 scale:4445| Factor | Weight | Scoring |46|--------|--------|---------|47| Dependent count | 30% | 0 deps = 1, 1 to 3 = 2, 4 to 10 = 3, 11 to 20 = 4, 21+ = 5 |48| Test coverage | 30% | Has dedicated test = 1, partial = 3, none = 5 |49| Change surface | 20% | < 10 lines = 1, 10 to 50 = 2, 50 to 200 = 3, 200+ = 5 |50| Shared/core file | 20% | Leaf = 1, mid-layer = 3, core/shared = 5 |5152**Overall risk** = weighted average rounded to nearest integer.5354### 4. Report: Generate Impact Prediction5556Output a markdown report:5758```markdown59## Impact Prediction: [scope]6061| File | Risk | Dependents | Test Coverage | Notes |62|------|------|------------|---------------|-------|63| src/auth/login.ts | 4/5 | 12 files | partial | Core auth flow |6465### High-Risk Changes (score >= 4)66- [file]: [why it's high risk and what to watch]6768### Recommended Actions69- [ ] Add tests for [untested file]70- [ ] Review [high-dependent file] with extra scrutiny71- [ ] Run integration tests covering [affected area]72```7374## Rules7576- **MUST** base risk scores on measurable signals (dependent count, coverage, diff size) — not vibes or adjective scales77- **MUST** name at least one specific action per high-risk file — "review carefully" is not an action78- **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.79- **NEVER** skip the test-coverage factor — a high-dependent file with 100% coverage is lower risk than a low-dependent file with none80- **CRITICAL**: the report ranks files by weighted risk score, not alphabetically. Readers will stop after the first 5 entries.81- **MANDATORY**: state the confidence level explicitly. Predictions from a 5-line diff are HIGH confidence; predictions from 500-line refactors are LOW.8283## Gotchas8485- `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.86- Dynamic imports (`importlib.import_module`, `require(variable)`, JavaScript `await import()`) are invisible to grep. Flag explicitly when the target uses them.87- 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.88- 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.89- 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".9091## When NOT to Use9293- For **executing** a change after prediction — use `/fix`, `/refactor`, or the relevant skill94- For PR review of logic quality — use `/review`95- For CI pipeline risk analysis — use `/ci-cd-patterns`96- For code quality metrics (complexity, duplication) — use `/analyze`97- For a brand-new codebase with no change history — this skill needs dependents to measure; use `/explore` first