Specdriven utveckling med Claude Code: En guidad handledning

Vad är specdriven utveckling?

Specdriven utveckling är ett arbetsflöde byggt på tre dokument i ordning: ett som berättar vad en ändring ska göra, en plan som specificerar stegen och kod som skrivs utifrån planen, med mänsklig granskning mellan varje par.

De tre granskningspunkterna en funktion passerar i specdriven utveckling.

En spec är ett kort dokument, skrivet på klarspråk innan någon kod, som säger vad en ändring ska göra. Ta en funktion som ”låt användare exportera sina data”. En spec för den låser ner svar som en agent annars hade gissat. Den listar 

• Stödda filformat
• Leveranssätt
• Beteende under en halvfärdig export
• De delar av funktionen som medvetet lämnas utanför

Här är den verkliga inledningen av en spec som Claude Code skrev för en workout-shape-verification-ändring i en Telegram-baserad ansvarighetsapp jag byggt. Ändringen ersätter en skör pulströskel med en kontroll av formen på pulskurvan över tid:

# Workout Shape-Based Verification — Design Spec
 
**Created:** 2026-05-05
**Status:** Draft
**Supersedes (partially):** [2026-03-17-calisthenics-verification-design.md]
  — replaces the absolute-HR thresholds for the Workout activity type.
  Run / Ride / Walk verification is unchanged.
 
## Problem
 
The current Workout verifier accepts an activity only if absolute heart-rate
levels clear fixed cutoffs: avg ≥ 120, max ≥ 140, range ≥ 30, suffer_score ≥ 3.
Two failures in production:
 
1. **False-negative risk.** As cardiovascular fitness improved
   (resting HR ~80), real calisthenics sessions with disciplined rest now
   average 115–125 bpm. Recent sessions have come within 4 bpm of the 120 floor.
 
<!-- ... continues for hundreds of lines through Solution, Risks,
 	Out of scope, and What is removed / added / changed / unchanged -->

Planen är nästa dokument. Den bryter ned specen ovan i numrerade uppgifter som agenten kan arbeta med en i taget, där varje uppgift namnger en fil, en ändring, en ordning och ett test. Där specen svarar på ”vad”, svarar planen på ”i vilka steg”. 

Koden kommer sist, skriven mot planen en uppgift i taget.

Tre dokument. En mänsklig granskning sitter mellan varje par. Du granskar specen innan den blir en plan. Du granskar planen innan den blir kod. Du granskar koden innan den mergas.

Hur specdriven utveckling skiljer sig från planläget

Du kanske har använt Claude Codes inbyggda planläge (tryck Skift+Tabb två gånger för att gå in) och undrat vad som skiljer. Planläget producerar en plan i en enda chattsväng. Planen lever i minnet, utan någon sparad spec och utan en granskningspunkt mellan faser.

Specdriven utveckling sparar både spec och plan som filer på disk. Var och en går igenom en mänsklig granskning innan nästa fas startar, och artefakterna överlever mellan sessioner. Planläget komprimerar två faser av mjukvaruutveckling till en chattsväng. Det fungerar för små jobb och fallerar så snart kodbasen växer och börjar betjäna riktiga användare.

Varför vibe-coding kör in i väggen

Vibe-coding fungerar för prototyper, enstaka filer och engångsskript. Det blir sämre i riktiga applikationer med användare att svara inför och i stora befintliga kodbaser. Den vettiga gränsen går vid cirka 4 filer. Varje ändring som berör så många filer behöver en spec, liksom alla refaktoreringar med ett tydligt slutläge, eller alla uppgifter där ”vad ska detta exakt göra?” är den svåra delen.

Misslyckandet har en tydlig orsak. En vag prompt som ”lägg till fotodelning i min app” får modellen att gissa tusentals outtalade krav.

Ta ett enda av de kraven: aviseringar. Produktägaren antar togglar per kanal. Backend bygger en på/av-brytare. Frontend antar OS-nivå-integration. Fyra rimliga tolkningar av tre ord, fyra olika produkter.

