Framework Components - johnpeterman72/CursorRIPER GitHub Wiki

Framework Components

The CursorRIPER Framework consists of several interconnected components that work together to provide a structured approach to AI-assisted development. This page explains each component in detail.

Core System Architecture

The framework is built on a modular architecture with these main components:

flowchart TD
    Core[core.mdc] --> State[state.mdc]
    State --> Phase{PROJECT_PHASE}
    Phase -->|UNINITIATED/INITIALIZING| Start[start-phase.mdc]
    Phase -->|DEVELOPMENT/MAINTENANCE| RIPER[riper-workflow.mdc]
    Start --> Memory[Memory Bank]
    RIPER --> Memory
    Memory --> Custom[customization.mdc]

Core Files (in .cursor/rules/)

These files define the framework's behavior and are processed by Cursor's AI:

1. core.mdc

The foundation of the framework that:

  • Defines the framework's core principles
  • Establishes loading order for other components
  • Sets up command parsing
  • Implements safety protocols
  • Defines the memory bank structure

2. state.mdc

Tracks the current state of the project:

  • PROJECT_PHASE (UNINITIATED, INITIALIZING, DEVELOPMENT, MAINTENANCE)
  • RIPER_CURRENT_MODE (NONE, RESEARCH, INNOVATE, PLAN, EXECUTE, REVIEW)
  • START_PHASE_STATUS and START_PHASE_STEP
  • Timestamps and version information
  • Defines allowed state transitions

3. start-phase.mdc

Guides the project initialization process through these steps:

  1. Requirements Gathering
  2. Technology Selection
  3. Architecture Definition
  4. Project Scaffolding
  5. Environment Setup
  6. Memory Bank Initialization

4. riper-workflow.mdc

Defines the five RIPER modes and their behaviors:

  • RESEARCH: Information gathering only
  • INNOVATE: Brainstorming approaches
  • PLAN: Creating detailed specifications
  • EXECUTE: Implementing planned changes
  • REVIEW: Validating implementation

5. customization.mdc

Allows users to customize framework behavior:

  • Response style preferences
  • Mode behavior settings
  • Memory management options
  • Custom commands and aliases
  • Documentation format preferences

START Phase

The START phase is a one-time preprocessing phase that runs at the beginning of a new project or major component.

Purpose

  • Project initialization and scaffolding
  • Setting up the memory bank with baseline information
  • Establishing project structure and requirements

Process Flow

flowchart TD
    Start[BEGIN START PHASE] --> Req[Requirements Gathering]
    Req --> Tech[Technology Selection]
    Tech --> Arch[Architecture Definition]
    Arch --> Scaffold[Project Scaffolding]
    Scaffold --> Setup[Environment Setup]
    Setup --> Memory[Memory Bank Initialization]
    Memory --> End[TRANSITION TO RIPER]

Key Features

  • Step-by-step guided setup
  • Template-based file creation
  • Automatic state transitions
  • Protection against re-initialization
  • Comprehensive documentation generation

RIPER Workflow

The RIPER workflow is the core operational component used during development and maintenance phases.

Purpose

  • Providing a structured approach to development
  • Preventing unintended modifications
  • Maintaining context across sessions
  • Ensuring thorough planning before implementation

Mode Descriptions

RESEARCH Mode

  • Purpose: Information gathering ONLY
  • Permitted: Reading files, asking clarifying questions, understanding code structure
  • Forbidden: Suggestions, implementations, planning, or any hint of action
  • Output Format: Begin with [MODE: RESEARCH], then ONLY observations and questions

INNOVATE Mode

  • Purpose: Brainstorming potential approaches
  • Permitted: Discussing ideas, advantages/disadvantages, seeking feedback
  • Forbidden: Concrete planning, implementation details, or any code writing
  • Output Format: Begin with [MODE: INNOVATE], then ONLY possibilities and considerations

PLAN Mode

  • Purpose: Creating exhaustive technical specification
  • Permitted: Detailed plans with exact file paths, function names, and changes
  • Forbidden: Any implementation or code writing, even "example code"
  • Output Format: Begin with [MODE: PLAN], then ONLY specifications and checklists

EXECUTE Mode

  • Purpose: Implementing EXACTLY what was planned in Mode 3
  • Permitted: ONLY implementing what was explicitly detailed in the approved plan
  • Forbidden: Any deviation, improvement, or creative addition not in the plan
  • Output Format: Begin with [MODE: EXECUTE], then ONLY implementation matching the plan

REVIEW Mode

  • Purpose: Ruthlessly validate implementation against the plan
  • Permitted: Line-by-line comparison between plan and implementation
  • Required: EXPLICITLY FLAG ANY DEVIATION, no matter how minor
  • Output Format: Begin with [MODE: REVIEW], then systematic comparison and explicit verdict

Memory Bank System

The memory bank provides persistent context across coding sessions. It consists of several markdown files that store project information.

Core Memory Files

  • projectbrief.md: Foundation document defining core requirements and goals
  • systemPatterns.md: System architecture and key technical decisions
  • techContext.md: Technologies used and development setup
  • activeContext.md: Current work focus and next steps
  • progress.md: What works, what's left to build, and known issues

For more details on the memory bank, see the Memory Bank System page.

Command System

The framework processes commands in two formats:

  1. Full commands:

    • ENTER RESEARCH MODE
    • ENTER INNOVATE MODE
    • ENTER PLAN MODE
    • ENTER EXECUTE MODE
    • ENTER REVIEW MODE
    • BEGIN START PHASE

  2. Slash commands:

    • /research
    • /innovate
    • /plan
    • /execute
    • /review
    • /start

Commands trigger state transitions and change the AI's behavior according to the specified mode.

Safety Protocols

The framework implements several safety measures:

  1. Destructive Operation Protection:

    • Warnings for potentially destructive operations
    • Explicit confirmation requirement
    • Automatic backups

  2. Phase Transition Protection:

    • Verification of transition requirements
    • Memory bank snapshots before transitions
    • State file updates

  3. Re-initialization Protection:

    • Detection of existing projects
    • Warning and confirmation requirement
    • Backup of existing memory files

Next Steps

CursorRIPER: Adaptive development, persistent intelligence.