Den komplette guiden til å skrive systemprompter for agenter — Lærdommer fra reverse-engineering av Claude Code

Title: Det pågår en massevrangforestilling i AI-verdenen akkurat nå.

Content: Det pågår en massevrangforestilling i AI-verdenen akkurat nå.

Hver eneste tutorial forteller deg at du må skrive system-prompts som om du kaster en trylleformel — bare du finner den rette besvergelsen, vil modellen adlyde. "Du er en EKSTREMT DYKTIG seniorutvikler med 20 års erfaring..." Høres det kjent ut?

De siste månedene har jeg bygget VibeCom, en AI-rådgiver for startups som kjører dype markedsundersøkelser og genererer analyser på VC-nivå. På veien dit har jeg reverskonstruert Claude Codes system-prompt, lest gjennom kildekoden til DeepAgents' middleware, og svidd av flere API-credits enn jeg liker å innrømme. Den største lærdommen? Det meste av det folk tror er viktig med system-prompts, betyr ingenting. Og de tingene som faktisk betyr noe, er det nesten ingen som snakker om.

Dette innlegget er den komplette dreieboken — ikke en 5-minutters oversikt, men alt jeg skulle ønske noen hadde fortalt meg før jeg startet. Hent deg en kaffe.

---

1. Designfilosofi: Stol på modellen

"An agent is a model. Not a framework. Not a prompt chain." — shareAI-lab/learn-claude-code

Denne tankegangen endret alt for meg. LLM-en vet allerede hvordan den skal resonnere, planlegge og utføre. System-promptet ditt skal ikke lære den å tenke — det skal sette opp miljøet den skal jobbe i.

Tenk på det som å ansette en seniorutvikler. Du gir dem ikke en sjekkliste på 20 punkter for hver eneste oppgave. Du forteller dem: her er hvem vi er, her er grensene, her er definisjonen på godt arbeid. Så flytter du deg ut av veien.

System-promptet ditt har nøyaktig fire jobber:

• Fortell den hvem den er — rolle og identitet
• Fortell den hvor veggene er — sikkerhetsbegrensninger
• Fortell den hvordan bra ser ut — kvalitetsstandarder
• Gi den verktøy — kapabiliteter og kunnskap

Det er det. Alt annet er støy.

Harness-tankegangen

Harness = Tools + Knowledge + Observation + Action Interfaces + Permissions

System-promptet ditt er brukermanualen for dette "seletøyet" (harness). Du designer ikke en rigid pipeline — du designer et miljø hvor modellen kan gjøre sitt beste arbeid autonomt.

Ikke skriv system-promptet ditt som et flytskjema. Modellen vil selv bestemme utførelsesrekkefølgen.

---

2. Prompt-struktur og rekkefølge

Den anbefalte layouten (Reverskonstruert fra Claude Code v2.0.14)

┌─────────────────────────────────────────────┐
│ 1. Identity                                  │  ← Leses først, forankrer adferd
│ 2. Security & Safety                         │  ← VIKTIGE markører, ufravikelig
│ 3. Tone & Style                              │  ← Kontrollerer output-format
│ 4. Core Workflow                             │  ← Hvordan jobben skal gjøres
│ 5. Tool Usage Policy                         │  ← Prioritering av verktøy
│ 6. Domain Knowledge                          │  ← På forespørsel, ikke forhåndslastet
│ 7. Environment Info                          │  ← Runtime-kontekst, injiseres dynamisk
│ 8. Reminders                                 │  ← Gjenta kritiske regler
├─────────────────────────────────────────────┤
│ [Tool Definitions — system-injected]         │  ← Kan ikke redigeres, ofte veldig lange
├─────────────────────────────────────────────┤
│ [User Message]                               │
└─────────────────────────────────────────────┘

Hvorfor denne rekkefølgen er viktig

LLM-er har en U-formet oppmerksomhetskurve — de følger best med på begynnelsen og slutten av promptet ditt, og mister fokus i midten. Dette er den veldokumenterte "Lost in the Middle"-effekten.

• Identitet + Sikkerhet på toppen: Modellen etablerer rolle og grenser først (primacy-effekten)
• Core Workflow i øvre midtdel: Din viktigste seksjon — hvordan agenten gjør jobben sin
• Verktøydefinisjoner injiseres av systemet etter promptet ditt: Claude Codes verktøydefinisjoner spiser ~11 438 tokens. Dette betyr at ditt tilpassede innhold faktisk havner nærmere begynnelsen enn du kanskje tror — noe som hjelper på etterlevelsen
• Påminnelser i bunnen: Utnytt recency bias for å forsterke kritiske regler

