# Cursor-Ready Starter That Actually Obeys 10 Rules > Cursor ignores loose docs. Keep rules in .cursorrules + thin files agents can't misread. Setup that survives real sessions. Source: https://boringpush.com/blog/cursor-ready-nextjs-starter ## Rules that evaporate mid-session Cursor users know the arc. Week one, the agent is magic. Week three, it is [building the wrong thing cleanly](https://www.reddit.com/r/cursor/comments/1ux5lr0/my_coding_agent_built_the_wrong_thing_cleanly). Assumptions stacked on assumptions. Fine details dropped when context overflowed. Rewrites that never fully stop. Instruction files, plan mode and bigger windows helped. But as that builder found, cleaner sessions still produced wrong requirements. And the bill arrives too. [Cursor cost threads](https://www.reddit.com/r/ChatGPTCoding/comments/1ikz8oh/cursor_alternative) complain that usage-based pricing compounds exactly when sessions sprawl. The mechanism is unflattering to our docs, not the model. Cursor reads rules files, open files and indexed context. Then it predicts. A 200-line architecture essay is prediction fuel it will half-remember. Ten hard constraints in a thin repo are rails it cannot leave. Rules do not stick because of wording. They stick because of repo shape. ## The setup: ten rules, thin files, a gate Keep your rules file under 30 lines. All shaped like laws, not advice. Here is a set that works. 1. Never add dependencies without asking. 2. Schemas change on every database together, never one. 3. API routes stay under 40 lines: validate, auth, one call, JSON. 4. Never drop tables or columns. Additive migrations only. 5. Amounts come from the product row, never the client or the webhook. 6. Keep helper files small and single-purpose. No logic in re-export files. 7. Read the file before describing it. Cite file and line. 8. Small diffs. Touch the fewest files that solve it. 9. End every change with a syntax check and zero-warning lint. 10. If a rule blocks you, stop and ask. Never route around rules. Why this works where essays fail: each rule maps to a repo shape that makes violation visible. Rule 3 is checkable by line count. Rule 4 is checkable by search. Rule 9 is a command, not a vibe. Thin, single-purpose files help too. The agent's context fills with relevant code instead of spaghetti. ## The Wednesday audit Fifteen minutes, weekly. 1. Look at the week's commits. Any session touching ten or more files? That is a scope smell. Find the prompt that caused it. 2. Check the package list for unapproved dependencies. Revert and ask why. 3. Run the project's tests, including the ones that compare behavior across databases and payment providers. That is what agents silently break. 4. Read one diff fully. Not for bugs. For shape. Thin and local means the system holds. Sprawling means tighten the next prompt, not the model. ## What to put in your own rules file Pick ten rules. Make each one checkable by a command or a glance. Keep the file short enough to read in a minute. Good rules name a thing the agent must never do. Bad rules name a feeling, like "write clean code". Review the list when a session surprises you. Tighten the rule that failed. ## Where this does not help Rules and repo shape reduce drift. They do not remove it. An agent can still misunderstand the requirement. No rules file fixes a vague prompt. Write the goal, name the files, read the diff. None of this makes Cursor cheaper by a number we can quote. The claim is narrower. Tight repos tend to produce shorter sessions, and shorter sessions burn fewer tokens. ## Why rules files fail Three patterns show up again and again. **Too long.** Past about 30 lines, agents skim like humans do. Ten laws beat fifty guidelines. **Too soft.** "Prefer", "try to", "where possible". An agent negotiates with those. It cannot negotiate with "never". **Unchecked.** A rule nobody verifies is a wish. Every rule needs a command or a glance that can fail it. Fix those three and a short file does the work of a long one. ## Make the gate the last step End every session at the same place. A syntax check on the files touched. Lint with zero warnings. A smoke test of the changed path. If any of them fail, the session is not done. It does not matter what the agent says. The gate is a command. It does not care how confident the summary sounds. ## Know this first Rules reduce drift. They do not remove it. A vague prompt still produces a vague result. Write the goal. Name the files. Read the diff. ## Why BoringPush is the way to do this Rules in a file beat rules in your head. BoringPush ships the rules already written. Ask before adding packages. Change every database together. Keep routes short. Finish with a clean check. Your agent starts every session on rails. ## FAQ ### `.cursorrules` vs `AGENTS.md` — which one? Both, same content. Cursor prefers `.cursorrules`, Claude Code prefers `CLAUDE.md`/`AGENTS.md`, other agents read `AGENTS.md`. One source of truth, symlinked or duplicated — never two versions. ### How long should rules files be? Under 30 lines. Past that, agents skim like humans do. Ten laws beat fifty guidelines. ### Plan mode, subagents, worktrees — worth it? Yes, as complements: plan mode for requirements, subagents for scoped tasks, worktrees for parallel tries. None replace repo shape — they multiply whatever the repo already is. ### Cursor cost keeps climbing — related? Directly. Sprawling sessions burn tokens; tight repos burn fewer. The same thin-file discipline that improves correctness cuts the bill — several cost threads trace spikes to runaway sessions. ### What if the agent keeps breaking one specific rule? The rule is probably unenforceable as written — make it checkable. "Keep routes clean" fails; "routes stay under 40 lines" holds, because anyone (including a hook) can verify it in a second.