Varje granskningssteg i specdriven utveckling fångar en annan klass av misstag innan de blir dyra. Specgranskningen fångar scope creep och fel rotorsak. Plangranskningen fångar halvfärdiga implementationer och motstridiga mönster. Kodgranskningen fångar planer som ser bra ut men bryts vid första fallande testet.

Utdelningen är verklig, och den byggs långsamt. Specfasen kostar timmar av skrivande innan någon kod körs, och de första funktionerna känns långsammare än vibe-coding. Min egen brytpunkt kom runt den fjärde eller femte funktionen. Då fångade specifikationerna designmisstag jag annars hade skeppat och skrivit om en vecka senare.

De tre nästa avsnitten går igenom tre open source-ansatser som kör detta arbetsflöde i Claude Code. De är ordnade från lättast till tyngst i hur mycket struktur de tvingar fram.

Superpowers

Superpowers är den lättaste av de tre. Det är den jag använder till vardags, och den vi går igenom mest i detalj.

Vad är Superpowers?

Superpowers är ett Claude Code-plugin av Jesse Vincent (obra/superpowers, MIT-licens), med runt 194 k stjärnor på GitHub. 

Det levererar ett set av skills. En Claude-skill i Claude Code är en namngiven instruktionsfil som agenten laddar vid behov för att följa ett specifikt arbetsflöde. Superpowers skickar med skills som håller Claude Code i den specdrivna loopen istället för att låta den hoppa direkt till kod.

Superpowers projektsida på GitHub.

Hur du installerar Superpowers

Installera via Claude Codes officiella plugin-marknadsplats:

/plugin install superpowers@claude-plugins-official

En SessionStart-hook laddar automatiskt using-superpowers-skillen, så arbetsflödet är aktivt i samma stund som du börjar skriva. (Claude code hooks är skript som agenten kör vid ett visst livscykelögonblick.) Det finns inget att koppla per projekt.

Superpowers-arbetsflödet

Därefter hanterar fyra skills ditt dagliga arbete:

En subagent är en separat Claude Code-instans som föräldern skickar iväg för fokuserat arbete i sitt eget kontextfönster. Granskar-subagenterna i tabellen ovan körs som subagenter, så de läser koden kallt, utan förälderns inramning.

Hur du använder Superpowers

Du anropar de fyra skillsen genom att beskriva vad du vill på vanlig svenska. Brainstorming-skillsen hör ”låt oss diskutera den här nya funktionen” och startar specsamtalet av sig själv. De andra triggas på samma sätt.

De fyra Superpowers-skillsen i ordning, med de två mänskliga granskningspunkterna mellan brainstorming och writing-plans.

Genomgången nedan använder samma workout-shape-verification-funktion från specexemplet ovan.

Steg 1: brainstorma till spec

Jag öppnar Claude Code och skriver:

Let's discuss a new feature. The Workout verifier in make-me-work uses absolute heart-rate cutoffs and is now misfiring as my resting HR drops. I want to replace the absolute cutoffs with a check on the shape of the HR curve over the session.

brainstorming-skillsen tar över och ställer ett tiotal frågor tillbaka, bland annat:

• Vad som räknas som rätt ”form”
• Vilka dataströmmar som ska kombineras
• Vad som ska göras med pass som ser rätt ut i formen men faller på en gammal tröskel
• Om ändringen även ska gälla för Run och Ride

Två mänskliga granskningspunkter landar här. Den första är designgranskningen, där jag bekräftar att svaren jag gav stämmer med vad jag vill. Den andra är specgranskningen. Jag läser filen Claude har skrivit och godkänner den innan något planarbetet börjar.

Steg 2: spec till plan

Jag kör writing-plans-skillsen. Den läser den godkända specen och skriver en planfil med fyra delar:

• En definition av vad ”Klart” betyder
• En filkarta över berörda filer
• En användarresa genom demovägen
• En numrerad uppgiftslista med checkbox-delsteg. 

Jag granskar planen, invänder mot uppgifter som ser i fel ordning ut eller är för grova och godkänner.

