Observing "dotai"

[TomLucidor]

Someone did a lot of weird hacks over Cursor to make it "self-improving", might be good to copy some of the designs from there

• The original https://github.com/udecode/dotai
• debloated version udecode/dotai@main...C-Sinclair:dotai:main
• long-term memory design udecode/dotai@main...bardicreels:lymbic:main

[grapeot]

Thanks for sharing! Yeah, I think dotai is similar to this repo. The difference/improvement is mainly it uses templates to introduce when and how to record the learning and errors. Probably we should mention in our README document that the provided cursor rules are just a starting point, and users are encouraged to explore more prompts for effective self-evolving for their specific use case, and then provide dotai and the long-term memory design as an example.

[TomLucidor]

How can this repo learn from doing LTM when Cursor (and also Roo-code) has a habit of overwriting their own scratchpad checklists? There should be a secondary place for logging errors, tacit knowledge, and marking down design decisions given by the user.

[grapeot]

The LTM is recorded in the Lessons section in .cursorrules [link]. And the short term planning is recorded in the Scratchpad section.

[TomLucidor]

This points back to the other issue regarding the use of individual lesson/design files to reduce context usage (kinda make sense as a strategy if LLM usage is not a one time fee like Cursor/Windsurf but something like Roo-code or others) #74

[grapeot]

I think this idea makes a lot of sense, especially if we want to effectively coach the AI and provide it with sufficient context and knowledge about long-term habits. At this point, I'm considering two solutions:

The first is a short-term workaround. I often use very long prompts for certain projects, like complex SQL data schemas and example queries. When I need to write queries for the database, I manually reference this file using @. But for tasks not relevant with SQL, I just don't @ the file to keep the context window clean. This is a manual solution for now.

The second, more long-term solution aligns with Cursor's move to phase out .cursorrules in favor of a more structured .mdc format. The .mdc format (called project rules) allows you to specify conditions for applying Cursor rules and define how Cursor should behave when those conditions are met. It acts like a trigger condition combined with current Cursor rules, providing an effective solution for automatic context switching.

However, the current design of project rules may break this repo because it doesn't allow the agent to update the .mdc format project rules. It's unclear why Cursor restricts this, but there might be workarounds, like using symbolic links. We are still exploring alternatives, though there's a technical risk that Cursor may further restrict this approach.

Overall, I agree with your suggestion and have been considering these short-term and long-term solutions, but more exploration and clarification from Cursor are necessary.

[TomLucidor]

The likely cause for this move, is that self-modifying agents are a double-edged sword: IF the self-modifying causes derailing, it is generally bad for the "customer", BUT when it does not derail, the agents may get powerful, plus FOSS tools like Roo-code are getting closer.
Likely that .mdc will also be paired with thing like MCP for more controlled output, which could be turned into a more robust alternative to current .cursorrules assuming that there are ways around. However starting a mistake-logging and learned memory server is another matter entirely

[grapeot]

I think that makes sense!

[TomLucidor]

Looking forward to MCP hacks for this RooCodeInc/Roo-Code#411 (reply in thread)

[grapeot]

Thanks for the comments. I was thinking along the same lines and plan to focus on this direction in the coming weeks.

We can see two challenges with the current .cursorrules-based solution:

1. There's a limitation on length, particularly for complex projects. Longer contexts not only increase cost and slow things down, but they also make the AI less effective at solving problems.
2. It lacks deterministic properties. The AI determines which contexts are useful without much transparency or control.

MDC (or project rules) is one attempt by Cursor itself to address this issue with a trigger-execution framework. Other attempts from MCP's perspective aim to offer a state machine-like solution. While it's less sophisticated, it provides more determinism.

I still don't have a very clear vision of what the ultimate solution would look like, but I will prioritize:

1. Ensuring this repository continues to function with the project rules.
2. Reflecting on the reasoning and motivation behind Cursor's strategies, and considering the potential use of MCP to address these issues.

[TomLucidor]

As a personal finding, agents cannot modify MDC files, which is disappointing, which means they really do not want "agent-spawning agents" OR "self-enhancing agents" being a cottage industry. I am still grasping how MCP operates tho.
See

• https://forum.cursor.com/t/enable-agent-to-update-cursor-rules/49119/5
• ai creates rules, the content is empty bmadcode/cursor-xml-rules-trial#1
• https://github.com/bmadcode/cursor-auto-rules-agile-workflow/issues/2

As the ultimate joke, add Roo-Code into Cursor to circumvent this constraint... but then it will have to be stuck in either software development mode (Cursor) vs metacognition mode (Roo-Code)

[grapeot]

I think I may have found some ways to change mdc files. It may actually be quite easy to support mdc file format in this case!

[TomLucidor]

I kinda feel something is off in this case @grapeot https://github.com/bmadcode/cursor-auto-rules-agile-workflow/issues/2#issuecomment-2671273332

[grapeot]

I kinda feel something is off in this case @grapeot bmadcode/cursor-auto-rules-agile-workflow#2 (comment)

I frequently see this with o3-mini model when it generates code and does not apply it at all. Try creating rules with claude-3.5-sonnet. I acknowledge that it creates only base-level things, but then it can be reviewed by o3-mini.

So, I would say it's rather Cursor+specific model integration issue and not an issue for this repo.

I successfully generated rules for my project. Well, not without issues completely (see https://github.com/bmadcode/cursor-auto-rules-agile-workflow/issues/4) but still very valuable.

I have had a similar experience and I suspect that the issue lies with the o3 Mini. This model seems particularly skilled at talking rather than taking action. It's generally hesitant to use tools to complete tasks for us; more often than not, it prefers to discuss and give us high level guidance. I've had several funny interactions with it, but ultimately decided to switch to Claude. I only turn to the chat mode and ask o1 for more detailed instructions when Claude gets blocked.