---

3. Hvordan skrive hver seksjon

3.1 Identitet — Hvem er denne agenten?

Mål: Forankre modellens rolle på 1-3 setninger.

You are Claude Code, Anthropic's official CLI for Claude.
You are an interactive agent that helps users with software engineering tasks.

Retningslinjer:

• Hold det kort — maks 1-3 setninger
• Navngi rollen eksplisitt (hjelper modellen med å skille kontekster)
• Oppgi kjerneansvaret ("hjelper med X"), ikke et vagt "du er en hjelpsom assistent"
• Nevn SDK/plattform hvis relevant ("bygget på Anthropic's Claude Agent SDK")

Anti-patterns:

• "Du er en hjelpsom, ufarlig og ærlig AI-assistent" — for generisk, ingen rolleforankring
• Et helt avsnitt med bakhistorie og "lore" — kaster bort tokens, modellen trenger ikke karakterutvikling

3.2 Sikkerhet & Trygghet — De absolutte grensene

Mål: Sett ufravikelige adferdsbegrensninger.

IMPORTANT: Assist with defensive security tasks only.
Refuse to create, modify, or improve code that may be used maliciously.
IMPORTANT: You must NEVER generate or guess URLs for the user.

Retningslinjer:

• Bruk IMPORTANT:-prefikset — Claudes trening på instruksjonshierarki gir dette ekstra vekt
• Bruk absolutt språk: NEVER, MUST NOT, Refuse to
• Oppgi både hva som er tillatt OG hva som er forbudt (toveis begrensninger er tydeligere)
• Plasser helt på toppen, ikke begrav det i midten
• Gjenta kritiske sikkerhetsregler til slutt — Claude Code gjør nøyaktig dette

Hvorfor gjenta? Primacy-effekt (begynnelse) + Recency-effekt (slutt) = dobbel forsterkning. Claude Codes sikkerhetserklæring dukker opp både i starten og slutten av promptet. Ikke fordi ingeniørene var glemske — men fordi de forstår den U-formede oppmerksomhetskurven.

3.3 Tone & Stil — Kontroll over output

Mål: Kontroller output-format og stemme.

## Tone and style

- Your responses should be short and concise.
- Only use emojis if the user explicitly requests it.
- Use Github-flavored markdown for formatting.
- NEVER create files unless absolutely necessary.

Retningslinjer:

• List opp spesifikke adferder, ikke et vagt "vær profesjonell"
• Hver regel bør kunne testes som sann/usann ("kort og konsis" vs. "prøv å være kortfattet")
• Inkluder krav til output-format (markdown? JSON? ren tekst?)
• Inkluder hva den IKKE skal gjøre — mange stilproblemer handler om å forby adferd

Claude Codes genistrek — Profesjonell objektivitet:

Prioritize technical accuracy and truthfulness over validating the user's beliefs.
Focus on facts and problem-solving, providing direct, objective technical info
without any unnecessary superlatives, praise, or emotional validation.

Dette avsnittet er avgjørende: det blokkerer modellens tendens til å være en "ja-maskin" (sycophancy). Hvis agenten din skal gi objektive vurderinger (code review, idé-evaluering, arkitekturvalg), trenger du absolutt en lignende klausul.

3.4 Core Workflow — Den viktigste seksjonen

Mål: Lær modellen hvordan den skal jobbe — metodikk, ikke rigide prosedyrer.

Dette er den vanskeligste seksjonen å skrive godt, og den som gir størst effekt når du treffer blink.

Kjerneprinsippet: gi prinsipper, ikke prosedyrer.

Fortell LLM-en hvordan god output ser ut og hvorfor det er bra — la den selv finne ut hvordan den kommer dit. Unngå å diktere nøyaktig antall felt, trinnsekvenser eller formater, med mindre outputen skal konsumeres av maskiner nedstrøms.

Claude Codes tilnærming:

## Doing tasks

The user will primarily request software engineering tasks.
For these tasks the following steps are recommended:

- Use the TodoWrite tool to plan the task if required

Legg merke til ordet "recommended" — ikke "du må følge disse nøyaktige trinnene". Det ene ordvalget gir modellen rom til å tilpasse seg.

En god workflow-definisjon:

1. Understand first — read existing code before modifying it
2. Plan first — break complex tasks into steps before executing
3. Minimal changes — only change what's necessary, don't "refactor while you're in there"
4. Verify — confirm your changes work (run tests, lint, etc.)

Hver regel har et implisitt "hvorfor" — modellen kan forstå intensjonen og generalisere til nye scenarioer.

Anti-patterns:

• En rigid 20-trinns prosedyre — modellen vil utføre den mekanisk og fryse ved uventet input
• "Først gjør A, så gjør B, så gjør C" — det er en prompt chain, ikke et agent-prompt
• Å overstyre ting LLM-en allerede er god på — kaster bort tokens

Jeg lærte dette på den harde måten med VibeCom. Tidlige versjoner hadde en 10-trinns research-workflow. Modellen utførte pliktoppfyllende alle 10 trinnene selv når trinn 3 allerede hadde besvart brukerens spørsmål. Da jeg byttet til prinsipper ("gjør research til du har tilstrekkelig bevis, deretter syntetiser"), gikk kvaliteten opp og token-kostnadene ned.

Unntaket: Når output skal konsumeres av maskiner nedstrøms (inter-agent kommunikasjon, API-responsformater), bør du definere strenge formater. Prinsipper er for adferd; skjemaer er for grensesnitt.

3.5 Retningslinjer for verktøybruk — Håndtere tvetydighet

Mål: Når flere verktøy kan gjøre det samme, fortell modellen hvilket den skal foretrekke.

## Tool usage policy

- Use specialized tools instead of bash commands:
  - Read for reading files instead of cat/head/tail
  - Edit for editing instead of sed/awk
  - Grep for searching instead of grep/rg
- You can call multiple tools in a single response. If independent, call in parallel.
- Use the Task tool for file search to reduce context usage.

Retningslinjer:

• Bruk "instead of" for å uttrykke prioritet (A i stedet for B)
• Forklar hvorfor den bør foretrekke visse verktøy ("gir en bedre brukeropplevelse", "reduserer kontekstbruk")
• Definer strategi for parallellisme (uavhengig → parallell, avhengig → sekvensiell)
• List opp sikkerhetsbegrensninger for verktøybruk (validering av filstier, tilgangssjekker)

Det avgjørende forholdet mellom verktøy og prompts:

Verktøydefinisjoner injiseres typisk av systemet, og du kan ikke redigere dem direkte. Claude Codes verktøydefinisjoner er på ~11 438 tokens. Dette betyr:

• Ikke gjenta informasjon som allerede finnes i verktøydefinisjonene
• Bruk system-promptet for strategisk veiledning: når man skal bruke hvert verktøy, hvorfor man skal foretrekke ett fremfor et annet, prioriteringsrekkefølge
• Kvaliteten på verktøydefinisjonene påvirker agentens effektivitet direkte — hvis du bygger din egen agent, invester tid i å skrive utmerkede verktøybeskrivelser

3.6 Domenekunnskap — Last inn ved behov, ikke på forhånd

Mål: Tilby spesialisert kunnskap som modellens treningsdata kanskje mangler.

Kjerneprinsippet: progressiv tilgjengeliggjøring, ikke kunnskapsdumping.

❌ Lim inn alle 200 API-endepunkter i system-promptet → token-eksplosjon
✅ Gi modellen et verktøy for å slå opp ting → "Last inn kunnskap når du trenger det"

Denne strategien deles av Claude Codes Skills-system og DeepAgents' Progressive Disclosure middleware. Begge laster kunnskap ved behov gjennom verktøykall i stedet for å forhåndslaste alt.

Implementeringstilnærminger:

1. Legg inn pekere i system-promptet: "Bruk get_api_docs-verktøyet for å hente dokumentasjon ved behov"
2. Bruk CLAUDE.md / AGENTS.md for prosjektkontekst — lastes ved runtime, ikke hardkodet
3. Bruk Skills / SKILL.md for oppdagelse av kapabiliteter — modellen ser en meny av tilgjengelige ferdigheter, og henter fulle spesifikasjoner ved behov

3.7 Miljøinformasjon — Runtime-kontekst

Mål: Gi modellen bevissthet om sitt eget kjøretidsmiljø.

<env>
Working directory: /Users/fengliu/Desktop/tfm/vibecom
Is directory a git repo: true
Platform: darwin
Today's date: 2026-03-21
</env>
You are powered by the model named Claude Opus 4.6.