Steg 3: plan till kod

Jag kör subagent-driven-development. Från och med nu rullar loopen utan mig. För varje uppgift i planen gör skillsen:

1. Skriver ett fallande test
2. Skriver koden för att få det att gå igenom
3. Refaktorerar
4. Skickar en kodgransknings-subagent som läser diffen kallt

Om granskaren flaggar ett problem fixar loopen det innan nästa uppgift. Det finns ingen mänsklig granskning inne i detta steg. De granskningar som spelar roll här är de två innan.

Steg 4: full diff-granskning

När planen är klar kör jag requesting-code-review. En ny subagent läser hela diffen mot spec och plan och postar en granskning. Jag tar till mig förslagen innan jag mergar.

När en uppgift i planen avslöjar en motsägelse mot specen, stannar loopen och frågar. Jag kan redigera specen (eller låta Claude göra det) och återskapa de berörda uppgifterna. Det andra alternativet är en engångskorrigering i själva uppgiften. Superpowers arbetar inte tyst runt specfel.

Riktiga specs och planer på disk

Här är specen för workout-shape-verification-funktionen, öppen i en editor:

Specfilen som den landar på disk efter att brainstorming-skillsen skrivit den.

Rubriken bär fälten Created, Status och Supersedes som brainstorming-skillsen skriver som standard. Problem-avsnittet följer. Inget av det är kod. Filen fortsätter bortom skärmdumpen med avsnitt för det föreslagna upplägget och begränsningarna för vad ändringen ska och inte ska röra.

Den matchande planen öppnar med sin User Journey:

Planfilen som writing-plans-skillsen producerar från den godkända specen.

Resan går igenom demovägen fem steg i taget, och namnger exakta kommandon, filer och argument vid varje steg. De numrerade uppgifterna som följer översätter varje steg till checkbox-delsteg som subagent-driven-development-skillsen kan arbeta sig igenom.

De två dokumenten parar ihop så här:

Spec och plan sida vid sida. Specen svarar på vad som ändras och varför. Planen svarar i vilka steg.

För större specs och planer lägger jag till ett steg som inte finns i den officiella loopen: en red-team-pass. Innan jag godkänner låter jag en eller flera Opus-subagenter läsa specen kallt och leta efter hål från olika vinklar. Det är en personlig vana, inte en Superpowers-funktion. Den har fångat tillräckligt många dåliga antaganden för att jag ska fortsätta med den.

När Superpowers är fel val

Superpowers passar solojobb i ett enda repo. Det fungerar bäst när hela kodbasen ryms i en Claude Code-session och du faktiskt kommer att läsa en tvåsidig spec. Den detaljerade jämförelsen finns i Hur du väljer mellan dem längre ner. Den korta versionen: Superpowers kämpar med multi-repo-funktioner och arbete som kräver tydlig rollseparation.

En utvecklare fångade ett fjärde felmönster i ett offentligt klagomål om pluginet: ”Till och med de minsta uppgifterna tar evigheter, med Claude som snurrar upp subagenter och skriver planer som är helt overkill. Att ändra lite CSS tar nu evigheter.”

Lösningen är att hoppa över Superpowers för pyttesmå ändringar. Skillsen aktiveras bara på brainstorming-triggers. En enraders CSS-ändring kan gå genom Claude Code utan att någonsin anropa specloopen. Det verkliga felmönstret där är att överanvända arbetsflödet för jobb som inte behöver en spec.

GitHub Spec Kit

Spec Kit är valet när specen måste överleva längre än en enskild Claude Code-session. Det är också rätt val när personer som aldrig öppnar Claude Code behöver läsa specen.

Vad är GitHub spec-kit?

Spec Kit är ett GitHub-projekt (github/spec-kit, MIT-licens), underhållet av GitHub självt, med över 100 k stjärnor. Det levererar ett CLI plus ett arbetsflöde som körs likadant över alla stora AI-kodningsagenter. Claude Code, Cursor, Aider, Cline och Roo Code stöds alla. Den agentneutrala designen är det som låter specen leva utanför Claude Code.

