Project Rules That Actually Hold
Writing .cursor/rules so the agent follows them past the third file — scoped, short, and testable.
What it is for
Rules that work on the first file and are forgotten by the third are the normal outcome, and the cause is usually length or scope rather than wording. This covers writing .cursor/rules that stay in effect: narrow, short, and stated so you can tell whether they were followed.
The skill
Rules are ignored when they are long, vague, or global. Write them the opposite way. Structure: - One file per concern under `.cursor/rules/`, with a `globs:` line so it only loads for the files it governs. A rule that loads for every file competes with every other rule. - Under 30 lines each. Past that the agent starts sampling from them. Content: - Write rules as things to DO, with the reason attached: "Use the repository's `Result<T>` for fallible calls — throwing crosses an isolate boundary and the error is lost." A rule with no reason is dropped first when context gets tight. - Include one CORRECT example from the actual codebase. Not a toy snippet: the agent pattern-matches on it. - Name the anti-pattern explicitly, with the symptom it produces. Test them: Open a fresh chat, ask for a change that the rule governs, and check whether the output obeys. If it does not, the rule is too long or its glob does not match. Do not add emphasis — shorten it and fix the glob.
How to install it
1. Open the tool and start a new conversation, project or template. 2. Paste the text below wherever the tool keeps standing instructions — usually called system prompt, instructions, or persona. 3. Save it so it applies to every run rather than a single message.