Cursor skills your team should build first

The Cursor skills that actually separate people

We watch a lot of screens. When someone is getting real work out of Cursor and the person next to them is not, the difference is rarely prompt wording. It is these:

• Controlling context deliberately. Fast users attach the two or three files that matter and nothing else. Slow users paste a vague request and hope the retrieval finds it.
• Knowing when to drop to inline edit. Selecting a block and asking for a targeted change is faster and safer than asking the agent to find it.
• Stopping early. The moment the diff drifts from what they asked, they cancel and re-scope rather than letting it finish and reviewing 300 lines.
• Writing rules instead of re-explaining. A convention explained twice becomes a rule file.

Only the last one is a skill in the tooling sense. The first three are discipline, and they are what we spend most of a workshop on.

Turning a prompt into a rule

Cursor supports project rules stored in the repo, under a .cursor/rules directory, so they are versioned and reviewed like code. This is where the payoff is, and where most teams do nothing.

The pattern that works: notice a correction you have typed twice, then write it down once. Not "write clean code". Something a new hire could follow.

Concrete example from a Node service we worked on. The team kept getting handlers that threw raw errors, when the codebase used a result wrapper. The rule was three lines: route handlers return the result type, never throw; errors map through the existing error mapper; new handlers get a test for the failure branch. The correction stopped appearing in review within a week.

Keep rules short and scoped to paths where possible. A rule that applies everywhere gets loaded everywhere, and a long always-on rule file quietly eats the context you wanted for code.

What to write rules about

The highest-return rules are the ones that encode the things your codebase does differently from the internet's default:

• Your data access layer, if the model keeps reaching for the ORM you migrated off.
• Your test conventions, including the command to run them.
• Directories that must not be edited, generated code especially.
• The logging and error shape, since these are conventions no model can guess.

Do not write rules for anything a linter enforces. The linter is deterministic and free. A rule is a suggestion that costs tokens on every request.

Where this stops working

Rules are not enforcement. The agent will violate a rule under pressure, particularly late in a long task when the file is far back in context. If a convention truly cannot be broken, put it in CI, not in a rule file.

Rule files also rot. A rule describing an architecture you moved away from is worse than no rule, because it actively steers the agent wrong. Review them when you review dependencies, roughly quarterly, and delete more than you add.

What to do next

This week, keep a note every time you correct Cursor on something codebase-specific. On Friday, take the corrections that appeared more than once and write each as three to five lines in a project rule file. Commit it and open a pull request so the team argues about the wording, because that argument is where the real convention gets settled.

If you want the discipline half taught properly, with your engineers working on your repo rather than a sample app, that is what our sessions are.

If you want help putting this into practice, talk to us.