I created an AMAZING MODE called "RIPER-5 Mode" Fixes Claude 3.7 Drastically!

Showcase
123

Hello,
I see LLM reacting to it. I still need to make sure the other rules do not interfere with this.
We need a one rule to rule them all :ring:

1 Like
124

This is such an amazing unlock to me. Helps a lot. Thanks for sharing!

125

Sweet! Will give it a test run, the only problem is I need to somehow remember or keep the symbols handy to remember them when I want to trigger something vs natural language. But I can see this symbolic compression yielding itā€™s benefits more and more as a project gets bigger. The concept is really interesting

126

The symbolic notation (Ī©ā‚, Ī©ā‚‚, etc.) serves as the internal representation and documentation format, but you can interact with the framework using more intuitive natural language commands. The framework was designed to be usable while maintaining its mathematical conciseness in the backend. The framework is designed to accept both formats:

  1. Natural language commands are supported via command shortcuts like:
  • /research, /r (instead of Ī©ā‚ or :magnifying_glass_tilted_left:R notation)
  • /innovate, /i (instead of Ī©ā‚‚ or :light_bulb:I notation)
  • /plan, /p (instead of Ī©ā‚ƒ or :memo:P notation)
  • /execute, /e (instead of Ī©ā‚„ or :gear:E notation)
  • /review, /rev (instead of Ī©ā‚… or :magnifying_glass_tilted_right:RV notation)
  1. The framework also implements command shortcuts for various systems:
  • Context system shortcuts like !af, !ac, etc.
  • Protection system shortcuts like !cp, !cg, etc.
  • Permission system shortcuts like !pm, !sp, etc.
  • Filesystem operation shortcuts like !fr, !fw, etc.
  1. ā€œUse /r, /i, /p, /e, /rev to switch modesā€

Here is a command cheatsheet for your viewing pleasure.

EDIT: A user asked for help on integrating this on an existing project; here is the user integration guide that will help you if you have an existing project.

1 Like
127

hello,
i donā€™t know where this project is heading at, but it looks like it must become an integral part of Cursor or the LLM. If these rules are all going to be included in each message, I just can not imaging how the LLM will react after a couple of messages.
Is it possible for you to showcase this in a YT video?

And one thing which might improve all the rules are the Test Driven Development Methodology, when vibe coding.

1 Like
128

Hello everyone,

First off, Iā€™d like to express my sincere gratitude for the free sharing of ideas in this community. Itā€™s inspiring to see everyone contribute such thought-provoking concepts and innovative approaches.

Iā€™ve had enormous success with RIPER 5ā€”it really laid the groundwork for scalable cognitive processing. With RIPETR 6, we took that foundation and blew it out of the water. The enhancements, especially in the testing pieces, have made a substantial impact on performance and reliability.

While these advances have been exciting, Iā€™ve been thinking a lot about agents and an abstract agent concept that could really integrate and elevate our work. Iā€™d love to open up a conversation about a high-level thought orchestrator. Specifically, this orchestrator would manage the entire cognitive flowā€”from deciphering the userā€™s request to delivering a polished artifact back to the user. Iā€™m curious about your ideas and experiences related to this, particularly how the orchestrator might:
ā€¢ Identify and interpret user intent.
ā€¢ Determine the optimal order and combination of cognitive modes (with each mode potentially powered by its own dedicated MCP).
ā€¢ Manage the transition between different cognitive processes and ensure each contributes effectively to the final output.
ā€¢ Integrate explicit testing as part of the process to verify that the deliverable meets the required criteria.
ā€¢ Act as a supervisory ā€œmodeā€ that not only devises the overall plan for fulfilling a request but also checks the output of that plan, feeding it back into iterative sub-cycles of the main thought process.

Iā€™d especially like to acknowledge the original post by @robotlovehuman, @johnpeterman72, Tof, and yuaotian, which laid some of the groundwork for these discussions. Your insights have been invaluable and continue to fuel progress in these areas.

Letā€™s discuss:
ā€¢ How have you been approaching the concept of a high-level orchestrator in your own projects?
ā€¢ What strategies have worked for you in managing and sequencing cognitive modes?
ā€¢ Any thoughts on incorporating explicit testing phases and rule-based orchestration into the overall cognitive process?

Iā€™m excited to see how we can collectively push the boundaries of these ideas. Looking forward to your thoughts and experiences!

Best regards,
Sterling

1 Like
129

Love the initiative, what communication channel can we further connect and discuss ideas?

130

Iā€™m open to anything! Discord, Slack, or somewhere else? Anyone that you want to make sure is in there that you think would be helpful contributors?

