Claude skills vs Cursor rules: wat kies je?

Als je in 2026 code schrijft met AI, ben je waarschijnlijk in twee plekken met instructies geëindigd: een .cursor/rules-map die Cursor leest, en een skills-map die Claude leest. Ze lossen hetzelfde probleem op, je AI leren hoe je project werkt zodat je jezelf niet blijft herhalen, en ze lossen het verschillend genoeg op dat de verkeerde keuze je tokens, synchronisatie-hoofdpijn, of beide kost.

We draaien SkillProof, waar we Claude skills installeren en testen op een schone machine voordat we ze vermelden. Dat geeft ons een specifiek gezichtspunt op deze vergelijking: we hebben tientallen rule-bestanden omgezet naar skills tijdens het testen, en we hebben beide formaten zien falen op manieren die hun documentatie niet vermeldt.

TL;DR: Cursor rules zijn eenvoudiger en zitten dichter bij je editor. Claude skills zijn krachtiger en reizen met je mee tussen tools. Rules winnen wanneer de instructie altijd moet gelden voor elk bestand dat bij een patroon past. Skills winnen wanneer de instructie voorwaardelijk is, ondersteunende bestanden bundelt, of buiten één IDE moet werken. De meeste developers die beide tools gebruiken, houden projectconventies in een gedeeld bestand en stoppen alles voorwaardelijke in skills.

	Cursor rules	Claude skills
Bereik	Per project (.cursor/rules/) of per gebruiker (instellingen)	Globaal (~/.claude/skills/) of per project (.claude/skills/)
Trigger	Glob-patronen, altijd-aan, of beschrijving-match	Beschrijving-match, bepaald door het model
Payload	Platte instructies	Instructies plus scripts, templates, referentiebestanden
Portabiliteit	Alleen Cursor	Claude Code, Claude Desktop, claude.ai, de Agent SDK
Contextkosten	Volledige rule-tekst wanneer gekoppeld; altijd-aan rules rijden mee met elk verzoek	~100 tokens metadata tot geactiveerd, dan de body
Ecosysteem	Groot; duizenden gedeelde .cursorrules op GitHub	Kleiner maar groeiend; inclusief Anthropics officiële set
Testcultuur	Vrijwel afwezig	Grotendeels afwezig; wij testen de onze

Nu de details, want de tabel verbergt de interessante delen.

Wat Cursor rules eigenlijk zijn

Cursor heeft twee generaties van hetzelfde idee. Het originele .cursorrules-bestand staat in je projectroot: één platte-tekst-bestand met instructies dat wordt geïnjecteerd in elk AI-verzoek in die repo. Het is verouderd maar wordt nog steeds gerespecteerd, en een groot deel van de publieke voorbeelden gebruikt het nog steeds.

Het huidige systeem is een .cursor/rules/-map met .mdc-bestanden, elk met frontmatter die bepaalt wanneer het van toepassing is. Vier modi: Always (elk verzoek), Auto Attached (activeert wanneer een bestand dat bij een glob past in context staat, dus globs: *.tsx koppelt alleen tijdens React-werk), Agent Requested (het model leest de beschrijving en beslist), en Manual (alleen wanneer je er met @ naar verwijst). Cursor leest ook AGENTS.md, wat verderop in dit artikel van belang is. Er zijn ook gebruikersniveau-rules, ingesteld in Cursors instellingen, die op alle projecten van toepassing zijn.

Als dat sterk lijkt op het trigger-systeem van een skill, is dat deels zo. Agent Requested rules worden precies op dezelfde manier op beschrijving gematcht als skills. Het verschil zit in wat er na de trigger gebeurt, en daar komen we op terug.

Waar rules echt winnen

Wij testen Claude skills voor de kost, dus je zou verwachten dat we overal voor skills pleiten. Dat doen we niet, want rules hebben echte sterke punten.

Altijd-aan rules zijn eenvoudiger te doorgronden. Een rule met alwaysApply: true zit in de context van elk verzoek, punt uit. Er is geen trigger die kan mismatchen, geen beschrijving die fout kan zijn, geen "waarom activeerde dit niet"-debugsessie. Wanneer wij skills testen, is een falende trigger een van de twee meest voorkomende defecten die we vinden. Rules in always- of glob-modus kunnen structureel dat defect niet hebben. Voor een kleine set harde projectregels ("kom nooit aan de gegenereerde bestanden in src/gen/") verslaat een domme altijd-aan rule een slimme voorwaardelijke.

