Claude Skills vs Cursor Rules: Hvad skal du vælge?

Hvis du skriver kode med AI i 2026, er du sikkert endt med instruktioner to steder: en .cursor/rules-mappe, som Cursor læser, og en skills-mappe, som Claude læser. De løser det samme problem — at lære din AI, hvordan dit projekt fungerer, så du slipper for at gentage dig selv — og de løser det forskelligt nok til, at et forkert valg koster dig tokens, synk-hovedpine eller begge dele.

Vi driver SkillProof, hvor vi installerer og tester Claude-skills på en ren maskine, før vi lister dem. Det giver os et bestemt udgangspunkt for denne sammenligning: vi har konverteret snesevis af rule-filer til skills under testning, og vi har set begge formater fejle på måder, deres dokumentation ikke nævner.

TL;DR: Cursor rules er enklere og ligger tættere på din editor. Claude-skills er mere kapable og rejser med dig på tværs af værktøjer. Rules vinder, når instruktionen skal gælde for hver fil, der matcher et mønster, altid. Skills vinder, når instruktionen er betinget, samler understøttende filer, eller skal virke uden for én IDE. De fleste udviklere, der bruger begge værktøjer, bør holde projektkonventioner i en delt fil og lægge alt betinget ind i skills.

	Cursor rules	Claude skills
Omfang	Per projekt (.cursor/rules/) eller per bruger (indstillinger)	Globalt (~/.claude/skills/) eller per projekt (.claude/skills/)
Trigger	Glob-mønstre, altid-på, eller beskrivelsesmatch	Beskrivelsesmatch, afgjort af modellen
Indhold	Rene instruktioner	Instruktioner plus scripts, skabeloner, referencefiler
Portabilitet	Kun Cursor	Claude Code, Claude Desktop, claude.ai, Agent SDK
Kontekstomkostning	Fuld rule-tekst når tilknyttet; altid-på-rules kører med på hver forespørgsel	~100 tokens metadata indtil trigget, derefter selve indholdet
Økosystem	Stort; tusindvis af delte .cursorrules på GitHub	Mindre, men voksende; inkluderer Anthropics officielle sæt
Testkultur	Reelt set ingen	Stort set ingen; vi tester vores

Nu til detaljerne, for tabellen skjuler de interessante dele.

Hvad Cursor rules egentlig er

Cursor har to generationer af samme idé. Den oprindelige .cursorrules-fil ligger i roden af dit projekt: én ren tekstfil med instruktioner, der injiceres i hver AI-forespørgsel i det repo. Den er udfaset, men stadig respekteret, og en stor del af de offentlige eksempler bruger den stadig.

Det nuværende system er en .cursor/rules/-mappe med .mdc-filer, hver med frontmatter, der styrer hvornår den gælder. Fire tilstande: Always (hver forespørgsel), Auto Attached (udløses når en fil, der matcher et glob, er i konteksten, så globs: *.tsx kun tilknyttes under React-arbejde), Agent Requested (modellen læser beskrivelsen og beslutter) og Manual (kun ved @-nævnelse). Cursor læser også AGENTS.md, hvilket betyder noget senere i denne artikel. Der findes også brugerniveau-rules, sat i Cursors indstillinger, som gælder på tværs af alle projekter.

Hvis det lyder meget som en skills trigger-system, gør det det til dels. Agent Requested-rules bliver matchet på beskrivelse, præcis som skills. Forskellen er, hvad der sker efter trigget, og det kommer vi til.

Hvor rules genuint vinder

Vi tester Claude-skills til daglig, så du ville forvente, at vi argumenterer for skills overalt. Det gør vi ikke, for rules har reelle styrker.

Altid-på-rules er lettere at ræsonnere om. En rule med alwaysApply: true er i konteksten for hver eneste forespørgsel, punktum. Der er ingen trigger, der kan fejle, ingen beskrivelse, der kan blive forkert, ingen "hvorfor aktiverede den ikke"-fejlsøgningssession. Når vi tester skills, er trigger-fejl en af de to mest almindelige defekter, vi finder. Rules i always- eller glob-tilstand kan strukturelt set ikke have den defekt. For et lille sæt hårde projektlove ("rør aldrig de genererede filer i src/gen/") slår en dum altid-på-rule en smart betinget en.

