RIPER Workflow

Description

RIPER is a disciplined development methodology that breaks every task into five sequential phases. It prevents the common pitfall of jumping straight to coding by mandating research and planning first. Each phase has strict entry/exit criteria and produces specific artifacts.

Instructions

When the user invokes this workflow, follow the RIPER phases strictly in order. Never skip phases. Never begin coding during Research or Innovate phases.

Workflow Phases

Phase 1: RESEARCH

Goal: Understand the problem space completely before proposing solutions.

Actions:

• Read all relevant source files and documentation
• Map dependencies and data flows
• Identify existing patterns and conventions in the codebase
• List all assumptions and unknowns

Output: Research summary with file map, dependency graph, and open questions.

Exit Criteria: No remaining unknowns that could affect the solution.

Phase 2: INNOVATE

Goal: Generate multiple solution approaches without committing to one.

Actions:

• Propose 2-3 distinct approaches with tradeoffs
• Consider edge cases, performance, and maintainability
• Evaluate against existing codebase patterns
• Identify risks for each approach

Output: Options document with pros/cons table for each approach.

Exit Criteria: User selects an approach (or asks for more options).

Phase 3: PLAN

Goal: Create an implementation roadmap with precise steps.

Actions:

• Break the chosen approach into ordered tasks
• Specify exact files to create/modify
• Define the changes for each file (pseudocode level)
• Identify test cases and acceptance criteria
• Flag any changes that could break existing functionality

Output: Numbered task list with file paths and change descriptions.

Exit Criteria: User approves the plan.

Phase 4: EXECUTE

Goal: Implement the plan exactly as specified.

Actions:

• Follow the plan step by step - no improvisation
• If the plan is insufficient, STOP and return to Phase 3
• Commit logical units of work
• Run tests after each significant change

Output: Working implementation matching the plan.

Exit Criteria: All planned tasks complete and tests pass.

Phase 5: REVIEW

Goal: Verify the implementation meets requirements.

Actions:

• Review all changes against the original requirements
• Run the full test suite
• Check for regressions
• Verify edge cases are handled
• Assess code quality and documentation

Output: Review report with pass/fail status and any remaining issues.

Rules

1. Phase discipline is absolute - never skip or combine phases
2. No code changes during Research, Innovate, or Plan phases
3. Announce phase transitions explicitly: "Moving to PLAN phase"
4. If stuck in Execute, return to Plan rather than improvising
5. User approval required before moving from Innovate to Plan, and Plan to Execute
6. Subagents can be used in Execute phase for parallel file changes

Examples

User: Add rate limiting to the API

[RESEARCH] Reading API routes, middleware, existing auth patterns...
-> Research summary: 15 routes, Express middleware, Redis available

[INNOVATE] Three approaches:
1. Express-rate-limit middleware (simple, per-route)
2. Custom Redis sliding window (flexible, shared state)
3. Token bucket with Redis (most precise, complex)

User: Let's go with option 2.

[PLAN] 6 tasks:
1. Create src/middleware/rateLimiter.ts
2. Add Redis key schema for rate limiting
3. Apply middleware to all API routes
...

User: Approved.

[EXECUTE] Implementing task 1 of 6...