Glob-scoping is precies. globs: **/*.sql betekent dat je SQL-conventies koppelen tijdens SQL-werk en nooit anders. De mapping van bestandstype naar instructie is mechanisch en voorspelbaar. Skills benaderen dit met beschrijvingsformulering ("gebruik bij het schrijven van SQL"), wat in de praktijk goed werkt maar een oordeel is van het model in plaats van een patroonmatch.

Ze zitten waar je typt. Rules integreren met Cursors Tab-aanvulling, inline edits en agent-modus zonder enige setup. Niets te installeren, geen mapconventies te leren behalve bestanden in een map zetten.

Het ecosysteem is enorm. Zoek op GitHub naar .cursorrules en je vindt duizenden bestanden die bijna elk framework dekken. De kwaliteit varieert enorm, maar de dekking niet.

Wat skills doen dat rules niet kunnen

Als je nieuw bent met het formaat, behandelt onze volledige gids voor Claude skills de anatomie. Hier is het vergelijking-relevante deel.

Voorwaardelijke triggering met echte economie erachter. Een skill laadt in fasen. Bij het opstarten leest Claude alleen de naam en beschrijving van elke skill, ruwweg 100 tokens. De body laadt wanneer de beschrijving bij je verzoek past. Referentiebestanden laden nog later, en alleen indien nodig. Vijftig geïnstalleerde skills draaien stationair op een paar duizend tokens totaal. Vijftig altijd-aan rules zouden een contextramp zijn, wat waarom Cursor rule-lengte begrenst en er voor waarschuwt. Progressive disclosure betekent dat een skill enorm kan zijn zonder duur te zijn, en dat verandert wat je je kunt veroorloven op te schrijven.

Gebundelde bestanden. Een skill is een map, geen bestand. Anthropics docx-skill bevat Python-scripts die Word-documenten bouwen. De skill-creator-skill bevat templates en een eval-harness. Een code review-skill kan een severity-rubriek meedragen als apart referentiebestand dat alleen laadt tijdens reviews. Rules zijn tekst die beschrijft wat het model moet doen. Skills kunnen de tooling meeleveren om het te doen, en het model draait het script in plaats van de output te improviseren.

Portabiliteit. Een skill die je schrijft voor Claude Code werkt ook in Claude Desktop, op claude.ai, en in alles gebouwd op de Agent SDK. Je git-conventies volgen je van terminal naar chat naar een custom agent. Een Cursor rule werkt in Cursor. Als je ooit van editor wisselt, of Claude gebruikt voor niet-editor-werk zoals schrijven of data-analyse, is het skill-formaat het formaat dat de overstap overleeft. Dit is het sterkste argument voor skills als cursor rules-alternatief: je schrijft de instructies één keer en ze zijn niet getrouwd met één product.

Skills kunnen handelen, niet alleen adviseren. Omdat Claude Code commando's uitvoert, kan een skill zeggen "voer dit script uit en plak de output" in plaats van "zo zou je de output kunnen formatteren." Het gat tussen gedrag beschrijven en gedrag leveren is hetzelfde gat tussen een stijlgids en een linter.

Wat rules doen dat skills niet kunnen

Twee dingen, en ze zijn niet klein.

IDE-native context. Rules doen mee aan alles wat Cursor doet: aanvullingen terwijl je typt, Cmd+K inline edits, het agent-paneel. Skills opereren waar Claude opereert, wat vandaag de CLI, desktop-app en web betekent, niet binnen de editor van een ander bedrijf. Als al je AI-gebruik plaatsvindt via Cursors Tab-toets, bereiken skills je daar niet.

Per-glob toepassing. Er is geen skill-equivalent van "koppel deze instructies wanneer een .proto-bestand in context staat." Het model beslist op basis van beschrijvingen, en hoewel het daar goed in is, is het geen garantie. Voor instructies die moeten correleren met bestandstype in plaats van taaktype, zijn glob-geschaalde rules het betere mechanisme, punt uit.

Het migratiepad, beide kanten op

Een .cursorrules-bestand omzetten naar een skill

Neem een typisch rules-bestand:

You are an expert React and TypeScript developer.

- Functional components with hooks only, no classes
- Named exports, never default exports
- Tailwind for styling, no inline style objects
- All API calls go through src/lib/api.ts
- Tests in Vitest, colocated as *.test.tsx

De omzetting is vooral een trigger en structuur toevoegen:

---
name: react-conventions
description: React/TypeScript conventions for this repo. Use when
  writing or reviewing components, hooks, styles, API calls, or
  frontend tests.
---

## Components
- Functional components with hooks. No class components.
- Named exports only. No default exports.

## Styling
- Tailwind utility classes. Never inline style objects.

## Data access
- Every API call goes through `src/lib/api.ts`. Do not call
  fetch directly from a component.

## Tests
- Vitest, colocated next to the component as `*.test.tsx`.

Zet het in .claude/skills/react-conventions/SKILL.md en het activeert bij frontend-werk in die repo. Drie dingen zijn veranderd en elk telt. De persona-regel ("You are an expert...") is weg omdat die niets doet; het model wordt niet beter in React door te horen dat het een expert is. De beschrijving somt nu concrete activiteiten op, want dat veld is de trigger en vage beschrijvingen zijn reden nummer één dat skills stil blijven liggen. En de bullets kregen koppen, aangezien een skill-body scanbaar moet zijn door het model tijdens het laden. Onze gids voor het schrijven van skills behandelt het beschrijving-schrijven uitgebreid; dat is de stap die mensen verknoeien.

Vraag jezelf ook af of een bullet een bestand zou moeten worden. Als je rules-bestand een API-responsformaat beschrijft, zet dan een echt voorbeeldresponse in reference.json naast de SKILL.md en verwijs ernaar. Die optie bestaat simpelweg niet in het rules-formaat.

De andere kant op

Een skill omzetten naar een Cursor rule betekent afplatten. Neem de body van je SKILL.md, verwijder de frontmatter, en sla het op als .cursor/rules/react-conventions.mdc met nieuwe frontmatter:

---
description: React/TypeScript conventions for this repo
globs: src/**/*.tsx,src/**/*.ts
alwaysApply: false
---

