Cursor Rules: Hur man skriver .cursor/rules-filer som faktiskt fungerar

Varje Cursor-användare stöter förr eller senare på samma hinder. AI:n genererar kod som tekniskt sett fungerar men ignorerar projektets konventioner — fel importsökvägar, föråldrade mönster, komponenter som inte liknar något annat i kodbasen. Cursor Rules löser det genom att ge AI:n bestående kontext om hur ditt projekt fungerar.

Vad är Cursor Rules och varför spelar de roll?

Cursor Rules är Markdown-filer som fungerar som en permanent systemprompt som injiceras före varje AI-interaktion — chatt, autokomplettering, kodgenerering, allt. Tänk på dem som onboardingdokumentation för AI:n. Istället för att rätta samma misstag varje session skriver du instruktionen en gång och den håller.

Det gamla upplägget var en enda .cursorrules-fil i projektets rotkatalog. Det fungerar fortfarande, men är föråldrat. Det nuvarande systemet använder en .cursor/rules/-katalog med individuella .mdc-filer (Markdown Cursor), var och en anpassad till specifika situationer. Det är ett mycket bättre upplägg eftersom du inte behöver stoppa in alla instruktioner i en enda jättefil — du delar upp regler efter ansvar och Cursor laddar bara de som är relevanta för vad du gör just nu.

Om du har jobbat med context engineering för AI-verktyg, är konceptet bekant: bättre inputkontext ger dramatiskt bättre output. Rules är context engineering för hela ditt utvecklingsflöde.

Sätta upp din första regelfil

Skapa katalogen .cursor/rules/ i projektets rotkatalog:

mkdir -p .cursor/rules

Varje regel är en .mdc-fil med YAML-frontmatter följt av Markdown-innehåll. Här är skelettet:

---
description: "När den här regeln ska gälla"
globs: ["src/components/**/*.tsx"]
alwaysApply: false
---

Dina instruktioner går här i vanlig Markdown.

Tre frontmatter-fält styr allt:

Du kan också skapa regler direkt i Cursor — skriv /create-rule i chatten och beskriv vad du vill ha. Men att skriva dem för hand ger dig mer kontroll.

De fyra regeltyperna förklarade

Hur en regel aktiveras beror på dess frontmatter-konfiguration. Det finns fyra lägen, och att välja rätt spelar roll för ditt kontextfönsterbudget.

Alltid tillämpa

---
alwaysApply: true
---

Laddas i varje enskild AI-förfrågan. Använd detta sparsamt — för projektövergripande grundläggande saker som din teknikstack-deklaration eller kritiska konventioner som gäller överallt. Varje alltid-på regel äter tokens från varje interaktion, oavsett om den är relevant eller inte.

Automatiskt bifogad (glob-baserad)

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

Aktiveras bara när du redigerar filer som matchar glob-mönstren. Det här är den viktigaste regeltypen. Dina React-komponentkonventioner laddas när du är i komponentfiler, dina API-mönster när du är i route-handlers, dina testregler när du skriver tester.

Agentbegärd (intelligent)

---
description: "Databamigrationsmönster med Drizzle ORM"
alwaysApply: false
---

Inga glob, inget always-apply — bara en beskrivning. Cursors agent läser beskrivningen och avgör om regeln är relevant för den aktuella uppgiften. Om du ber den skriva en migration laddar den den här regeln. Om du stylar en knapp hoppar den över den. Det fungerar förvånansvärt bra för regler som inte neatly mappar till filsökvägar.

Manuell

---
---

Inga frontmatter-fält inställda (eller tomt frontmatter). Dessa regler aktiveras bara när du explicit nämner dem med @regelnamn i chatten. Bra för sällan använda men viktiga instruktioner — som deployment-checklistor eller refaktoreringsguider du bara behöver ibland.

Glob-mönster som faktiskt fungerar

Glob avgör vilka filer som utlöser automatiskt bifogade regler. Fel konfigurerade och dina regler utlöses antingen aldrig eller överallt. Det här fungerar:

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

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

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

# Flera specifika kataloger
globs: ["src/api/**", "src/services/**"]

Några fallgropar från verklig användning:

• src/* matchar bara en katalognivå. Du vill nästan alltid ha src/**/* för rekursiv matchning.
• *.js matchar inte .jsx- eller .ts-filer. Var explicit om filtyper.
• Glob måste vara en YAML-lista. Klammersynax som {src,lib}/**/*.ts kan misslyckas tyst — använd separata listposter istället.
• Prefixet ! exkluderar mönster, vilket är användbart för att ignorera genererade filer eller legacy-kod.

Praktiska regelexempel

Här möts teori och verklighet. Det här är regler du kan lägga till i ett projekt och omedelbart se bättre AI-output.

