Den kompletta guiden till att skriva systemprompter för agenter — Lärdomar från reverse engineering av Claude Code

Jag dekompilerade Claude Codes systemprompt, studerade DeepAgents källkod och byggde min egen AI-agent från grunden. De flesta prompt-guider är bara fluff.

Det pågår en massillusion inom AI just nu.

Varje tutorial säger åt dig att skriva system-prompts som om du kastade en trollformel — hitta bara rätt ramsa så kommer modellen att lyda. "Du är en EXTREMT BEGÅVAD senior utvecklare med 20 års erfarenhet..." Låter det bekant?

Jag har tillbringat de senaste månaderna med att bygga VibeCom, en AI-rådgivare för startups som kör djup marknadsresearch och genererar VC-klassad analys. Längs vägen har jag reverse-engineerat Claude Codes system-prompt, plöjt igenom DeepAgents middleware-källkod och bränt fler API-krediter än jag vill erkänna. Den största läxan? Det mesta folk tror spelar roll när det gäller system-prompts gör faktiskt inte det. Och de saker som faktiskt spelar roll är det nästan ingen som pratar om.

Det här inlägget är den kompletta spelboken — inte en 5-minuters översikt, utan allt jag önskar att någon hade berättat för mig innan jag började. Hämta en kaffe.

1. Designfilosofi: Lita på modellen

"En agent är en modell. Inte ett ramverk. Inte en prompt-kedja." — shareAI-lab/learn-claude-code

Den här insikten förändrade allt för mig. LLM:en vet redan hur man resonerar, planerar och exekverar. Din system-prompt lär den inte att tänka — den sätter upp miljön som den ska arbeta i.

Tänk på det som att anställa en senior utvecklare. Du ger dem inte en checklista på 20 steg för varje uppgift. Du säger: det här är vilka vi är, här är gränserna, så här ser ett bra resultat ut. Sedan kliver du ur vägen.

Din system-prompt har exakt fyra jobb:

Berätta vem den är — roll och identitet
Berätta var väggarna finns — säkerhetsbegränsningar
Berätta hur bra ser ut — kvalitetsstandarder
Ge den verktyg — kapabiliteter och kunskap

Det är allt. Allt annat är brus.

"Harness"-tänket

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

Din system-prompt är instruktionsboken för denna "harness" (sele/arbetsmiljö). Du designar inte en stel pipeline — du designar en miljö där modellen kan göra sitt bästa arbete autonomt.

Skriv inte din system-prompt som ett flödesschema. Modellen kommer själv att bestämma exekveringsordningen.

2. Prompt-struktur och sektionsordning

Den rekommenderade strukturen (Reverse-engineerad från Claude Code v2.0.14)

┌─────────────────────────────────────────────┐
│ 1. Identity                                  │  ← Läs först, förankrar beteende
│ 2. Security & Safety                         │  ← VIKTIGA markörer, okränkbara
│ 3. Tone & Style                              │  ← Kontrollerar utdataformat
│ 4. Core Workflow                             │  ← Hur arbetet ska utföras
│ 5. Tool Usage Policy                         │  ← Prioriteringar för verktygsval
│ 6. Domain Knowledge                          │  ← Vid behov, laddas inte i förväg
│ 7. Environment Info                          │  ← Runtime-kontext, injiceras dynamiskt
│ 8. Reminders                                 │  ← Upprepa kritiska regler
├─────────────────────────────────────────────┤
│ [Tool Definitions — system-injected]         │  ← Ej redigerbara, oftast väldigt långa
├─────────────────────────────────────────────┤
│ [User Message]                               │
└─────────────────────────────────────────────┘

Varför den här ordningen spelar roll

LLM:er har en U-formad uppmärksamhetskurva — de lägger mest märke till början och slutet av din prompt, och tappar fokus i mitten. Detta är "Lost in the Middle"-effekten, och den är väldokumenterad.

Identitet + Säkerhet i toppen: Modellen etablerar roll och gränser först (primacy-effekten)
Kärnflöde (Core Workflow) i övre mitten: Din viktigaste sektion — hur agenten utför sitt arbete
Verktygsdefinitioner injiceras av systemet efter din prompt: Claude Codes verktygsdefinitioner slukar ~11 438 tokens. Detta innebär att ditt anpassade innehåll faktiskt hamnar närmare början än du kanske tror — vilket hjälper följsamheten
Påminnelser i botten: Utnyttja "recency bias" (närhetseffekten) för att förstärka kritiska regler