Retningslinjer:

• Generer dynamisk, aldri hardkod
• Inkluder: arbeidsmappe, plattform, dato, modellnavn, git-status
• Bruk strukturert format (XML-tags eller kodeblokker) for enkel parsing
• Dato er viktig — modellen må vite hva "nå" er for å vurdere hvor fersk informasjonen er

3.8 Påminnelser — Den siste forsterkningen

Mål: Gjenta de mest kritiske reglene på slutten av promptet.

Claude Code gjentar sin sikkerhetsbegrensning og TodoWrite-krav i bunnen:

IMPORTANT: Assist with defensive security tasks only. [repeated]
IMPORTANT: Always use the TodoWrite tool to plan and track tasks. [repeated]

Retningslinjer:

• Gjenta kun 2-3 av de aller viktigste reglene — ikke dupliser alt
• Utnytt recency bias — modellen husker nylig innhold mye bedre
• Beste kandidater: sikkerhetsbegrensninger, regler som oftest brytes, påminnelser om core workflow

---

4. Token-budsjett og konteksthåndtering

Referanse for budsjettallokering

Seksjon	Anbefalte Tokens	Notater
Identity + Safety	200-500	Kortfattet, men ufravikelig
Tone & Style	300-800	Regler må være spesifikke, men ikke bable
Core Workflow	500-2 000	Viktigste seksjon, verdt investeringen
Tool Usage Policy	300-1 000	Avhenger av antall verktøy
Domain Knowledge	0-1 000	Innlasting ved behov foretrekkes
Environment Info	100-300	Genereres dynamisk
Reminders	100-300	Gjenta kun det essensielle
Din total	1 500-6 000
Tool Definitions (system)	5 000-15 000	Utenfor din kontroll

Kurve for kontekstforringelse

Testing i miljøet (Reddit u/CodeMonke_) har kartlagt hvordan etterlevelsen faktisk forringes i praksis:

• < 80K tokens: Prompt-etterlevelsen holder seg stabil
• 80K - 120K tokens: Evnen til å følge instruksjoner begynner å forringes
• > 120K tokens: Betydelig forringelse — modellen "glemmer" tidlige instruksjoner
• > 180K tokens: Alvorlig forringelse

Ditt 200K kontekstvindu ≠ 200K med effektiv kontekst. Planlegg deretter.

Avbøtende strategier:

• Hold system-promptet ditt slankt (< 6 000 tokens for din del)
• Bruk oppsummering for å komprimere samtalehistorikken (DeepAgents utløses ved ~80K tegn)
• Plasser kritiske regler i begge ender av promptet (U-formet oppmerksomhet)
• Injiser <system-reminder>-tags midt i samtalen (mer om dette i seksjon 8)

---

5. Skriveprinsipper

5.1 Gi prinsipper, ikke prosedyrer

❌ "Step 1: Read the file. Step 2: Find the bug. Step 3: Fix it. Step 4: Run tests."
✅ "Always understand existing code before modifying it. Verify your changes work."

Prinsipper generaliserer. Prosedyrer kan bare følges mekanisk. Når modellen møter en situasjon du ikke forutså, guider prinsipper den til riktig beslutning. Prosedyrer gjør ikke det.

Unntak: Når output konsumeres av maskiner (inter-agent kommunikasjon, API-formater), definer strenge skjemaer.

5.2 Bruk absolutt språk for harde grenser

Styrke	Språk	Brukes til
Absolutt forbud	NEVER, MUST NOT	Sikkerhet, irreversible operasjoner
Sterkt krav	ALWAYS, MUST	Core workflow-regler
Anbefaling	recommended, prefer	Best practices med unntak
Forslag	consider, you may	Valgfrie optimaliseringer

Eksempler fra Claude Code:

• NEVER update the git config — absolutt forbud
• ALWAYS prefer editing an existing file — sterkt, men unntak finnes
• The following steps are recommended — foreslått workflow

5.3 Bruk eksempler i stedet for forklaringer

## Code References

When referencing specific functions or pieces of code include
the pattern `file_path:line_number`.

<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer`
function in src/services/process.ts:712.
</example>

Ett eksempel lærer bort mer enn 100 ord med forklaring:

• Modeller lærer mønstre fra eksempler mer pålitelig enn fra abstrakte beskrivelser
• Pakk inn med <example>-tags for å skille dem fra regler
• Gi både positive ("gjør dette") og negative ("ikke gjør dette") eksempler
• Bruk ekte, spesifikke eksempler — ikke "foo/bar"-placeholdere

5.4 Toveis begrensninger

✅ "Use dedicated tools: Read for reading files, Edit for editing files."
✅ "Do NOT use bash for file operations (cat, head, tail, sed, awk)."

Å bare si "gjør dette" → modellen vet ikke når den IKKE skal gjøre det. Å bare si "ikke gjør dette" → modellen vet ikke hva alternativet er. Toveis → tydelig og utvetydig.

5.5 Forklar hvorfor, ikke bare hva

❌ "Don't use git commit --amend."
✅ "Avoid git commit --amend. ONLY use --amend when either
   (1) user explicitly requested amend OR
   (2) adding edits from pre-commit hook.
   Reason: amending may overwrite others' commits."

Å forklare hvorfor lar modellen ta riktige vurderinger i edge-cases. Claude Codes git-sikkerhetsprotokoll er en masterclass — hver regel impliserer sin egen rasjonale.

5.6 Struktur over prosa

• Markdown-overskrifter (##, ###) — modeller gjenkjenner hierarki
• Punktlister fremfor avsnitt — hver regel kan testes uavhengig
• XML-tags for spesielt innhold: <example>, <env>, <system-reminder>
• Tabeller for sammenligninger og mapping
• Dump aldri ustrukturert tekst — strukturerte prompts utkonkurrerer konsekvent naturlig språk i etterlevelsestester

---

6. Anti-patterns som kaster bort tokens

Prompt-chains forkledd som agenter

"First call tool A to get data.
Then call tool B with the result.
Then format the output as JSON.
Then save to file."

Dette er ikke et agent-prompt — det er et pipeline-script. Modellen vil utføre det mekanisk og miste sin autonome planleggingsevne.

Løsningen: Fortell modellen hva målet og begrensningene er. La den bestemme trinnene selv.

Smiger-engineering

"You are an EXTREMELY TALENTED and INCREDIBLY EXPERIENCED
senior software engineer with 20 years of experience..."

Kompimenter og superlativer forbedrer ikke output-kvaliteten. Modellen har ikke et ego som trenger å boostes. Spar de 15 tokensene til en faktisk regel.

Kunnskapsdumping

"Here is the complete API documentation for our 200 endpoints..."

Dette sluker kontekstvinduet ditt og akselererer kontekst-råte. Bytt det ut med innlasting ved behov:

"Use the get_api_docs tool to retrieve API documentation when needed."

Gjentakelse av verktøybeskrivelser

Hvis verktøydefinisjonen allerede sier "Read tool reads a file from the filesystem", ikke si det igjen i system-promptet ditt. Legg kun til strategisk veiledning som verktøydefinisjonen ikke dekker — når det skal brukes, hvorfor det foretrekkes, prioriteringsrekkefølge.

Manglende feilhåndtering

Uten eksplisitt veiledning vil modeller prøve feilede verktøykall på nytt i en uendelig loop. Inkluder alltid:

"If a tool call is denied, do not re-attempt the exact same call.
Think about why it was denied and adjust your approach."

Å ignorere forfall i kontekstvinduet

200K kontekstvindu ≠ 200K effektiv kontekst. Reell testing viser at forringelsen starter ved 80K. Du trenger en oppsummeringsstrategi.

---

7. Injeksjonspunkter og prioritet

Claude Codes tre tilpasningsmetoder

Metode	Erstatter	Plassering	Best for
Output Styles	"Tone and style" + "Doing tasks"-seksjoner	Rett før verktøydefinisjoner	Endre interaksjonsstil
--append-system-prompt	Ingenting (additivt)	Etter output style, før verktøydefinisjoner	Legge til spesifikk adferd
--system-prompt	Hele system-promptet	Beholder verktøy + én identitetslinje	Full tilpasning (atomknappen)

Hvis du bruker flere: Output Style → Append Prompt → Tool Definitions

Instruksjonshierarki

Claude er spesifikt trent med et instruksjonshierarki:

1. User's explicit instructions (CLAUDE.md, direct requests)  ← Høyeste prioritet
2. Custom system prompt additions                               ← Høy
3. Default system prompt                                        ← Medium
4. Tool definitions                                             ← Referansenivå

Dette betyr:

• CLAUDE.md-regler overstyrer standard system-prompt-adferd
• Brukerens direkte forespørsler overstyrer alt
• Ditt tilpassede prompt overstyrer standardpromptet

Dynamiske injeksjonsmekanismer

• <system-reminder> — injiser i hvilken som helst melding midt i samtalen for å minne modellen på kritiske regler
• CLAUDE.md / AGENTS.md — lastes ved runtime fra filer, legges til system-promptet
• Skills / SKILL.md — lastes ved behov via verktøykall, null fotavtrykk i system-promptet

---

8. Injeksjon midt i samtalen — Det hemmelige våpenet

System-promptet dukker bare opp én gang, helt i starten av meldings-arrayet. Men LLM-er aksepterer hele meldings-arrayet (vekslende bruker / assistent / verktøy-meldinger) som input, og du kan injisere prompts i brukermeldinger og verktøyresultater også. Claude Code bruker denne teknikken tungt i produksjon.

Hvorfor det er nødvendig

Kampen mot kontekst-råte. Etter hvert som samtaler blir lengre, forringes modellens etterlevelse av system-promptets instruksjoner (merkbart ved 80K+ tokens). Å injisere påminnelser midt i samtalen = oppfriskning av reglene via recency bias.

Den mentale modellen:

• System-prompt = grunnloven (etablert én gang, langsiktig autoritet)
• Påminnelser i brukermeldinger = memoer (sendes periodisk, opprettholder håndhevelse)

Tre injeksjonspunkter i meldings-arrayet

Messages Array:
┌─────────────────────────────────────┐
│ System Prompt                       │ ← Dukker opp én gang, primacy-effekt
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ User Message 1                      │
│ Assistant Message 1                 │
│ User Message 2 + <system-reminder>  │ ← Injeksjon midt i samtalen
│ Assistant Message 2                 │
│ Tool Result + <system-reminder>     │ ← Kan injiseres i verktøyresultater også
│ ...                                 │
│ User Message N + <system-reminder>  │ ← Siste melding, sterkest recency
└─────────────────────────────────────┘

Lokasjon	Fordel	Ulempe
System prompt	Primacy-effekt, leses først	Dukker opp én gang, "glemmes" i lange samtaler
User message injection	Recency bias, periodisk refresh	Hver injeksjon koster tokens
Tool result injection	Mest naturlige injeksjonspunkt	Fungerer bare når verktøy kalles

Hvordan Claude Code faktisk bruker det

Forutsetning — deklarer taggene i system-promptet:

Tool results and user messages may include <system-reminder> tags.
<system-reminder> tags contain useful information and reminders.
They are automatically added by the system, and bear no direct
relation to the specific tool results or user messages in which they appear.

Dette trinnet er kritisk: det forteller modellen at disse taggene er system-injisert, ikke noe brukeren sier.

Bruk 1: Adferdspåminnelser (periodisk oppfriskning av regler)

<system-reminder>
The task tools haven't been used recently. If you're working on tasks
that would benefit from tracking progress, consider using TaskCreate...
</system-reminder>

Claude Code bruker dette for å minne modellen på å planlegge med TodoWrite — fordi modeller har en tendens til å "glemme" planlegging og bare begynne å kode.

Bruk 2: Bytte av modus (Plan Mode)

<system-reminder>
Plan mode is active. The user indicated that they do not want you to
execute yet -- you MUST NOT make any edits, run any non-readonly tools,
or otherwise make any changes to the system.
</system-reminder>

Plan mode er ikke implementert i system-promptet. Det er en tag som injiseres i neste brukermelding. Dette lar deg bytte modus dynamisk uten å modifisere system-promptet. Genialt.

Bruk 3: Varsler om filendringer

<system-reminder>
Note: /path/to/file.ts was modified, either by the user or by a linter.
This change was intentional, so make sure to take it into account.
</system-reminder>

Når en ekstern prosess (linter, formatter, manuell redigering) modifiserer en fil, varsler systemet modellen via en påminnelse — noe som forhindrer beslutninger basert på utdatert filinnhold.

Bruk 4: Dynamisk kontekst (datoer, prosjektregler)

<system-reminder>
Today's date is 2026-03-21.
Current branch: dev
claudeMd: [CLAUDE.md content injected here]
</system-reminder>

Runtime-kontekst (dato, git-status, prosjektregler) injiseres via brukermeldinger, ikke hardkodet i system-promptet.

Retningslinjer for å skrive påminnelser

• Pakk inn i XML-tags (<system-reminder>) — modellen kan skille systeminjeksjon fra brukerens tale
• Forhåndsdeklarer tags i system-promptet — ellers kan modellen prøve å svare på påminnelsen
• Ikke injiser i hver melding — hver injeksjon koster tokens, injiser kun når det trengs
• Hold det kort — en påminnelse er ikke et system-prompt nummer to, bare 1-2 kritiske regler
• Ikke motsi system-promptet — påminnelser supplerer og forsterker, de overstyrer ikke
• Bruk for dynamisk veksling — plan mode, readonly mode, feature flags

Når du skal bruke System Prompt vs. User Message Reminder

Scenario	System Prompt	User Message Reminder
Rolledefinisjon	✅	❌
Sikkerhetsbegrensninger	✅ Første deklarasjon	✅ Periodisk gjentakelse
Workflow-metodikk	✅	❌
Modusbytte (plan mode)	❌	✅
Varsler om filendringer	❌	✅
Dato / miljøinfo	✅ Startverdi	✅ Oppdatert verdi
Adferdskorrigering	❌	✅
Påminnelser om verktøybruk	✅ Regeldefinisjon	✅ Nudge for utførelse

---

9. Prompt Cache — Spar 90 % på gjentakende tokens

Anthropics prompt caching lar deg cache det statiske prefikset i meldings-arrayet ditt. Når påfølgende forespørsler deler samme prefiks, treffer de cachen — noe som sparer penger og reduserer latency.

For agenter betyr dette enormt mye: du sender system-promptet + verktøydefinisjonene på nytt ved hvert eneste LLM-kall i løpet av en samtale.

Nøkkeltall

Metrikk	Verdi
Pris for cache-treff	10 % av normal pris (90 % besparelse)
Pris for cache-skriving	125 % av normal pris (25 % premium på første skriving)
Cache TTL	5 minutter (utløper hvis ingen forespørsler)
Minimum cachebar lengde	1 024 tokens (Claude 3.5+)
Cache-granularitet	Prefiks-matching — fra starten til et markert bruddpunkt
Maks antall bruddpunkter	4

Hvordan dette endrer prompt-design

Kjerneprinsipp: statisk innhold først, dynamisk innhold sist.

✅ Cache-vennlig layout:
  System prompt (statisk)      ← Cache breakpoint 1
  Tool definitions (statisk)   ← Cache breakpoint 2
  CLAUDE.md / prosjektregler   ← Cache breakpoint 3 (endres av og til)
  Conversation history         ← Breakpoint 4 for rullerende vindu

❌ Cache-ødeleggende layout:
  System prompt
  DYNAMISK TIDSSTEMPEL         ← Endres hver forespørsel, alt etter = cache miss
  Tool definitions
  Conversation history

Fellen ingen advarer deg mot: Hvis du legger inn et dynamisk tidsstempel midt i system-promptet ditt, blir alt som kommer etter det en cache-miss. Hver. Eneste. Forespørsel. Ett tidsstempel på feil sted, og du betaler full pris for tusenvis av tokens.

API-bruk

const response = await anthropic.messages.create({
  model: "claude-sonnet-4-6",
  system: [
    {
      type: "text",
      text: "You are a startup advisor...",
      cache_control: { type: "ephemeral" }  // ← markerer et cache-bruddpunkt
    }
  ],
  messages: [...]
});

Strategi med flere bruddpunkter

Breakpoint 1: System prompt           ← Endres nesten aldri
Breakpoint 2: Tool definitions         ← Endres nesten aldri
Breakpoint 3: Prosjektregler / CLAUDE.md ← Endres av og til
Breakpoint 4: Første N historikk-meldinger ← Rullerende vindu-cache

Selv når samtalehistorikken endres, treffer de første 3 bruddpunktene fortsatt. En samtale på 10 turer sparer omtrent 40-60 % på input token-kostnader.

Designanbefalinger

• Ingen høyfrekvente dynamiske verdier i system-promptet — dato er greit (endres daglig), presise tidsstempler er ikke det
• Legg dynamisk kontekst (git-status, etc.) i brukermeldings-injeksjoner — ikke i system-promptet, ellers ødelegger du cachen
• Hold verktøydefinisjoner stabile — ikke legg til/fjern verktøy dynamisk ved runtime
• Bruk rullerende vindu for samtalehistorikk — cache de første N meldingene, bare den nyeste meldingen er en cache-miss

---

10. Sjekklisten

Etter at du har skrevet system-promptet ditt, gå gjennom det med denne sjekklisten:

Struktur

• Er identitet helt på toppen?
• Er sikkerhetsbegrensninger markert med IMPORTANT og gjentatt til slutt?
• Er det tydelig seksjonsinndeling med overskrifter?
• Er eksempler pakket inn i <example>-tags?

Token-budsjett

• Er din del < 6 000 tokens?
• Unngår du å gjenta informasjon som allerede er i verktøydefinisjonene?
• Lastes domenekunnskap inn ved behov, ikke på forhånd?
• Er det fritt for ordrik "lore" eller bakhistorie for karakteren?

Regelkvalitet

• Kan hver regel testes som sann/usann?
• Bruker harde grenser absolutt språk (NEVER/MUST)?
• Bruker myke forslag anbefalingsspråk (recommended/prefer)?
• Forklarer kritiske regler hvorfor, ikke bare hva?
• Er det toveis begrensninger (gjør dette + ikke gjør det)?

Agent-adferd

• Er det gitt prinsipper, ikke rigide trinn-for-trinn prosedyrer?
• Er scenarioet "verktøykall avvist" håndtert?
• Er strategien for "hindring møtt" håndtert (ikke prøv på nytt med rå makt)?
• Er det en strategi for konteksthåndtering på plass (terskel for oppsummering)?

Hva du IKKE skal gjøre

• Ingen smiger eller superlative adjektiver?
• Ingen overflødige "du er en hjelpsom AI"-deklarasjoner?
• Er det ikke skrevet som en prompt chain?
• Ingen over-engineering (funksjoner ingen ba om)?

---

Hvis jeg skulle startet i dag

Her er nøyaktig hva jeg ville gjort:

1. Start med identitet + sikkerhet i de første 3 linjene. To setninger for hvem agenten er. Harde grenser med NEVER/MUST. Gjenta sikkerhetsreglene til slutt.

2. Skriv din core workflow som prinsipper, ikke trinn. Maks 4-5 kulepunkter. Bruk "recommended" og "prefer" for myke regler, "NEVER" og "MUST" for harde.

3. Budsjetter 1 500-6 000 tokens for din del. Verktøydefinisjoner vil legge til 5 000-15 000 mer. Hvis du er over 6K, dumper du sannsynligvis kunnskap som burde vært lastet inn ved behov.

4. Strukturer alt. Markdown-overskrifter, punktlister, XML-tags for eksempler. Et strukturert prompt utkonkurrerer prosa i naturlig språk hver eneste gang.

5. Bygg inn påminnelser midt i samtalen fra dag én. Deklarer <system-reminder> i system-promptet ditt. Injiser påminnelser for kritiske regler, modusbytter og kontekstoppdateringer.

6. Design for cache. Statisk innhold først, dynamisk innhold sist. Legg aldri verdier som endrer seg i selve system-promptet.

---

Ironien i alt dette arbeidet? De beste system-promptene er korte. Claude Codes tilpassede instruksjoner (ekskludert verktøydefinisjoner) er overraskende konsise. Hver eneste linje fortjener plassen sin.

Jeg pleide å tro at prompt engineering handlet om å finne smarte triks. Nå tror jeg det handler om disiplin — å si mindre, si det presist, og stole på at modellen finner ut av resten. Modellen er smartere enn promptet ditt. Design miljøet, ikke adferden.

---

Referanser

Kilde	Nøkkelinnsikt
Claude Code v2.0.14 System Prompt	Full referanse for struktur på produksjons-agent-prompt
Reddit: Understanding Claude Code's 3 System Prompt Methods	Dypdykk i Output Styles / --append / --system-prompt, reelle data på kontekst-råte
shareAI-lab/learn-claude-code	"Modellen er agenten"-filosofien, harness-engineering metodikk
Anthropic Prompt Engineering Docs	Offisielle best practices for prompting
DeepAgents Framework	Oppsummerings-middleware, progressiv tilgjengeliggjøring av skills

Excerpt: Det meste av det folk tror er viktig med system-prompts, betyr ingenting. Og de tingene som faktisk betyr noe, er det nesten ingen som snakker om. Etter å ha reverskonstruert Claude Code og bygget VibeCom, er dette den komplette dreieboken for hvordan du faktisk designer AI-agenter. Hent deg en kaffe.