# Så konfigurerar du Spec Kit i Claude Code 2026: specifikationer i stället för promptar > Så konfigurerar du GitHub Spec Kit i Claude Code med fyra faser: Specify, Plan, Tasks och Implement. Här är ett alternativ till improviserat vibe coding. Source: https://ailoot.ai/blog/sv/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/sv/spec-kit-claude-code-spec-driven-development/ Language: sv Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-a735bdb9e0f851f555fc14d4ddff512218e2e0836806aa9ec58f2eeb08befdb1
Det viktigaste Spec Kit är ett verktyg från GitHub som låter dig skriva en uppgiftsspecifikation på naturligt språk. Därefter sätter Claude Code ihop en plan, delar upp den i uppgifter och skriver koden. Det här är inte teori: 107 000 GitHub-stjärnor på 8 månader, AWS använde metoden för att bygga ett läkemedelsutvecklingsprojekt på 3 veckor i stället för flera månader. Den här guiden går igenom installationen, mallarna, arbetsflödets 4 faser med en slutkontroll och hur du kopplar det till din CLAUDE.md.
[Ailoot-dokumentationen](https://ailoot.ai/docs/) — referensmaterial om hur tjänsten används.
## Vad hände med vibe coding i maj 2026?
Det viktigaste GitHub Spec Kit samlade 107 000 stjärnor på 8 månader, och AWS publicerade en fallstudie som rapporterade en besparing på 80+ timmar för en enda funktion. Veckans trend i maj: specifikation som ersättning för improvisation.
Ett år senare, den 4 februari 2026, publicerade han en tillbakablickande tråd: I sitt tal på Sequoia Ascent 2026 uttryckte han det ännu mer precist: ”Vibe coding höjer golvet—hur mycket alla kan göra inom programvara. Agentisk ingenjörskonst bevarar taket—kvalitetsribban för professionell utveckling.” På samma scen sa han en sak som kom in i branschens vokabulär: ”Du kan inte införa sårbarheter på grund av vibe coding. Du ansvarar fortfarande för din programvara, precis som förut.” Två saker hände parallellt. I september 2025 publicerade GitHub verktyget [Spec Kit](https://github.com/github/spec-kit)—det samlade 107 000 stjärnor på 8 månader. I februari 2026 publicerade AWS [en detaljerad fallstudie om läkemedelsutveckling](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) som rapporterade ”95 % av affärslogiken genererad från specifikationen, vilket sparade 80+ timmar”. I slutet av maj 2026 hade en samsyn vuxit fram i den engelskspråkiga informationsvärlden: vibe coding som arbetsmetod är nybörjarnivån. Därefter kommer Spec-Driven Development. Den här guiden förklarar hur du installerar och använder metoden. ## Vad är Spec Kit och Spec-Driven Development?
Det viktigaste Spec-Driven Development (SDD) vänder upp och ner på det vanliga arbetssättet med en AI-agent. Tidigare var koden den enda sanningskällan och specifikationen kompletterande pappersarbete. Nu är specifikationen sanningskällan, och koden blir det sista steget—dess implementering. Spec Kit är ett CLI-verktyg från GitHub som omvandlar 4 faser (Specify, Plan, Tasks, Implement) och en avslutande Converge-kontroll till färdiga kommandon i Claude Code, Cursor, Copilot och 30+ andra agenter.
Metodens grundidé sammanfattas i en rad från GitHubs officiella dokumentation:

Spec-Driven Development ändrar hierarkin: specifikationer tjänar inte koden—koden tjänar specifikationerna. Specifikationen blir det primära artefaktet, och koden är dess uttryck i ett visst språk och ramverk.

— GitHub Spec Kit-dokumentation, https://github.com/github/spec-kit/blob/main/spec-driven.md
I praktiken består det av 4 faser (Spec Kit lägger till ytterligare en, en nollfas—constitution, som beskrivs nedan): 1. **Specify** - skriv på naturligt språk en specifikation av vad du vill ha. VAD som ska göras och VARFÖR. Inte HUR. 2. **Plan** - agenten tar specifikationen och sätter ihop en teknisk plan: vilka tekniker, vilken arkitektur och vilka komponenter. 3. **Tasks** - agenten delar upp planen i konkreta, verifierbara uppgifter med beroenden. 4. **Implement** - agenten (eller dess underagenter) arbetar igenom uppgifterna och skriver koden. Efter Implement har den aktuella versionen av Spec Kit ett verifieringssteg som heter **Converge**: agenten jämför den färdiga koden med specifikationen, planen och uppgifterna och lägger sedan till sådant som saknas i `tasks.md`. Kör Implement och Converge i en loop tills Converge svarar ”Converged”. Varje fas är en separat Markdown-fil i repot. Varje fas är ett separat snedstreckskommando i Claude Code: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, medan kontrollen är `/speckit-converge`. Spec Kits dokumentation skriver samma kommandon med en punkt (`/speckit.specify`), men i Claude Code installeras Spec Kit som skills, och de anropas med bindestreck. Om något går fel i ett steg redigerar du Markdown-filen och kör nästa fas igen. Spec Kit är en specifik implementering av SDD. I maj 2026 hade det redan fler än 30 integrationer med olika AI-agenter. Inom ett repo fungerar Spec Kit på samma sätt med Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose och ett dussin till. | Spec Kit-fas | Snedstreckskommando | Artefakt i repot | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (valfritt) | `/speckit-clarify` | ändringar i `spec.md` | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (valfritt) | `/speckit-checklist` | checklista för kravkvalitet | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (valfritt) | `/speckit-analyze` | rapport om spec, plan och uppgifter | | Implement | `/speckit-implement` | kod i projektet | | Converge | `/speckit-converge` | utlåtandet ”Converged” eller nya uppgifter i `tasks.md` | Efter en körning innehåller repot alltså inte bara kod, utan även dess specifikation, plan och uppgifter. En månad senare kan du återvända till projektet, läsa `spec.md` och förstå vad som gjordes och varför. Det här är inte längre ”vibe coding glömde att koden finns”—det är projektets arbetsminne. ## Varför behöver en vibe coder som inte skriver kod det här?
Det viktigaste Det största problemet för en vibe coder är oförutsägbarhet. I dag bygger agenten en fungerande funktion åt dig på 20 minuter; i morgon producerar den spagettikod för en liknande uppgift. Spec Kit tar bort källan till den här oförutsägbarheten—en vagt formulerad uppgift. När du skriver en specifikation med en mall arbetar agenten konsekvent eftersom den har en entydig sanningskälla. Dessutom får du ett beständigt artefakt i repot som du kan återvända till en månad senare.
Spec Kit formaliserar planering i separata steg med 4 snedstreckskommandon. Logiken är densamma: skilj ”tänka igenom det” från ”implementera det” så att de sker i olika kontextfönster. Varje steg får en ren kontext som inte har belamrats av föregående fas. Tre konkreta fördelar för en vibe coder: - **Förutsägbarhet.** När du säger till agenten ”gör ett registreringsformulär med e-postbekräftelse” gissar den själv 10 detaljer—och tre av dem blir fel jämfört med vad du tänkte dig. När du har en `spec.md` med User Stories, Acceptance Scenarios och markeringar för `[NEEDS CLARIFICATION]` vid varje osäker punkt finns det inget att gissa. - **Projektminne.** En månad senare kommer du inte ihåg vad du diskuterade med agenten i chatten. Men `spec.md`, `plan.md` och `tasks.md` finns i repot, i mappen `specs/###-feature/` bredvid koden. De visar inte bara vad som gjordes, utan också varför. - **Skala.** För en funktion som berör 1-2 filer märks skillnaden knappt. För en funktion som berör 20 filer och 5 dataentiteter är skillnaden mellan ”skriva om allt efter 4 timmar” och ”allt har hamnat i huvudgrenen efter 4 timmar”. AWS Kiro visade 95 % automatisering av affärslogik från en specifikation i TargetID-projektet. Den största illusionen med vibe coding är att det verkar snabbare i början. En halvtimme, och där är en prototyp. Men efter en vecka går prototypen sönder, och det är enklare att kasta bort den. Spec-Driven Development tar lite längre tid i början (en timme i stället för en halvtimme), men en vecka senare arbetar du fortfarande i samma repo. ## Så installerar du Spec Kit i Claude Code (4 steg)
Det viktigaste Spec Kit installeras via uv, en Python-pakethanterare från Astral. Själva kommandot tar en rad. Efter installationen går du till ditt repo och kör `specify init` med flaggan `--integration claude` (eller väljer Claude Code i listan över agenter). Då får du en färdig struktur med mallar för constitution, spec, plan och tasks, plus en uppsättning `/speckit-*`-kommandon direkt i Claude Code. Installationen tar 5 minuter om uv redan är installerat och 10 minuter om du installerar det från grunden.
**Steg 1. Installera uv.** Du behöver bara göra det en gång; det finns kvar på systemet. ```bash # macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" ``` Kontrollera att uv installerades: ```bash uv --version ``` **Steg 2. Installera Spec Kit.** Ett kommando: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Kontrollera: ```bash specify --version ``` **Steg 3. Initiera repot.** Gå till projektmappen (eller skapa en ny) och kör: ```bash specify init --here --integration claude ``` Flaggan `--integration claude` väljer Claude Code direkt. Utan den ber Spec Kit dig välja en agent från en interaktiv lista och kan också fråga efter en skripttyp (för macOS och Linux låter du det vara `sh`). Om mappen inte är tom varnar Spec Kit om att det slår ihop sina filer med dina: checka in ditt arbete först och kör sedan kommandot igen med flaggan `--force`. Därefter visas följande i repot: ``` .specify/ memory/ constitution.md # project rules, filled in by /speckit-constitution scripts/ templates/ spec-template.md plan-template.md tasks-template.md .claude/ skills/ speckit-constitution/SKILL.md speckit-specify/SKILL.md speckit-clarify/SKILL.md speckit-plan/SKILL.md speckit-checklist/SKILL.md speckit-tasks/SKILL.md speckit-analyze/SKILL.md speckit-implement/SKILL.md speckit-converge/SKILL.md speckit-taskstoissues/SKILL.md ``` **Steg 4. Öppna Claude Code och kontrollera snedstreckskommandona.** Kör det här i samma mapp: ```bash claude ``` Skriv `/speckit` i sessionen—kommandona `speckit-*` bör visas bland förslagen. Starta om Claude Code så att det läser in `.claude/skills/` på nytt om de inte visas. Om du redan har `CLAUDE.md` i projektroten lämnar Spec Kit den ifred—det fungerar tillsammans med den i `.specify/memory/constitution.md`. Spec Kit fungerar även utan Claude Code (det stöder 30+ agenter), men den här guiden handlar specifikt om konfigurationen med Claude. Om du vill installera två verktyg direkt kan du läsa de separata guiderna om att [konfigurera CLAUDE.md](https://ailoot.ai/blog/sv/claude-md-template/) och [Plan Mode i Claude Code](https://ailoot.ai/blog/sv/claude-code-plan-mode/). Spec Kit är den första byggstenen i ett ”anställningskontrakt för en agent”. Den kompletta konfigurationen innehåller alla tre delarna: en AI-klon (din metod i form av Skills och underagenter), en Second Brain (strukturen `business/` som agenten återvänder till varje gång) och kontextteknik (Spec Kit, Plan Mode, /compact). Det här är de tre pelarna utan vilka AI hallucinerar. ## Så skriver du din första specifikation (Specify)
Det viktigaste Spec Kit ber dig beskriva en funktion fritt och utökar sedan beskrivningen till en `spec.md`-fil med hjälp av en mall: User Stories med P1/P2/P3-prioriteringar, Acceptance Scenarios i formatet Given/When/Then, Functional Requirements (FR-001, FR-002 osv.) och Success Criteria med mätbara resultat. När agenten är osäker lägger den in en markering som `[NEEDS CLARIFICATION: ...]`—och du besvarar sådana frågor innan du går vidare till Plan.
Skriv i Claude Code: ``` /speckit-specify ``` Sedan ber agenten dig beskriva funktionen. Använd ett enkelt språk utan teknisk jargong i det här steget: ``` I want a registration form in my app. The user enters an email and password, receives a confirmation email, and after confirming lands on the dashboard. Confirmation expires after 48 hours. If the email is still unconfirmed, delete the account within 5 minutes after that deadline; never delete a confirmed account. ``` I detta illustrativa exempel har raderingstoleransen preciserats till 5 minuter efter 48-timmarsgränsen. Bekräfta toleransen före Plan för en verklig produkt; en exakt 48-timmarsgräns kräver utformning och tester som upprätthåller det starkare kravet. Agenten sätter ihop `specs/001-registration/spec.md`. Öppna den, så ser du en struktur som den här: ```markdown # Feature Specification: User Registration **Feature Branch**: `001-registration` **Created**: 2026-05-31 **Status**: Draft **Input**: User Description: "I want a registration form..." ## User Scenarios & Testing *(mandatory)* ### Primary User Story As a new user, I want to register an account with email confirmation, so that I can access the dashboard with a verified identity. ### Acceptance Scenarios 1. **Given** I am on the registration page, **When** I submit valid email and password, **Then** I receive a confirmation email within 1 minute. 2. **Given** I clicked the confirmation link within 48 hours, **When** I land on the dashboard, **Then** I see my email confirmed in profile. 3. **Given** I have not confirmed at the 48-hour deadline, **When** cleanup runs within the next 5 minutes, **Then** my account is deleted and email is freed for re-registration. 4. **Given** my account is just under 48 hours old or already confirmed, **When** cleanup runs, **Then** the account is not deleted. ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION: email/password only, or also SSO/OAuth?] - **FR-002**: System MUST send confirmation email within 60 seconds - **FR-003**: Confirmation MUST expire at 48 hours; the system MUST delete still-unconfirmed accounts no later than 5 minutes after that deadline and MUST NOT delete confirmed accounts - **FR-004**: System MUST log all registration attempts for [NEEDS CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?] ### Key Entities - User: email, password_hash, email_verified_at, created_at, deleted_at - ConfirmationToken: token, user_id, expires_at, used_at ## Success Criteria *(mandatory)* - **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95) - **SC-002**: 0 accidental deletions of confirmed accounts - **SC-004**: No deletion before 48 hours; every eligible unconfirmed account is deleted by age 48 hours 5 minutes under the tested workload - **SC-003**: Registration completion rate > 60% (from form open to dashboard) ``` Lägg märke till markeringarna `[NEEDS CLARIFICATION: ...]`. Spec Kit lägger avsiktligt in dem där agenten inte fick ett entydigt svar från din text. Innan du går vidare till fasen Plan måste du antingen besvara dem manuellt i `spec.md` eller köra `/speckit-clarify`, så går agenten igenom de oklara punkterna och ställer frågor i dialogen. Det här steget formaliserar planering i separata steg med fyra slash-kommandon. Logiken: I Spec Kit ersätter det inbyggda kommandot `/speckit-clarify` den uttalade begäran ”ställ frågor till mig”. Effekten är densamma: du går inte vidare till Plan förrän det inte längre finns några markeringar för `[NEEDS CLARIFICATION]` kvar i `spec.md`. Det ska inte finnas några tekniker i `spec.md`. Inga omnämnanden av React, Postgres, Prisma eller Redis. Specifikationen beskriver vad systemet gör ur användarens och verksamhetens perspektiv. Teknikstacken kommer i nästa fas. ## Vad gör Claude i Plan-fasen?
Det viktigaste Kommandot `/speckit-plan` tar den färdiga specifikationen och sätter ihop en teknisk plan: vilka tekniker som ska användas, vilken arkitektur, vilka moduler, dataentiteter och API-kontrakt. Planen skrivs till `specs/###-feature/plan.md`, kontrakten exporteras till en separat mapp `contracts/` och datamodellen placeras i `data-model.md`. I det här steget känner Claude redan till din stack från CLAUDE.md och constitution, så planen passar det befintliga projektet i stället för att föreslå ”låt oss skriva om allt i Rust”.
När `spec.md` är klar kör du: ``` /speckit-plan ``` Du kan även lägga till teknikledtrådar direkt i kommandot: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email ``` Claude läser tre källor: din `spec.md`, din `CLAUDE.md` (eller `memory/constitution.md`) och den befintliga koden i repot. Resultatet är en `plan.md` med en struktur som ungefär ser ut så här: ```markdown # Implementation Plan: User Registration ## Technical Context - Framework: Next.js 14 App Router - Database: PostgreSQL via Prisma - Email: Resend (single transport) - Validation: Zod schema in shared lib - Auth: NextAuth.js with credentials provider ## Architecture Decisions ### 1. Token storage Tokens stored in DB (table ConfirmationToken), not in JWT. Reason: need server-side revoke on email re-register. ### 2. Email delivery Async via cron `/api/cron/send-confirmation` triggered immediately after registration. Retries handled by Resend. ### 3. Auto-delete cron Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL. The clarified example allows at most 5 minutes of deletion delay. Verify scheduler lag and completion time against that bound; report a missed bound as a failure, not a successful daily cleanup. ## Data Model See data-model.md ## API Contracts See contracts/ - POST /api/auth/register - POST /api/auth/confirm - GET /api/auth/resend-confirmation ## Implementation Phases 1. Database migration (Prisma schema + migration file) 2. API routes (3 endpoints) 3. UI: registration form + confirmation success page 4. Cron jobs (send + cleanup) 5. Email template 6. Integration tests ``` `data-model.md` beskriver entiteterna och relationerna mellan dem. `contracts/` innehåller API-kontraktsskelett (antingen OpenAPI YAML eller TypeScript-typer för begäran och svar). Det här är inte kod—det är intentioner som Claude senare omvandlar till faktiska routes. Den största fördelen med Plan-fasen är en ren kontext. Claude försöker inte hålla både specifikationen och implementeringen i huvudet samtidigt. Den tänker igenom allt först, skriver ned beslutet i en fil och går sedan vidare. Därefter finns det valfria kommandot `/speckit-analyze`. Det körs efter Tasks-fasen och före Implement: det granskar uppsättningen `spec.md + plan.md + tasks.md` för motsägelser och kontrollerar om alla specifikationskrav täcks av planen och uppgifterna. Det redigerar inte filer; det producerar bara en rapport. Det fungerar i praktiken som en formell rimlighetskontroll före implementeringen. ## Så delar du upp arbetet i uppgifter (Tasks)
Det viktigaste Kommandot `/speckit-tasks` delar upp planen i konkreta uppgifter. Varje uppgift innehåller beroenden, en uppskattning och en markering som säger ”kan parallelliseras” eller ”strikt sekventiell”. Resultatet är `tasks.md`, där uppgifterna använder checklisteformatet `[ ] T-001: ...`. Du kan sedan lämna över de här uppgifterna för implementering med `/speckit-implement` eller omvandla dem till GitHub Issues med `/speckit-taskstoissues`—och fördela dem mellan ett team eller flera parallella Claude Code-sessioner.
När du har `spec.md` och `plan.md` kör du: ``` /speckit-tasks ``` Claude utökar planen till `tasks.md`: ```markdown # Tasks: User Registration ## Phase 1: Database (no dependencies) - [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe) - [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001) - [ ] T-003: Generate migration `add-user-registration` (after T-002) ## Phase 2: API contracts (no dependencies) - [ ] T-004: Create Zod schemas in shared/validation/auth.ts - [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004) ## Phase 3: Routes (depends on Phase 1+2) - [ ] T-006: Implement POST /api/auth/register - [ ] T-007: Implement POST /api/auth/confirm - [ ] T-008: Implement GET /api/auth/resend-confirmation ## Phase 4: UI (parallel with Phase 3) - [ ] T-009: Build /register page with form - [ ] T-010: Build /register/confirm/[token] page - [ ] T-011: Build /register/success page ## Phase 5: Cron + integration (depends on Phase 3+4) - [ ] T-012: Cron /api/cron/send-confirmation - [ ] T-013: Cron /api/cron/cleanup-unconfirmed - [ ] T-014: Email template registration-confirmation.tsx - [ ] T-015: Integration tests (Playwright), including cleanup just before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure, and protection of confirmed accounts ## Notes - T-001, T-004, T-009-T-011 are parallel-safe (different files) - T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially - T-006 needs T-003 (migration applied) and T-005 (types) ``` Lägg märke till markeringarna `parallel-safe` och `after T-NNN`. Det här är beroendegrafen som senare gör det möjligt att köra flera faser parallellt. Hela Spec Kit-accelerationen bygger på den här mekanismen: vissa uppgifter kan lämnas till fem olika Claude Code-sessioner samtidigt, medan andra måste köras strikt sekventiellt. Spec Kit gör det här automatiskt med ett enda kommando, direkt från start. Det valfria kommandot `/speckit-taskstoissues` tar `tasks.md` och skapar GitHub Issues från listan, var och en med en länk tillbaka till `spec.md`. Det är användbart om du arbetar i ett team eller vill följa framstegen via GitHub Projects. ## Så implementerar du med underagenter (Implement)
Det viktigaste Den sista fasen `/speckit-implement` startar implementeringen. Claude arbetar igenom `tasks.md` uppifrån och ned och bockar av uppgifter med `[x]` när de är klara. Du kan köra flera parallella Claude Code-sessioner samtidigt—en fas per session. I varje session startar Claude underagenter för olika typer av arbete: en granskare för kod, en testare för kontroller och en dokumentationsskribent för README. Det här är de ”1000 parallella underagenter” som Anthropic skrev om när Opus 4.8 lanserades—i Spec Kit är det bara ett arbetssätt, inte en separat produkt.
``` /speckit-implement ``` Claude börjar med den första uppgiften i `tasks.md`. Varje uppgift går igenom en kort cykel: läsa relevanta filer, skriva en diff, köra testerna, kontrollera `[x]`. Underagenter anropas automatiskt vid behov: en separat för kodgranskning, en separat för att köra lintning och en separat för att leta efter regressioner. Och separat, om regler: I Spec Kit formaliseras den här cykeln. Du har `spec.md` som sanningskälla, `plan.md` för tekniska beslut och `tasks.md` som checklista. Om Claude går fel någonstans återvänder du till specifikationen och säger: ”Det där stämmer inte med FR-003; gör om.” Inga långa promptar som säger ”kom ihåg vad vi diskuterade...”—hela historiken finns i filerna. Om du har kopplat in [Dynamic Workflows i Opus 4.8](https://ailoot.ai/blog/sv/claude-code-dynamic-workflows/) kan du sätta Spec Kit i fullautomatiskt läge: ett kommando `/speckit-implement`, så parallelliserar Claude arbetet, sammanställer resultaten och kontrollerar dem. Gränsen är 1000 underagenter samtidigt. För de flesta funktioner räcker 10-30. När alla `[x]`-rutor är markerade och kontrollen i nästa avsnitt svarar ”Converged” granskar du PR:en (eller en serie PR:ar om det finns många uppgifter) och slår ihop den. Artefakten—`spec.md`, `plan.md`, `tasks.md`—finns kvar i repot som dokumentation för funktionen. Ett år senare behöver du inte bakåtspåra logiken från koden. ## Så kontrollerar du att agenten inte har missat något (Converge)
Det viktigaste Efter Implement har den aktuella versionen av Spec Kit ett kontrollsteg som heter `/speckit-converge`. Agenten jämför den färdiga koden med `spec.md`, `plan.md` och `tasks.md`. Om allt stämmer svarar den ”Converged” och lämnar filerna orörda. Om den hittar något som saknas lägger den till det som nya uppgifter i slutet av `tasks.md`. Sedan kör du `/speckit-implement` igen, följt av `/speckit-converge` igen, tills du får ”Converged”.
``` /speckit-converge ``` Först ger agenten en sammanfattning av vad den hittade, med allvarlighetsgrader, och sedan ett av två resultat. ”Converged” betyder att inget saknas, att `tasks.md` är oförändrad byte för byte och att du kan gå vidare till granskning. ”Tasks appended” betyder att agenten hittade utelämningar, lade till dem i avsnittet Convergence i `tasks.md` och berättar hur många de är. Converge redigerar eller raderar inte kod; det enda den skriver är nya uppgifter i `tasks.md`. Därför kan du köra den utan oro, men först efter att `/speckit-implement` har arbetat igenom den aktuella `tasks.md`. Varje efterföljande genomgång hittar färre utelämningar. ## Hur skiljer sig Spec Kit från CLAUDE.md och Plan Mode?
Det viktigaste Det här är en vanlig fråga när verktygen jämförs. Det korta svaret: CLAUDE.md är agentens ”anställningskontrakt”, en enda sanningskälla för hela projektet. Plan Mode är engångsplanering inför en specifik uppgift. Spec Kit är en funktions hela livscykel: från beskrivning till implementering, med artefakter i repot. De ersätter inte varandra; de kombineras till ett system i tre lager: global kontext (CLAUDE.md) → projektkontext (Spec Kit constitution) → funktionskontext (spec.md + plan.md + tasks.md).
Jämför dem utifrån 5 egenskaper: | Egenskap | CLAUDE.md | Plan Mode | Spec Kit | |----|----|----|----| | När det körs | Varje session | På begäran (Shift+Tab eller /plan) | Med snedstreckskommandot /speckit-\* | | Livslängd | Hela projektet | En session | En funktion | | Var det finns | Repots rot | I Claudes kontext | `specs/###-feature/*` | | Vad det sparar | Stack, regler, ordlista | Aktuell plan + observationer | spec + plan + tasks + kontrakt | | Mall | Fritt format (reporegler) | Ingen | Strukturerad Markdown | | Bästa roll | Projektregler och stack | Kontroll före en större ändring | Hela funktionscykeln: från VAD till KOD | I Spec Kit-termer är det här `.specify/memory/constitution.md`. Vid initieringen kan Spec Kit antingen använda din befintliga CLAUDE.md som grund för constitution eller skapa en separat fil bredvid den. Jag brukar låta CLAUDE.md vara det globala ”kontraktet” (stack, ordlista, distributionsprotokoll) och använda Spec Kit-constitution för regler som är specifika för funktioner—till exempel ”alla formulär valideras genom Zod; inga manuella kontroller”. Kopplingen till Plan Mode är enklare. Plan Mode är ett snabbt läge för ”planera innan du skriver kod” i en enda session. Det fungerar bra för små ändringar (rätta en bugg, refaktorera en funktion). För en stor funktion räcker Plan Mode inte till eftersom en sessions kontextfönster är för litet för en plan på 3000 rader—som jag förklarar direkt i livesessionen: Spec Kit är ett konkret verktyg för kontextteknik. Det flyttar ”den arkitektoniska duken” från chatten till filer. Spec.md ligger kvar i repot och varje ny Claude-session läser den igen—du behöver inte upprepa dig. En konfiguration för ett stort projekt: 1. **CLAUDE.md** - stack, ordlista, sådant man inte ska göra. Den ligger i roten. 2. **.specify/memory/constitution.md** för Spec Kit—regler som är specifika för det här arbetsflödet. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** - första funktionen. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** - andra funktionen. 5. För det dagliga arbetet använder du antingen `/speckit-implement` (för färdiga uppgifter) eller `/plan` (en snabb dubbelkontroll före en ändring). ## Vilka verkliga fall fungerar?
Det viktigaste Spec Kit- och SDD-metoden har redan gett mätbara resultat i stora företag. AWS rapporterade i ett läkemedelsutvecklingsprojekt att 95 % av affärslogiken genererades från en specifikation, vilket sparade över 80 timmar på en funktion. Rackspace Technology rapporterade att 52 veckors arbete komprimerades till 3 veckor och att effektiviteten ökade med över 90 %. Spec Kit samlade 107 000 GitHub-stjärnor på 8 månader.
Några konkreta fall: - **AWS Kiro – läkemedelsutvecklingsagent.** I ett [blogginlägg från AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) daterat den 18 februari 2026 beskriver AWS-teamet TargetID-projektet. Tre utvecklare, tre veckor, en läkemedelsutvecklingsagent. Enligt AWS genererade Kiro mer än 95 % av affärslogikens kod, vilket sparade mer än 80 utvecklingstimmar. AWS uppger också att dokumentationen som Kiro skrev sparade uppskattningsvis 8 timmar och att antalet iterativa prompt-och-fixa-cykler minskade med 40 %. - **Rackspace Technology.** I samma AWS-blogginlägg rapporterar Rackspace att de ”slutförde 52 veckors uppskattat arbete på bara 3 veckor” och att effektiviteten ökade med 90 %. Det här är mer än en liten funktion – det är ett helt företagsprojekt. - **GitHub Spec Kits tillväxt.** Repot hade 107 000 stjärnor den 31 maj. Tillväxten kan tyda på att intresset för metoden ökar. För läsaren betyder det här att metoden inte är teoretisk: seriösa team använder den redan i produktion. ## När passar Spec Kit INTE?
Det viktigaste Spec Kit passar inte överallt. Det finns tre tydliga områden där det inte passar: små ändringar (rätta en bugg, byta namn på en variabel), experiment och prototyper (där det faktum att du inte vet vad du vill är själva poängen med vibe coding) och äldre kod med komplicerat tillstånd (där specifikationen kan bli inaktuell innan den är klar). Det finns seriösa invändningar mot att använda specifikationer i sådana fall. Det är värt att känna till dem, så att du inte lägger tid på specifikationer som inte hjälper.
**Olämpligt nr 1 – små ändringar.** Om uppgiften är ”byt namn på en variabel”, ”rätta ett stavfel i texten” eller ”lägg till en logg” tar det längre tid att gå igenom Specify → Plan → Tasks än att göra själva ändringen. För små ändringar går Plan Mode eller en direkt prompt i Claude Code snabbare. **Olämpligt nr 2 – experiment i realtid.** När du ännu inte vet vad du vill ha och behöver ”känna dig fram” i gränssnittet eller snabbt sätta ihop en prototyp för att se ”om den fungerar”, är en specifikation meningslös. Värdet ligger just i att du improviserar. När du ”leker med en idé” kan improvisation passa bättre än en specifikation. **Olämpligt nr 3 – äldre kod med komplicerat tillstånd.** Ett starkt motargument är att verkligheten förändras snabbare än specifikationerna. Ta prenumerationsfakturering: teamet beskriver faktureringscykler och skatteregler, men en vecka senare ber ekonomiavdelningen om europeisk moms – specifikationen kan vara inaktuell redan före lanseringen. När affärslogiken förändras snabbt blir det en börda att underhålla specifikationer. En ytterligare risk är en falsk känsla av kontroll. Martin Fowlers artikel granskar detta: strukturerna är eleganta, men agenter ignorerar ofta instruktioner eller följer tvärtom mallar alltför bokstavligt. Resultatet blir kod som är strukturellt korrekt men inte passar just ditt repo—specifikationen garanterar inte att agenten förstod den som du avsåg. I april 2026 varnade branschanalytiker för vattenfallsmetoden: att skriva en stor specifikation före koden är en väg som redan en gång har sänkt branschen, när kravdokumenten var 200 sidor långa. Ingenjörer har varit försiktiga med den här metoden sedan dess, och den försiktigheten är befogad. **Vad ska man göra åt det?** Jag föreslår en enkel regel: funktionens storlek i förhållande till tiden det tar att skriva en specifikation. Om en funktion tar mindre än 2 timmar att implementera ska du inte skriva en spec—Plan Mode går snabbare. Om en funktion tar en vecka ska du definitivt använda Spec Kit; tidsbesparingen betalar tillbaka den timslånga specifikationen fem gånger om. Mellan 2 timmar och en vecka får du använda ditt omdöme, men personligen skriver jag en spec även för funktioner som tar en halv dag eftersom artefakten i repot är värd mer än de 30 minuterna man sparar. ## Nästa steg: hur integrerar du Spec Kit i projektet?
Det viktigaste Det enklaste första steget är att prova Spec Kit på en ny liten funktion, inte på ett helt befintligt projekt. Installera det, initiera det i ett repo, kör `/speckit-specify` för en funktion och titta på artefakten. Om en vecka eller två har du fått en känsla för när du ska byta till det och när du ska fortsätta med snabba promptar. Den kompletta metoden kombinerar CLAUDE.md + Spec Kit + Skills + underagenter.
En konkret plan för de kommande 7 dagarna: - **Dag 1.** Installera uv och Spec Kit (5-10 minuter). Kontrollera att `/speckit-*`-kommandona har dykt upp i Claude Code. Försök inte tillämpa dem på ett befintligt projekt—börja med ett nytt. - **Dag 2.** Välj en verklig funktion som du planerar att bygga. Kör `/speckit-specify` med en fritt formulerad beskrivning. Öppna `spec.md`, läs den och besvara varje `[NEEDS CLARIFICATION]`. Stressa inte vidare till Plan. - **Dag 3.** Kör `/speckit-plan` med ledtrådar om din stack. Läs `plan.md`, särskilt avsnittet Architecture Decisions. Redigera det manuellt om något inte passar dig. - **Dag 4-5.** Kör `/speckit-tasks` och sedan `/speckit-analyze` för att dubbelkontrollera uppsättningen med spec, plan och uppgifter, och därefter `/speckit-implement`. Se hur Claude bockar av `[x]` i `tasks.md`. Det kan köra fast någonstans—det är normalt. Gå tillbaka till `spec.md`, förtydliga kravet och starta om `/speckit-implement` med en specifik uppgift. När uppgifterna är avklarade kör du `/speckit-converge` och upprepar sekvensen Implement och Converge tills det svarar ”Converged”. - **Dag 6-7.** Granska PR:en (eller en serie PR:ar). Slå ihop den. Läs din `spec.md` och `plan.md`—de är dokumentationen för funktionen under det kommande året. Det här föreslår jag att du läser parallellt: - [Så konfigurerar du CLAUDE.md 2026](https://ailoot.ai/blog/sv/claude-md-template/) - grunden för Spec Kits constitution. - [Plan Mode i Claude Code](https://ailoot.ai/blog/sv/claude-code-plan-mode/) - ett snabbt alternativ för små uppgifter. - [Kontextteknik 2026](https://ailoot.ai/blog/sv/context-engineering/) - varför Spec Kit fungerar över huvud taget. - [Skills, underagenter, MCP eller plugins](https://ailoot.ai/blog/sv/skills-subagents-mcp-plugins-claude-code/) - vad du kan lägga till i Spec Kit för ditt arbetsflöde. - [Dynamic Workflows i Claude Code](https://ailoot.ai/blog/sv/claude-code-dynamic-workflows/) - hur du startar många underagenter samtidigt under Implement-fasen.
### Källor - [GitHub Spec Kit – repo](https://github.com/github/spec-kit) - [GitHub Spec Kit – officiell dokumentation](https://github.github.com/spec-kit/) - [Spec-Driven Development – officiell metodtext](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [Spec-mall – GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [AWS Industries Blog – Från specifikation till produktion: Kiros läkemedelsutvecklingsagent (18 februari 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Claude Code-dokumentation – underagenter](https://code.claude.com/docs/en/sub-agents) - [Claude Code-dokumentation – skills](https://code.claude.com/docs/en/skills) - [Claude Code-dokumentation – kommandon](https://code.claude.com/docs/en/commands)
Det kompletta kontextarbetsflödet: AI-klon + Second Brain + kontextteknik. Mer material finns på [Ailoot](https://ailoot.ai/). ## Frågor om den här guiden: Så konfigurerar du Spec Kit i Claude Code 2026: specifikationer i stället för promptar ### Varför räcker inte daglig städning för ett 48-timmarskrav på radering? Ett konto som når gränsen strax efter daglig körning kan vänta nästan ytterligare ett dygn. Precisera tolererad raderingsfördröjning i specifikationen, välj schema som passar och testa både 48-timmarströskeln och maximal fördröjning. ### Vad gör jag när plan.md motsäger spec.md? Återgå till kravet och lös skillnaden före implementering. Uppdatera specifikation, plan, uppgifter och acceptanskontroller tillsammans och verifiera sedan samma överenskomna beteende genom Analyze och implementationskontroller. ## Ailoot · Företaget och dess projektportfölj Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll. Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder. Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.