Rules are short, durable constraints—style, safety, alwaysApply globs. Skills are multi-step SKILL.md workflows you invoke on demand. Subagents get a separate context when the job shouldn’t share the main thread. Paste entire guides into always-on rules and you tax every chat; package the workflow as a skill instead. Spec Kit’s Cursor path lands under .cursor/skills via specify init --integration cursor-agent. ShipKits’ wedge is an opinionated skills pack plus an AGENTS.md router—not a Spec Kit fork. Soft start: /free; pack: Agent Starter Kit ($47).
Who this is for
You’re drowning in `.mdc` rules. Agent mode feels slower or noisier than it should. You’ve heard Cursor skills, Spec Kit `/speckit-*` commands, and “just put it in AGENTS.md”—and you’re not sure which layer owns what.
Official Cursor docs for rules, skills, and subagents are the authority for product UI and flags. This post does not rewrite that help center. It owns the ops decision: when each layer wins, how Spec Kit coexists, and how a skills pack sits under a portable `AGENTS.md` contract (see One AGENTS.md for Cursor, Claude Code, and Codex).
Anti-pattern: guides in always-on rules
The failure mode is familiar:
- 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 when the task is a one-line fix.
- Someone adds another guide. 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`.
Rules vs skills vs subagents (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 |
| Subagent | Separate context for a bounded job | Don’t pollute the main thread |
| AGENTS.md | Portable operating contract across harnesses | Commands, verify, guardrails—router, not a skill dump |
Skills do not replace `AGENTS.md`. The contract stays portable; skills stay reusable procedures inside Cursor (and Spec Kit’s Cursor install path).
Migration on-ramp (point to Cursor)
If rules already bloated, use Cursor’s official `/migrate-to-skills` path as the on-ramp. Follow Cursor’s skills and rules docs—don’t treat this article as a clone of the help center. After migration: keep remaining rules short; move multi-step playbooks into skills; leave the shared contract in `AGENTS.md`.
Spec Kit → `.cursor/skills`
Spec Kit’s Cursor integration installs skills into the project skills tree:
specify init --integration cursor-agentThat path typically yields Spec Kit skills under `.cursor/skills` (invoked as `/speckit-*` style commands in Cursor). Treat Spec Kit as upstream tooling you operationalize—not something to fork and rebrand.
Coexist, don’t collide:
- Keep Spec Kit skill ids intact.
- Namespace your ops pack so custom skills don’t overwrite Spec Kit’s.
- Document in `AGENTS.md` which skills are Spec Kit vs team ops, and whether they are project-scoped (preferred for shared desks) or user-level personal shortcuts.
ShipKits wedge: skills pack + AGENTS.md router
ShipKits is not a Spec Kit fork and not a rewrite of Cursor help. The commercial and ops wedge is:
- `AGENTS.md` as router — portable contract for Cursor, Claude Code, Codex (and adapters).
- Opinionated skills pack — reusable agent-ops procedures under `.cursor/skills`, living beside Spec Kit when you use it.
- Thin Cursor rules — globs and alwaysApply only.
That’s the same shelf as the Agent Starter Kit ($47): harness templates under the instruction layer. Soft path: /free.
If a skill in your pack demos remote MCP tools, wire Connect with the live MCP OAuth for Cursor and Claude recipe—or the MCP Starter Kit—different job from the skills pack itself.
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 |
| A bounded job that shouldn’t share main context | Subagent | Stuffing it into a mega-rule |
| Portable commands / verify / guardrails across harnesses | AGENTS.md | Replacing the contract with Cursor-only skills |
| Spec-driven `/speckit-*` flows from Spec Kit | 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 Spec Kit and custom skills don’t share ids → confirm `AGENTS.md` still owns verify and approval stops.
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 assembling Cursor help, Spec Kit, and three conflicting rule 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—coexist with Spec Kit under `.cursor/skills`, don’t fork it. 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.