Rules, memory, workspaces

[olimorris]

For any questions people have regarding Rules (replacing memory in v18) and the removal of workspaces...

You can see the rules I use in CodeCompanion, here

[olimorris]

cc: @Sir-Didymus

[olimorris]

Recommend you take a look at how I use memory/rules in CodeCompanion. So much more readable, flexible and maintainable than workspaces. I appreciate there's manual effort involved in moving them over (although I recommend just getting an LLM to do it). I've been using them in CodeCompanion since September.

[Sir-Didymus]

Thank you for the quick response!

I looked at your rule files, and I agree, this is much more readable than a single gigantic workspace file.
Being able to split context into separate files convinced me to give them a try.
The fact that rules are written in markdown instead of JSON also helps a lot.

[olimorris]

In v18, you'll be able to set system instructions too. I'm not fully up to speed with what Cursor Rules can do but the way I've architected them means it won't be difficult to match their feature set.

[cuducos]

UPDATE Moved my post here because it was off topic. I got here clicking on a link in #2439 — so I thought it was a more generic topic (it is not, my bad).

[Sir-Didymus]

@olimorris

Thanks for pointing me to your memory files.

I've switched to memory files and am loving it.
The best part in my opinion is the ability to compose them from several memory files, as well as the ability to write in markdown and structure the text more freely as compared to JSON.

I have two questions regarding memory/rules:

1. How is the current implementation of memory different from rules? What will change in version 18?

2. Would it be possible to implement the ability to dynamically load memory/rule groups from a path in the current working directory?
   Having to create all the groups in the plugins configuration is a bit cumbersome, especially because most groups I use are specific to a single project. It would be nice if we could specify the groups in the project itself instead. Maybe CodeCompanion could automatically search for rules/groups in a .rules/ directory of the project root.

[olimorris]

1. You can read the draft docs, for v18 here. Mostly just the name that's changed and the ability to change the chat buffer's system prompt via a rules file.
2. That's a good point. I will put that on the list for some point after v18.0.0 - I need to ship it this week. default_rules can now be a function now to enable you conditionally specify which groups to load.

[olimorris]

@Sir-Didymus the more I think about this the more I do want it in v18. Can you share some more information about how you'd like to structure your rules across different projects/repos?

[Sir-Didymus]

@Sir-Didymus the more I think about this the more I do want it in v18. Can you share some more information about how you'd like to structure your rules across different projects/repos?

Tbh, what structure you decide on eventually is not that important to me, what's important to me (and I'd bet to a lot of other people, too) is the ability to define rules on a per-workspace basis.

Looking at cursor rules, they seem to provide something like this already: Project specific rules go into .cursor/rules/.
You could look for rules in .codecompanion/rules/, or perhaps just .rules for brevity.

I also like their different types of rules:

• Always Apply - Apply to every chat session
• Apply Intelligently - When Agent decides it's relevant based on description
• Apply to Specific Files - When file matches a specified pattern
• Apply Manually - When @-mentioned in chat (e.g., @my-rule)

Looking at this unanswered question on the cursor forums also raises a pretty interesting idea:

Multiple .rules/ folders inside the codebase, with the rules living right next to the code they are documenting (for the LLM), that are automatically applied whenever relevant files are shared with the LLM.
For example, if a project has a database/ subdirectory containing database related code, then there could be local rules in database/.rules/ that get applied automatically whenever a file from database/ is shared with the LLM.

These are just some ideas for the future, but again, the most important thing to me would be to have project-specific rules in some way.

[olimorris]

#2509 will add directory support and file pattern matching to v18.0.0.

[Sir-Didymus]

#2509 will add directory support and file pattern matching to v18.0.0.

Nice, thank you for adding this :)

[minusfive]

@olimorris Seems like there's a documentation error: docs (and this thread) reference default_rules, where I believe it should be autoload.

[olimorris]

Can you share the docs?

[minusfive]

@olimorris

• https://github.com/search?q=repo%3Aolimorris%2Fcodecompanion.nvim%20default_rules&type=code
• https://codecompanion.olimorris.dev/configuration/rules#enabling-rules

[minusfive]

@olimorris found another couple of issues: Markdown prompts (prompt library) don't seem autoload the default rules specified for the interaction type. They (md prompts) also seem to silently fail to load whenever there are comments nested in the frontmatter opts object (e.g. you comment-out an option). Would you like me to open new issues for them?

[olimorris]

Good catch, thanks for sharing. FYI, there's a link at the bottom of all docs pages allowing you to edit and quickly make a PR should you spot anything else in the future.

They (md prompts) also seem to silently fail to load whenever there are comments nested in the frontmatter opts object (e.g. you comment-out an option). Would you like me to open new issues for them?

This will be fixed in v18.3.3

[olimorris]

Markdown prompts (prompt library) don't seem autoload the default rules specified for the interaction type

I can't recall if I ever did add that in or not. That may be an oversight in the docs or something I intended to add but never got around to. It's a pretty quick workaround to use the rules slash command at least.