A team encodes a twelve-step deploy procedure as an always-applied rule. Unrelated conversations now carry the whole procedure as context, and the Agent treats the steps as background guidance rather than something to execute. What is the right correction?

The principle — Rules and skills are different instruments. A rule is a short guideline applied as context in every matching conversation; a skill is a detailed, repeatable process invoked when the work calls for it.

Why the key is correct — Cursor's guidance is to use a rule when a short instruction is enough, and a skill when Agent needs a detailed, repeatable process to follow. A twelve-step deploy is squarely the second case. Moving it to a SKILL.md under .cursor/skills/ lifts it out of every unrelated conversation and makes it something invoked deliberately, either by typing a slash command or by the Agent matching the description to the request. The symptom the team noticed follows directly from the mismatch: content delivered as standing context reads as background guidance, not as a procedure to run now. A skill can also carry scripts and reference files, which a rule cannot.

Why the others are wrong — Shortening the steps preserves the mismatch and throws away the detail that makes the procedure reliable, since the formats differ in how they are applied rather than in where the file sits. Splitting across several always-applied rules multiplies the standing context instead of reducing it, and it breaks an ordered sequence into fragments that arrive independently of one another. Restating the procedure in every prompt is the manual work that skills remove, and it drifts the moment a step is paraphrased.

Remember this — Ask whether the content is a constraint or a procedure. Constraints belong in rules; ordered procedures belong in skills, where they load on demand.

Sources — Cursor's Skills documentation.