Mode Transitions

🔄 Mode Transition Guide

Master the art of switching between RIPER modes effectively, understanding when and how to transition for optimal workflow efficiency.

🎯 Understanding Mode Transitions

Mode transitions are controlled context switches that:

• Change operational permissions
• Update active context
• Create safety backups
• Log workflow progress

Each transition represents a mental shift in your development approach.

🗺️ Transition Map

┌─────────┐     ┌─────────┐     ┌─────────┐
│ RESEARCH│ ←→ │ INNOVATE│ ←→ │  PLAN   │
│   Ω₁    │     │   Ω₂    │     │   Ω₃    │
└─────────┘     └─────────┘     └─────────┘
     ↑               ↑               ↓
     └───────────────┼───────────────┘
                     ↓
              ┌─────────┐     ┌─────────┐
              │ EXECUTE │ ←→ │ REVIEW  │
              │   Ω₄    │     │   Ω₅    │
              └─────────┘     └─────────┘

Key Points:

• Any mode can transition to any other
• Standard flow: R→I→P→E→R
• Shortcuts allowed when needed
• Each transition has a cost

🎮 Transition Commands

Basic Commands

From → To	Command	Shortcut
Any → Research	/research	/r
Any → Innovate	/innovate	/i
Any → Plan	/plan	/p
Any → Execute	/execute	/e
Any → Review	/review	/rev

Usage Examples

/research     # Full command
/r           # Shortcut

🔄 Transition Process

What Happens During Transition

Φ_mode_transition = {
  transition(mode_a, mode_b) = {
    // 1. Create safety backup
    Σ_backup.create_backup(),
    
    // 2. Verify current mode completion
    verify_completion(mode_a),
    
    // 3. Update mode
    set_mode(mode_b),
    
    // 4. Apply new permissions
    enforce_permissions(𝕊(mode_b)),
    
    // 5. Update context
    update_context(MΓ[mode_b]),
    
    // 6. Log transition
    log_transition(mode_a, mode_b)
  }
}

Transition Timeline

1. Backup (100ms) - Save current state
2. Verification (50ms) - Check completion
3. Mode Switch (10ms) - Update mode
4. Permissions (20ms) - Apply restrictions
5. Context (100ms) - Load relevant items
6. Logging (20ms) - Record transition

Total: ~300ms per transition

📋 Standard Workflow Transitions

1. Starting New Feature

START → RESEARCH → INNOVATE → PLAN → EXECUTE → REVIEW

Example flow:

/r
"What's the current authentication system?"

/i
"What modern auth approaches could we use?"

/p
"Create plan for JWT implementation"

/e
"Implement the JWT authentication"

/rev
"Verify implementation matches requirements"

2. Bug Fix Flow

RESEARCH → PLAN → EXECUTE → REVIEW

Skipping innovation for direct fixes:

/r
"Investigate login timeout issue"

/p
"Plan fix for session timeout"

/e
"Apply the timeout fix"

/rev
"Verify fix resolves issue"

3. Emergency Hotfix

EXECUTE → REVIEW → EXECUTE

Quick fix-and-verify cycle:

/e
"Fix critical production bug"

/rev
"Check fix doesn't break anything"

/e
"Apply additional safety checks"

4. Architecture Planning

RESEARCH → INNOVATE → PLAN → RESEARCH → PLAN

Iterative design process:

/r
"Study current system limitations"

/i
"Explore scalability solutions"

/p
"Design new architecture"

/r
"Research specific technologies"

/p
"Finalize architecture plan"

🎯 Transition Strategies

1. Complete Current Work

Before transitioning:

Current: EXECUTE mode
Task: Implementing user service

Before switching:
- ✅ Complete current function
- ✅ Add necessary comments
- ✅ Run basic tests
- ✅ Commit changes

Then: /review

2. Document Transition Reason

Add context for why switching:

/plan
"Need to plan error handling strategy before continuing with implementation"

3. Use Natural Breakpoints

Transition at logical boundaries:

Good transition points:
- ✅ Feature complete
- ✅ Function implemented
- ✅ Test written
- ✅ Bug fixed

Poor transition points:
- ❌ Mid-function
- ❌ Partial implementation
- ❌ Uncommitted changes

4. Batch Similar Work

Minimize transitions by grouping:

Instead of:
R→P→E→R→P→E→R→P→E

Better:
R→R→R→P→P→P→E→E→E→R

🔍 Mode-Specific Considerations

From RESEARCH (Ω₁)

Common transitions:

• → INNOVATE: When understanding is complete
• → PLAN: When solution is obvious
• → EXECUTE: Emergency fixes only

