I ask it to create any updates to a .tmp file and I copy and paste using a text editor and commit immediately, found that the file can still get mangled if cursor is left to it’s own devices.
If there is a mdc link in the rule and you have multiple project folders it also will append the project folder to the link every time you save, breaking the link and and any chaining. I opened a bug report on that.
But good idea on the md to mdc. Might work if it also does that on an edit (explicit instruction to create a new file on an edit).
yeah similar experience now unfortunately - and it was working well for quite some time, so strange.
I am starting to think that the xml tags in the file are not worth the pain even if there might be a slight improvement in some things.
I recently reverted the workflow I use to just using text as I did in the beginning and it is working better than the version I created trying to use xml. Natural language still seems to just win out in a structure markdown format
Should the description field be concise or detailed? Or does this depend on the “vibe coding” and “vibe changing” of the Cursor development team? I saw this:
As this seems to be a somewhat popular post, I should update I have shared a big update to the rule generator to better generate the rules reliable and support the 4 rule types, and better organize them. The repo is up to date with a lot of improvements. New video also on the channel with some more details and examples…
I’m actually working on my own little cursor rules generator and was initially hoping to reference your project to learn a bit. But honestly, I found it pretty tough to wrap my head around / get started with.
Any chance you could share some pointers or advice on how best to approach it? My generator is still pretty barebones right now, so I’m looking to learn.
Hey there, cool looking site and project you have going there Honestly the easiest thing to do it just start with a .cursor/rules folder and the single core rule-generating-agent.mdc file latest from the repo as a starting point and just tweak it over time. Honestly the future of agentic development I am starting to realize is not really in rules, and only a small set of rules will be needed as projects grow and the models continue to evolve. I have updated the repo a few days ago, its stable in its current state. I have a lot of info in the repo but much of it is starting to get into custom agent modes and is not necessary for starting out - and the workflows are constantly evolving and also maybe beyond what you are initially looking for.
I can get by with 1 or 2 rules in pretty complex projects just by using the style and conventions that seem the model wants to follow - while guiding it with good granular tasks and a plan for project structure and documents to keep it aligned. also work in small chunks, commit often anything is completed that is working (and also all regression of tests still works) etc… Adding rules like, use solid, keep dry, etc… are really not doing anything of value IMO as generally the model will try to follow that anyways it seems. I have seen little evidence with the latest models of much different between having that or not.
The basic rules that do help I have noticed are related to documentation rules, rules for testing 80%+ threshold, and a few around conversation and personality preferences. Other than that, all of my rules have been hand crafted mostly and stay stable because they are all around the workflows I want it to follow.
Hey there - A few potential things come to mind, as there have been a lot of changes to rules since publication. I have updated the github with updated instructions and tips that might help - but ill also mention a few.
1 - the newer rule format has 3 from matter fields - and if you are using the MDC viewer (the gui with the dropdown) you should not see any front matter in the file (front matter is hidden in the mdc viewer)
2 - I recommend not using the MCD viewer at all - it causes odd issues where rules will not save - and not using it you will see the actual 3 front matter fields and can just modify them yourself (or with the latest version of the auto generating rule)
if you have an always rule - the globs and description are not going to be used.
Also - since always rules always apply, the agent will not always say its using the rule - that usually only happens with ‘agent’ rules (which do rely on a very strong description)
Also one more thing - unfortunately it DOES seem that model selection matters - most of this week for example, Gemini for some reason has been really had at picking up agent rules or loads them but still ignores the content where Claud 3.7 and 3.5 remain solid.
Honestly the easiest thing to do it just start with a .cursor/rules folder and the single core rule-generating-agent.mdc file latest from the repo as a starting point and just tweak it over time. Honestly the future of agentic development I am starting to realize is not really in rules, and only a small set of rules will be needed as projects grow and the models continue to evolve. I have updated the repo a few days ago, its stable in its current state. I have a lot of info in the repo but much of it is starting to get into custom agent modes and is not necessary for starting out - and the workflows are constantly evolving and also maybe beyond what you are initially looking for.
