Så bygger jag master prompts för Claude Code
När jag började använda Claude i terminalen skrev jag gärna en stor prompt som skulle förklara hela uppgiften. Det fungerar för en engångsinsats.
När jag började använda Claude i terminalen skrev jag gärna en stor prompt som skulle förklara hela uppgiften. Det fungerar för en engångsinsats. Problemet kommer när samma arbetssätt används för ett projekt som pågår i veckor: prompten blir både kravspecifikation, historik, stilguide, TODO-lista och säkerhetspolicy på samma gång.
Min version av en master prompt har därför förändrats. Den ska inte innehålla allt. Den ska styra arbetet mot rätt varaktiga artefakter.
Master prompten ska etablera kontraktet
Jag vill normalt få med sex saker tidigt:
Det gör att agenten vet vad "klart" betyder innan den börjar optimera implementationen.
Berätta vilka filer som ska bli permanenta
Om en regel ska gälla nästa vecka ska den inte bara leva i dagens chatturn. Jag instruerar därför Claude att skriva bestående beslut till rätt plats: exempelvis CLAUDE.md, en spec, ett ADR, en Skill eller ett test.
Master prompten kan säga:
Det minskar behovet av att återberätta hela projektet i varje session.
Kräv inspection före implementation
I codebase-arbete vill jag att Claude först undersöker nuvarande lösning. Inte anta att projektet följer samma struktur som ett nytt exempelrepo.
Anthropic rekommenderar i sin promptguidance — en sida som kan uppdateras eller byta namn över tid — tydliga, explicita instruktioner och att modellen undersöker relevanta filer innan den gör påståenden om kod den inte har läst. Jag gör det till en hård regel i audit-/enhance-prompts:
Separera krav från metod
En dålig master prompt specificerar både resultatet och exakt hur agenten måste tänka i varje steg. Det kan låsa modellen vid min första idé.
Jag försöker vara hård på constraints och acceptance criteria, men mjukare på implementeringsmetoden när flera lösningar är rimliga.
Exempel:
Lägg evals i prompten, inte bara ambitioner
"Gör den robust" är inte ett test. Jag vill hellre beskriva vilka failure cases som ska överleva implementationen.
För en content-Skill kan det vara:
- saknad first-hand evidence -> NOT READY,
- tidskänslig claim utan primärkälla -> BLOCKED,
- humanizer ändrar säkerhetsgrad -> FAIL,
- två liknande briefs -> cannibalization review.
Då kan agenten faktiskt verifiera sitt arbete.
Undvik superpromptens vanligaste fälla
Ju mer jag lagt i master prompts, desto tydligare har ett problem blivit: modellen kan uppfylla 90 procent och missa en liten men kritisk regel långt upp i texten.
Därför bryter jag ut stabila delsystem. Research-policy blir en referensfil. Editorial-policy blir en Skill. Databasregler blir schema/docs. Detaljerade states blir kod.
Master prompten blir då en orchestrator, inte en encyklopedi.
Min defaultstruktur
Jag börjar ofta med:
Sedan ber jag agenten börja med inspection och gap analysis, inte implementation.
Det gör prompten längre än "bygg detta", men mycket kortare än att försöka bära hela projektets kunskap i en enda textvägg. Och framför allt: det som lärs under arbetet kan flytta in i permanenta artefakter i stället för att dö med sessionen.