If you use more than one AI editor, you have already noticed that every editor invented its own rules file format. Cursor takes .cursorrules. Windsurf takes .windsurfrules. Cline takes .clinerules. Zed takes .rules. Continue.dev has customCommands inside config.yaml. Claude Code reads Markdown files under .claude/commands/.
None of them agree on syntax. Some support metadata; others just take a raw system prompt. Some auto-register slash commands; others append to a system prompt on every turn. Some are per project; some are global.
This is a survey from someone who has installed the same skills into every one of them.
What they all have in common
- All of them accept a system prompt as plain text.
- All are text files you can edit in any editor.
- All apply per workspace (or per user via a global file).
- All can be committed to git and reviewed like code.
- All are silently ignored if malformed. None throw a helpful error at load time.
The last point is the biggest UX issue across the board. If your rules file has a typo, you often notice by observing the AI behave normally, then wondering why your rules did not take effect. Testing is manual.
Where they differ
| Editor | File | Metadata | Multiple commands | Scope |
|---|---|---|---|---|
| Cursor | .cursorrules | No | No (one master prompt) | Per project |
| Continue.dev | ~/.continue/config.yaml | Yes (name, description) | Yes (customCommands array) | Per user |
| Claude Code | .claude/commands/*.md | Yes (frontmatter) | Yes (one file per command) | Per project |
| Windsurf | .windsurfrules | No | No | Per project |
| Cline | .clinerules | No | No | Per project |
| Zed | .rules + ~/.config/zed/prompts/ | No (rules) / Yes (prompts) | Yes (per prompt file) | Both |
The per-editor rundown
Cursor is the most opinionated: one master file, one big system prompt that applies to everything. Great for a small tight rule ("always use TypeScript strict mode"), bad for a library of ten skills. If you dump ten prompts into one .cursorrules, every reply gets influenced by all ten and the specific one you wanted gets diluted.
Continue.dev has the best model of the six for a skill library. The customCommands array in config.yaml gives each command a name, description, and prompt. They show up as /name in Continue's chat. Downside: config.yaml lives in ~/.continue/, so it is per user, not per project. You cannot check it into a repo.
Claude Code's .claude/commands/ directory is the cleanest per project pattern. One markdown file per command, frontmatter for metadata, body for the prompt. Ships with the codebase; every team member on the project sees the same commands. Downside: only works in Claude Code.
Windsurf uses .windsurfrules. Same one master file pattern as Cursor. Same tradeoff: fine for a rule, bad for a library.
Cline uses .clinerules. Same again. There is a pattern here.
Zed is the only editor that supports both patterns natively. .rules in the workspace is the master file (Cursor style); files under ~/.config/zed/prompts/ become per user slash commands (Claude Code style). Best of both if you use Zed for everything.
How to install a skill library across all six
You can install a library into any of these editors by hand. It is boring, error prone, and gets stale the moment the source updates.
The alternative: install once, in whatever format your editor wants, from a source that regenerates the target format on every change. This is what Achilleon does.
Every skill in Achilleon is one YAML file. On every merge, six exporters regenerate the editor specific bundles:
# Cursor
curl -O https://raw.githubusercontent.com/taskclan/achilleon/main/dist/cursor/.cursorrules
# Continue.dev
curl https://raw.githubusercontent.com/taskclan/achilleon/main/dist/continue/config.yaml
# Claude Code
mkdir -p .claude/commands \
&& curl -sSL https://github.com/taskclan/achilleon/archive/main.tar.gz \
| tar -xz --strip-components=3 -C .claude/commands 'achilleon-main/dist/claude-code/commands'
# Windsurf, Cline, Zed: same pattern, different filename.Same library, six editors, one source of truth. If the community improves the /debug prompt in Achilleon, everyone gets the improvement the next time they refresh.
Which editor should you pick
Honest answer: whichever one you already use.
All six editors are usable for AI-assisted coding. The AI feature quality gap between them is smaller than the workflow quality gap between different editors. If you like Zed, use Zed. If you already know Cursor, stay in Cursor.
What you SHOULD do, regardless of editor:
- Get your skill library out of the editor and into a source of truth (a repo, a shared YAML, whatever).
- Regenerate the editor specific format automatically.
- Version the prompts and treat them like code.
Editor rules files are just a distribution channel. The prompts are the thing that matters.