- Functional components with hooks. No class components.
- Named exports only. No default exports.
...

Je verliest de gebundelde bestanden, dus alles wat een script was wordt een beschrijving van wat het script deed. Je verliest progressive disclosure, dus snoei flink: een skill-body van 3.000 tokens zou een rule van 500 tokens moeten worden, waarbij je alleen behoudt wat Cursors modellen echt per verzoek nodig hebben. Houd de glob strak zodat de rule niet meetelt bij ongerelateerd werk.

Beide draaien zonder jezelf te dupliceren

Genoeg developers gebruiken Cursor voor het bewerken en Claude Code voor agent-werk in dezelfde repo. De valkuil is het onderhouden van twee kopieën van dezelfde conventies die binnen een maand uit elkaar drijven.

De oplossing die voor ons heeft gewerkt: kies één canonieke plek per instructie, gebaseerd op de vorm ervan.

Gedeelde projectfeiten gaan in AGENTS.md. Beide tools lezen het. Architectuurnotities, buildcommando's, mapindeling, de "kom nooit aan deze bestanden"-lijst. Eén bestand, geen duplicatie, en het dient ook menselijke nieuwkomers.

Glob-vormige instructies blijven in .cursor/rules. Bestandstype-conventies die mechanisch moeten koppelen in de editor.

Taak-vormige en cross-tool instructies worden skills. Debugmethodologie, reviewchecklists, releaseprocedures, alles met een script of template, alles wat je ook beschikbaar wilt in Claude Desktop of chat.

Als een instructie echt in beide formaten moet bestaan, maak van de rule een verwijzing, geen kopie: een tweeregelige .mdc die zegt "conventies voor X leven in .claude/skills/x/SKILL.md; volg ze" houdt één bron van waarheid. Sommige teams scripten de omzetting in CI in plaats daarvan, en regenereren .mdc-bestanden uit SKILL.md-bodies bij elke commit. Dat is meer machinerie dan de meeste projecten nodig hebben, maar het verslaat stille drift bij een groot team.

Eén ding waar we je van weg zouden houden: hetzelfde document van 2.000 woorden woordelijk in beide systemen plakken. In Cursor blaast het elk verzoek op. In Claude is het meestal een teken dat de inhoud gesplitst moet worden in een kleine altijd-relevante kern en een set voorwaardelijke skills. Dit is dezelfde redenering als bij skills vs MCP: match het mechanisme met de vorm van het probleem in plaats van één tool alles te laten doen.

