I have a list of very specific rules, specification like instructions how my modular monolith needs to be build. File structure, convention etc, some implementation examples for certain classes etc.
Most of the the time, but not always, when using the planning mode, it gets the things right and creates a decent plan. If it does so, it almost always fails to create all the things it planned. For example today it missed to create the whole presentation layer, despite it having it planned…
It NEVER did test driven development, it almost never verifies its code is working in between steps, despite it is instructed to do so in the rules.
What am I doing wrong? For me AI works nice when I create single classes, but for bigger things it is just unreliable and I have to go after it like a very junior developer, so not a lot time saving here.
If you’re using MCP servers - those are probably exploding your context - get rid of them all, or use a smarter MCP server which does context-compression, so the agent only learns how to use tools, when it needs to use the tools (e.g. mcp-link )
I got Claude to tell me how to make it obey the rules, and it converted everything to an html-like structured XML format - HTML/XML has infinitely richer methods than text/markdown for marking things with priorities and importance - it’s never let me down for a year since!
I use ONLY the “User Rules” - nothing else - but I do have a rule telling it to read the project readme.md at the start of every new session, which it always does, and those files prime it with whatever other rules/info it needs for the folder it’s in.
Mine start with this:-
@Agent: IMPORTANT: Read all these rules right now.
<html><head><title>Rules the Agent must always follow</title></head><body>
<h1>Rules the Agent must always follow</h1>
<!-- version 2025-08-08 12:00 -->
<dl>
<dt id="dt_tags_are_the_rule_conditions"> When trying to understand these conditions and rules: </dt>
<dd>
<ol>
<li> as you work, stay mindful of all the conditions defined in this context; conditions are the ones defined with <dt> tags. </li>
<li> when a <dt> condition applies to what you are doing, follow all the rules inside the conditions' rule-set. </li>
<li> the rule-sets are <ol> lists in the conditions' <dd> definition, and each rule is defined inside its own <li> tag </li>
<li> we use HTML syntax for rules, to avoid ambiguity and uncertainty. be mindful of the hierarchical meaning of HTML tags </li>
<li> in html, a <dt> defines a term (in our case, the condition), a <dd> defines what to do when that condition is matched, the <ol> helps you distinguish each new rules, and each <li> ... </li> item defines each rule to apply when the condition is matched. </li>
<li> the structure of this first rule does itself conform to our rule structure! </li>
</ol>
</dd>
<dt id="rule_for_referencing_other_rules"> When following a rule that references another rule: </dt>
<dd>
<ol>
<li> Reference rules using either their id prefixed with # or their exact <dt> text in quotes: e.g., `see #new_file_creation_rule` or `see: "When creating new files:"` </li>
</ol>
</dd>
(lots of critical proprietary stuff comes next
it is 525 lines long.
The models I use the most a Grok for coding and Opus for planning.
This is my TDD rule (.cursor/rules/tdd.mdc). I’m aware that we can or should use now .cursor/rules/<name>/rule.mdc (Rules | Cursor Docs) but this simply does not work for me. Even when I create a new rule via the Cursor Settings UI, it will just create a new *.mdc file.
---
description: Test Driven Development
alwaysApply: true
globs:
---
# Test Driven Development
- When you write new code or make changes and fixing bugs, you MUST create the tests first
- Make sure your test reflect the requirements and are accurate
- When your implementation is done the tests SHOULD pass
- If they don't make them pass, your implementation is very likely wrong then
- When you fix bugs, you MUST create first a test that proves the problem and fails, then fix it.
When I go to the project rules, the Cursor editor takes some time to load them, I have 18 mdc file and none of them is huge. The longest one has 183 lines.
Why does it show Applies to subdirectory: cursor/rules?
Edit: When re-open the folder in WSL2 it still shows Applies to subdirectory: cursor/rules but at the same time it duplicates the entries in the list of rules and shows them on time with and one time without the message. This looks like a bug.
Explicit mention: At the start of each chat, type @tdd.mdc to make sure the rule is included
User Rules: Copy the critical TDD instructions into Settings > Rules > User Rules (global, always applied)
Concrete examples: Instead of “you MUST create tests first”, give a step by step example:
Before implementing:
1. Create test file: tests/[feature].test.ts
2. Run: npm test (should fail)
3. Write implementation
4. Run: npm test (should pass)
Structured format: Try Chris Drake’s approach from that topic, use HTML or XML style markup for a clearer rule hierarchy
The agent doesn’t follow the full plan
Can you share an example plan where tasks were skipped? That’ll help spot the pattern. Also please include:
Request ID from the problematic chat (Chat menu > Copy Request ID)
Which models you used for planning and execution
Project size (number of files)
Issue with the RULE.md format
You’re right, the docs recommend .cursor/rules/<name>/RULE.md, but in version 2.3.29 the UI creates .mdc files directly. That’s a legacy format that still works. The new structure was fixed in recent versions, so it might be worth updating to the latest.
Try the workarounds above and let me know if they help. I’m especially interested in the Request ID where the agent ignores the TDD rules.
Thank you for the quick reply, I’m about to run out of credits on my private account, so I’ll get you the data you have asked for next week when I’m back at work. I’ll have to work on presentations and training material but I should have some time for AI, so I’ll try to get what you’ve asked for. Thanks again!
