Den komplette guide til at skrive Agent System Prompts — Erfaringer fra reverse-engineering af Claude Code

Jeg dekompilerede Claude Codes system prompt, studerede DeepAgents' kildekode og byggede min egen AI-agent fra bunden. De fleste prompt-guides er ren varm luft.

Title: Der foregår en kollektiv vrangforestilling i AI-verdenen lige nu

Content: Der foregår en kollektiv vrangforestilling i AI-verdenen lige nu.

Hver eneste tutorial fortæller dig, at du skal skrive system-prompts, som om du kaster en trylleformular — du skal bare finde den rigtige besværgelse, så adlyder modellen. "You are an EXTREMELY TALENTED senior engineer with 20 years of experience..." Lyder det bekendt?

Jeg har brugt de sidste par måneder på at bygge VibeCom, en AI-startup-rådgiver, der kører dybdegående markedsundersøgelser og genererer analyser på VC-niveau. Undervejs har jeg reverse-engineeret Claude Codes system-prompt, læst DeepAgents' middleware-kildekode igennem og brændt flere API-credits af, end jeg har lyst til at indrømme. Den største lektie? Det meste af det, folk tror er vigtigt ved system-prompts, betyder ingenting. Og de ting, der rent faktisk betyder noget, er der næsten ingen, der taler om.

Dette indlæg er den komplette drejebog — ikke et 5-minutters overblik, men alt det, jeg ville ønske, nogen havde fortalt mig, før jeg startede. Hent en kop kaffe.

1. Designfilosofi: Stol på modellen

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

Denne idé ændrede alt for mig. LLM'en ved allerede, hvordan den skal ræsonnere, planlægge og eksekvere. Din system-prompt lærer den ikke at tænke — den sætter miljøet op, som den skal arbejde i.

Tænk på det som at ansætte en seniorudvikler. Du giver dem ikke en tjekliste på 20 trin til hver eneste opgave. Du fortæller dem: Her er hvem vi er, her er grænserne, og her er, hvordan succes ser ud. Derefter træder du til side.

Din system-prompt har præcis fire opgaver:

Fortæl den, hvem den er — rolle og identitet
Fortæl den, hvor grænserne går — sikkerhedsbegrænsninger
Fortæl den, hvordan succes ser ud — kvalitetsstandarder
Giv den værktøjer — evner og viden

Det er det. Alt andet er støj.

Harness-tankegangen

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

Din system-prompt er brugermanualen til dette "harness" (arbejdsramme). Du designer ikke en rigid pipeline — du designer et miljø, hvor modellen kan udføre sit bedste arbejde autonomt.

Skriv ikke din system-prompt som et rutediagram. Modellen vil selv beslutte eksekveringsrækkefølgen.

2. Prompt-struktur og rækkefølge af sektioner

Det anbefalede layout (Reverse-engineeret fra Claude Code v2.0.14)

┌─────────────────────────────────────────────┐
│ 1. Identity                                  │  ← Read first, anchors behavior
│ 2. Security & Safety                         │  ← IMPORTANT markers, non-negotiable
│ 3. Tone & Style                              │  ← Controls output format
│ 4. Core Workflow                             │  ← How to do the work
│ 5. Tool Usage Policy                         │  ← Tool selection priorities
│ 6. Domain Knowledge                          │  ← On-demand, not pre-loaded
│ 7. Environment Info                          │  ← Runtime context, dynamically injected
│ 8. Reminders                                 │  ← Re-state critical rules
├─────────────────────────────────────────────┤
│ [Tool Definitions — system-injected]         │  ← Not editable, usually very long
├─────────────────────────────────────────────┤
│ [User Message]                               │
└─────────────────────────────────────────────┘

Hvorfor denne rækkefølge er vigtig

LLM'er har en U-formet opmærksomhedskurve — de er mest opmærksomme på starten og slutningen af din prompt, og mister fokus i midten. Dette er den veldokumenterede "Lost in the Middle"-effekt.