Spec Kit-projektsidan på GitHub.

Hur du installerar GitHub spec-kit

Det finns ännu inget officiellt PyPI-paket, så installera CLI:t från Git-taggen med uv:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

Byt ut vX.Y.Z mot aktuell releasetagg. Paketet heter specify-cli, och kommandot det registrerar är specify.

GitHub spec-kit-arbetsflödet

Arbetsflödet körs via nio snedstreckskommandon som CLI:t installerar i din agents slash-kommandolista. Sex är kärnan i loopen, tre är valfria för fall som kärnloopen inte täcker.

Separatorn mellan kommandogrupp och verb är en punkt, inte ett kolon: /speckit.specify, inte /speckit:specify. 

De nio Spec Kit-snedstreckskommandona: sex kärnkommandon på pipelinen, tre valfria som hänger på sidan.

Artefakterna dessa kommandon producerar är samma spec och plan som du såg i Superpowers-avsnittet, också skrivna till disk och spårade av Git. Skillnaden är portabiliteten: Spec Kits artefakter är designade att fungera med vilken AI-kodningsagent som helst, inte bara Claude Code, och arbetsflödet är byggt för intressentgranskning via GitHub-pull requests snarare än som en biprodukt av en enskild verktygsslinga.

När du ska använda GitHub spec-kit

I ett soloprojekt behöver du troligen inte Spec Kit. Sträck dig efter det när:

• Projektet växer förbi en person
• Din spec behöver granskas av personer som aldrig öppnar Claude Code
• Du kör en icke-Claude-Code-agent för en del av arbetet
• Du vill ha ett specformat som lever utanför något enskilt verktyg och fortfarande är läsbart månader senare

BMAD-metoden

Där Spec Kit organiserar artefakter, organiserar BMAD människor. Den delar upp arbetsflödet från spec till kod i fyra faser, var och en körd av en namngiven rollagent.

Vad är BMAD?

BMAD-METHOD (bmad-code-org/BMAD-METHOD, MIT-licens, cirka 47 k stjärnor) är på version 6. Akronymen, i projektets egna docs, står för ”Breakthrough Method for Agile AI-Driven Development.” Den kör ovanpå Claude Code och andra agenter och installeras som ett modulekosystem. Standardinstallationen ger dig en kärnmodul med sex rollagenter, fyra arbetsfaser och 34 eller fler namngivna arbetsflöden.

BMAD-METHODs projektsida på GitHub.

Hur du installerar BMAD

Installera BMAD med Node:

npx bmad-method install

De sex rollagenterna är promptpersonor som användaren aktiverar med namn inifrån agentvärden. I Claude Code innebär det att skriva aktiveringskommandot som BMAD installerar. Kolla README för exakt syntax, som skiftar mellan releaser. 

Introduktion till BMAD:s kollega-agenter och artefakter

När de aktiveras tar agenten den rollens instruktioner, röst och utdata tills du byter persona. De sex är:

• Mary, analytikern
• Paige, tekniska skribenten
• John, produktchefen
• Sally, UX-designern
• Winston, arkitekten
• Amelia, utvecklaren

Två roller du kanske väntar dig saknas i v6: det finns ingen Scrum Master-agent och ingen fristående QA-agent. Sprintplanering och story-förberedelse faller på utvecklaragenten, och QA-testgenerering är ett arbetsflöde som utvecklaren triggar.

Artefaktuppsättningen är tyngre än en enda spec. Du får:

• en produktbrief
• en PRD (Product Requirements Document)
• en UX-spec
• ett arkitekturdokument
• epics uppdelade i user stories (vad användare kan göra när arbetet skeppas)

PRD:n och arkitekturdokumentet spelar tillsammans samma roll som Superpowers-specen. Uppdelningen lägger dem över två rollagenter och i ett mer formellt format. Artefaktuppsättningen som helhet täcker en full mjukvaruutvecklingslivscykel, där varje funktion ärver kontext från lagret ovanför.

BMAD-arbetsflödet

V6-arbetsflödet körs i fyra faser.

