Claude-skills vs Cursor-regler: hva bør du velge?

Skriver du kode med AI i 2026, har du sannsynligvis endt opp med instruksjoner to steder: en .cursor/rules-mappe som Cursor leser, og en skills-mappe som Claude leser. De løser samme problem, nemlig å lære AI-en hvordan prosjektet ditt fungerer slik at du slipper å gjenta deg selv, og de løser det forskjellig nok til at å velge feil koster deg tokens, synk-hodepine, eller begge deler.

Vi driver SkillProof, der vi installerer og tester Claude-skills på en ren maskin før vi lister dem. Det gir oss et spesielt ståsted for denne sammenligningen: vi har konvertert dusinvis av regelfiler til skills under testing, og vi har sett begge formatene feile på måter dokumentasjonen deres ikke nevner.

Kort fortalt: Cursor-regler er enklere og ligger nærmere editoren din. Claude-skills er mer kapable og følger deg på tvers av verktøy. Regler vinner når instruksjonen skal gjelde for hver fil som matcher et mønster, alltid. Skills vinner når instruksjonen er betinget, bunter støttefiler, eller må fungere utenfor én IDE. De fleste utviklere som bruker begge verktøyene, bør ha prosjektkonvensjoner i en delt fil og legge alt betinget i skills.

	Cursor-regler	Claude-skills
Omfang	Per prosjekt (.cursor/rules/) eller per bruker (innstillinger)	Globalt (~/.claude/skills/) eller per prosjekt (.claude/skills/)
Trigger	Glob-mønstre, alltid på, eller beskrivelsesmatch	Beskrivelsesmatch, avgjort av modellen
Innhold	Rene instruksjoner	Instruksjoner pluss skript, maler, referansefiler
Portabilitet	Bare Cursor	Claude Code, Claude Desktop, claude.ai, Agent SDK
Kontekstkostnad	Full regeltekst når tilkoblet; alltid-på-regler følger hver forespørsel	~100 tokens metadata inntil utløst, deretter selve innholdet
Økosystem	Stort; tusenvis av delte .cursorrules på GitHub	Mindre, men voksende; inkluderer Anthropics offisielle sett
Testkultur	Praktisk talt ingen	Nesten ingen; vi tester våre

Nå til detaljene, for tabellen skjuler de interessante delene.

Hva Cursor-regler egentlig er

Cursor har to generasjoner av samme idé. Den originale .cursorrules-filen ligger i prosjektroten: én ren tekstfil med instruksjoner som injiseres i hver AI-forespørsel i det repoet. Den er avviklet, men fortsatt respektert, og en stor andel offentlige eksempler bruker den fortsatt.

Det gjeldende systemet er en .cursor/rules/-mappe med .mdc-filer, hver med frontmatter som styrer når den gjelder. Fire moduser: Always (hver forespørsel), Auto Attached (utløses når en fil som matcher et glob er i kontekst, så globs: *.tsx kobles på bare under React-arbeid), Agent Requested (modellen leser beskrivelsen og bestemmer selv), og Manual (bare når du @-nevner den). Cursor leser også AGENTS.md, noe som blir viktig senere i artikkelen. Det finnes også brukernivå-regler, satt i Cursors innstillinger, som gjelder på tvers av alle prosjekter.

Høres det ut som en skills triggersystem? Delvis er det det. Agent Requested-regler beskrivelsesmatches akkurat som skills. Forskjellen ligger i hva som skjer etter triggeren, og dit kommer vi.

Der regler virkelig vinner

Vi tester Claude-skills for å leve, så du forventer kanskje at vi argumenterer for skills overalt. Det gjør vi ikke, for regler har reelle styrker.

Alltid-på-regler er enklere å resonnere om. En regel med alwaysApply: true er i konteksten til hver forespørsel, punktum. Det finnes ingen trigger som kan bomme, ingen beskrivelse å skrive feil, ingen «hvorfor aktiverte den seg ikke»-feilsøkingsøkt. Når vi tester skills, er triggerfeil en av de to vanligste svakhetene vi finner. Regler i always- eller glob-modus kan strukturelt sett ikke ha den svakheten. For et lite sett harde prosjektlover («aldri rør de genererte filene i src/gen/») slår en dum alltid-på-regel en smart betinget en.