Projektövergripande basregel (Alltid tillämpa)

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

Håll det under 30 rader. Det laddas med varje förfrågan, så varje ord kostar tokens.

React-komponentregel (Automatiskt bifogad)

---
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 (Automatiskt bifogad)

```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-tjänsteregel (Automatiskt bifogad)

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

## Hantera tokenkostnaden

Det här är något som de flesta Cursor-guider hoppar över: varje regel du skriver kostar tokens. Ett projekt med 20 alltid-på regler kan bränna **över 2 000 tokens per förfrågan** bara på instruktioner — innan AI:n ens tittar på din kod.

Det spelar roll eftersom Cursors chattkontext är ungefär 20 000 tokens i standardläge. Om dina regler äter upp 25 % av det har du förlorat en fjärdedel av AI:ns "tänkutrymme" för din faktiska fråga. Du märker sämre outputkvalitet när regler hopas, särskilt i längre konversationer.

Tre principer för att hålla tokenbudgeten sund:

**1. Använd automatiskt bifogade och agentbegärda regler frikostigt.** Bara din projektstackdeklaration bör vara alltid på. Allt annat bör laddas villkorligt. Den React-komponentregeln? Den behöver inte finnas i kontext när du skriver SQL-migrationer.

**2. Skriv tätt, inte omständligt.** Ersätt "Det rekommenderas starkt att utvecklare använder TypeScript-interface istället för typaliaser när de definierar offentliga API-kontrakt" med "Prefer `interface` over `type` for public APIs." AI:n behöver inte övertalas — den behöver instruktioner.

**3. Tillämpa treregeln.** Kodifiera bara ett mönster som en regel efter att AI:n gjort fel tre gånger. Om Cursor redan hanterar dina namnkonventioner rätt utan en regel, hoppa över regeln. Varje onödig regel är bortkastad kontext.

Du kan övervaka tokenanvändningen i statusfältet längst ner på Cursors chattfönster. Håll koll när det närmar sig 100 % — det är signalen att rensa.

## Organisera regler för ett riktigt projekt

Ett produktionsprojekt behöver typiskt 5-8 regelfiler. Här är en struktur som fungerar bra:

```text
.cursor/rules/
  base.mdc            # Teknikstack, always-apply (< 30 rader)
  components.mdc      # React/Vue-mönster, glob till komponentkataloger
  api.mdc             # Backend-konventioner, glob till API-kataloger
  database.mdc        # ORM-mönster, glob till models/migrations
  testing.mdc         # Testkonventioner, glob till testfiler
  deployment.mdc      # CI/CD-mönster, manuell trigger
  personal.mdc        # Dina preferenser (gitignored)

Committa allt till versionshantering utom personal.mdc. På så vis får hela teamet samma AI-beteende — vilket är hela poängen. Som en Cursor-forumanvändare uttrycker det, bra regler innebär att du "accepterar fler förslag som de är, med output som matchar dina konventioner vid första försöket."

Om du jobbar med andra AI-kodningsverktyg vid sidan av Cursor, överförs koncepten direkt. Claude Code använder CLAUDE.md, GitHub Copilot har instruktionsfiler och Windsurf har sitt eget format — men det underliggande principen är identisk.

Hur regelprioritet fungerar

När flera regler gäller för samma fil följer Cursor en tydlig hierarki:

Team Rules finns tillgängliga i Team- och Enterprise-planer. De ställs in i Cursor-dashboarden av administratörer och tillämpas i hela organisationen — enskilda utvecklare kan inte stänga av dem.

Inom projektregler är beteendet inte strikt definierat om två regler gäller för samma fil och är i konflikt. I praktiken tenderar senare laddade regler att ha företräde. Att numrera dina filer (001-base.mdc, 002-components.mdc) ger förutsägbar ordning.

Om AI-funktioner finns på er roadmap är det vår specialitet: Techsys AI-integrationsteam tar LLM-system från prototyp till produktion. Vill du ha en second opinion på er stack? Boka en kostnadsfri konsultation.

Vanliga misstag och hur man fixar dem

Efter att ha läst igenom dussintals communitytrådar och testat regler i olika projekt, är det här misstagen som mest snubblar folk:

Skriva regler som är för vaga. "Skriv ren kod" säger ingenting till AI:n. "Använd namngivna exporter, inte standardexporter. Strukturera komponenter som: importer, typer, funktion, delkomponenter" ger den något handlingsbart.

Göra allt till always-apply. Första instinkten är att sätta alwaysApply: true på varje regel. Motstå det. Granska dina regler kvartalsvis — om du har mer än 2-3 alltid-på regler slösar du förmodligen tokens.