Niemand test rules ook

Hier is het deel van deze vergelijking dat niemand anders je zal geven, omdat het onze hele reden van bestaan is.

Toen we begonnen met het testen van community Claude skills, faalde ruwweg de helft bij de eerste poging: gebroken triggers, instructies die het model niet kan volgen, output niet beter dan de baseline. We hebben de faal-taxonomie gedocumenteerd in waarom de helft van de Claude skills niet werkt. De ongemakkelijke vervolgvraag is of de duizenden gedeelde .cursorrules-bestanden op GitHub beter zijn.

Dat zijn ze niet, en structureel kunnen ze het ook niet zijn. Dezelfde prikkels gelden: rules worden gepubliceerd vanuit de workflow van één auteur, nooit geverifieerd op een schone setup, nooit gemeten tegen een baseline zonder rule, en met sterren beoordeeld op basis van README-kwaliteit in plaats van resultaten. Wanneer we populaire rule-bestanden uit elkaar hebben getrokken, vinden we dezelfde defecten waarop we skills afwaarderen. Persona-opvulling die context verbruikt en niets verandert. Instructies geschreven voor een modelversie twee generaties terug. Tegenstrijdige bullets ("wees beknopt" veertig regels na "leg je redenering altijd uitgebreid uit"). Rules zo lang dat ze de code verdringen die ze zouden moeten verbeteren.

Rules ontwijken één faalmodus, aangezien een altijd-aan rule niet kan falen om te activeren. Elke andere faalmodus draagt direct over. Een conventiedocument dat de output slechter maakt is even schadelijk in beide formaten; het formaat verandert alleen hoe het geleverd wordt.

Dus aan welke kant van deze vergelijking je ook uitkomt, het praktische advies is identiek: installeer geen gedeelde instructiebestanden op vertrouwen. Diff de output met en zonder de instructies op een echte taak uit je eigen project. Tien minuten vergelijken verslaat elk aantal sterren. Voor skills hebben we dat werk al gedaan in onze geteste coding-collectie, waar items zoals systematic-debugging bewijs voor/na dragen in plaats van beloftes. Voor Cursor rules doet, voor zover wij weten, niemand dat werk. Trek zelf je conclusie over wat de helft ervan waard is.

FAQ

Kan Claude Code mijn .cursorrules-bestand direct lezen? Niet automatisch. Claude Code leest CLAUDE.md, AGENTS.md, en zijn skills-mappen, en negeert .cursorrules en .cursor/rules. Je kunt het vragen om het bestand in een sessie te lezen, maar voor iets permanents, zet de inhoud om naar een skill of verplaats de gedeelde delen naar AGENTS.md.

Kosten Cursor rules tokens zoals skills dat doen? Meer, in de meeste setups. Een altijd-aan rule rijdt mee met elk enkel verzoek op volledige lengte. Een skill draait stationair op ongeveer 100 tokens metadata en betaalt alleen voor zijn body bij activatie. Glob-geschaalde rules verkleinen het gat, aangezien ze alleen koppelen tijdens matchend werk, maar er is geen rules-equivalent van referentiemateriaal op aanvraag laden.

Moet ik al mijn Cursor rules omzetten naar skills? Nee. Houd glob-geschaalde, bestandstype-conventies als rules als je in Cursor werkt; dat mechanisme is echt beter voor ze. Zet het taak-vormige materiaal om: workflows, checklists, alles met templates of scripts, alles wat je buiten de editor wilt.

Is er een gedeelde standaard die beide tools lezen? AGENTS.md komt het dichtst in de buurt. Cursor en Claude Code lezen het beide, samen met een groeiende lijst andere agents. Het zijn platte altijd-aan instructies zonder voorwaardelijk laden, dus behandel het als de plek voor een kleine kern van projectfeiten in plaats van een stortplaats.

Zijn Claude skills of Cursor rules beter voor een team? Skills worden ingecheckt in git onder .claude/skills/ en versioneren als code, en rules worden op dezelfde manier ingecheckt onder .cursor/rules/, dus beide distribueren prima. De teamvraag gaat eigenlijk over bereik: als iedereen in Cursor leeft, bereiken rules ze zonder setup. Als het team ook Claude Code, Desktop, of agents gebouwd op de SDK gebruikt, zijn skills het enige formaat dat elk oppervlak dekt, en het sync-patroon hierboven houdt de twee uit elkaar drijven.