I abit unrelated but a general question to all: can i enforce a strict code conversion from remix to nextjs based on some convert_rules.md and integrate that into riper?
I have my own attempt here:
But i think its complex i love riper very much so far its has given me the best results but it will not convert my code and react components in nextjs to remix even if i tell it to do that exactly and provide my file with rules in the chat with @
badic thought it riper will not follow exactly the commands i give it when converting multiple code filetrees, is there a way to enforce it to that somehow?
I have had no hallucination problems asking it to implement feature x or y
Sometimes it says its fixed something with an aproach it thought was the best solution but then it doesent work perhaps we can improve riper here since its kind off frustrating to run 3/4 refactors and the end result still not works. Perhaps there should be an addition in the riper protocol to evaluate multiple implementations of a refactor and rhen choose the best? Thoughts?
Would love to get some feedback on these thoughts i feel like im on an iland aline with you fellow guys and gals we are the pioneers of next level ai!
I tried this but could not get it to work.
I even asked claude to provide an idiots guide based on the readme and all files but it fails to load the riper mode.
Perhaps you can provide an example project in your repro that includes all the correct files and directorys setup? That would help tremmendous.
I agree. It should start with project initialization, scaffolding, and setting up the Memory Bank with baseline information. Then move to riper with research command. But all of this was unsuccessful.
The agent always starts with creating bank memory, framework folder according to the rules, and each .md files for project and sometimes creating itself project like the to-do app.
I’m confused about how to implement these rules. I tried to place the rules in the project and also tried to the .cursor rules folder and set the rule type to always, but it’s unsuccessful running these rules to my project.
The riper mode still uses .cursorrules for learning journal and to update progress, but I see in the cursor docs that the file is obsolete and will be removed by cursor (Cursor – Rules for AI).
I think to migrated it to the .cursor/rules folder but can it file be updated?
The files .md in the memory bank were created and updated in 2023, not the current date when the project was initialized.
To address the .cursorrules comment above and some other feedback I have received, I have created two new repos to keep things clean.
A comprehensive framework for AI-assisted software development in Cursor IDE that combines structured workflow with persistent memory.
CursorRIPER Direct (CRD) provides a minimalist approach to the RIPER methodology, focusing on developer workflows rather than framework components. This one has fewer files and handles memory management differently.
Does it prevent critical ‘omissions’ by 3.7, which is a well known flaw as it outputs well reasoned content that makes omissions so much harder to spot?
Added:
This is not a Cursor related flaw and that would be way easier to fix. its reproducible on any App that uses 3.7 API even non-dev related, simple prompts.
I do not wish the attention such a proof would create, but I’m not the only one who faced 3.7 issues which even beyond this amazing rules continue to affect users of 3.7 on any app.
You know what’s also something useful I started tinkering with? I added ALLOWED OPERATIONS per MODE. For example, sometimes in RESEARCH mode, it’ll want to go and explore the whole codebase — so you could say something like: “you can only use the read tool if the user explicitly provides the path.” Still testing though, let me know what you think
This is especially important if you’re using some agentic mode where it sees “explore” and might go off and explore on its own. You could just restate that in the instructions, but having a clear ALLOWED OPERATIONS (almost like CRUD operations) and FORBIDDEN ones makes the rules super explicit and really reinforces the boundaries. What do you think, you think its worth added a FORBIDDEn and ALLOWED strict CRUD operation per mode?
Check out the community’s upgrades and enhancements, like @johnpeterman72 GitHub repo is very well thought out complete solution and added a memory bank, however if you are an absolute beginner stick to something simpler but as you get more comfortable and the project expand then seeks out complete solutions like John’s github
Aha I see what you mean, I read the @symbol_guide, yes this is solves most of the scenarios I brought up, the only thing I was thinking along with it is something that is more MACRO and straight forward before you even see the nitty gritty details almost like a MACRO ON/OFF button on an ENTIRE category of a CRUD operation then within it you can actually see the details. See this post by @Phantomn he made this post up there somewhere, which has also a nice approach: I created an AMAZING MODE called "RIPER-5 Mode" Fixes Claude 3.7 Drastically! - #86 by Phantomn
Check it out it has that simpler MACRO approach I was alluding to, I think along with your in depth @symbol system would work nicely - Just my two cents, as almost from experimentation very clear simple MACRO rules should be the non-negotiables then its like the main filter then once it passes it then it needs the detailed @symbol. Let me know your thoughts, coz I really like the way you think and engineer John
Thank you. I was simply refining it into o1 format to stay within the 1500-character limit for use with GPT.
However, I’m not sure whether it’s an issue with Claude or Cursor, but the original Custom Instruction turned out to be more useful on Claude.
Surprisingly, it’s showing great effectiveness on Gemini Pro.