Glömma att testa regler. Efter att ha skrivit en regel, öppna en relevant fil och be Cursor generera något som borde följa regeln. Om det inte gör det kan ditt glob-mönster vara fel, eller instruktionen tillräckligt tydlig.

Inte dokumentera antimönster. Att berätta för AI:n vad den ska göra är halva jobbet. Att berätta vad den inte ska göra är den andra hälften. Inkludera i varje regel ett avsnitt "GÖR ALDRIG dessa" med explicita exempel på fel tillvägagångssätt.

Ignorera regelspara i UI:n. En känd bugg gör att regelredigeringar försvinner. Om ändringar försvinner, stäng Cursor helt, välj "Override" i popup-fönstret för osparade ändringar och öppna på nytt.

Cursor Rules vs CLAUDE.md vs AGENTS.md

Cursor är inte det enda verktyget som använder instruktionsfiler. Så här jämförs formaten för den som jobbar med flera AI-kodningsassistenter:

Cursors fördel är granulariteten. CLAUDE.md och AGENTS.md är enklare — de laddar allt alltid. Cursor låter dig ladda rätt regler vid rätt tidpunkt, vilket spelar roll när din instruktionsuppsättning växer bortom ett par hundra rader.

För en djupare titt på hur kontext formar AI-output i dessa verktyg förklarar vår guide om context engineering principerna som gäller oavsett vilken editor du använder.

Vanliga frågor

Är .cursorrules föråldrat?

Ja. Den enda .cursorrules-filen i projektets rotkatalog fungerar fortfarande, men Cursor rekommenderar att migrera till .cursor/rules/*.mdc-filer. Det nya formatet stöder glob-mönster, villkorlig laddning och bättre organisation. Migrera genom att dela upp din monolitiska fil i fokuserade regler.

Vilken filändelse ska jag använda — .mdc eller .md?

Använd .mdc för filer som inkluderar YAML-frontmatter (description, globs, alwaysApply). Vanliga .md-filer fungerar också i reglerkatalogen men stöder inte frontmatter-metadata som möjliggör villkorlig laddning.

Hur många regler bör ett projekt ha?

Fem till åtta är det optimala för de flesta projekt. En alltid-på basregel, tre till fyra automatiskt bifogade regler efter filtyp och en eller två manuella regler för specialuppgifter. Mer än 10 regler innebär vanligtvis att några kan konsolideras eller tas bort.

Påverkar Cursor Rules autokomplettering och tabbkomplettering?

Regler gäller för chatt- och agentinteraktioner. User Rules gäller inte för inline-redigeringar (Cmd/Ctrl+K), och regler påverkar i allmänhet inte Cursor Tab-kompletteringsförslag. De är mest effektiva i chatt- och Composer-sessioner.

Kan jag dela regler mellan flera projekt?

Ja, via Cursors Remote Rules-funktion. Gå till Cursor Settings > Rules, Commands, välj "Remote Rule (GitHub)" och klistra in en repo-URL. Regler synkroniseras automatiskt när källrepon uppdateras. Alternativt kan du underhålla ett delat regelrepo och symlänka till varje projekt.

Vad är den maximalt rekommenderade regellängden?

Cursors dokumentation föreslår att hålla enskilda regler under 500 rader. I praktiken, sikta på under 100 rader per regel. Kortare regler är lättare att underhålla och kostar färre tokens. Om en regel överstiger 150 rader, dela upp den i två fokuserade regler.

Fungerar regler med alla AI-modeller i Cursor?

Regler fungerar med alla modeller som Cursor stöder — Claude, GPT-4o, Gemini och andra. Reglerna injiceras som kontext på systemnivå oavsett vilken modell du har valt. Modellbeteendet kan variera, men reglerna i sig är modellagnostiska.

Hur felsöker jag en regel som inte fungerar?

Verifiera först att glob-mönstret matchar din fil — öppna filen och kontrollera om regeln visas i kontextpanelen. Testa sedan med en direkt fråga som borde utlösa regeln. Prova sedan att sätta alwaysApply: true tillfälligt för att bekräfta att regelinnehållet i sig fungerar. Om det gör det, är problemet ditt glob-mönster.

Ska jag committa .cursor/rules till git?

Absolut. Hela poängen med projektregler är teamövergripande konsekvens. Committa allt i .cursor/rules/ utom personliga preferensfiler. Lägg till personal.mdc i .gitignore för individuella inställningar som inte ska gälla alla.

Kan jag använda Cursor Rules tillsammans med MCP-servrar?

Ja, och de kompletterar varandra väl. Regler definierar hur AI:n ska skriva kod, medan MCP-servrar ger AI:n tillgång till externa verktyg och data. En regel kanske säger "använd alltid vår interna API-klient", medan en MCP-server låter AI:n faktiskt fråga det API:et under utveckling.

Källor

• 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