Identitet + Sikkerhed i toppen: Modellen etablerer rolle og grænser først (primacy-effekten)
Kerne-workflow i den øvre midte: Din vigtigste sektion — hvordan agenten udfører sit arbejde
Værktøjsdefinitioner injiceres af systemet efter din prompt: Claude Codes værktøjsdefinitioner æder ~11.438 tokens. Det betyder, at dit tilpassede indhold faktisk ender tættere på begyndelsen, end du måske forventer — hvilket hjælper på overholdelsen af reglerne
Påmindelser i bunden: Udnyt recency-bias til at forstærke kritiske regler

3. Sådan skriver du hver sektion

3.1 Identitet — Hvem er denne agent?

Mål: Forankr modellens rolle på 1-3 sætninger.

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 sætninger
Navngiv rollen eksplicit (hjælper modellen med at skelne mellem kontekster)
Angiv kerneansvaret ("hjælper med X"), ikke et vagt "du er en hjælpsom assistent"
Nævn SDK/platform, hvis det er relevant ("bygget på Anthropics Claude Agent SDK")

Anti-patterns:

"You are a helpful, harmless, and honest AI assistant" — for generisk, ingen forankring af rollen
Et helt afsnit med baggrundshistorie og "lore" — spilder tokens, modellen har ikke brug for karakterudvikling

3.2 Sikkerhed & Beskyttelse — De hårde grænser

Mål: Sæt ubrydelige adfærdsmæssige begrænsninger.

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:

Brug IMPORTANT:-præfikset — Claudes træning i instruktionshierarki giver dette ekstra vægt
Brug absolut sprog: NEVER, MUST NOT, Refuse to
Angiv både hvad der er tilladt OG hvad der er forbudt (tosidede begrænsninger er tydeligere)
Placer det helt i toppen, ikke begravet i midten
Gentag kritiske sikkerhedsregler til sidst — Claude Code gør præcis dette

Hvorfor gentage? Primacy-effekt (begyndelsen) + Recency-effekt (slutningen) = dobbelt forstærkning. Claude Codes sikkerhedserklæring optræder både i starten og slutningen af prompten. Ikke fordi ingeniørerne var glemsomme — men fordi de forstår den U-formede opmærksomhedskurve.

3.3 Tone & Stil — Kontrol af 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:

Oplist specifikke adfærdsmønstre, ikke et vagt "vær professionel"
Hver regel skal kunne testes som sand/falsk ("short and concise" vs. "try to be brief")
Inkluder krav til output-format (markdown? JSON? ren tekst?)
Inkluder hvad den IKKE skal gøre — mange stilproblemer handler om at forbyde en bestemt adfærd

Claude Codes genistreg — Professionel 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 afsnit er afgørende: Det blokerer modellens tendens til at snakke brugeren efter munden (sycophancy). Hvis din agent skal give objektive vurderinger (code review, evaluering af idéer, arkitekturbeslutninger), har du absolut brug for en lignende klausul.

3.4 Kerne-workflow — Den vigtigste sektion

Mål: Lær modellen hvordan den skal arbejde — metodologi, ikke rigide procedurer.

Dette er den sværeste sektion at skrive godt, og den der har størst effekt, når du rammer rigtigt.

Kerneprincippet: giv principper, ikke procedurer.

Fortæl LLM'en, hvordan et godt output ser ud, og hvorfor det er godt — lad den selv finde ud af, hvordan den når dertil. Undgå at diktere præcise antal felter, sekvenser af trin eller formater, medmindre outputtet skal forbruges af maskiner længere nede i systemet.

Claude Codes tilgang:

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

Læg mærke til ordet "recommended" — ikke "du skal følge disse præcise trin". Det ene ordvalg giver modellen plads til at tilpasse sig.

En god workflow-definition:

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 implicit "hvorfor" — modellen kan forstå hensigten og generalisere til nye scenarier.

Anti-patterns:

En rigid procedure på 20 trin — modellen vil eksekvere mekanisk og fryse ved uventede inputs
"Gør først A, gør derefter B, gør derefter C" — det er en prompt-chain, ikke en agent-prompt
At over-guide ting, som LLM'en allerede er god til — det spilder tokens

Jeg lærte dette på den hårde måde med VibeCom. Tidlige versioner havde et research-workflow på 10 trin. Modellen eksekverede pligtopfyldende alle 10 trin, selv når trin 3 allerede havde besvaret brugerens spørgsmål. Da jeg skiftede til principper ("research indtil du har tilstrækkelig evidens, og syntetiser derefter"), steg kvaliteten, og token-omkostningerne faldt.

Undtagelsen: Når outputtet skal forbruges af maskiner (inter-agent kommunikation, API-responsformater), bør du definere strikse formater. Principper er til adfærd; skemaer er til grænseflader.

3.5 Politik for brug af værktøjer — Løsning af tvetydighed

Mål: Når flere værktøjer kan gøre det samme, skal du fortælle modellen, hvilket den skal foretrække.

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

Brug "instead of" for at udtrykke prioritet (A i stedet for B)
Forklar hvorfor den skal foretrække bestemte værktøjer ("giver en bedre brugeroplevelse", "reducerer kontekstforbrug")
Definer strategi for parallelisme (uafhængige → parallel, afhængige → sekventiel)
Oplist sikkerhedsbegrænsninger for brug af værktøjer (validering af stier, rettighedstjek)

Det afgørende forhold mellem værktøjer og prompts:

Værktøjsdefinitioner injiceres typisk af systemet, og du kan ikke redigere dem direkte. Claude Codes værktøjsdefinitioner er på ~11.438 tokens. Det betyder:

Gentag ikke information, der allerede findes i værktøjsdefinitionerne
Brug system-prompten til strategisk vejledning: hvornår hvert værktøj skal bruges, hvorfor man skal foretrække ét frem for et andet, og prioriteringsrækkefølge
Kvaliteten af værktøjsdefinitioner påvirker agentens effektivitet direkte — hvis du bygger din egen agent, så invester tid i at skrive fremragende værktøjsbeskrivelser

3.6 Domæneviden — Indlæs on-demand, ikke på forhånd

Mål: Giv specialiseret viden, som modellens træningsdata måske mangler.

Kerneprincippet: progressiv afsløring, ikke videns-dumps.

❌ Paste all 200 API endpoints into the system prompt → token explosion
✅ Give the model a tool to look things up → "Load knowledge when you need it"

Denne strategi deles af Claude Codes Skills-system og DeepAgents' Progressive Disclosure-middleware. Begge indlæser viden on-demand via værktøjskald i stedet for at pre-loade alt.

Implementeringstilgange:

Læg pointers i system-prompten: "Use the get_api_docs tool to retrieve documentation when needed"
Brug CLAUDE.md / AGENTS.md til projektkontekst — indlæses ved runtime, hardcodes ikke
Brug Skills / SKILL.md til opdagelse af evner — modellen ser en menu af tilgængelige skills og henter fulde specifikationer on-demand

3.7 Miljø-info — Runtime-kontekst

Mål: Giv modellen bevidsthed om sit eksekveringsmiljø.

<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, hardcode aldrig
Inkluder: working directory, platform, dato, modelnavn, git-status
Brug struktureret format (XML-tags eller kodeblokke) for nem parsing
Dato er vigtig — modellen har brug for at kende "nu" for at vurdere, hvor frisk informationen er

3.8 Påmindelser — Den sidste forstærkning

Mål: Gentag de mest kritiske regler i slutningen af prompten.

Claude Code gentager sin sikkerhedsbegrænsning og TodoWrite-krav i bunden:

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

Retningslinjer:

Gentag kun 2-3 af de mest kritiske regler — dupliker ikke alt
Udnyt recency-bias — modellen husker nyligt indhold stærkere
Bedste kandidater: sikkerhedsbegrænsninger, regler der oftest overtrædes, påmindelser om kerne-workflow

4. Token-budget og håndtering af kontekst

Reference for budgetallokering

Sektion	Anbefalede Tokens	Noter
Identitet + Sikkerhed	200-500	Kortfattet, men ufravigelig
Tone & Stil	300-800	Regler skal være specifikke, men undgå at ævle
Kerne-workflow	500-2.000	Vigtigste sektion, investeringen værd
Politik for værktøjer	300-1.000	Afhænger af antallet af værktøjer
Domæneviden	0-1.000	On-demand indlæsning foretrækkes
Miljø-info	100-300	Genereres dynamisk
Påmindelser	100-300	Gentag kun det absolut nødvendige
Din total	1.500-6.000
Værktøjsdefinitioner (system)	5.000-15.000	Ikke under din kontrol

Kurve for kontekst-forfald

