Cursor Rules: Slik skriver du .cursor/rules-filer som faktisk fungerer

Alle Cursor-brukere støter før eller siden på det samme hinderet. AI-en genererer kode som teknisk sett fungerer, men ignorerer prosjektets konvensjoner — feil importstier, utdaterte mønstre, komponenter som ikke ligner noe annet i kodebasen. Cursor Rules løser dette ved å gi AI-en varig kontekst om hvordan ditt prosjekt fungerer.

Hva er Cursor Rules og hvorfor er de viktige?

Cursor Rules er Markdown-filer som fungerer som en permanent systemprompt som injiseres før hver AI-interaksjon — chat, autofullføring, kodegenerering, alt. Tenk på dem som onboardingdokumentasjon for AI-en. I stedet for å rette de samme feilene hver økt skriver du instruksjonen én gang og den blir stående.

Den gamle tilnærmingen var én enkelt .cursorrules-fil i prosjektets rotmappe. Det fungerer fortsatt, men er foreldet. Det nåværende systemet bruker en .cursor/rules/-mappe med individuelle .mdc-filer (Markdown Cursor), hver avgrenset til spesifikke situasjoner. Dette er et mye bedre oppsett fordi du ikke trenger å stappe alle instruksjoner i én stor fil — du deler regler etter ansvarsområde, og Cursor laster bare de som er relevante for det du gjør akkurat nå.

Hvis du har jobbet med context engineering for AI-verktøy, er konseptet kjent: bedre inputkontekst gir dramatisk bedre output. Rules er context engineering for hele utviklingsarbeidsflyten din.

Sette opp din første regelfil

Opprett katalogen .cursor/rules/ i prosjektets rotmappe:

mkdir -p .cursor/rules

Hver regel er en .mdc-fil med YAML-frontmatter etterfulgt av Markdown-innhold. Her er skjelettet:

---
description: "Når denne regelen skal gjelde"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---

Instruksjonene dine går her i vanlig Markdown.

Tre frontmatter-felt styrer alt:

Du kan også opprette regler direkte i Cursor — skriv /create-rule i chatten og beskriv hva du vil ha. Men å skrive dem for hånd gir deg mer kontroll.

De fire regeltypene forklart

Hvordan en regel aktiveres avhenger av frontmatter-konfigurasjonen. Det finnes fire moduser, og å velge riktig har betydning for kontekstvindubudsjettet ditt.

Alltid bruk

---
alwaysApply: true
---

Lastes inn i hver eneste AI-forespørsel. Bruk dette sparsomt — for prosjektomfattende grunnleggende ting som teknologistackdeklarasjonen din eller kritiske konvensjoner som gjelder overalt. Hver alltid-på regel spiser tokens fra hver interaksjon, enten den er relevant eller ikke.

Automatisk vedlagt (glob-basert)

---
globs: ["src/api/**/*.ts", "src/routes/**/*.ts"]
alwaysApply: false
---

Aktiveres bare når du redigerer filer som matcher glob-mønstrene. Dette er den viktigste regeltypen i praksis. React-komponentkonvensjonene dine lastes når du er i komponentfiler, API-mønstrene dine når du er i rutebehandlere, testreglene dine når du skriver tester.

Agentanmodet (intelligent)

---
description: "Databasemigrasjonsmønstre med Drizzle ORM"
alwaysApply: false
---

Ingen glob, ingen always-apply — bare en beskrivelse. Cursors agent leser beskrivelsen og bestemmer om regelen er relevant for den gjeldende oppgaven. Hvis du ber den skrive en migrasjon, henter den inn denne regelen. Hvis du stiler en knapp, hopper den over den. Dette fungerer overraskende bra for regler som ikke neatly kartlegger til filstier.

Manuell

---
---

Ingen frontmatter-felt satt (eller tomt frontmatter). Disse reglene aktiveres bare når du eksplisitt nevner dem med @regelnavn i chatten. Bra for sjelden brukte men viktige instruksjoner — som deployment-sjekklister eller refaktoreringsguider du bare trenger av og til.

Glob-mønstre som faktisk fungerer

Glob bestemmer hvilke filer som utløser automatisk vedlagte regler. Feil konfigurert og reglene dine utløses enten aldri eller overalt. Her er hva som fungerer:

# Alle TypeScript-filer i src
globs: ["src/**/*.ts", "src/**/*.tsx"]

# Bare komponentfiler
globs: ["**/components/**/*.tsx"]

# Python-filer, unntatt tester
globs: ["**/*.py", "!**/test_*.py"]

# Flere spesifikke kataloger
globs: ["src/api/**", "src/services/**"]

Noen fallgruver fra faktisk bruk:

• src/* matcher bare ett katalognivå. Du vil nesten alltid ha src/**/* for rekursiv matching.
• *.js matcher ikke .jsx- eller .ts-filer. Vær eksplisitt om filtyper.
• Glob må være en YAML-liste. Klammesyntaks som {src,lib}/**/*.ts kan feile stille — bruk separate listoppføringer.
• Prefikset ! ekskluderer mønstre, nyttig for å ignorere genererte filer eller legacy-kode.

Praktiske regeleksempler

Her møtes teori og praksis. Dette er regler du kan legge til i et prosjekt og umiddelbart se bedre AI-output.

Prosjektomfattende basisregel (Alltid bruk)

---
alwaysApply: true
---

# Project: Acme Dashboard

## Tech Stack
- Next.js 15 (App Router only — no Pages Router)
- TypeScript strict mode
- Tailwind CSS v4
- Drizzle ORM with PostgreSQL
- pnpm for package management

## Critical Conventions
- All components are React Server Components by default
- Use "use client" only when the component needs interactivity
- Import paths use @/ alias mapped to src/
- Error handling: wrap async operations in try/catch, never use .catch()
- No default exports except for pages and layouts

Hold dette under 30 linjer. Det lastes med hver forespørsel, så hvert ord koster tokens.

React-komponentregel (Automatisk vedlagt)

---
description: "React component patterns and conventions"
globs: ["src/components/**/*.tsx", "src/app/**/*.tsx"]
alwaysApply: false
---

# React Component Rules

## Structure
Every component file follows this order:
1. Imports
2. Type definitions (Props interface)
3. Component function (named export)
4. Sub-components (if any)

## Patterns

Use named exports, not default:
- YES: `export function Button({ label }: ButtonProps)`
- NO: `export default function Button()`

For data fetching in Server Components:
```tsx
// Fetch directly in the component — no useEffect
export async function UserProfile({ id }: { id: string }) {
  const user = await db.query.users.findFirst({
    where: eq(users.id, id)
  });
  return <div>{user.name}</div>;
}

Anti-Patterns (NEVER do these)

• No useEffect for data fetching in Server Components
• No CSS modules — use Tailwind exclusively
• No barrel exports (index.ts re-exports)
• No prop drilling beyond 2 levels — use context or composition

### Python API-regel (Automatisk vedlagt)

```yaml
---
description: "FastAPI endpoint conventions and patterns"
globs: ["src/api/**/*.py", "src/routes/**/*.py"]
alwaysApply: false
---

# FastAPI Conventions

## Endpoint Structure
- Use APIRouter for route grouping
- Type all request/response models with Pydantic v2
- Dependency injection for database sessions

## Pattern
```python
from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.ext.asyncio import AsyncSession

router = APIRouter(prefix="/users", tags=["users"])

@router.get("/{user_id}", response_model=UserResponse)
async def get_user(
    user_id: int,
    db: AsyncSession = Depends(get_db)
) -> UserResponse:
    user = await db.get(User, user_id)
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return UserResponse.model_validate(user)

Error Handling

• Always use HTTPException, not raw Response objects
• Log errors with structlog before raising
• Return consistent error shapes: {"detail": "message"}

### Go-tjenesteregel (Automatisk vedlagt)

```yaml
---
description: "Go service patterns and error handling"
globs: ["**/*.go", "!**/*_test.go"]
alwaysApply: false
---

# Go Conventions

## Error Handling
- Always handle errors immediately — no _ for error returns
- Wrap errors with fmt.Errorf("context: %w", err)
- Use sentinel errors for expected failure cases

## Project Layout
- cmd/ for entrypoints
- internal/ for private packages
- pkg/ for public libraries