Glob-scoping er præcist. globs: **/*.sql betyder, at dine SQL-konventioner tilknyttes under SQL-arbejde og ellers aldrig. Mappingen fra filtype til instruktion er mekanisk og forudsigelig. Skills tilnærmer dette med beskrivelsesformulering ("brug ved skrivning af SQL"), hvilket virker godt i praksis, men er et skøn foretaget af modellen frem for et mønster-match.

De lever, hvor du skriver. Rules integreres med Cursors Tab-fuldførelse, inline-redigeringer og agent-tilstand uden nogen opsætning. Intet at installere, ingen mappe-konventioner at lære udover at droppe filer i en mappe.

Økosystemet er enormt. Søg efter .cursorrules på GitHub, og du finder tusindvis af filer, der dækker næsten hver eneste framework. Kvaliteten varierer voldsomt, men dækningen gør ikke.

Hvad skills gør, som rules ikke kan

Hvis du er ny til formatet, dækker vores fulde guide til Claude-skills anatomien. Her er den del, der er relevant for sammenligningen.

Betinget triggering med reel økonomi bag sig. En skill loader i faser. Ved opstart læser Claude kun hver skills navn og beskrivelse, groft sagt 100 tokens. Indholdet loader, når beskrivelsen matcher din forespørgsel. Referencefiler loader endnu senere, og kun hvis nødvendigt. Halvtreds installerede skills ligger stille på nogle få tusinde tokens i alt. Halvtreds altid-på-rules ville være en kontekstkatastrofe, hvilket er grunden til, at Cursor begrænser og advarer om rule-længde. Progressiv afsløring betyder, at en skill kan være enorm uden at være dyr, og det ændrer, hvad du har råd til at skrive ned.

Bundlede filer. En skill er en mappe, ikke en fil. Anthropics docx-skill leverer Python-scripts, der bygger Word-dokumenter. skill-creator-skillen leverer skabeloner og en eval-motor. En code review-skill kan bære en sværhedsgrads-rubrik som en separat referencefil, der kun loader under reviews. Rules er tekst, der beskriver, hvad modellen bør gøre. Skills kan inkludere selve værktøjet til at gøre det, og modellen kører scriptet i stedet for at improvisere outputtet.

Portabilitet. En skill, du skriver til Claude Code, virker også i Claude Desktop, på claude.ai og i alt bygget på Agent SDK'et. Dine git-konventioner følger dig fra terminal til chat til en custom agent. En Cursor-rule virker i Cursor. Hvis du nogensinde skifter editor, eller bruger Claude til ikke-editor-arbejde som skrivning eller dataanalyse, er skill-formatet det, der overlever flytningen. Det er det stærkeste argument for skills som et cursor rules-alternativ: du skriver instruktionerne én gang, og de er ikke bundet til ét produkt.

Skills kan handle, ikke kun rådgive. Fordi Claude Code udfører kommandoer, kan en skill sige "kør dette script og indsæt outputtet" i stedet for "sådan formaterer man outputtet". Kløften mellem at beskrive adfærd og at levere adfærd er den samme kløft som mellem en stilguide og en linter.

Hvad rules gør, som skills ikke kan

To ting, og de er ikke små.

IDE-native kontekst. Rules deltager i alt, hvad Cursor gør: fuldførelser mens du skriver, Cmd+K inline-redigeringer, agent-panelet. Skills opererer, hvor Claude opererer, hvilket i dag betyder CLI'en, desktop-appen og web, ikke inde i en anden virksomheds editor. Hvis al din AI-brug foregår i Cursors Tab-tast, når skills dig ikke der.

Per-glob-anvendelse. Der findes ingen skill-ækvivalent til "tilknyt disse instruktioner, når en .proto-fil er i konteksten." Modellen beslutter ud fra beskrivelser, og selvom den er god til det, er det ingen garanti. For instruktioner, der skal korrelere med filtype frem for opgavetype, er glob-scopede rules den bedre mekanisme, punktum.

Migreringsvejen, begge retninger

At konvertere en .cursorrules-fil til en skill

Tag en typisk rules-fil:

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

Konverteringen består mest i at tilføje en trigger og struktur:

---
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`.

Læg den i .claude/skills/react-conventions/SKILL.md, og den trigger på frontend-arbejde i det repo. Tre ting ændrede sig, og hver betyder noget. Persona-linjen ("You are an expert...") er væk, fordi den ikke gør noget; modellen bliver ikke bedre til React af at blive fortalt, at den er en ekspert. Beskrivelsen lister nu konkrete aktiviteter, fordi det felt er triggeren, og vage beskrivelser er hovedårsagen til, at skills ligger stille. Og punkterne fik overskrifter, siden en skills indhold bør kunne skimmes af modellen ved load-tid. Vores guide til at skrive skills dækker beskrivelsesdelen i dybden; det er trinnet, folk klokker i.

Mens du er i gang, så spørg om nogen af punkterne burde blive en fil. Hvis din rules-fil beskriver et API-svarformat, så læg et faktisk eksempelsvar i reference.json ved siden af SKILL.md og peg på det. Den mulighed findes simpelthen ikke i rules-formatet.

At gå den anden vej

At konvertere en skill til en Cursor-rule betyder at flade den ud. Tag indholdet af din SKILL.md, fjern frontmatter, og gem den som .cursor/rules/react-conventions.mdc med ny 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.
...

Du mister de bundlede filer, så alt, der var et script, bliver en beskrivelse af, hvad scriptet gjorde. Du mister progressiv afsløring, så beskær hårdt: en 3.000-token skill-krop bør blive til en 500-token rule, og kun beholde det, Cursors modeller reelt har brug for per forespørgsel. Hold globbet stramt, så rule'n ikke belaster urelateret arbejde.

At køre begge uden at duplikere dig selv

Mange udviklere bruger Cursor til redigering og Claude Code til agent-arbejde i samme repo. Fælden er at vedligeholde to kopier af samme konventioner, der driver fra hinanden inden for en måned.

Løsningen, der har virket for os: vælg ét kanonisk hjem per instruktion, baseret på dens form.

Delte projektfakta går i AGENTS.md. Begge værktøjer læser den. Arkitekturnoter, build-kommandoer, mappestruktur, "rør aldrig disse filer"-listen. Én fil, ingen duplikering, og den tjener også nyankomne mennesker.

Glob-formede instruktioner bliver i .cursor/rules. Filtype-konventioner, der mekanisk bør tilknyttes i editoren.

Opgave-formede og tværværktøjs-instruktioner bliver skills. Debug-metodik, review-tjeklister, release-procedurer, alt med et script eller en skabelon, alt du også vil have tilgængeligt i Claude Desktop eller chat.

Hvis en instruktion genuint skal eksistere i begge formater, så gør rule'n til en pointer, ikke en kopi: en to-linjers .mdc, der siger "konventioner for X ligger i .claude/skills/x/SKILL.md; følg dem" holder én kilde til sandhed. Nogle teams scripter konverteringen i CI i stedet og genererer .mdc-filer fra SKILL.md-indhold ved commit. Det er mere maskineri, end de fleste projekter har brug for, men det slår stille drift på et stort team.

Én ting, vi ville fraråde: at indsætte det samme 2.000-ords dokument i begge systemer ordret. I Cursor oppuster det hver forespørgsel. I Claude er det som regel et tegn på, at indholdet bør splittes i en lille altid-relevant kerne og et sæt betingede skills. Det er samme ræsonnement som skills vs MCP: match mekanismen til problemets form i stedet for at tvinge ét værktøj til at gøre alt.

Ingen tester rules heller

Her er den del af denne sammenligning, ingen andre vil give dig, fordi det er hele vores eksistensberettigelse.

Da vi begyndte at teste community Claude-skills, fejlede omkring halvdelen i første forsøg: ødelagte triggere, instruktioner modellen ikke kan følge, output, der ikke er bedre end baseline. Vi dokumenterede fejltaksonomien i hvorfor halvdelen af Claude-skills ikke virker. Det ubehagelige opfølgende spørgsmål er, om de tusindvis af delte .cursorrules-filer på GitHub er bedre.

Det er de ikke, og strukturelt kan de ikke være det. De samme incitamenter gælder: rules udgives fra én forfatters workflow, verificeres aldrig på en ren opsætning, måles aldrig mod en uden-rule-baseline, og optjener stjerner baseret på README-kvalitet frem for resultater. Når vi har skilt populære rule-filer ad, finder vi de samme defekter, vi trækker point fra hos skills for. Persona-udfyldning, der bruger kontekst og ændrer intet. Instruktioner skrevet til en modelversion to generationer gammel. Modstridende punkter ("vær kortfattet" fyrre linjer efter "forklar altid din tankegang i detaljer"). Rules så lange, at de fortrænger den kode, de skal forbedre.

Rules undgår én fejltilstand, siden en altid-på-rule ikke kan fejle i at trigge. Hver anden fejltilstand overføres direkte. Et konventionsdokument, der gør outputtet dårligere, er lige så skadeligt i begge formater; formatet ændrer bare, hvordan det leveres.

Så uanset hvilken side af denne sammenligning du lander på, er den praktiske anbefaling identisk: installér ikke delte instruktionsfiler på tro og love. Diff outputtet med og uden instruktionerne på en reel opgave fra dit eget projekt. Ti minutters sammenligning slår ethvert stjerneantal. For skills har vi allerede gjort det arbejde på tværs af vores testede kodningssamling, hvor entries som systematic-debugging bærer før/efter-beviser frem for løfter. For Cursor rules gør, så vidt vi ved, ingen det arbejde overhovedet. Drag selv din konklusion om, hvad halvdelen af dem er værd.

Ofte stillede spørgsmål

Kan Claude Code læse min .cursorrules-fil direkte? Ikke automatisk. Claude Code læser CLAUDE.md, AGENTS.md og sine skills-mapper, og ignorerer .cursorrules og .cursor/rules. Du kan bede den om at læse filen i en session, men for alt permanent, konvertér indholdet til en skill eller flyt de delte dele til AGENTS.md.

Koster Cursor rules tokens på samme måde som skills? Mere, i de fleste opsætninger. En altid-på-rule kører med i hver eneste forespørgsel i fuld længde. En skill ligger stille på omkring 100 tokens metadata og betaler kun for sit indhold, når den trigges. Glob-scopede rules indsnævrer kløften, siden de kun tilknyttes under matchende arbejde, men der findes ingen rules-ækvivalent til at loade referencemateriale efter behov.

Bør jeg konvertere alle mine Cursor rules til skills? Nej. Behold glob-scopede, filtype-konventioner som rules, hvis du arbejder i Cursor; den mekanisme er genuint bedre for dem. Konvertér det opgave-formede materiale: workflows, tjeklister, alt med skabeloner eller scripts, alt du vil have uden for editoren.

Findes der en delt standard, begge værktøjer læser? AGENTS.md er det tætteste, der findes. Cursor og Claude Code læser begge den, sammen med en voksende liste af andre agenter. Det er ren altid-på-instruktion uden betinget loading, så behandl den som hjemmet for en lille kerne af projektfakta frem for en skraldespand.

Er Claude-skills eller Cursor rules bedre for et team? Skills checkes ind i git under .claude/skills/ og versioneres som kode, og rules checkes ind under .cursor/rules/ på samme måde, så begge distribuerer fint. Team-spørgsmålet handler egentlig om flade: hvis alle lever i Cursor, når rules dem med nul opsætning. Hvis teamet også bruger Claude Code, Desktop eller agenter bygget på SDK'et, er skills det eneste format, der dækker hver flade, og synk-mønsteret ovenfor holder de to fra at drive fra hinanden.