Community-tests (Reddit u/CodeMonke_) har kortlagt, hvordan overholdelsen af regler forfalder i den virkelige verden:

< 80K tokens: Prompt-overholdelse forbliver stabil
80K - 120K tokens: Evnen til at følge instruktioner begynder at forfalde
> 120K tokens: Betydeligt forfald — modellen "glemmer" tidlige instruktioner
> 180K tokens: Alvorligt forfald

Dit 200K kontekstvindue ≠ 200K effektiv kontekst. Planlæg derefter.

Strategier til afbødning:

Hold din system-prompt slank (< 6.000 tokens for din del)
Brug opsummering til at komprimere samtalehistorikken (DeepAgents trigger ved ~80K tegn)
Placer kritiske regler i begge ender af prompten (U-formet opmærksomhed)
Injicer <system-reminder>-tags midt i samtalen (mere om dette i sektion 8)

5. Skriveprincipper

5.1 Giv principper, ikke procedurer

❌ "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."

Principper generaliserer. Procedurer kan kun følges mekanisk. Når modellen støder på en situation, du ikke havde forudset, guider principper den til den rigtige beslutning. Det gør procedurer ikke.

Undtagelse: Når outputtet forbruges af maskiner (inter-agent kommunikation, API-formater), skal du definere strikse skemaer.

5.2 Brug absolut sprog til hårde begrænsninger

Styrke	Sprog	Brug til
Absolut forbud	`NEVER`, `MUST NOT`	Sikkerhed, irreversible operationer
Stærkt krav	`ALWAYS`, `MUST`	Regler for kerne-workflow
Anbefaling	`recommended`, `prefer`	Best practices med undtagelser
Forslag	`consider`, `you may`	Valgfrie optimeringer

Claude Code eksempler:

NEVER update the git config — absolut forbud
ALWAYS prefer editing an existing file — stærkt, men der findes undtagelser
The following steps are recommended — foreslået workflow

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

Ét eksempel underviser bedre end 100 ords forklaring:

Modeller lærer mønstre fra eksempler mere pålideligt end fra abstrakte beskrivelser
Pak dem ind i <example>-tags for at adskille dem fra reglerne
Giv både positive ("gør dette") og negative ("gør ikke dette") eksempler
Brug rigtige, specifikke eksempler — ikke "foo/bar"-placeholders

5.4 Tosidede begrænsninger

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

At sige kun "gør dette" → modellen ved ikke, hvornår den IKKE skal gøre det. At sige kun "gør ikke dette" → modellen kender ikke alternativet. Tosidet → klart og utvetydigt.

5.5 Forklar hvorfor, ikke kun hvad

❌ "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."

At forklare hvorfor lader modellen træffe korrekte vurderinger i edge-cases. Claude Codes git-sikkerhedsprotokol er en masterclass — hver regel antyder sin egen begrundelse.

5.6 Struktur frem for prosa