## Pattern
```go
func (s *UserService) GetByID(ctx context.Context, id string) (*User, error) {
    user, err := s.repo.Find(ctx, id)
    if err != nil {
        if errors.Is(err, ErrNotFound) {
            return nil, fmt.Errorf("user %s: %w", id, ErrNotFound)
        }
        return nil, fmt.Errorf("fetching user %s: %w", id, err)
    }
    return user, nil
}

## Håndtere tokenkostnaden

Her er noe de fleste Cursor-guider hopper over: hver regel du skriver koster tokens. Et prosjekt med 20 alltid-på regler kan brenne **over 2 000 tokens per forespørsel** bare på instruksjoner — før AI-en engang ser på koden din.

Det betyr noe fordi Cursors chat-kontekst er omtrent 20 000 tokens i standardmodus. Hvis reglene dine spiser 25 % av det, har du mistet en fjerdedel av AI-ens "tenkeplass" for det faktiske spørsmålet ditt. Du vil merke dårligere outputkvalitet etter hvert som regler hoper seg opp, spesielt i lengre samtaler.

Tre prinsipper for å holde tokenbudsjettet sunt:

**1. Bruk automatisk vedlagte og agentanmodede regler aktivt.** Bare prosjektstackdeklarasjonen bør være alltid på. Alt annet bør lastes betinget. Den React-komponentregelen? Den trenger ikke å være i kontekst når du skriver SQL-migrasjoner.

**2. Skriv tett, ikke omstendelig.** Erstatt "Det anbefales sterkt at utviklere bruker TypeScript-grensesnitt fremfor typaliaser når de definerer offentlige API-kontrakter" med "Prefer `interface` over `type` for public APIs." AI-en trenger ikke å overbevises — den trenger instruksjoner.

**3. Bruk treregelen.** Kodifiser bare et mønster som en regel etter at AI-en har gjort det feil tre ganger. Hvis Cursor allerede håndterer navnekonvensjonene dine riktig uten en regel, hopp over regelen. Hver unødvendig regel er bortkastet kontekst.

Du kan overvåke tokenbruk i statuslinjen nederst i Cursors chat-panel. Se opp når det nærmer seg 100 % — det er signalet om å rydde opp.

## Organisere regler for et ekte prosjekt

Et produksjonsprosjekt trenger vanligvis 5-8 regelfiler. Her er en struktur som fungerer bra:

```text
.cursor/rules/
  base.mdc            # Teknologistack, always-apply (< 30 linjer)
  components.mdc      # React/Vue-mønstre, glob til komponentkataloger
  api.mdc             # Backend-konvensjoner, glob til API-kataloger
  database.mdc        # ORM-mønstre, glob til models/migrations
  testing.mdc         # Testkonvensjoner, glob til testfiler
  deployment.mdc      # CI/CD-mønstre, manuell trigger
  personal.mdc        # Dine preferanser (gitignored)

Commit alt til versjonskontroll unntatt personal.mdc. Slik får hele teamet samme AI-atferd — som er hele poenget. Som en Cursor-forumbruker sier det, gode regler betyr at du "aksepterer flere forslag som de er, med output som matcher konvensjonene dine på første forsøk."

Hvis du jobber med andre AI-kodingsverktøy ved siden av Cursor, overføres konseptene direkte. Claude Code bruker CLAUDE.md, GitHub Copilot har instruksjonsfiler, og Windsurf har sitt eget format — men det underliggende prinsippet er identisk.

Slik fungerer regelprioritet

Når flere regler gjelder for samme fil, følger Cursor et tydelig hierarki:

Team Rules er tilgjengelige i Team- og Enterprise-planer. De settes i Cursor-dashboardet av administratorer og håndheves på tvers av organisasjonen — individuelle utviklere kan ikke slå dem av.

Innen prosjektregler er atferden ikke strengt definert hvis to regler gjelder for samme fil og er i konflikt. I praksis har regler som lastes senere en tendens til å ta forrang. Å nummerere filene dine (001-base.mdc, 002-components.mdc) gir forutsigbar rekkefølge.

Vanlige feil og hvordan du fikser dem

Etter å ha lest gjennom dusinvis av community-tråder og testet regler på tvers av prosjekter, er dette feilene som snubler folk mest:

Å skrive regler som er for vage. "Skriv ren kode" sier ingenting til AI-en. "Bruk navngitte eksporter, ikke standardeksporter. Strukturer komponenter som: importer, typer, funksjon, delkomponenter" gir den noe handlingsbart.

Å gjøre alt til always-apply. Den første instinkten er å sette alwaysApply: true på hver regel. Motstå det. Gjennomgå reglene dine kvartalsvis — hvis du har mer enn 2-3 alltid-på regler, sløser du sannsynligvis tokens.

Å glemme å teste regler. Etter å ha skrevet en regel, åpne en relevant fil og be Cursor generere noe som bør følge regelen. Hvis den ikke gjør det, kan glob-mønsteret ditt være feil, eller instruksjonen er ikke tydelig nok.

Å ikke dokumentere antimønstre. Å fortelle AI-en hva den skal gjøre er halvparten av jobben. Å fortelle den hva den ikke skal gjøre er den andre halvparten. Inkluder i hver regel en seksjon "GJØR ALDRI disse" med eksplisitte eksempler på feil tilnærming.

Å ignorere regellagring i UI-en. En kjent feil forårsaker at regelredigeringer forsvinner. Hvis endringer forsvinner, lukk Cursor fullstendig, velg "Override" i popup-vinduet for ulagrede endringer og åpne på nytt.

Cursor Rules vs CLAUDE.md vs AGENTS.md

