Skip to main content

/will - Future State Prediction

Predict outcomes, compatibility impacts, test results, and future states.

System Prompt

⚠️ EXECUTION DIRECTIVE: When the user invokes this command, you MUST:

  1. IMMEDIATELY execute - no questions, no explanations first
  2. Parse the query to identify the prediction needed
  3. Analyze evidence from code, tests, dependencies
  4. Provide prediction with confidence level

DO NOT:

  • Make predictions without evidence
  • Skip confidence levels

The user invoking the command IS the confirmation.


Usage

/will <prediction-query>

Query Patterns

Query PatternPurposeAnalysis Method
/will this break compatibilityAPI compatibilitySemver analysis, consumers
/will tests passTest predictionTest history, code changes
/will this scaleScalabilityLoad patterns, bottlenecks
/will this deploy succeedDeploymentConfig validation, deps
/will this merge cleanlyMerge predictionGit conflict analysis

Execution Steps

Step 1: Parse Prediction Query

# Identify prediction type:
# - compatibility, tests, scale, deploy, merge, performance

Step 2: Gather Evidence

# For compatibility
git diff --name-only HEAD~1 | grep -E '\.(py|ts|js)$'
# Check for breaking changes in public APIs

# For tests
git log --oneline -10 -- tests/
# Check recent test failures

# For deployment
kubectl get deployments -o yaml | grep -E 'image:|replicas:'
# Validate configuration

# For merge
git merge-base HEAD main
git diff --stat $(git merge-base HEAD main)

Step 3: Analyze Impact

# Identify:
# - Direct impacts (what will change)
# - Indirect impacts (what depends on changes)
# - Risk factors (what could go wrong)

Step 4: Provide Prediction

# Format: LIKELY/UNLIKELY + confidence + evidence + risks

Response Format

┌─────────────────────────────────────────────────────────────────┐
│ /will: <query> │
├─────────────────────────────────────────────────────────────────┤
│ PREDICTION │
│ ────────── │
│ │
│ ✅ LIKELY / ⚠️ UNCERTAIN / ❌ UNLIKELY │
│ │
│ Confidence: XX% (HIGH/MEDIUM/LOW) │
│ │
│ EVIDENCE │
│ ──────── │
│ • <evidence point 1> │
│ • <evidence point 2> │
│ • <evidence point 3> │
│ │
│ IMPACT ANALYSIS │
│ ─────────────── │
│ Direct: │
│ • <direct impact> │
│ Indirect: │
│ • <indirect impact> │
│ │
│ RISK FACTORS │
│ ──────────── │
│ • <risk 1> - Mitigation: <action> │
│ • <risk 2> - Mitigation: <action> │
│ │
│ RECOMMENDED ACTIONS │
│ ─────────────────── │
│ 1. <action to verify/mitigate> │
│ 2. <action to verify/mitigate> │
│ │
├─────────────────────────────────────────────────────────────────┤
│ Based on: <analysis sources> │
└─────────────────────────────────────────────────────────────────┘

Examples

Compatibility Check

/will this API change break compatibility

Output:

❌ UNLIKELY TO BREAK (85% confidence)

EVIDENCE:
• Only internal functions modified
• Public API signatures unchanged
• No consumers of changed functions found

RISK FACTORS:
• Indirect imports - Mitigation: Search for dynamic imports

RECOMMENDED ACTIONS:
1. Run: grep -r "from module import changed_func"
2. Check for reflection-based usage

Test Prediction

/will tests pass after this change

Output:

⚠️ UNCERTAIN (55% confidence)

EVIDENCE:
• 3 test files touch modified code
• Last 5 runs: 4 passed, 1 flaky failure
• No test coverage for new edge case

RISK FACTORS:
• test_auth.py has flaky history
• New code path untested

RECOMMENDED ACTIONS:
1. Add test for new edge case
2. Run tests locally before push

Merge Prediction

/will this branch merge cleanly into main

Output:

✅ LIKELY (90% confidence)

EVIDENCE:
• 5 files changed, none modified in main since branch
• No overlapping line changes detected
• git merge-tree shows no conflicts

RISK FACTORS:
• package.json touched - check for lockfile conflicts

RECOMMENDED ACTIONS:
1. Run: git fetch origin && git merge-tree HEAD origin/main

Scalability Prediction

/will this handle 10x traffic

Output:

❌ UNLIKELY (70% confidence)

EVIDENCE:
• Single database connection, no pooling
• No caching layer
• Synchronous processing

RISK FACTORS:
• Database becomes bottleneck at 2x
• Memory grows linearly with requests

RECOMMENDED ACTIONS:
1. Add connection pooling
2. Implement Redis caching
3. Consider async processing
CommandPurpose
/should <decision>Get recommendations
/can <action>Check capabilities
/is <state>Verify current state
/does <action>Verify current behavior
/how <task>Get implementation steps

Success Output

✅ COMMAND COMPLETE: /will
Query: <query>
Prediction: LIKELY/UNCERTAIN/UNLIKELY
Confidence: XX%
Evidence: <count> points analyzed

Completion Checklist

Before marking complete:

  • Prediction type identified
  • Evidence gathered
  • Confidence level assigned
  • Risks identified
  • Mitigations suggested

Failure Indicators

This command has FAILED if:

  • ❌ No query provided
  • ❌ Prediction without evidence
  • ❌ No confidence level given
  • ❌ No actionable recommendations

When NOT to Use

Do NOT use when:

  • Need current state (use /is)
  • Need capability check (use /can)
  • Need recommendations (use /should)

Principles

This command embodies:

  • #9 Based on Facts - Evidence-based predictions
  • #6 Clear, Understandable - Clear confidence levels
  • #3 Complete Execution - Always includes mitigations

Full Standard: CODITECT-STANDARD-AUTOMATION.md


Version: 1.0.0 Created: 2026-02-04 Author: CODITECT Team Framework: 5W+H Question Framework