3. Att skriva varje sektion

3.1 Identitet — Vem är den här agenten?

Mål: Förankra modellens roll på 1-3 meningar.

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

Riktlinjer:

Håll det kortfattat — max 1-3 meningar
Namnge rollen explicit (hjälper modellen att skilja på kontexter)
Ange huvudansvaret ("hjälper till med X"), inte ett vagt "du är en hjälpsam assistent"
Nämn SDK/plattform om tillämpligt ("byggd på Anthropics Claude Agent SDK")

Anti-mönster:

"Du är en hjälpsam, ofarlig och ärlig AI-assistent" — för generiskt, ingen förankring i rollen
Ett helt stycke med bakgrundshistoria och "lore" — slösar tokens, modellen behöver ingen karaktärsutveckling

3.2 Säkerhet & Skydd — De hårda gränserna

Mål: Sätt okränkbara beteendegränser.

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.

Riktlinjer:

Använd prefixet IMPORTANT: — Claudes träning för instruktionshierarki ger detta extra vikt
Använd absolut språk: NEVER, MUST NOT, Refuse to
Ange både vad som är tillåtet OCH vad som är förbjudet (dubbelriktade gränser är tydligare)
Placera allra högst upp, begrav det inte i mitten
Upprepa kritiska säkerhetsregler på slutet — Claude Code gör exakt detta

Varför upprepa? Primacy-effekten (början) + Recency-effekten (slutet) = dubbel förstärkning. Claude Codes säkerhetsdeklaration dyker upp både i början och i slutet av prompten. Inte för att utvecklarna var glömska — utan för att de förstår den U-formade uppmärksamhetskurvan.

3.3 Ton & Stil — Att kontrollera output

Mål: Kontrollera utdataformat och röst.

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

Riktlinjer:

Lista specifika beteenden, inte ett vagt "var professionell"
Varje regel bör vara testbar som sant/falskt ("kort och koncis" vs. "försök att vara kortfattad")
Inkludera krav på utdataformat (markdown? JSON? ren text?)
Inkludera vad den INTE ska göra — många stilproblem handlar om att förbjuda beteenden

Claude Codes guldklimp — Professionell 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.

Det här stycket är avgörande: det blockerar modellens tendens att vara inställsam (sycophancy). Om din agent behöver ge objektiva bedömningar (code review, idéutvärdering, arkitekturbeslut) behöver du absolut en liknande klausul.

3.4 Kärnflöde (Core Workflow) — Den viktigaste sektionen

Mål: Lär modellen hur den ska arbeta — metodik, inte stela procedurer.

Det här är den svåraste sektionen att skriva bra, och den som ger mest effekt när du får till den.

Kärnprincipen: ge principer, inte procedurer.

Berätta för LLM:en hur bra utdata ser ut och varför det är bra — låt den själv räkna ut hur den ska ta sig dit. Undvik att föreskriva exakta fältantal, stegsekvenser eller format, såvida inte utdatan ska konsumeras av maskiner längre ner i kedjan.

Claude Codes tillvägagångssätt:

## 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ägg märke till ordet "recommended" (rekommenderas) — inte "du måste följa dessa exakta steg". Det enda ordvalet ger modellen utrymme att anpassa sig.

En bra definition av arbetsflödet:

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

Varje regel har ett implicit "varför" — modellen kan förstå avsikten och generalisera till nya scenarier.

Anti-mönster:

En stel procedur på 20 steg — modellen kommer att exekvera mekaniskt och frysa vid oväntad input
"Gör först A, gör sedan B, gör sedan C" — det är en prompt-kedja, inte en agent-prompt
Att överstyra saker som LLM:en redan är bra på — slösar tokens

Jag lärde mig detta den hårda vägen med VibeCom. Tidiga versioner hade ett research-flöde på 10 steg. Modellen utförde plikttroget alla 10 steg även när steg 3 redan hade besvarat användarens fråga. När jag bytte till principer ("researcha tills du har tillräckligt med bevis, syntetisera sedan") gick kvaliteten upp och token-kostnaderna ner.