Glob-skoping er presist. globs: **/*.sql betyr at SQL-konvensjonene dine kobles på under SQL-arbeid og aldri ellers. Sammenhengen mellom filtype og instruksjon er mekanisk og forutsigbar. Skills tilnærmer seg dette med beskrivelsesformuleringer («bruk når du skriver SQL»), som fungerer godt i praksis, men er en vurdering modellen gjør, ikke en mønstermatch.

De lever der du skriver. Regler integrerer med Cursors Tab-fullføring, inline-redigeringer og agent-modus uten noe oppsett. Ingenting å installere, ingen mappekonvensjoner å lære utover å legge filer i en mappe.

Økosystemet er enormt. Søk på GitHub etter .cursorrules og du finner tusenvis av filer som dekker nesten alle rammeverk. Kvaliteten varierer voldsomt, men dekningen gjør det ikke.

Hva skills gjør som regler ikke kan

Er du ny i formatet, dekker vår fullstendige guide til Claude-skills anatomien. Her er den sammenligningsrelevante delen.

Betinget triggering med reell økonomi bak seg. En skill lastes i trinn. Ved oppstart leser Claude bare navn og beskrivelse for hver skill, omtrent 100 tokens. Innholdet lastes når beskrivelsen matcher forespørselen din. Referansefiler lastes enda senere, og bare ved behov. Femti installerte skills ligger i ro på noen få tusen tokens totalt. Femti alltid-på-regler ville vært en kontekstkatastrofe, som er grunnen til at Cursor setter tak og advarer om regellengde. Progressiv avsløring betyr at en skill kan være enorm uten å være dyr, og det endrer hva du har råd til å skrive ned.

Bundlede filer. En skill er en mappe, ikke en fil. Anthropics docx-skill leverer Python-skript som bygger Word-dokumenter. skill-creator-skillen leverer maler og et evalueringsverktøy. En code review-skill kan ha en alvorlighetsrubrikk som en egen referansefil som bare lastes under reviews. Regler er tekst som beskriver hva modellen bør gjøre. Skills kan inkludere verktøyet som gjør det, og modellen kjører skriptet i stedet for å improvisere resultatet.

Portabilitet. En skill du skriver for Claude Code fungerer også i Claude Desktop, på claude.ai, og i alt bygget på Agent SDK-et. Git-konvensjonene dine følger deg fra terminal til chat til en egendefinert agent. En Cursor-regel fungerer i Cursor. Bytter du noen gang editor, eller bruker Claude til ikke-editor-arbeid som skriving eller dataanalyse, er skill-formatet det som overlever flyttingen. Dette er det sterkeste argumentet for skills som et alternativ til Cursor-regler: du skriver instruksjonene én gang, og de er ikke giftet bort til ett produkt.

Skills kan handle, ikke bare rådgi. Fordi Claude Code kjører kommandoer, kan en skill si «kjør dette skriptet og lim inn resultatet» i stedet for «her er hvordan man kunne formatert resultatet». Gapet mellom å beskrive atferd og å levere atferd er det samme gapet som mellom en stilguide og en linter.

Hva regler gjør som skills ikke kan

To ting, og de er ikke små.

IDE-innebygd kontekst. Regler deltar i alt Cursor gjør: fullføringer mens du skriver, Cmd+K inline-redigeringer, agent-panelet. Skills opererer der Claude opererer, som i dag betyr CLI-en, desktop-appen og web, ikke inne i et annet selskaps editor. Skjer all AI-bruken din via Cursors Tab-tast, når skills deg ikke der.

Per-glob-anvendelse. Det finnes ingen skill-ekvivalent til «koble på disse instruksjonene når en .proto-fil er i kontekst». Modellen bestemmer ut fra beskrivelser, og selv om den er god på dette, er det ingen garanti. For instruksjoner som må korrelere med filtype fremfor oppgavetype, er glob-skopede regler den bedre mekanismen, punktum.

Migrasjonsveien, begge retninger

Å konvertere en .cursorrules-fil til en skill

Ta en typisk regelfil:

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 handler mest om å legge til 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`.

Legg den i .claude/skills/react-conventions/SKILL.md og den utløses ved frontend-arbeid i det repoet. Tre ting endret seg, og hver av dem betyr noe. Persona-linjen («You are an expert...») er borte fordi den ikke gjør noe; modellen blir ikke bedre på React av å bli fortalt at den er ekspert. Beskrivelsen lister nå konkrete aktiviteter, fordi det feltet er triggeren, og vage beskrivelser er hovedgrunnen til at skills ligger i dvale. Og punktene fikk overskrifter, siden en skills innhold bør være raskt å skumme for modellen ved lasting. Vår guide til å skrive skills dekker beskrivelsesskrivingen i dybden; det er steget folk roter til.

Mens du er i gang, spør om noen av punktene bør bli en fil. Beskriver regelfilen din et API-responsformat, legg et faktisk eksempelrespons i reference.json ved siden av SKILL.md og pek til det. Det alternativet finnes rett og slett ikke i regel-formatet.

Å gå motsatt vei

Å konvertere en skill til en Cursor-regel betyr å flate den ut. Ta innholdet i SKILL.md-en din, dropp frontmatter, og lagre 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 filene, så alt som var et skript blir en beskrivelse av hva skriptet gjorde. Du mister progressiv avsløring, så kutt hardt: et 3000-tokens skill-innhold bør bli en 500-tokens regel, og bare beholde det Cursors modeller faktisk trenger per forespørsel. Hold globen stram slik at regelen ikke belaster urelatert arbeid.

Å kjøre begge uten å duplisere deg selv

Mange utviklere bruker Cursor til redigering og Claude Code til agentarbeid i samme repo. Fellen er å vedlikeholde to kopier av samme konvensjoner som driver fra hverandre i løpet av en måned.

Løsningen som har fungert for oss: velg ett kanonisk hjem per instruksjon, basert på formen dens.

Delte prosjektfakta går i AGENTS.md. Begge verktøy leser den. Arkitekturnotater, byggekommandoer, mappestruktur, «aldri rør disse filene»-listen. Én fil, null duplisering, og den tjener også menneskelige nykommere.

Glob-formede instruksjoner blir i .cursor/rules. Filtype-konvensjoner som mekanisk bør kobles på i editoren.

Oppgaveformede og verktøy-uavhengige instruksjoner blir skills. Feilsøkingsmetodikk, reviewsjekklister, utgivelsesprosedyrer, alt med et skript eller en mal, alt du også vil ha tilgjengelig i Claude Desktop eller chat.

Må en instruksjon virkelig finnes i begge formater, la regelen være en peker, ikke en kopi: en to-linjers .mdc som sier «konvensjoner for X ligger i .claude/skills/x/SKILL.md; følg dem» holder én sannhetskilde. Noen team skripter konverteringen i CI i stedet, og genererer .mdc-filer fra SKILL.md-innhold ved commit. Det er mer maskineri enn de fleste prosjekter trenger, men det slår stille drift i et stort team.

Én ting vi vil dra deg bort fra: å lime inn samme 2000-ords dokument i begge systemer ordrett. I Cursor blåser det opp hver forespørsel. I Claude er det vanligvis et tegn på at innholdet bør splittes i en liten alltid-relevant kjerne og et sett betingede skills. Dette er samme resonnement som skills vs MCP: match mekanismen til formen på problemet i stedet for å tvinge ett verktøy til å gjøre alt.

Ingen tester regler heller

Her er delen av sammenligningen ingen andre vil gi deg, fordi det er hele grunnen til at vi finnes.

Da vi begynte å teste community Claude-skills, feilet omtrent halvparten ved første forsøk: ødelagte triggere, instruksjoner modellen ikke kan følge, resultat ikke bedre enn utgangspunktet. Vi dokumenterte feiltaksonomien i hvorfor halvparten av Claude-skills ikke fungerer. Det ubehagelige oppfølgingsspørsmålet er om de tusenvis av delte .cursorrules-filene på GitHub er noe bedre.

Det er de ikke, og strukturelt sett kan de ikke være det. Samme insentiver gjelder: regler publiseres fra én forfatters arbeidsflyt, aldri verifisert på en ren oppsett, aldri målt mot en uten-regel-baseline, og stjernemerket basert på README-kvalitet fremfor resultater. Når vi har plukket fra hverandre populære regelfiler, finner vi de samme svakhetene vi trekker skills for. Persona-fyll som spiser kontekst og endrer ingenting. Instruksjoner skrevet for en modellversjon to generasjoner tilbake. Motstridende punkter («vær kortfattet» førti linjer etter «forklar alltid resonnementet ditt i detalj»). Regler så lange at de fortrenger koden de skal forbedre.

Regler unngår én feilmodus, siden en alltid-på-regel ikke kan unnlate å utløses. Enhver annen feilmodus overføres direkte. Et konvensjonsdokument som gjør resultatet dårligere, er like skadelig i begge formater; formatet endrer bare hvordan det leveres.

Så uansett hvilken side av denne sammenligningen du lander på, er det operative rådet identisk: ikke installer delte instruksjonsfiler på tro og love. Diff resultatet med og uten instruksjonene på en reell oppgave fra ditt eget prosjekt. Ti minutters sammenligning slår enhver stjernesum. For skills har vi allerede gjort den jobben på tvers av vår testede kodesamling, der oppføringer som systematic-debugging bærer før/etter-bevis fremfor løfter. For Cursor-regler, så vidt vi vet, gjør ingen den jobben i det hele tatt. Trekk din egen konklusjon om hva halvparten av dem faktisk er verdt.

Ofte stilte spørsmål

Kan Claude Code lese .cursorrules-filen min direkte? Ikke automatisk. Claude Code leser CLAUDE.md, AGENTS.md og sine skills-mapper, og ignorerer .cursorrules og .cursor/rules. Du kan be den lese filen i en økt, men for noe permanent, konverter innholdet til en skill eller flytt de delte delene til AGENTS.md.

Koster Cursor-regler tokens på samme måte som skills? Mer, i de fleste oppsett. En alltid-på-regel følger hver eneste forespørsel i full lengde. En skill ligger i ro på rundt 100 tokens metadata og betaler for innholdet sitt bare når den utløses. Glob-skopede regler minker gapet, siden de bare kobles på under matchende arbeid, men det finnes ingen regel-ekvivalent til å laste referansemateriale ved behov.

Bør jeg konvertere alle Cursor-reglene mine til skills? Nei. Behold glob-skopede, filtype-konvensjoner som regler hvis du jobber i Cursor; den mekanismen er genuint bedre for dem. Konverter det oppgaveformede materialet: arbeidsflyter, sjekklister, alt med maler eller skript, alt du vil ha utenfor editoren.

Finnes det en delt standard begge verktøy leser? AGENTS.md er det nærmeste. Cursor og Claude Code leser begge den, sammen med en voksende liste andre agenter. Det er rene alltid-på-instruksjoner uten betinget lasting, så behandle den som hjemmet for en liten kjerne av prosjektfakta fremfor en søppelbøtte.

Er Claude-skills eller Cursor-regler bedre for et team? Skills sjekkes inn i git under .claude/skills/ og versjoneres som kode, og regler sjekkes inn under .cursor/rules/ på samme måte, så begge distribueres greit. Teamspørsmålet handler egentlig om overflate: lever alle i Cursor, når regler dem uten oppsett. Bruker teamet også Claude Code, Desktop, eller agenter bygget på SDK-et, er skills det eneste formatet som dekker hver flate, og synk-mønsteret over hindrer de to i å drive fra hverandre.