Cursor Agent Rules That Stick: What Survives Real Projects

Most pasted “cursor rules” dumps fail because they describe an ideal teammate instead of encoding mistakes you already paid for. I use cursor agent rules in two layers — always-on habits, then per-project contracts. This post is the Layer 1 deep dive of my Cursor workflow: what I keep, what I cut, and two failures that forced the wording.

Why most cursor agent rules get ignored

Long aspirational walls lose to short constraints the agent can actually check. “Be careful and professional” is a vibe. “Do not write article prose” is a gate.

Every unread line still competes with the task for context. A rule that nobody can verify is noise dressed as governance.

The fix is not more adjectives. It is fewer rules tied to failures you already funded with time or money.

Two layers: habits vs project law

I keep two layers on purpose: user-level habits for how the agent works, and project files for what this repo is allowed to do. Skills and pipelines sit on top; rules are the contract the agent should honor before those run.

User-level rules apply across projects. Project files add repo-specific law. For where those files live, Cursor’s rules docs are enough — I am not turning this into a settings tour.

At the product level, keep the map light:

• Project rules can live under .cursor/rules as .mdc files with activation metadata.
• AGENTS.md is a plain markdown alternative at the project root (and nested directories).
• User-level rules travel with you; project files stay with the repo.

On this blog I mostly use AGENTS.md. It is portable, readable in git, and easy to sharpen after a bad review. .mdc scoping is optional when you need glob or activation control — mention it, then move on.

Those two layers are how cursor agent rules stay short enough to enforce. Habits travel with me; project law stays with the repo.

If you want the identity layer behind this setup, I wrote that separately in Why I use Cursor.

Behavioral guidelines I keep on every project

Always-on habits belong at the user level, not in every repo’s domain file. Mine are inspired by Andrej Karpathy’s advice for coding agents; after that name, I just call them behavioral guidelines or the four habits.

They shape how the agent works. They are not product law for what this blog may publish.

The four habits

1. Think before coding — Do not assume. Surface confusion. If multiple interpretations exist, present them; do not pick silently.
2. Simplicity first — Ship the minimum that solves the problem. No speculative features or abstractions “for later.”
3. Surgical changes — Touch only what you must. Match existing style. Do not “improve” adjacent code while you are there.
4. Goal-driven execution — Define success criteria and verification steps first, then loop until those checks pass.

Concrete implications I want in daily diffs:

• Assume less; ask or offer options when the request is ambiguous.
• Ship less speculative code; one-use abstractions die in review.
• Prefer small diffs over drive-by refactors.
• Define “done” before editing so the agent cannot declare victory by vibes.

These habits travel with me. Repo-specific contracts do not.

Project rules that pay rent (AGENTS.md example)

Domain law lives in per-project AGENTS.md. On this blog, the hard split is editor (harness) versus writer.

Role	Who	Does
Editor / harness	Main agent (stronger model)	Brief, facts, structure, quality gate, revision instructions, publish prep
Writer	Subagent (cursor-grok-4.5-high-fast or gpt-5.6-terra-medium)	Prose only from the brief

The contracts that earn their keep:

• The main agent does not write article body prose.
• If the gate fails, fix the brief or style guide and re-delegate — do not hand-polish the draft in the expensive model.
• Goal state: a cheap writer’s draft passes the editor gate with no prose rewrite by the editor.
• Briefs live next to drafts as *.brief.md; recurring failures become rules in config/style-guide.md.
• Other project laws stay short: N:1 synthesis only (no 1:1 rewriting); synth posts use non-experience voice; WordPress publish is always draft first; never expose .env or App Passwords.

That style-guide accumulation is how Layer 4 stays honest. Recurring gate misses become one more enforceable line, not another essay in the rules file. The full pipeline shape is in AI writing pipeline; this post stays on the rule that enforces the split.

Failure 1 — Editor rewrites the draft

Before the editor/writer split was a hard rule, a strong model would research, draft, and then rewrite the same article when review failed. Cost went to typing. Learning went nowhere.

After the rule: review failures improve *.brief.md or config/style-guide.md, then a cheaper writer regenerates. The system gets smarter. The expensive model stops typing paragraphs.

That is why the AGENTS.md split exists. The expensive model owns the system; cheap writers own paragraphs. Without that line, “fix the draft” feels productive and quietly burns the budget.

Turning gate failures into rules

A sticky rule is often a gate failure converted into a sentence the next brief must satisfy — not a motivational paragraph. Failure 2 is the clean template.

Failure 2 — Hedged pricing prose

Before style-guide rule 10 (harness v5, as of 2026-07-20), comparison drafts used hedges like “commonly reported around $X” even when official pricing pages stated a number. That sounded careful. It was just vague.

After the rule: briefs must supply verified numbers with as-of dates; writers state those facts plainly. Four published or synth posts were re-briefed and rewritten (de-hedge) once the sentence existed.

On one pass, hedge counts dropped sharply (log notes e.g. 15→1).

The loop is boring on purpose:

1. Observe the failure in review.
2. Write one enforceable sentence.
3. Put it where the next brief or writer must see it (config/style-guide.md, or a harder AGENTS.md line).

Same spirit shows up in methodology posts now: experience writing waits on artifact excerpts and a human-supplied failure case before the writer runs. Sticky rules and sticky briefs are the same habit.

What I refuse to put in rules

I cut anything that goes stale faster than the workflow, or that duplicates a skill’s job.

I refuse:

• Tool worship and model-name sermons that need a rewrite every month.
• Dumping a skill’s entire procedure into AGENTS.md — skills own procedures; rules own constraints.
• Secret-handling theater beyond a hard ban on committing or pasting credentials.

Short rules beat long sermons for a simple reason. Agents follow constraints they can check better than vibe instructions. Long rule files compete with the task for context.

Every line should prevent a real failure mode, or it should go. If a sentence only makes me feel organized, it does not belong in the file.

Wrap-up

Sticky cursor agent rules are short contracts backed by scars. User habits cover how the agent works; AGENTS.md covers what this repo is allowed to do.

Rules are not magic. Agents still miss them. Humans still have to notice misses and sharpen the text.

Stale rules are worse than none — delete or rewrite when the workflow changes.

For many repos, user guidelines plus project AGENTS.md are enough. Reach for .cursor/rules .mdc files when you need activation control; do not tutorialize yourself into a second constitution.

This was Layer 1 of my Cursor workflow. Next methodology candidates are a brief→gate checklist and skill authoring — when those scars are ready to encode, not on a calendar promise.