Configuring Cursor quickly turns into a pile unless you answer one question: which layer owns this decision. There are many mechanisms - editor settings, rules, skills, subagents, hooks, permissions, external servers, plugins - and almost any requirement can be expressed in several ways. The problem is that several ways at once give not reliability but contradiction: instructions compete, the context grows, and behavior stops being explainable. Editor settings meanwhile keep their familiar hierarchy of scopes, and the agent files add one of their own, and those two hierarchies live side by side without meeting.
The naive approach is to write the requirement everywhere possible so that it definitely works. In practice that leads to the opposite. The same rule in the user settings, the team ones, the project file and a skill starts living its own life: somewhere it was updated, somewhere it was forgotten, and now nobody can say which wording is in effect. Worse, duplication eats context and lowers the weight of each individual instruction: four similar but non-identical requirements are parsed by the model not as one reinforced demand but as an invitation to choose.
The right model is one owner per decision. Appearance and editor behavior are settings. A durable instruction to the project is a rule or a contract file in the repository. A repeatable multi-step process is a skill. A specialized role with a separate context is a subagent. Blocking or auditing an action is a hook, permissions or the sandbox. An external system is a server over the tools protocol. And delivering that whole set between projects is a plugin. The owner is assigned once and until the next deliberate revision, not picked anew every time something needs adjusting.
It helps to lay tasks and mechanisms out in a table with a why column once. Below is that map. Its value is in the third column: it explains why this particular mechanism fits - deterministic interface behavior, versioned context, on-demand instructions, isolation of exploration, deterministic enforcement, typed tools, a versioned bundle. That column is the working instrument: when a new requirement has no articulate why, you are trying to put it in the wrong place.
| Task | Best mechanism | Why |
|---|---|---|
| Appearance and editor behavior |
|---|
| Settings |
| Deterministic interface behavior |
| A durable instruction to the project | A project rule or AGENTS.md | Versioned context next to the code |
|---|
| A repeatable multi-step process | A skill | On-demand instructions, scripts and assets |
|---|
| A role with its own context | A subagent | Isolating exploration from the main conversation |
|---|
| Blocking or auditing an action | A hook, permissions, the sandbox | Deterministic enforcement |
|---|
| An external system | A server over the tools protocol | Typed tools and resources |
|---|
| Delivering a set between projects | A plugin | A versioned portable bundle |
|---|
The key distinction inside that map is between what steers and what enforces. Rules and skills steer: they influence the model's decisions but do not guarantee a result. Permissions, the sandbox and hooks enforce: they fire identically regardless of wording. If a requirement must always hold, it lives in the enforcing layer; if it is a style of work, in the steering one. Mixing those two roles is the main source of a false sense of security.
The difference shows on an ordinary requirement: run the tests before finishing a task. Written as a rule, it works in most cases and fails exactly when it matters most: the task is long, the context is crowded, one action is left before the end, and the model treats the step as optional. Written as a hook on the finishing event, it runs every time, and it costs one script and one line of configuration. The difference between those two options is not in the quality of the wording but in whether the requirement takes part in the reasoning or stands outside it.
There is also a practical sign that the layers were chosen correctly. Any requirement should be explainable in one sentence of the form this lives here because. If the explanation sounds like we duplicated it just in case, the layer is wrong. And conversely: when every requirement has one home, the system's behavior becomes readable - you can open a specific file and see exactly what applies, instead of assembling the result from four sources in your head.
A layering mistake is usually spotted in the same place: behavior diverges between people. For one person the agent always runs the typecheck, for another it does not; for one it refuses to touch the infrastructure directory, for another it edits it calmly. The first reaction is to suspect the model or the version, but almost always the reason is that the requirement sits in one person's user layer and is absent for the other. Hence a diagnostic rule: a divergence between machines is a question about the layer rather than about the model, and you start with who owns the requirement.
The engineering conclusion is simple: do not duplicate a requirement in four places. Choose an owner, leave a reference or nothing in the others, and move enforcement into the deterministic layer. That shortens the context, makes behavior explainable and sharply simplifies diagnosis when something works differently than expected. A set of settings can be checked with one exercise: take any requirement and name the file it lives in. If you cannot name it, the requirement has no owner.
The typical failures are predictable. Writing one requirement into four different places and getting a contradiction. Expecting from a rule the guarantee only a hook or permissions give. Keeping team policy where it can easily be removed locally. Blaming the model for behavior that diverges between people. And configuring the tool piecemeal without asking which layer should own the decision.