From rules to skills: create, migrate, and find Agent Skills that stick

Ad-hoc rules and pasted prompts worked until every project needed the same workflow again. Agent Skills package that knowledge as a version-controlled folder with a SKILL.md, so compatible agents can discover, load, and reuse it on demand.

This guide covers four practical moves on 1 October 2026: write a skill that survives reuse, migrate eligible Cursor rules and slash commands, find and install skills from the open ecosystem, and decide when to invoke them. Demand for this topic is real but niche: roughly 5.4k X posts in the past week matched agent/cursor/claude skills keywords — enough signal to write a clear guide, not a trend chase.

Why skills replaced ad-hoc rules

Cursor's docs describe Agent Skills as an open standard: portable, version-controlled packages that teach agents domain-specific tasks, with progressive loading so full instructions arrive only when relevant. The same idea is documented at agentskills.io: a skill is a folder with metadata (name, description) plus instructions, and optionally scripts, references, and assets.

Rules that always apply, or that only match certain globs, still have a place. Skills win when the procedure is repeatable, should travel across agents or repos, and should stay out of context until the task matches the description.

Write a skill that sticks

Several catalogued skills exist specifically to help you author better ones (already listed on Skill Rank — this post does not add catalog spam):

• write-a-skill (mattpocock/skills) — structure and drafting habits for a reusable skill.
• skill-creator (anthropics/skills) — Anthropic's authoring workflow for SKILL.md packages.
• writing-skills (obra/superpowers) — another practical pass on clarity and scope.
• Optional: skill-development in Anthropic's Claude Code materials if you work in that toolchain.

Practical writing checklist:

1. Put the trigger in the description — agents match on that first.
2. Keep SKILL.md short; push long references into references/ so context stays cheap.
3. Name scripts and paths relative to the skill root; say when to run them.
4. State boundaries: what the skill will not do, and what the human must confirm.
5. Prefer one intent per skill over a kitchen-sink playbook.

Migrate rules and slash commands

If you already have Cursor dynamic rules or slash commands, the built-in `/migrate-to-skills` skill (Cursor 2.4+) converts eligible items into skills under .cursor/skills/.

Cursor's migration notes (checked 2026-10-01):

• Converts dynamic rules that use “Apply Intelligently” — alwaysApply: false (or unset) and no globs.
• Converts user- and workspace-level slash commands into skills with disable-model-invocation: true so they stay explicitly invoked.
• Does not migrate alwaysApply: true rules, rules with specific globs, or user rules that are not on the filesystem.

After migration, open Customize → Skills, read each generated SKILL.md, and tighten descriptions before you rely on automatic activation.

Find and install without guessing

Discovery tools already in the Skill Rank catalog:

• find-skills (vercel-labs/skills) — search and select skills from the open ecosystem; skills.sh is the public directory/leaderboard side of that ecosystem.
• using-agent-skills (addyosmani/agent-skills) — orientation on when and how to apply skills in day-to-day agent work.

Install paths differ by client (plugin marketplace, npx/skills CLI, or copying a skill folder into .cursor/skills/ / .agents/skills/). Prefer a source you can audit: repository URL, license, and a recent commit date.

When to invoke — and when to refuse

• Auto: description clearly matches the task and the skill does not claim destructive defaults.
• Manual `/skill-name`: high-risk ops, one-off rituals, or skills marked disable-model-invocation: true.
• Custom Mode: keep a skill attached for a whole session when every turn needs the same procedure.

Before any install or first real use, follow today's hygiene post: Read an agent skill before installing it. Stars and leaderboard rank are not a security review.

A short workflow you can reuse

1. State the job in one sentence.
2. Search Skill Rank / skills.sh for an existing skill; skip inventing a twin.
3. Read SKILL.md and any scripts/ before enabling tools.
4. Run one small, reversible task; only then use it on production work.
5. If the skill is yours, commit it next to the repo that owns the workflow.

Skills stick when the description matches real work, the body stays short, and you treat every new package like code you did not write yourself.