Cursor rules vs skills: what goes where in an AI coding assistant

The first day with an AI coding assistant is impressive. By the third day you notice you are explaining the same things again: run the tests with this command, leave that folder alone, write commit messages this way. Rules and skills both exist to end that repetition. They do it differently, and putting an instruction in the wrong one is the usual reason it gets ignored.

What Cursor rules are

Cursor’s documentation describes rules as system-level instructions for its agent. Project rules live in a folder inside your project and are version-controlled with the code. User rules are global to your own Cursor environment. Team rules are managed centrally for a whole team, and a plain AGENTS.md file is offered as a simpler alternative.

A project rule can come into play in four ways. It can apply always. It can apply when the agent reads its description and judges it relevant. It can attach when the files you are working on match a pattern you set. Or you can mention it by name in the chat.

What a skill is

A skill is a folder with a SKILL.md file in it. The top of the file gives the skill a name and a description. The rest is the procedure the assistant should follow. The folder can also hold supporting files such as reference notes, examples and scripts.

The format comes from Agent Skills, an open standard that works across several AI coding assistant tools. The assistant keeps only the descriptions in view. When a request matches one, it loads the full skill and follows it. You can also call a skill yourself by typing a slash and its name.

Cursor rules vs skills: the practical difference

Think of a rule as something the assistant should keep in mind and a skill as something it should do. “We use tabs, never spaces” is a rule. “Here is how we cut a release, in nine steps, with this script” is a skill.

The two overlap. A rule that applies only when the agent finds it relevant behaves a lot like a skill, since both are chosen by description. The difference is in what they carry. A rule holds guidance. A skill is a package that can bring its own scripts and templates, and its body stays out of the way until it is needed.

Cost matters as well. Anything that applies always is read in every session, whether or not it is relevant. A long release checklist placed in an always-on rule takes up room during a session spent fixing a typo.

Where Claude Code skills fit

Claude Code, Anthropic’s coding tool, splits things along the same line with different names. Standing guidance goes into CLAUDE.md, a file in the project root that is read at the start of every session. Procedures go into skills.

Claude Code skills can sit in your personal folder, where they apply to all your projects, or inside the project, where the whole team gets them with the repository. Custom commands, once a separate feature, now work the same way as skills. Existing command files keep working.

A skill’s settings also control who may start it. You can stop the assistant from starting a skill by itself, so it runs only when you call it. Anthropic’s documentation recommends this for skills with side effects, such as a deployment.

Because both products support the same open standard, a skill is the more portable of the two formats. Portability has limits. Each product adds its own fields on top of the standard, and a field one tool understands may mean nothing to the other. Cursor’s own rule files work only in Cursor. Test anything you move.

What to put where

• Short conventions that always hold: an always-applied rule, or CLAUDE.md.
• Conventions for one part of the codebase: a rule tied to a file pattern.
• A multi-step procedure you need now and then: a skill.
• Anything with side effects: a skill that only you can call.
• Work that needs a script or a template: a skill with supporting files.

Mistakes we see most

The first is the vague description. “Helps with testing” tells the assistant nothing about when to act. A description that names the trigger, such as a request to review a diff or write a commit message, gets used.

The second is the overgrown always-on file. Every team adds to it and nobody removes anything. After a few months the one rule that matters is buried under forty that do not.

The third is trusting the result too much. Neither rules nor skills stop an assistant from making mistakes. They raise the odds that it starts in the right place, and a person still has to review the code.

Both products change often, so check the official documentation before relying on any detail here. If you would like rules and skills designed around your team’s workflow, that is work we do at Webitro. We are independent and not affiliated with Anthropic or Cursor.