Use a rule for short, durable constraints—style, safety, alwaysApply or glob matches. Use a skill (SKILL.md) for multi-step workflows you invoke on demand. Paste entire guides into always-on rules and every chat pays the tax; package the workflow as a skill instead. Globs and alwaysApply belong on rules, not skills. Skills do not replace AGENTS.md—that stays the portable router; skills stay reusable procedures under it. Defer product UI and migrate flags to Cursor’s skills and rules docs. ShipKits’ wedge is an opinionated skills pack plus that router—not a help-center rewrite. Soft start: /free; pack: Agent Starter Kit ($47).
Who this is for
You’re choosing between another `.mdc` rule and a `SKILL.md` and want a one-pass decision—not a tour of Cursor’s help center. Companions on this shelf: the fuller split in Cursor rules vs skills — when to use each (and how Spec Kit fits), and the install path in Spec Kit → `.cursor/skills` install guide.
Official Cursor docs remain the authority for UI, flags, and `/migrate-to-skills`. This post owns the ops call: rule vs skill vs router.
Anti-pattern: guides in always-on rules
- A useful internal guide gets pasted into a project rule.
- The rule is alwaysApply (or matches too broadly).
- Every agent turn pays for the whole essay—even for a one-line fix.
- Another guide lands. Context bloat compounds. Nobody removes the old one.
Rule of thumb: if you wouldn’t want it injected into *every* relevant chat, it isn’t a rule. It’s a skill, a doc, or a pointer from `AGENTS.md`.
Decision tree (use this first)
| If you need… | Use… | Not… |
|---|---|---|
| A short “always / never” constraint on matching files | Rule (glob / alwaysApply) | Pasting a full guide into always-on rules |
| A multi-step workflow you invoke when relevant | Skill (`SKILL.md`) | Dumping the workflow into `AGENTS.md` prose |
| Portable commands / verify / guardrails across harnesses | AGENTS.md | Replacing the contract with Cursor-only skills |
| Spec-driven `/speckit-*` flows | Spec Kit skills after `specify init --integration cursor-agent` | Forking Spec Kit into your pack |
| Team-shared ops procedures + router | Skills pack under `AGENTS.md` (Agent Starter path) | User-only skills with no repo copy |
Debug order when context feels wrong: list always-on rules → move essays to skills → confirm globs/alwaysApply stay on rules → confirm `AGENTS.md` still owns verify and approval stops.
What belongs where (plain split)
| Layer | Job | Shape |
|---|---|---|
| Rule (`.cursor/rules/*.mdc`) | Short constraints; globs / alwaysApply | Durable “always remember this” |
| Skill (`.cursor/skills/**/SKILL.md`) | Multi-step workflow on demand | Invoke when the job matches |
| AGENTS.md | Portable operating contract | Commands, verify, guardrails—router, not a skill dump |
A `SKILL.md` holds a reusable procedure with clear when-to-use language—not secrets, not the whole repo operating contract. Prefer project-scoped skills for shared desks so the repo carries the pack; user-level skills are personal shortcuts—document which is which in `AGENTS.md`.
What the Agent Starter Kit is for
The Agent Starter Kit ($47) packages harness templates and the skills-pack + `AGENTS.md` router angle for agent-ops desks. Use it when you want an opinionated layout instead of guessing rule vs skill from three conflicting files. Soft path: /free first if you want the decision-tree mindset before buying.
Soft next step
Keep rules short, skills on-demand, and `AGENTS.md` as the portable router. When you want the pack packaged, use /free for the starter desk, or the Agent Starter Kit ($47) for the skills pack + harness templates. No rush—ship the decision tree into your own runbook either way.