cursor

Migrating Cursor commands to skills with `/migrate-to-skills`

Cursor’s official /migrate-to-skills path converts eligible commands (and bloated always-on piles that were really workflows) into skill packs—SKILL.md under a skills dir. Not everything should migrate: short durable constraints stay thin always-apply rules; multi-step, sometimes-needed procedures become skills. AGENTS.md stays the portable router—skills do not replace it. Keep short always-true safety and style constraints as thin always-apply rules. Convert multi-step, sometimes-needed playbooks into skills. After migrate, confirm the skill appears where Cursor lists project skills and invoke it once on a throwaway task. Product UI and flags live in Cursor’s docs—this is the migrate how-to, not a help-center rewrite.

Before / after (conceptual)

Before: slash-command piles and/or fat always-on rules that encode multi-step playbooks you only need sometimes.

After:

text
.cursor/
├── rules/*.mdc              # thin alwaysApply / globs only
└── skills/
    └── <workflow>/
        └── SKILL.md         # on-demand procedure
AGENTS.md                    # portable router (unchanged job)

Keep vs convert decision: When should I use a skill instead of a rule?. Layer contrast + Spec Kit fit: Cursor rules vs skills — when to use each (and how Spec Kit fits).

Run `/migrate-to-skills`; sanity-check load

  1. Pick one bloated workflow (not the whole wall on day one).
  2. Run Cursor’s `/migrate-to-skills` on that eligible command/rule pile—follow the product UI, don’t clone the help center here.
  3. Confirm the skill appears where Cursor lists project skills.
  4. Invoke it once on a throwaway task; check the description still matches the workflow you intended.
  5. Leave short safety/style constraints as thin rules; delete the duplicate always-on copy of the migrated workflow.

If the migrate command’s UI or flags change, defer to Cursor’s skills and rules docs.

Keep vs convert

Keep as thin ruleConvert to skill
Must apply every turn (safety, style)Multi-step, sometimes-needed workflow
Short always/never constraintOld command that was really a playbook
Glob-scoped durable guardGuide that taxed every agent turn

Full decision tree: skill-vs-rule-when.

Pack coexistence (Spec Kit / skills pack)

Migration can collide on skill ids or duplicate workflows you already ship via a pack or Spec Kit install. After migrate:

  • Reconcile names/ids with your existing pack.
  • Don’t fork Spec Kit into the pack—coexist.
  • Leave shared harness truth in `AGENTS.md`.

Install path: Spec Kit → `.cursor/skills` install guide. Packaging: Package a reusable Cursor skills pack for your team. This post stays migrate-only.

What the Agent Starter Kit is for

The Agent Starter Kit ($47) is an opinionated skills pack plus `AGENTS.md` router—use it when you want a known-good layout after (or instead of) ad-hoc migrate cleanup. Soft path: /free; Cheat Sheet for the skim checklist; kit when you’re standardizing pack + router.

Pack: package-cursor-skills-pack. Install: spec-kit-cursor-skills-install. Contrast: cursor-rules-vs-skills-spec-kit. Decision: skill-vs-rule-when.

Soft next step

Run `/migrate-to-skills` on one bloated workflow, verify the skill loads, keep thin always-apply rules for safety/style, and leave `AGENTS.md` as the router. Soft ladder: /free, then the Agent Starter Kit ($47). Pack: package-cursor-skills-pack; install: spec-kit-cursor-skills-install; contrast: cursor-rules-vs-skills-spec-kit; decision: skill-vs-rule-when.

FAQ

What does `/migrate-to-skills` do?+

Cursor’s official on-ramp that converts eligible commands (and bloated always-on piles meant as workflows) into skill packs (`SKILL.md` / skills dir). Use the product command; don’t restate the whole help center in the post.

Do all commands become skills, or should some stay rules?+

Not all. Multi-step, sometimes-needed workflows → skills. Short durable constraints → thin always-apply rules. Link skill-vs-rule-when for the keep/convert decision.

Will migration conflict with an existing Spec Kit / skills pack?+

It can collide on ids or duplicate workflows. After migrate, reconcile names/ids with your pack/Spec Kit install — link those posts; this how-to is migrate-only.

How do I verify a skill loads after migrate?+

Confirm the skill appears where Cursor lists project skills, invoke it once on a throwaway task, and check the description still matches the workflow you intended.

When should I keep a thin rule instead of a skill?+

When the guidance must apply every turn without an invoke (safety, style, globs). If you only need it sometimes, it belongs in a skill — not alwaysApply.

Soft next step?+

Run `/migrate-to-skills` on one bloated workflow, verify load.

Get the free starter

Value first, then a kit when you are ready. No fake urgency. Start with Harness Desk Starter at /free.