Slik bruker du rules i Claude Code

Rules er instruksjoner som bare lastes når Claude Code jobber med bestemte filer. Lær å lage en regel med paths, teste at Claude følger den, og se den i /context.

Publisert

Utdrag fra nettkurset «Claude Code – komplett guide»Av

Kodebasen din er på engelsk, men alt brukeren ser skal være på norsk. Du har skrevet det i CLAUDE.md. Likevel dukker det opp en engelsk knappetekst innimellom, gjerne når oppgaven du ga var på engelsk. Instruksjonen druknet i alt det andre som ligger i rotfilen. Det er problemet rules løser.

En rule er en markdown-fil med instruksjoner til Claude, lagret i mappen .claude/rules. I stedet for å legge alle instruksjonene i CLAUDE.md, deler du dem opp i egne filer: én for testing, én for kodeformat, én for sikkerhet. Det gjør dem lettere å organisere og vedlikeholde, særlig i større prosjekter.

Regler som bare gjelder der de trengs

Det som gjør rules kraftige, er at du kan styre når de kommer inn i konteksten. Uten noe spesielt lastes regelen når økten starter, og gjelder prosjektet generelt. Gir du regelen paths, altså stier eller filmønstre, kommer den først inn når Claude begynner å jobbe med de filene.

Forskjellen fra settings.json er nivået. Settings.json gjelder hele prosjektet overordnet, som å se helheten i en pasient. Rules er kirurgens presise verktøy, for konsentrerte tilfeller. Og forskjellen fra CLAUDE.md er at regelen ikke tar plass i konteksten før den er relevant.

Slik lager du din første rule i Claude Code

I kurset er regelen enkel: all tekst brukeren ser i grensesnittet skal være på norsk, aldri engelsk. Den er bare relevant for filer som lager grensesnittet, og i dette prosjektet ligger de i mappene app og components.

  1. Opprett mappen rules inne i .claude.
  2. Start en ny økt. Oppgaven er lett, så medium tenkenivå holder, og modusen kan stå på Auto.
  3. Skriv: «Opprett en rule for dette prosjektet som sier at all tekst brukeren ser i grensesnittet skal være på norsk. Regelen skal bare gjelde TSX-filer i app og components. Legg regelen i .claude/rules med et kort og beskrivende filnavn, og ikke endre andre filer.»
  4. Åpne filen når Claude er ferdig. Den starter med en beskrivelse og et felt for paths eller globs, og deretter selve regelen.

Kjenner du ikke prosjektet godt nok til å vite hvilke mapper som gjelder, kan du be Claude finne det ut. Den lander som regel på det samme.

Test at Claude følger regelen

Den beste testen er å gi en oppgave som frister til å bryte regelen. I kurset skrives hele oppgaven på engelsk: legg til et tredje kort på innloggingssiden, for gjester, som forklarer at de kan bla i samlingen uten å logge inn, med en knapp til forsiden. Velg passende tekst selv.

Resultatet kommer på norsk, selv om oppgaven var på engelsk. Vil du se at regelen faktisk ble lastet, kjører du /context. Under minnefiler står regelen oppført, i kurset som «Norwegian UI text». Da vet du at den kom inn fordi Claude jobbet med filer under app.

Tips: Lag regler for ting Claude burde forstått selv, men ikke alltid gjør. Språk i grensesnittet, hvilke komponenter som skal brukes, hva som aldri skal endres uten å spørre. Det er der en rule gir mest igjen for tre linjer tekst.

Hva som hører hjemme i en rule

En god rule er kort, gjelder et avgrenset område, og sier noe Claude ikke kan lese ut av koden selv. Konvensjoner for tester i testmappen. Hvilke designtokens som skal brukes i komponenter. At datatabeller alltid skal ha lenken på tittelteksten, ikke hele cellen. Instruksjoner som gjelder hele prosjektet, som hvilke kommandoer som finnes, hører derimot hjemme i CLAUDE.md, og det Claude aldri får gjøre uten å spørre, hører hjemme i settings.json.

Blir en rule lang, er det et tegn på at den dekker to ting. Del den. Flere små regler med presise paths er lettere å vedlikeholde enn én stor, og de tar mindre plass i konteksten fordi hver av dem bare lastes når den trengs.

En liten Git-lærdom fra kurset

Etter regelen ba kursholderen Claude committe, og tok for gitt at det gikk til master. Det gjorde det ikke. Claude hadde opprettet en egen gren, og først et direkte spørsmål, «er disse endringene pushet til master?», avslørte det. Slikt er ikke uvanlig. På Utdannet.no er løsningen en egen commit-skill som beskriver nøyaktig hvordan commits skal gjøres, hver gang. Har du en fast måte å ville ha det på, er en skill riktig sted, ikke en påminnelse i hver økt.

Neste steg

Tillatelsene som avgjør hva Claude får gjøre uten å spørre, ligger i settings.json. Arbeidsmåter du gjentar, som commit-flyten ovenfor, hører hjemme i en skill, se Slik lager du din egen skill i Claude Code. Og hvordan rules, CLAUDE.md og docs utfyller hverandre, får du i Slik bevarer du kunnskap mellom økter i Claude Code.

Denne videoen er hentet fra kurset Claude Code – komplett guide på Utdannet.no. I det fulle kurset lager du regelen, tester den med en engelsk oppgave og verifiserer med /context, før du går videre til skills, hooks og MCP i samme prosjekt.

Om kursholderen

Espen Faugstad kursholder hos Utdannet.no

Gründer av Utdannet.no

Ekspert på digital kompetanse med over 160 nettkurs – fra Google Ads og Analytics til Adobe-programmer og kunstig intelligens. Gründer av Utdannet.no og en av Norges mest erfarne formidlere av digital læring, med over 1,5 millioner videoavspillinger. Har levert kurs og opplæring for virksomheter som NKI, NITO, NHO, NAV, Polaris Media og Adresseavisen. Forfatter av læreboken «Lær Photoshop i en fei» utgitt på Fagbokforlaget i 2015. Kursene er bygget på praktisk læring med konkrete eksempler – tilpasset både nybegynnere og viderekomne.