How to Write Rules for AI Coding Agents

The working pattern for AI coding agent rules is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Yes. The frame below is a starting point, not a script. Fill in your own files, constraints and done state, and keep the plan step so the agent commits to an approach before it writes code.

Task: [one outcome]
Context: [files, errors, docs and examples]
Boundary: [what not to touch]
Done when: [test, typecheck, screenshot or review proof]

Before editing, write a short plan with files, risk and checks.

The Boundary line is the one people leave out, and probably the one doing the most work. Without it every file the agent can reach is fair game, so you end up reviewing incidental edits to config and imports and some helper you'd forgotten existed, all mixed in with the change you actually wanted. Naming what not to touch takes a few seconds. Reverting it afterwards does not.

"Done when" has to name something you can run. A test name, a typecheck, a command whose output you can read, a screenshot of one specific state. "Done when the bug is fixed" doesn't count, and I'd say that's the single most common version of this mistake, because it quietly hands the judgment back to the agent, and the agent is going to tell you it's finished either way.

Running AI coding agent rules as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

Rules are persistent directives Cursor injects into prompts to supplement what the model already knows. There are four types, and the difference is when each one fires.

Build rules reactively, not preventively

Models do best with the least to pay attention to. An always-apply rule with 300 directives silently appends "…and also do these 300 other things" to every prompt, which dilutes every answer. Keep always-apply to the basics - tech stack, what you are building, key constraints - and add a directive only after the model makes the same mistake more than a few times. Do not write "just in case" rules.

Revisit rules on long projects so they don't go stale or conflict. As models improve they need fewer preventative and behavioral instructions than they did a year or two ago.

Don't write it from scratch. In chat - and in the CLI - you can run create rule, create skill, or create sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition., and Cursor hands you a built-in template plus a prompt that scaffolds it for you. From there you iterate conversationally in the same chat: "help fix the linting errors," then "I don't like this part, add that." The blank page is the hard part, and these templates remove it.

Yes, and it's one of the highest-value rules to write. Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. has an ask-clarification tool that lets Cursor solicit direction before building. It surfaces on its own when a prompt is vague, or you can invoke it explicitly ("feel free to use the ask clarification toolA Plan-mode tool that lets the agent pause and ask you for direction before building; it surfaces on vague prompts or when you invoke it explicitly. Press Enter for the full definition."). You can also pin the behavior in a skill so it fires every time.

Why it works: the questions surface the assumptions the model would otherwise guess at, and you correct them before any code exists. That is cheaper than auditing a plan built on the wrong premises.