Cursor er ikke det eneste verktøyet som bruker instruksjonsfiler. Slik sammenlignes formatene for alle som jobber med flere AI-kodingsassistenter:

Cursors fordel er granulariteten. CLAUDE.md og AGENTS.md er enklere — de laster alt alltid. Cursor lar deg laste de riktige reglene til riktig tid, noe som betyr noe når instruksjonssetteet ditt vokser utover noen hundre linjer.

For et dypere blikk på hvordan kontekst former AI-output i disse verktøyene, forklarer context engineering-guiden vår prinsippene som gjelder uavhengig av hvilken editor du bruker.

Hvis AI-funksjoner står på veikartet ditt, er det spesialiteten vår: Techsys AI-integrasjonsteam tar LLM-systemer fra prototype til produksjon. Vil du ha en ny vurdering av oppsettet ditt? Få en gratis konsultasjon.

Ofte stilte spørsmål

Er .cursorrules foreldet?

Ja. Den enkle .cursorrules-filen i prosjektets rotmappe fungerer fortsatt, men Cursor anbefaler å migrere til .cursor/rules/*.mdc-filer. Det nye formatet støtter glob-mønstre, betinget lasting og bedre organisering. Migrer ved å dele opp den monolittiske filen i fokuserte regler.

Hvilken filtype bør jeg bruke — .mdc eller .md?

Bruk .mdc for filer som inkluderer YAML-frontmatter (description, globs, alwaysApply). Vanlige .md-filer fungerer også i regelkatalogen, men støtter ikke frontmatter-metadata som muliggjør betinget lasting.

Hvor mange regler bør et prosjekt ha?

Fem til åtte er det optimale for de fleste prosjekter. Én alltid-på basisregel, tre til fire automatisk vedlagte regler etter filtype, og én eller to manuelle regler for spesialoppgaver. Mer enn 10 regler betyr vanligvis at noen kan konsolideres eller fjernes.

Påvirker Cursor Rules autofullføring og tabbfullføring?

Regler gjelder for chat- og agentinteraksjoner. User Rules gjelder ikke for inline-redigeringer (Cmd/Ctrl+K), og regler påvirker vanligvis ikke Cursor Tab-fullføringsforslag. De er mest effektive i chat- og Composer-sesjoner.

Kan jeg dele regler mellom flere prosjekter?

Ja, via Cursors Remote Rules-funksjon. Gå til Cursor Settings > Rules, Commands, velg "Remote Rule (GitHub)" og lim inn en repo-URL. Regler synkroniseres automatisk når kilderepoet oppdateres. Alternativt kan du vedlikeholde et delt regelrepo og symlenkere til hvert prosjekt.

Hva er den anbefalte maksimale regellengden?

Cursors dokumentasjon antyder å holde individuelle regler under 500 linjer. I praksis, sikt mot under 100 linjer per regel. Kortere regler er lettere å vedlikeholde og koster færre tokens. Hvis en regel overstiger 150 linjer, del den i to fokuserte regler.

Fungerer regler med alle AI-modeller i Cursor?

Regler fungerer med alle modeller Cursor støtter — Claude, GPT-4o, Gemini og andre. Reglene injiseres som kontekst på systemnivå uavhengig av hvilken modell du har valgt. Modellatferd kan variere, men reglene i seg selv er modellagnostiske.

Hvordan feilsøker jeg en regel som ikke fungerer?

Bekreft først at glob-mønsteret matcher filen din — åpne filen og sjekk om regelen vises i kontekstpanelen. Test deretter med et direkte spørsmål som bør utløse regelen. Prøv deretter å sette alwaysApply: true midlertidig for å bekrefte at regelinnholdet i seg selv fungerer. Hvis det gjør det, er problemet glob-mønsteret ditt.

Bør jeg committe .cursor/rules til git?

Absolutt. Hele poenget med prosjektregler er teamomfattende konsistens. Commit alt i .cursor/rules/ bortsett fra personlige preferansefiler. Legg til personal.mdc i .gitignore for individuelle innstillinger som ikke bør gjelde alle.

Kan jeg bruke Cursor Rules sammen med MCP-servere?

Ja, og de utfyller hverandre godt. Regler definerer hvordan AI-en skal skrive kode, mens MCP-servere gir AI-en tilgang til eksterne verktøy og data. En regel kan si "bruk alltid den interne API-klienten vår", mens en MCP-server lar AI-en faktisk spørre det API-et under utvikling.

Kilder

• Cursor Rules Documentation
• Trigger.dev — How to Write Great Cursor Rules
• Cursor Forum — MDC Rules Best Practices and Troubleshooting
• Peakvance — Guide to Cursor Rules: Token Tax
• awesome-cursor-rules-mdc on GitHub