Skip to content

t1k:predict

FieldValue
Modulet1k-extended
Version2.14.3
Effortmedium
Tools

Keywords: debate, expert, pre-implementation, predict, review, risky, tradeoffs

/t1k:predict
<proposed change description>

5 expert personas review a proposed change and debate its merits, risks, and alternatives.

/t1k:predict "Add caching layer to API responses"
#PersonaFocusLooks For
1ArchitectSystem design, scalability, couplingOver-engineering, tight coupling, wrong abstractions, missing extensibility
2SecurityAttack surface, data flow, trust boundariesAuth bypass, injection, data exposure, insufficient logging
3PerformanceBottlenecks, memory, latencyN+1 queries, unnecessary allocations, cache invalidation issues
4UX/DXUser/developer impact, edge casesBreaking changes, poor error messages, confusing APIs
5Devil’s AdvocateAssumptions, alternatives, hidden costs”What if this is the wrong approach entirely?”
  1. Read the proposed change description
  2. Each persona reviews independently:
    • State their concerns (1-3 bullet points)
    • Rate risk for their domain (1-5 scale)
    • Suggest mitigations
  3. Synthesize:
    • Consensus risk score (average of 5 ratings)
    • Prioritized concern list (highest risk first)
    • Go/No-Go recommendation with conditions
## Prediction: {change description}
### Architect (Risk: 3/5)
- Concern: ...
- Mitigation: ...
### Security (Risk: 2/5)
- Concern: ...
- Mitigation: ...
### Performance (Risk: 4/5)
- Concern: ...
- Mitigation: ...
### UX/DX (Risk: 1/5)
- Concern: ...
- Mitigation: ...
### Devil's Advocate (Risk: 3/5)
- Alternative: ...
- Hidden cost: ...
### Consensus
- **Overall Risk: 2.6/5**
- **Recommendation: GO with conditions**
- **Top 3 concerns to address:**
1. ...
2. ...
3. ...
TrapReality
”This change is too simple for a debate”Simple changes with hidden complexity cause the worst incidents.
”We already discussed this”Discussion ≠ structured risk assessment.
”The user wants to start coding”5 minutes of prediction saves 5 hours of debugging.
  • Before any change affecting >3 files
  • Before any security-sensitive change
  • Before any architectural decision
  • When the team disagrees on approach
  • When risk feels “medium” or higher

Sub-agent forking: see skills/t1k-architecture/references/fork-hygiene.md.