Context saved:

• Findings documented in σ₃
• Questions answered in σ₁
• Understanding captured in σ₄

From INNOVATE (Ω₂)

Common transitions:

• → PLAN: When approach is chosen
• → RESEARCH: Need more information
• → EXECUTE: Never directly (bad practice)

Context saved:

• Ideas in σ₂
• Alternatives considered
• Decisions documented

From PLAN (Ω₃)

Common transitions:

• → EXECUTE: Plan complete
• → RESEARCH: Need clarification
• → INNOVATE: Rethink approach

Context saved:

• Detailed steps in σ₄
• Specifications in σ₂
• Milestones in σ₅

From EXECUTE (Ω₄)

Common transitions:

• → REVIEW: Implementation complete
• → PLAN: Need to adjust approach
• → RESEARCH: Never (maintain focus)

Context saved:

• Progress in σ₅
• Code protected in σ₆
• Changes tracked in σ₄

From REVIEW (Ω₅)

Common transitions:

• → EXECUTE: Fix issues found
• → PLAN: Major changes needed
• → RESEARCH: Investigate problems

Context saved:

• Results in σ₅
• Issues documented
• Verification complete

⚡ Quick Transitions

Rapid Mode Switching

For experienced users:

/r → /i → /p → /e → /rev

Can be done in seconds when you know exactly what you need.

Context Preservation

Use mode context command:

/plan
!cm    # Automatically sets plan-appropriate context

Skip Confirmation

For trusted transitions:

/execute --force
# Skips completion verification

🚨 Transition Warnings

1. Incomplete Work Warning

⚠️ INCOMPLETE WORK DETECTED
Current mode: EXECUTE
Unsaved changes: 3 files

Continue with transition? (y/n)

2. Context Loss Warning

⚠️ CONTEXT CHANGE
Moving from EXECUTE to RESEARCH
Active context will be archived

Proceed? (y/n)

3. Permission Change Warning

⚠️ PERMISSION REDUCTION
EXECUTE → REVIEW
You will lose write permissions

Confirm transition? (y/n)

💡 Best Practices

1. Transition Mindfully

Each mode switch should have purpose:

❌ Bad: Random mode switching
✅ Good: "Switching to PLAN to design error handling"

2. Complete Thoughts

Finish current thinking before switching:

❌ Bad: Mid-sentence transition
✅ Good: Complete idea, then transition

3. Use Appropriate Modes

Don't force wrong mode:

❌ Bad: Try to code in RESEARCH
✅ Good: Switch to EXECUTE for coding

4. Document Transitions

Keep transition log:

## Transition Log
- 10:30 RESEARCH → INNOVATE: Explored auth options
- 11:15 INNOVATE → PLAN: Chose JWT approach
- 11:45 PLAN → EXECUTE: Plan complete, implementing

🎮 Advanced Transitions

1. Multi-Mode Operations

Some tasks span modes:

Task: Refactor authentication

RESEARCH: Understand current system
INNOVATE: Design improvements
PLAN: Create refactor strategy
EXECUTE: Implement changes
REVIEW: Verify functionality

2. Parallel Workflows

Managing multiple features:

Feature A: In EXECUTE
Feature B: In RESEARCH

Strategy:
- Complete Feature A execution
- Switch to Feature B research
- Use context switching (!cc, !cm)

3. Emergency Transitions

When things go wrong:

Current: EXECUTE
Error: Critical bug found

Emergency flow:
/plan      # Don't debug in EXECUTE
# Analyze issue
/execute   # Apply fix
/review    # Verify

📊 Transition Metrics

Track Your Patterns

## Weekly Transition Stats
- Total transitions: 127
- Most common: EXECUTE → REVIEW (34)
- Longest session: EXECUTE (2.5 hours)
- Quick switches: 12

Optimize Workflow

If transitions > 10/hour:
- Batch similar work
- Plan better upfront
- Use longer sessions

Measure Efficiency

Good metrics:
- 3-5 transitions per feature
- 30-60 min per mode session
- 80% standard flow compliance

🔧 Troubleshooting Transitions

Stuck in Wrong Mode

Problem: In RESEARCH but need to code
Solution: 
1. Document findings
2. /execute
3. Implement solution

Frequent Back-and-Forth

Problem: R→P→R→P→R→P
Solution:
1. Gather all info first
2. Create complete plan
3. Then execute

Lost After Transition

Problem: Forgot why switched modes
Solution:
1. Check transition log
2. Review activeContext.md
3. Look at last changes

📚 Related Topics

• RIPER Modes
• Context Management
• Permission System
• Memory System

---

← Backup System | Home | Memory Management →