Undantaget: När utdatan konsumeras av maskiner längre ner i kedjan (kommunikation mellan agenter, API-svarsformat) bör du definiera strikta format. Principer är för beteende; scheman är för gränssnitt.

3.5 Policy för verktygsanvändning — Att lösa tvetydigheter

Mål: När flera verktyg kan göra samma sak, berätta för modellen vilket den ska föredra.

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

Riktlinjer:

Använd "istället för" (instead of) för att uttrycka prioritet (A istället för B)
Förklara varför den ska föredra vissa verktyg ("ger en bättre användarupplevelse", "minskar kontextanvändningen")
Definiera strategi för parallellism (oberoende → parallellt, beroende → sekventiellt)
Lista säkerhetsbegränsningar för verktygsanvändning (sökvägsvalidering, behörighetskontroller)

Den avgörande relationen mellan verktyg och prompts:

Verktygsdefinitioner injiceras vanligtvis av systemet och du kan inte redigera dem direkt. Claude Codes verktygsdefinitioner är på ~11 438 tokens. Detta innebär:

Upprepa inte information som redan finns i verktygsdefinitionerna
Använd system-prompten för strategisk vägledning: när varje verktyg ska användas, varför man ska föredra ett framför ett annat, prioriteringsordning
Kvaliteten på verktygsdefinitionen påverkar direkt agentens effektivitet — om du bygger din egen agent, investera tid i att skriva utmärkta verktygsbeskrivningar

3.6 Domänkunskap — Ladda vid behov, inte i förväg

Mål: Tillhandahåll specialiserad kunskap som modellens träningsdata kanske saknar.

Kärnprincipen: progressivt avslöjande (progressive disclosure), inte kunskapsdumpar.

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

Denna strategi delas av Claude Codes Skills-system och DeepAgents Progressive Disclosure-middleware. Båda laddar kunskap vid behov genom verktygsanrop snarare än att ladda allt i förväg.

Implementeringsmetoder:

Lägg in pekare i system-prompten: "Använd verktyget get_api_docs för att hämta dokumentation vid behov"
Använd CLAUDE.md / AGENTS.md för projektkontext — laddas vid runtime, hårdkodas inte
Använd Skills / SKILL.md för upptäckt av kapabiliteter — modellen ser en meny av tillgängliga färdigheter och hämtar fullständiga specifikationer vid behov

3.7 Miljöinformation — Runtime-kontext

Mål: Ge modellen medvetenhet om sin exekveringsmiljö.

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

Riktlinjer:

Generera dynamiskt, hårdkoda aldrig
Inkludera: arbetskatalog, plattform, datum, modellnamn, git-status
Använd strukturerat format (XML-taggar eller kodblock) för enkel parsning
Datum spelar roll — modellen behöver veta när "nu" är för att bedöma hur färsk informationen är

3.8 Påminnelser — Den sista förstärkningen

Mål: Upprepa de mest kritiska reglerna i slutet av prompten.

Claude Code upprepar sin säkerhetsbegränsning och TodoWrite-krav i botten:

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

Riktlinjer:

Upprepa bara 2-3 av de allra viktigaste reglerna — duplicera inte allt
Utnyttja recency bias — modellen minns nyligen läst innehåll starkare
Bästa kandidaterna: säkerhetsgränser, regler som oftast bryts, påminnelser om kärnflödet

4. Token-budget och kontexthantering

Referens för budgetallokering

Sektion	Rekommenderade tokens	Anteckningar
Identitet + Säkerhet	200-500	Kortfattat men okränkbart
Ton & Stil	300-800	Regler måste vara specifika, men svamla inte
Kärnflöde	500-2 000	Viktigaste sektionen, värd investeringen
Policy för verktyg	300-1 000	Beror på antalet verktyg
Domänkunskap	0-1 000	Laddning vid behov föredras
Miljöinformation	100-300	Genereras dynamiskt
Påminnelser	100-300	Upprepa bara det allra viktigaste
Din total	1 500-6 000
Verktygsdefinitioner (system)	5 000-15 000	Utom din kontroll

Kontextens nedbrytningskurva

Community-tester (Reddit u/CodeMonke_) har kartlagt hur följsamheten faktiskt bryts ner i praktiken:

< 80K tokens: Prompt-följsamheten förblir stabil
80K - 120K tokens: Förmågan att följa instruktioner börjar försämras
> 120K tokens: Betydande försämring — modellen "glömmer" tidiga instruktioner
> 180K tokens: Allvarlig försämring

Ditt kontextfönster på 200K ≠ 200K av effektiv kontext. Planera därefter.

Strategier för att mildra detta:

Håll din system-prompt slimmad (< 6 000 tokens för din del)
Använd summering för att komprimera konversationshistoriken (DeepAgents triggar vid ~80K tecken)
Placera kritiska regler i båda ändarna av prompten (U-formad uppmärksamhet)
Injicera <system-reminder>-taggar mitt i konversationen (mer om detta i sektion 8)

5. Skrivprinciper

5.1 Ge principer, inte 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."

Principer går att generalisera. Procedurer kan bara följas mekaniskt. När modellen stöter på en situation du inte förutsett, vägleder principer till rätt beslut. Det gör inte procedurer.

Undantag: När utdata konsumeras av maskiner (kommunikation mellan agenter, API-format), definiera strikta scheman.

5.2 Använd absolut språk för hårda gränser

Styrka	Språk	Används för
Absolut förbud	`NEVER`, `MUST NOT`	Säkerhet, oåterkalleliga operationer
Starkt krav	`ALWAYS`, `MUST`	Regler för kärnflödet
Rekommendation	`recommended`, `prefer`	Best practices med undantag
Förslag	`consider`, `you may`	Valfria optimeringar

Claude Code-exempel:

NEVER update the git config — absolut förbud
ALWAYS prefer editing an existing file — starkt, men undantag finns
The following steps are recommended — föreslaget arbetsflöde

5.3 Använd exempel istället för förklaringar

## 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 exempel lär ut mer än 100 ord av förklaringar:

Modeller lär sig mönster från exempel mer tillförlitligt än från abstrakta beskrivningar
Slå in i <example>-taggar för att separera från regler
Ge både positiva ("gör så här") och negativa ("gör inte så här") exempel
Använd riktiga, specifika exempel — inte "foo/bar"-platshållare

5.4 Dubbelriktade gränser

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

Att bara säga "gör detta" → modellen vet inte när den INTE ska göra det. Att bara säga "gör inte detta" → modellen känner inte till alternativet. Dubbelriktat → tydligt och otvetydigt.

5.5 Förklara varför, inte bara vad

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

Att förklara varför låter modellen göra korrekta bedömningar i edge cases. Claude Codes git-säkerhetsprotokoll är en masterclass — varje regel antyder sin egen logik.

5.6 Struktur framför prosa

Markdown-rubriker (##, ###) — modeller känner igen hierarki
Punktlistor framför textstycken — varje regel kan testas oberoende
XML-taggar för speciellt innehåll: <example>, <env>, <system-reminder>
Tabeller för jämförelser och mappningar
Dumpa aldrig ostrukturerad text — strukturerade prompts överträffar konsekvent naturlig prosa i tester av följsamhet

6. Anti-mönster som slösar dina tokens

Prompt-kedjor förklädda till 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."

Det här är ingen agent-prompt — det är ett pipeline-script. Modellen kommer att exekvera mekaniskt och förlora sin autonoma planeringsförmåga.

Lösningen: Berätta för modellen vad målet och begränsningarna är. Låt den själv bestämma stegen.

Smicker-engineering (Flattery Engineering)

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

Komplimanger och superlativ förbättrar inte utdatakvaliteten. Modellen har inget ego som behöver boostas. Spara de 15 tokens till en faktisk regel.

Kunskapsdumpar

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

Detta slukar ditt kontextfönster och påskyndar kontextröta (context rot). Ersätt med laddning vid behov:

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

Att upprepa verktygsbeskrivningar

Om verktygsdefinitionen redan säger "Read-verktyget läser en fil från filsystemet", säg det inte igen i din system-prompt. Lägg bara till strategisk vägledning som verktygsdefinitionen inte täcker — när det ska användas, varför man ska föredra det, prioriteringsordning.

Saknad felhantering

Utan explicit vägledning kommer modeller att försöka göra om misslyckade verktygsanrop i en oändlig loop. Inkludera 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."

Att ignorera kontextfönstrets förfall

200K kontextfönster ≠ 200K effektiv kontext. Tester i verkligheten visar att försämringen börjar vid 80K. Du behöver en strategi för summering.

7. Injiceringspunkter och prioritet

Claude Codes tre anpassningsmetoder

Metod	Ersätter	Placering	Bäst för
Output Styles	"Tone and style" + "Doing tasks"-sektionerna	Precis före verktygsdefinitionerna	Att ändra interaktionsstil
--append-system-prompt	Ingenting (additivt)	Efter output style, före verktygsdefinitioner	Att lägga till specifika beteenden
--system-prompt	Hela system-prompten	Behåller verktygsdefinitioner + en identitetsrad	Fullständig anpassning (the nuclear option)

Om du använder flera: Output Style → Append Prompt → Tool Definitions

Instruktionshierarki

Claude är specifikt tränad med en instruktionshierarki:

1. User's explicit instructions (CLAUDE.md, direct requests)  ← Högsta prioritet
2. Custom system prompt additions                               ← Hög
3. Default system prompt                                        ← Medium
4. Tool definitions                                             ← Referensnivå

Detta innebär:

CLAUDE.md-regler åsidosätter standardbeteendet i system-prompten
Användarens direkta förfrågningar åsidosätter allt
Din anpassade prompt åsidosätter standardprompten

Dynamiska injiceringsmekanismer

<system-reminder> — injicera i valfritt meddelande mitt i konversationen för att påminna modellen om kritiska regler
CLAUDE.md / AGENTS.md — laddas vid runtime från filer, läggs till i system-prompten
Skills / SKILL.md — laddas vid behov via verktygsanrop, noll avtryck i system-prompten

8. Injicering mitt i konversationen — Det hemliga vapnet

System-prompten dyker bara upp en gång, allra först i meddelande-arrayen. Men LLM:er accepterar hela meddelande-arrayen (alternerande användar- / assistent- / verktygsmeddelanden) som input, och du kan injicera prompts i användarmeddelanden och verktygsresultat också. Claude Code använder denna teknik flitigt i produktion.

Varför det är nödvändigt

Att bekämpa kontextröta. När konversationer blir längre försämras modellens förmåga att följa system-promptens instruktioner (märkbart vid 80K+ tokens). Att injicera påminnelser mitt i konversationen = att uppdatera reglerna via recency bias.

Den mentala modellen:

System-prompt = grundlagen (etableras en gång, långsiktig auktoritet)
Påminnelser i användarmeddelanden = PM/Memos (skickas periodiskt, upprätthåller efterlevnad)

Tre injiceringspunkter i meddelande-arrayen

Messages Array:
┌─────────────────────────────────────┐
│ System-prompt                       │ ← Syns en gång, primacy-effekt
│   (identity, safety, workflow...)   │
├─────────────────────────────────────┤
│ Användarmeddelande 1                │
│ Assistentmeddelande 1               │
│ Användarmeddelande 2 + <system-reminder>  │ ← Injicering mitt i konversationen
│ Assistentmeddelande 2               │
│ Verktygsresultat + <system-reminder>     │ ← Kan injiceras i verktygsresultat också
│ ...                                 │
│ Användarmeddelande N + <system-reminder>  │ ← Senaste meddelandet, starkast recency-effekt
└─────────────────────────────────────┘

Plats	Fördel	Nackdel
System prompt	Primacy-effekt, läses först	Syns en gång, "glöms bort" i långa konversationer
User message injection	Recency bias, periodisk uppdatering	Varje injicering kostar tokens
Tool result injection	Mest naturliga injiceringspunkten	Fungerar bara när verktyg anropas

Hur Claude Code faktiskt använder det

Förutsättning — deklarera taggarna 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.

Detta steg är kritiskt: det talar om för modellen att dessa taggar är systeminjicerade, inte användarens tal.

Användning 1: Beteendepåminnelser (periodisk regeluppdatering)

<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 använder detta för att påminna modellen om att planera med TodoWrite — eftersom modeller tenderar att "glömma" planeringen och bara börja koda.

Användning 2: Lägesväxling (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 (planeringsläge) implementeras inte i system-prompten. Det är en tagg som injiceras i nästa användarmeddelande. Detta låter dig växla lägen dynamiskt utan att modifiera system-prompten. Genialiskt.

Användning 3: Notifieringar om filändringar

<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 extern process (linter, formaterare, manuell redigering) modifierar en fil, meddelar systemet modellen via en påminnelse — vilket förhindrar beslut baserade på inaktuellt filinnehåll.

Användning 4: Dynamisk kontext (datum, projektregler)

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

Runtime-kontext (datum, git-status, projektregler) injiceras via användarmeddelanden, den hårdkodas inte i system-prompten.

Riktlinjer för att skriva påminnelser

Slå in i XML-taggar (<system-reminder>) — modellen kan skilja systeminjicering från användarens tal
Fördeklarera taggar i system-prompten — annars kan modellen försöka svara på påminnelsen
Injicera inte i varje meddelande — varje injicering kostar tokens, injicera bara när det behövs
Håll det kort — en påminnelse är inte en andra system-prompt, bara 1-2 kritiska regler
Motsäg inte system-prompten — påminnelser kompletterar och förstärker, de åsidosätter inte
Använd för dynamisk växling — plan mode, readonly mode, feature flags

När man ska använda System Prompt vs. User Message Reminder

Scenario	System Prompt	User Message Reminder
Rolldefinition	✅	❌
Säkerhetsgränser	✅ Första deklarationen	✅ Periodisk upprepning
Arbetsflödesmetodik	✅	❌
Lägesväxling (plan mode)	❌	✅
Notifieringar om filändringar	❌	✅
Datum / miljöinformation	✅ Initialt värde	✅ Uppdaterat värde
Beteendekorrigering	❌	✅
Påminnelser om verktygsanvändning	✅ Regeldefinition	✅ Exekveringsknuffar (nudges)

9. Prompt Cache — Spara 90% på återkommande tokens

Anthropics prompt caching låter dig cacha det statiska prefixet av din meddelande-array. När efterföljande förfrågningar delar samma prefix träffar de cachen — vilket sparar pengar och minskar latensen.

För agenter spelar detta stor roll: du skickar om system-prompten + verktygsdefinitionerna vid varje enskilt LLM-anrop inom en konversation.

Viktiga siffror

Mätvärde	Värde
Kostnad vid cache-träff	10% av normalpriset (90% besparing)
Kostnad för cache-skrivning	125% av normalpriset (25% påslag vid första skrivningen)
Cache TTL	5 minuter (löper ut om inga förfrågningar görs)
Minsta cachebara längd	1 024 tokens (Claude 3.5+)
Cache-granularitet	Prefix-matchning — från början till en markerad brytpunkt (breakpoint)
Maximala brytpunkter	4

Hur detta förändrar prompt-design

Kärnprincip: statiskt innehåll först, dynamiskt innehåll sist.

✅ Cache-vänlig layout:
  System-prompt (statisk)      ← Cache-brytpunkt 1
  Verktygsdefinitioner (statiska)   ← Cache-brytpunkt 2
  CLAUDE.md / projektregler   ← Cache-brytpunkt 3 (ändras ibland)
  Konversationshistorik         ← Brytpunkt 4 för rullande fönster

❌ Cache-förstörande layout:
  System-prompt
  DYNAMIC TIMESTAMP            ← Ändras vid varje request, allt efter = cache-miss
  Verktygsdefinitioner
  Konversationshistorik

Fällan ingen varnar dig för: Om du lägger en dynamisk tidsstämpel mitt i din system-prompt blir allt efter den en cache-miss. Vid. Varje. Request. En tidsstämpel på fel ställe och du betalar fullt pris för tusentals tokens.

API-användning

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

Strategi för flera brytpunkter

Brytpunkt 1: System-prompt           ← Ändras nästan aldrig
Brytpunkt 2: Verktygsdefinitioner         ← Ändras nästan aldrig
Brytpunkt 3: Projektregler / CLAUDE.md ← Ändras ibland
Brytpunkt 4: De första N historikmeddelandena  ← Rullande fönster-cache

Även när konversationshistoriken ändras, träffar de första 3 brytpunkterna fortfarande. En konversation på 10 turer sparar ungefär 40-60% på input-token-kostnader.

Designrekommendationer

Inga högfrekventa dynamiska värden i system-prompten — datum är okej (ändras dagligen), exakta tidsstämplar är det inte
Lägg dynamisk kontext (git-status, etc.) i injiceringar i användarmeddelanden — inte i system-prompten, annars förstör du cachen
Håll verktygsdefinitioner stabila — lägg inte till/ta bort verktyg dynamiskt vid runtime
Använd rullande fönster för konversationshistorik — cacha de första N meddelandena, bara det nyaste meddelandet blir en cache-miss

10. Checklistan

Efter att du har skrivit din system-prompt, granska den mot den här checklistan:

Struktur

Ligger identiteten allra högst upp?
Är säkerhetsgränserna markerade med IMPORTANT och upprepade på slutet?
Tydlig sektionsuppdelning med rubriker?
Är exempel inslagna i <example>-taggar?

Token-budget

Är din del < 6 000 tokens?
Upprepar du inte information som redan finns i verktygsdefinitionerna?
Laddas domänkunskap vid behov, istället för att laddas i förväg?
Ingen onödigt lång "lore" eller karaktärsbakgrund?

Regelkvalitet

Är varje regel testbar som sant/falskt?
Använder hårda gränser absolut språk (NEVER/MUST)?
Använder mjuka förslag rekommendationsspråk (recommended/prefer)?
Förklarar kritiska regler varför, inte bara vad?
Dubbelriktade gränser (gör detta + gör inte detta)?

Agentbeteende

Ges principer, inte stela steg-för-steg-procedurer?
Har du hanterat scenariot "verktygsanrop nekades"?
Har du hanterat strategin för "stötte på hinder" (försök inte tvinga igenom det med brute-force)?
Finns en strategi för kontexthantering på plats (tröskelvärde för summering)?

Vad du INTE ska göra

Inget smicker eller superlativa adjektiv?
Inga överflödiga "du är en hjälpsam AI"-deklarationer?
Inte skriven som en prompt-kedja?
Ingen over-engineering (funktioner ingen bett om)?

Om jag började idag

Här är exakt vad jag skulle göra:

Börja med identitet + säkerhet på de första 3 raderna. Två meningar för vem agenten är. Hårda gränser med NEVER/MUST. Upprepa säkerhetsreglerna på slutet.
Skriv ditt kärnflöde som principer, inte steg. Max 4-5 punkter. Använd "recommended" och "prefer" för mjuka regler, "NEVER" och "MUST" för hårda.
Budgetera 1 500-6 000 tokens för din del. Verktygsdefinitioner kommer att lägga till 5 000-15 000 till. Om du är över 6K dumpar du förmodligen kunskap som borde laddas vid behov.
Strukturera allt. Markdown-rubriker, punktlistor, XML-taggar för exempel. En strukturerad prompt slår naturlig prosa varje gång.
Bygg in påminnelser mitt i konversationen från dag ett. Deklarera <system-reminder> i din system-prompt. Injicera påminnelser för kritiska regler, lägesväxlingar och kontextuppdateringar.
Designa för cache. Statiskt innehåll först, dynamiskt innehåll sist. Lägg aldrig föränderliga värden i själva system-prompten.

Ironin i allt detta arbete? De bästa system-promptarna är korta. Claude Codes anpassade instruktioner (exklusive verktygsdefinitioner) är förvånansvärt koncisa. Varje rad förtjänar sin plats.

Jag brukade tro att prompt engineering handlade om att hitta smarta trick. Nu tror jag att det handlar om disciplin — att säga mindre, säga det exakt, och lita på att modellen räknar ut resten. Modellen är smartare än din prompt. Designa miljön, inte beteendet.

Referenser

Källa	Nyckelinsikt
Claude Code v2.0.14 System Prompt	Referens för prompt-struktur för agenter i produktion
Reddit: Understanding Claude Code's 3 System Prompt Methods	Djupdykning i Output Styles / --append / --system-prompt, verklig data på kontextröta
shareAI-lab/learn-claude-code	Filosofin "modellen är agenten", metodik för harness engineering
Anthropic Prompt Engineering Docs	Officiella best practices för prompts
DeepAgents Framework	Middleware för summering, progressivt avslöjande av färdigheter (skills)