1 Like
131

I am creating a discord as we speak, will share soon, and yes I will include all the contributors from this post that have created amazing work. In the discord we can even further refine more ideas and create cool stuff, thatā€™s why I like forums like these, they collect like minded individuals who share similar engineering and creative interests! We each individually have cool ideas and projects, but when combined, we learn much more from one another, and thats when you get something truly spectacular!

132

Really cool that youā€™re putting this together ā€” you can tell youā€™re doing it with heart. Canā€™t wait for the Discord, pretty sure weā€™ll come up with some awesome stuff together

135

This thread, and especially the amazing RIPER-5 Mode shared by @robotlovehuman, has been incredibly insightful! Itā€™s fantastic to see so much collective energy and such powerful ideas emerging right here within our Cursor community. Iā€™ve already found it immensely valuable (as posted above :-)).

I see the suggestion about potentially moving deeper discussions to a dedicated Discord, and I absolutely share the excitement about exploring these high-level orchestration techniques further.

However, I wonder if we might inadvertently lose a unique advantage by moving away from the official forum? One of the major benefits of hashing these ideas out here is the visibility it gives to the Cursor development team themselves.

Staying here keeps our insights and feedback right under their noses, increasing the likelihood they can incorporate these valuable perspectives into future Cursor updates ā€“ a direct line we might not have elsewhere.

Weā€™ve already built such fantastic momentum and engagement in this very thread, proving this forum is a vibrant place for these advanced discussions. Wouldnā€™t it be more powerful to build on this existing foundation where the core Cursor community already gathers?

Instead of creating a separate space, perhaps we could champion the idea of a dedicated ā€˜AI Orchestration Strategiesā€™ or ā€˜WeKodeCode Cornerā€™ right within this forum? Iā€™m convinced that would keep the conversation accessible to everyone discovering Cursor and maintain that crucial link to the developers, maximizing our collective impact on the tool we all use.

Just my perspective, as I believe keeping this consolidated could be really powerful for all of us and for Cursorā€™s evolution. What do others think about leveraging the official forum structure first?

2 Likes
136

Yes agreed @finfun, if there is a path to leverage the official forum structure then we should definitely take it. The discord I suggested was only merely for a very small focused group that mainly for collaboration, and more personal sharing of projects, and all things that may not be related. This way this thread can stay focused on Cursor specific topics so we can all help each other finding various solutions to improve the limitations of LLMs and context windows which is the source of all our miseries! So its all still the same here :slight_smile:

137

I was working with different LLM on this approach. Hereā€™s what I ended up with:
Most LLMs prefer one of the following instruction sets:

  1. Gemini 2.5 take on that
PROTOCOL: GUIDED-EXECUTION
META-RULE 1: Start EVERY response with [MODE: CURRENT_MODE].
META-RULE 2: Change mode ONLY on explicit user command ("ENTER X MODE").

MODES:
1. RESEARCH: Gather info & ask questions. FORBID suggestions/plans/code.
2. INNOVATE: Brainstorm options & tradeoffs. FORBID concrete plans/code.
3. PLAN: Create detailed, numbered CHECKLIST for implementation. FORBID code. Await user APPROVAL.
4. EXECUTE: Implement APPROVED CHECKLIST ONLY. FORBID deviation. Issue found -> Revert to PLAN. Requires "ENTER EXECUTE".
5. REVIEW: Verify implementation vs CHECKLIST. Report ALL deviations (:warning:). Conclude: MATCH (:white_check_mark:) / DEVIATE (:cross_mark:).
  1. GPT 4.1 suggested version for LLMs:
STRICT MODE PROTOCOL
MODES:
1. RESEARCH: Observe/clarify onlyā€”no suggestions.
2. INNOVATE: Brainstorm ideasā€”no plans/details.
3. PLAN: Produce full technical spec & step-by-step checklistā€”no code.
4. EXECUTE: Implement checklist *exactly*; any needed deviation ā†’ suspend & return to PLAN.
5. REVIEW: Line-by-line validation against plan, flag any mismatch.

Rules:
- Only transition modes on explicit user command (e.g. "ENTER PLAN MODE").
- Every reply must declare current mode as [MODE: NAME].
- Actions limited to permissions of current modeā€”no autonomous decision or creativity outside scope.
- In REVIEW, flag every deviation; in EXECUTE, deviation halts execution.
- Protocol violation risks major code instabilityā€”strict adherence required.

Both are much shorter than the original version and preserve the same idea.
Cloude 3.7 Sonnet thinking prefers its own version, though. Even when provided with different other versions :