Markdown-overskrifter (##, ###) — modeller genkender hierarki
Punktopstillinger frem for afsnit — hver regel kan testes uafhængigt
XML-tags til specielt indhold: <example>, <env>, <system-reminder>
Tabeller til sammenligninger og mapninger
Dump aldrig ustruktureret tekst — strukturerede prompts udkonkurrerer konsekvent naturlig sprogprosa i tests af regeloverholdelse

6. Anti-patterns der spilder dine tokens

Prompt-chains forklædt 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 en agent-prompt — det er et pipeline-script. Modellen vil eksekvere mekanisk og miste sin autonome planlægningsevne.

Løsningen: Fortæl modellen målet og begrænsningerne. Lad den selv beslutte trinnene.

Smiger-engineering

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

Komplimenter og superlativer forbedrer ikke output-kvaliteten. Modellen har ikke et ego, der skal boostes. Gem de 15 tokens til en rigtig regel.

Videns-dumps

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

Dette æder dit kontekstvindue og fremskynder kontekst-forfald. Erstat med on-demand indlæsning:

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

Gentagelse af værktøjsbeskrivelser

Hvis værktøjsdefinitionen allerede siger "Read tool reads a file from the filesystem", så sig det ikke igen i din system-prompt. Tilføj kun strategisk vejledning, som værktøjsdefinitionen ikke dækker — hvornår det skal bruges, hvorfor det skal foretrækkes, prioriteringsrækkefølge.

Manglende håndtering af fejl

Uden eksplicit vejledning vil modeller forsøge at genkalde fejlede værktøjskald i et uendeligt loop. Inkluder altid:

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

Ignorering af kontekstvinduets forfald

200K kontekstvindue ≠ 200K effektiv kontekst. Tests i den virkelige verden viser, at forfaldet starter ved 80K. Du har brug for en strategi for opsummering.

7. Injektionspunkter og prioritet

Claude Codes tre metoder til tilpasning

Metode	Erstatter	Placering	Bedst til
Output Styles	"Tone and style" + "Doing tasks" sektionerne	Lige før værktøjsdefinitioner	Ændring af interaktionsstil
--append-system-prompt	Ingenting (additiv)	Efter output style, før værktøjsdefinitioner	Tilføjelse af specifik adfærd
--system-prompt	Hele system-prompten	Beholder værktøjsdefinitioner + én identitetslinje	Fuld tilpasning (den drastiske løsning)

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

Instruktionshierarki

Claude er specifikt trænet med et instruktionshierarki:

1. User's explicit instructions (CLAUDE.md, direct requests)  ← Highest priority
2. Custom system prompt additions                               ← High
3. Default system prompt                                        ← Medium
4. Tool definitions                                             ← Reference level

Det betyder:

CLAUDE.md-regler overskriver standard system-prompt-adfærd
Brugerens direkte anmodninger overskriver alt
Din tilpassede prompt overskriver standard-prompten

Dynamiske injektionsmekanismer

<system-reminder> — injicer i enhver besked midt i samtalen for at minde modellen om kritiske regler
CLAUDE.md / AGENTS.md — indlæses ved runtime fra filer, tilføjes til system-prompten
Skills / SKILL.md — indlæses on-demand via værktøjskald, nul fodaftryk i system-prompten

8. Injektion midt i samtalen — Det hemmelige våben

System-prompten optræder kun én gang, helt i starten af besked-arrayet. Men LLM'er accepterer hele besked-arrayet (skiftevis bruger / assistent / værktøjsbeskeder) som input, og du kan også injicere prompts i brugermeddelelser og værktøjsresultater. Claude Code bruger denne teknik flittigt i produktion.

Hvorfor det er nødvendigt

Kampen mod kontekst-forfald. Efterhånden som samtaler bliver længere, forfalder modellens overholdelse af system-promptens instruktioner (mærkbart ved 80K+ tokens). At injicere påmindelser midt i samtalen = opfriskning af reglerne via recency-bias.

Den mentale model:

System-prompt = grundloven (etableres én gang, langsigtet autoritet)
Brugermeddelelses-påmindelser = memos (sendes periodisk, opretholder håndhævelsen)

Tre injektionspunkter i besked-arrayet

Messages Array:
┌─────────────────────────────────────┐
│ System Prompt                       │ ← Appears once, primacy effect
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ User Message 1                      │
│ Assistant Message 1                 │
│ User Message 2 + <system-reminder>  │ ← Mid-conversation injection
│ Assistant Message 2                 │
│ Tool Result + <system-reminder>     │ ← Can inject into tool results too
│ ...                                 │
│ User Message N + <system-reminder>  │ ← Latest message, strongest recency
└─────────────────────────────────────┘

Placering	Fordel	Ulempe
System-prompt	Primacy-effekt, læses først	Optræder én gang, "glemmes" i lange samtaler
Brugermeddelelses-injektion	Recency-bias, periodisk opfriskning	Hver injektion koster tokens
Værktøjsresultat-injektion	Mest naturlige injektionspunkt	Virker kun, når værktøjer kaldes

Hvordan Claude Code rent faktisk bruger det

Forudsætning — deklarer tags i system-prompten:

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 trin er kritisk: Det fortæller modellen, at disse tags er system-injicerede, ikke brugerens tale.

Brug 1: Adfærdsmæssige påmindelser (periodisk opfriskning af 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 bruger dette til at minde modellen om at planlægge med TodoWrite — fordi modeller har en tendens til at "glemme" planlægning og bare begynde at kode.

Brug 2: Skift af tilstand (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 implementeret i system-prompten. Det er et tag, der injiceres i den næste brugermeddelelse. Dette lader dig skifte tilstande dynamisk uden at ændre system-prompten. Genialt.

Brug 3: Notifikationer om filændringer

<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 proces (linter, formatter, manuel redigering) ændrer en fil, giver systemet modellen besked via en påmindelse — hvilket forhindrer beslutninger baseret på forældet filindhold.

Brug 4: Dynamisk kontekst (datoer, projektregler)

<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, projektregler) injiceres via brugermeddelelser, ikke hardcodet i system-prompten.

Retningslinjer for at skrive påmindelser

Pak ind i XML-tags (<system-reminder>) — modellen kan skelne systeminjektion fra brugertale
Forhåndsdeklarer tags i system-prompten — ellers kan modellen forsøge at svare på påmindelsen
Injicer ikke i hver besked — hver injektion koster tokens, injicer kun når det er nødvendigt
Hold det kort — en påmindelse er ikke en system-prompt nummer to, bare 1-2 kritiske regler
Modsig ikke system-prompten — påmindelser supplerer og forstærker, de overskriver ikke
Brug til dynamisk skift — plan mode, readonly mode, feature flags

Hvornår skal man bruge System-prompt vs. Brugermeddelelses-påmindelse

Scenarie	System-prompt	Brugermeddelelses-påmindelse
Rolledefinition	✅	❌
Sikkerhedsbegrænsninger	✅ Første deklaration	✅ Periodisk gentagelse
Workflow-metodologi	✅	❌
Skift af tilstand (plan mode)	❌	✅
Notifikationer om filændringer	❌	✅
Dato / miljø-info	✅ Startværdi	✅ Opdateret værdi
Adfærdskorrektion	❌	✅
Påmindelser om brug af værktøjer	✅ Regeldefinition	✅ Eksekverings-nudges

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

Anthropics prompt-caching lader dig cache det statiske præfiks af dit besked-array. Når efterfølgende anmodninger deler det samme præfiks, rammer de cachen — hvilket sparer penge og reducerer latency.

For agenter betyder dette utrolig meget: Du gensender system-prompten + værktøjsdefinitionerne ved hvert eneste LLM-kald inden for en samtale.

Nøgletal

Metrik	Værdi
Pris for cache hit	10% af normal pris (90% besparelse)
Pris for cache write	125% af normal pris (25% premium på første skrivning)
Cache TTL	5 minutter (udløber hvis ingen anmodninger)
Minimum cachebar længde	1.024 tokens (Claude 3.5+)
Cache-granularitet	Præfiks-matching — fra starten til et markeret breakpoint
Maksimum breakpoints	4

Hvordan dette ændrer prompt-design

Kerneprincip: statisk indhold først, dynamisk indhold sidst.

✅ Cache-friendly layout:
  System prompt (static)      ← Cache breakpoint 1
  Tool definitions (static)   ← Cache breakpoint 2
  CLAUDE.md / project rules   ← Cache breakpoint 3 (changes occasionally)
  Conversation history         ← Breakpoint 4 for rolling window

❌ Cache-destroying layout:
  System prompt
  DYNAMIC TIMESTAMP            ← Changes every request, everything after = cache miss
  Tool definitions
  Conversation history

Fælden, ingen advarer dig imod: Hvis du placerer et dynamisk tidsstempel midt i din system-prompt, bliver alt efter det til et cache miss. Hver. Eneste. Anmodning. Ét tidsstempel på det forkerte sted, og du betaler fuld pris for tusindvis af tokens.

API-brug

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

Multi-Breakpoint Strategi

Breakpoint 1: System prompt           ← Almost never changes
Breakpoint 2: Tool definitions         ← Almost never changes
Breakpoint 3: Project rules / CLAUDE.md ← Changes occasionally
Breakpoint 4: First N history messages  ← Rolling window cache

Selv når samtalehistorikken ændrer sig, rammer de første 3 breakpoints stadig. En samtale på 10 ture sparer groft sagt 40-60% på input-token-omkostninger.

Designanbefalinger

Ingen højfrekvente dynamiske værdier i system-prompten — dato er fint (ændres dagligt), præcise tidsstempler er ikke
Læg dynamisk kontekst (git-status osv.) i brugermeddelelses-injektioner — ikke i system-prompten, ellers ødelægger du cachen
Hold værktøjsdefinitioner stabile — tilføj/fjern ikke værktøjer dynamisk ved runtime
Brug rullende vindue til samtalehistorik — cache de første N beskeder, kun den nyeste besked er et cache miss

10. Tjeklisten

Når du har skrevet din system-prompt, så gennemgå den med denne tjekliste:

Struktur

Er identiteten helt i toppen?
Er sikkerhedsbegrænsninger markeret med IMPORTANT og gentaget til sidst?
Er der klar adskillelse af sektioner med overskrifter?
Er eksempler pakket ind i <example>-tags?

Token-budget

Er din del < 6.000 tokens?
Undgår du at gentage information, der allerede findes i værktøjsdefinitionerne?
Indlæses domæneviden on-demand i stedet for at være pre-loaded?
Er der ingen overflødig "lore" eller baggrundshistorie for karakteren?

Regelkvalitet

Kan hver regel testes som sand/falsk?
Bruger hårde begrænsninger absolut sprog (NEVER/MUST)?
Bruger bløde forslag anbefalingssprog (recommended/prefer)?
Forklarer kritiske regler hvorfor, ikke kun hvad?
Er der tosidede begrænsninger (gør dette + gør ikke det der)?

Agent-adfærd

Er der givet principper, ikke rigide trin-for-trin procedurer?
Er scenariet "værktøjskald afvist" håndteret?
Er strategien for "stødt på forhindring" håndteret (undgå brute-force retries)?
Er der en strategi for håndtering af kontekst på plads (tærskel for opsummering)?

Hvad du IKKE skal gøre

Ingen smiger eller superlative adjektiver?
Ingen overflødige "du er en hjælpsom AI"-deklarationer?
Ikke skrevet som en prompt-chain?
Ingen over-engineering (features ingen har bedt om)?

Hvis jeg startede forfra i dag

Her er præcis, hvad jeg ville gøre:

Start med identitet + sikkerhed i de første 3 linjer. To sætninger om, hvem agenten er. Hårde begrænsninger med NEVER/MUST. Gentag sikkerhedsreglerne til sidst.
Skriv dit kerne-workflow som principper, ikke trin. Maks. 4-5 punkter. Brug "recommended" og "prefer" til bløde regler, "NEVER" og "MUST" til hårde.
Budgetter 1.500-6.000 tokens til din del. Værktøjsdefinitioner vil tilføje 5.000-15.000 mere. Hvis du er over 6K, dumper du sandsynligvis viden, der burde indlæses on-demand.
Strukturer alt. Markdown-overskrifter, punktopstillinger, XML-tags til eksempler. En struktureret prompt udkonkurrerer naturlig sprogprosa hver gang.
Indbyg påmindelser midt i samtalen fra dag ét. Deklarer <system-reminder> i din system-prompt. Injicer påmindelser for kritiske regler, tilstandsskift og kontekstopdateringer.
Design til cache. Statisk indhold først, dynamisk indhold sidst. Placer aldrig skiftende værdier i selve din system-prompt.

Det ironiske ved alt dette arbejde? De bedste system-prompts er korte. Claude Codes tilpassede instruktioner (eksklusive værktøjsdefinitioner) er overraskende kortfattede. Hver linje gør sig fortjent til sin plads.

Jeg troede engang, at prompt-engineering handlede om at finde smarte tricks. Nu tror jeg, det handler om disciplin — at sige mindre, sige det præcist, og stole på, at modellen finder ud af resten. Modellen er klogere end din prompt. Design miljøet, ikke adfærden.

Referencer

Kilde	Nøgleindsigt
Claude Code v2.0.14 System Prompt	Fuld reference til struktur af en produktions-agent-prompt
Reddit: Understanding Claude Code's 3 System Prompt Methods	Dybdegående kig på Output Styles / --append / --system-prompt, data fra den virkelige verden om kontekst-forfald
shareAI-lab/learn-claude-code	"Modellen er agenten"-filosofien, metodologi for harness-engineering
Anthropic Prompt Engineering Docs	Officielle best practices for prompts
DeepAgents Framework	Middleware til opsummering, progressiv afsløring af skills