De fyra BMAD-faserna och rollagenten som kör var och en. Quick Flow-spåret hoppar över de tre första faserna för småjobb.

Fas 1, analys, är valfri. Mary (analytiker) och Paige (teknisk skribent) kör research och producerar en produktbrief. Hoppa över fasen om du redan vet vad du bygger.

Fas 2, planering, är obligatorisk. John (PM) skriver PRD:n. Sally (UX-designer) lägger till en UX-spec när funktionen har ett UI.

Fas 3, lösningsarbete, är Winstons fas. Arkitekten skissar först arkitekturen, sedan bryter John ner kraven i epics och stories. Att lägga stories efter arkitekturen är ett v6-val som storleksätter dem mot verkliga implementationsgränser. Winston kör sedan en implementeringsredo-kontroll som landar i PASS, CONCERNS eller FAIL.

Fas 4, implementation, är där Amelia (utvecklare) arbetar story för story: skapa storyn, bygg den och kodgranska den. När en hel epic är klar triggar hon ett QA-testgenereringsflöde över hela epicen. Detta är fasen där Claude Code gör själva kodandet, i rollen som Amelia.

För små, välavgränsade jobb levererar BMAD ett ”Quick Flow”-spår som aktiverar Amelia direkt och hoppar över de tre första faserna. Aktiveringskommandot finns i BMAD:s README (exakt syntax skiftar mellan releaser). Quick Flow producerar ingen PRD och inget arkitekturdokument, bara en kort story och koden som uppfyller den. Det är svaret på invändningen ”det här är overkill för en knappändring”.

När specen visar sig vara fel mitt i implementationen loopar BMAD tillbaka genom Winstons Fas 3-dom. Ett FAIL skickar dig tillbaka till Fas 2 för att skriva om PRD:n. Ett CONCERNS fortsätter med Winstons noterade risker kopplade till storyn. Uppdelningen låter dig fortsätta vid små inkonsekvenser och stoppa hårt vid stora.

När komplexiteten lönar sig

BMAD lönar sig i långvariga projekt med riktiga användare att svara inför. Det passar också multidev-team, med överlämningar mellan personer. Fas- och rollseparationen måste spara mer tid än den kostar.

Det är fel passform för ett enmans sidoprojekt. I solojobb är uppdelningen i fyra faser och sex agenter mest overhead. Det finns ingen andra person i teamet för att rollseparationen ska spela roll.

Hur du väljer mellan ramverken

Tre regler avgör valet.

• Använd Spec Kit om specen måste läsas av personer som aldrig öppnar Claude Code, eller måste leva i Git som en långsiktig artefakt.
• Om flera personer arbetar över tydliga roller, eller en riktig PM-lik intressent är i loopen, använd BMAD.
• Annars, använd Superpowers.

Tre frågor om ditt projekt, fyra ramverksval på andra sidan.

Det finns ett fjärde alternativ som beslutsträdet nämner: kombinera Spec Kit med Superpowers. Använd Spec Kit för specfasen så att artefakterna lever i Git för tvärteamgranskning. Rikta sedan Superpowers subagent-driven-development-skill mot Spec Kits planfil med en rad konfiguration. Du får den hållbara specen från Spec Kit tillsammans med den tajta implementationsslingan från Superpowers.

Slutsats

Specdriven utveckling är tre dokument i ordning. Specen säger vad som ska byggas, planen säger i vilka steg, och koden följer planen. En mänsklig granskning sitter mellan varje par.

Kör beslutsträdet ovan för att välja ramverk, vilket för de flesta läsare landar på Superpowers. Installera det och välj en funktion du annars skulle vibe-coda, något som berör 3 till 5 filer. Kör det från början till slut genom brainstorm, spec, plan och exekvering. En riktig körning lär arbetsflödet bättre än någon beskrivning.

Om du vill fräscha upp grunderna i Claude Code först har DataCamp en praktisk Claude Code-handledning, en guide till bästa praxis som täcker planläge, CLAUDE.md och TDD, och en djupdykning i planläget i sig.