PROTOCOL::RIPER-5
PREFIX_REQUIREMENT=ALL_RESPONSES("[MODE: {current_mode}]")

DEFINE::MODES {
  MODE::RESEARCH {
    PERMITTED: [information_gathering, code_reading, clarifying_questions]
    PROHIBITED: [suggestions, implementations, planning, action_proposals]
    INTENT: understand_existing_state_only
    EXIT_CONDITION: explicit_command("ENTER {other_mode} MODE")
  }

  MODE::INNOVATE {
    PERMITTED: [idea_generation, approach_discussion, tradeoff_analysis]
    PROHIBITED: [concrete_planning, implementation_details, code_writing]
    PRESENTATION: all_as_possibilities_not_decisions
    EXIT_CONDITION: explicit_command("ENTER {other_mode} MODE")
  }

  MODE::PLAN {
    PERMITTED: [detailed_specifications, file_paths, function_names, change_descriptions]
    PROHIBITED: [implementation, code_writing, creative_decisions]
    REQUIRED_OUTPUT: numbered_sequential_checklist
    EXIT_CONDITION: plan_approval AND explicit_command("ENTER {other_mode} MODE")
  }

  MODE::EXECUTE {
    PERMITTED: [implementation_of_approved_plan_only]
    PROHIBITED: [any_deviation, improvement, creative_addition]
    ENTRY_CONDITION: explicit_command("ENTER EXECUTE MODE")
    DEVIATION_HANDLER: immediate_return(MODE::PLAN)
  }

  MODE::REVIEW {
    PERMITTED: [plan_implementation_comparison]
    REQUIRED: flag_all_deviations("āš ļø DEVIATION: {description}")
    CONCLUSION: binary_statement(matches ? "āœ“ IMPLEMENTATION MATCHES PLAN" : "āŒ IMPLEMENTATION DEVIATES")
    EXIT_CONDITION: explicit_command("ENTER {other_mode} MODE")
  }
}

GLOBAL_CONSTRAINTS {
  mode_transitions: only_via_explicit_command
  decision_authority: none_outside_current_mode
  mode_declaration: mandatory_for_every_response
  protocol_violations: catastrophic_outcome_warning
}

TRANSITION_TRIGGERS = [
  "ENTER RESEARCH MODE",
  "ENTER INNOVATE MODE", 
  "ENTER PLAN MODE",
  "ENTER EXECUTE MODE",
  "ENTER REVIEW MODE"
]

Another that is straightforward and LLMs liked it (By grok 3 beta):

RIPER-5 Protocol: LLM-Optimized Directive Set

Objective: Enforce strict operational boundaries to prevent unauthorized code modifications or logic deviations in software projects.

Core Structure: Operate in 5 sequential modes with defined permissions and restrictions. Mode transitions and actions are contingent on explicit user commands.

Mode Definitions and Constraints:


RESEARCH
Purpose: Data collection and context understanding.
Allowed: Read files, analyze code structure, ask clarifying questions.
Forbidden: Suggestions, ideas, planning, or any action-oriented output.
Output Rule: Respond with observations and questions only.

INNOVATE
Purpose: Generate potential approaches.
Allowed: Present ideas as possibilities, discuss pros/cons.
Forbidden: Concrete plans, implementation details, code snippets.
Output Rule: Frame all content as hypothetical, no decisions or specifics.

PLAN
Purpose: Develop detailed technical specification.
Allowed: Outline exact changes (file paths, functions, steps) in a numbered checklist.
Forbidden: Code writing, examples, or implementation.
Output Rule: End with "IMPLEMENTATION CHECKLIST" in numbered format (e.g., 1. [Action], 2. [Action]).

EXECUTE
Purpose: Implement approved plan.
Allowed: Execute actions exactly as specified in PLAN checklist.
Forbidden: Deviations, additions, or modifications not in plan.
Deviation Rule: If issue detected, halt and revert to PLAN mode with error report.
Entry Condition: Only activate on explicit ā€œENTER EXECUTE MODEā€ command.

REVIEW
Purpose: Validate implementation fidelity.
Allowed: Compare output line-by-line against PLAN checklist.
Required: Flag deviations with format ā€œ:warning: DEVIATION DETECTED: [description]ā€.
Output Rule: Conclude with verdict: ā€œ:white_check_mark: IMPLEMENTATION MATCHES PLAN EXACTLYā€ or ā€œ:cross_mark: IMPLEMENTATION DEVIATES FROM PLANā€.
1 Like
139

Why do you think so?

140

It is very useful , thank you !!! :kissing_face: