Boilerplate .cursor/rules

Discussion
1

Perhaps many people like me spend too much time on thinking out laconic, good and working .cursor/rules :roll_eyes:

It would be great if we could start from some reasonable template .cursor/rules suitable for the given project tech-stack and LLM-model?

Ideally these .mdc rule files should be generated by Composer as your very first project setup step.

Here I assume that the rules should be tailored mainly for Composer agent mode (I hope we forget about redundant “normal mode” soon).

For example, as for the Rust I’d start from:

.cursor/rules/session-startup.mdc:

---
description: start-up rules to be applied at the beginning each session (Chat, Composer and Bug Finder)
globs:
---

# Session Start-up Rules
- ensure the code base is indexed/read
- in particular ensure the [README.md](mdc:README.md) and all files in doc/ directory are read in

Thoughts:

  • I am not sure whether code base is automatically read on session startup (and will it be the same in the next Cursor version?)

  • even after code base is explicitly read/indexed, I see that instructions from README.md are boldly ignored.

code-generation-finalization-rule.mdc:

---
description: The rules to be applied after the code changes are done by Composer
globs:
---

The following rules should be applied after the code changes are done by Composer

- always run build to ensure your code changes don't break the build phase
- run build in a form defined in project docs (README.md and doc/*)
- after build succeeded run the tests (test invocations should be also done according to the docs)
- for the introduced new benchmarking tests invoke 'cargo test' prepended by `timeout` and reasonable time threshold value (e.g. 5s) to. Do so until you get the benchmarking test runnable to avoid unlucky long or even infinite waiting. After you get test runnable, the benchmarking duration should be set to smth about 15s if not differently requested

Thoughts:

  • actually test-related rules could be in the separate test-rules.mdc file.

Guys, meanwhile, please share your successful .mdc rules

2

Good ideas - but hard to maintain I think.

Ive also become very focused on tweaking and figuring out what does and doesnt help with rule files - one thing that also makes it hard is different wording or lack there off does see do also be impacted by the model choice. so I end up tweaking them all to work best for claude, but other models might benefit from different wordings or rules.

for example, it seems but is hard to tell, that having a rule such as dont tell me you are doing something, just do it to the actual file might be helpful to o3-mini - but needs a lot of trial and error to see if its really helping or just seems like it.

also a lot depends on greenfield vs brownfield at least with the agent mode where it will use a lot of convention it finds in similar files without strong prompting to basicaly say do what i say here and not what you see there.

Also - there are some repositories out there of cursor rules, but they all are pretty old at this point and do not seem to stay up to date and evolve with the tool and the models - but are decent for getting some ideas.

1 Like
3

BTW - I do think the docs need a lot more realistic documents showing real world use or tips. for example, the documentation for MCP shows a weather example - why not show something that would acutally be of use to extending the capabilities of cursors existing features to help a developer.

similar thought witht he rules.mdc files - the short doc doesnt make it clear enough how the description field (and not the content it seems) is what drives the file even being picked up.

you description btw is a great idea I will try to replicate the default behavior of having it at the root of the project instead

2 Likes
4

found an interesting topic (also with good links) on .cursorrules.
Perhaps many ideas could be combined.