Sådan konfigurerer du Spec Kit i Claude Code i 2026: specifikationer i stedet for prompts

Hvad skete der med vibe coding i maj 2026?#

Et år senere, den 4. februar 2026, udgav han en retrospektiv tråd:

I sit oplæg på Sequoia Ascent 2026 formulerede han det endnu mere præcist: “Vibe coding hæver gulvet—hvor meget alle kan udrette inden for software. Agentisk ingeniørarbejde bevarer loftet—kvalitetsniveauet for professionel udvikling.” På samme scene kom han med en bemærkning, der blev en del af branchens ordforråd: “Man kan ikke tillade sig at indføre sårbarheder på grund af vibe coding. Du er stadig ansvarlig for din software, som før.”

To ting skete parallelt. I september 2025 udgav GitHub værktøjet Spec Kit—det nåede 107.000 stjerner på 8 måneder. I februar 2026 udgav AWS en detaljeret casebeskrivelse om lægemiddeludvikling med rapporten “95 % af forretningslogikken genereret ud fra specifikationen, hvilket sparede 80+ timer”.

Ved udgangen af maj 2026 havde der dannet sig en konsensus i det engelsksprogede informationsmiljø: vibe coding som arbejdsmetode er begynderniveauet. Næste trin er Spec-Driven Development. Denne guide forklarer, hvordan du installerer og bruger metoden.

Hvad er Spec Kit og Spec-Driven Development?#

Metodens kerneidé er sammenfattet i én linje fra GitHubs officielle dokumentation:

I praksis udfolder det sig i 4 faser (Spec Kit tilføjer én mere, en fase nul—constitution, som beskrives nedenfor):

1. Specify - skriv en specifikation på naturligt sprog om, hvad du ønsker. HVAD der skal gøres, og HVORFOR. Ikke HVORDAN.
2. Plan - agenten tager specifikationen og udarbejder en teknisk plan: hvilke teknologier, hvilken arkitektur og hvilke komponenter.
3. Tasks - agenten opdeler planen i konkrete, verificerbare opgaver med afhængigheder.
4. Implement - agenten (eller dens underagenter) arbejder sig gennem opgaverne og skriver koden.

Efter Implement har den aktuelle version af Spec Kit et verificeringstrin kaldet Converge: agenten kontrollerer den færdige kode mod specifikationen, planen og opgaverne og føjer derefter alt manglende til tasks.md. Kør Implement og Converge i en løkke, indtil Converge svarer “Converged”.

Hver fase er en separat Markdown-fil i repoet. Hver fase er en separat slash-kommando i Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, mens kontrollen er /speckit-converge. Spec Kits dokumentation skriver de samme kommandoer med et punktum (/speckit.specify), men i Claude Code installeres Spec Kit som skills, og de kaldes med en bindestreg. Hvis noget går galt i et trin, redigerer du Markdown-filen og kører den næste fase igen.

Spec Kit er en specifik implementering af SDD. I maj 2026 havde det allerede mere end 30 integrationer med forskellige AI-agenter. I ét repo fungerer Spec Kit på samme måde med Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose og et dusin flere.

Efter en kørsel indeholder dit repo altså ikke kun kode, men også dens specifikation, plan og opgaver. En måned senere kan du vende tilbage til projektet, læse spec.md og forstå, hvad der blev gjort og hvorfor. Det er ikke længere “vibe coding glemte, at koden findes”—det er projektets arbejdshukommelse.

Hvorfor har en vibe coder, der ikke skriver kode, brug for det?#

Spec Kit formaliserer planlægning på tværs af separate trin med 4 slash-kommandoer. Logikken er den samme: adskil “at tænke det igennem” fra “at implementere det”, så de foregår i forskellige kontekstvinduer. Hvert trin får en ren kontekst, der ikke er blevet rodet til af den foregående fase.

Tre konkrete fordele for en vibe coder:

• Forudsigelighed. Når du siger til agenten “lav en registreringsformular med e-mailbekræftelse”, gætter den selv på 10 detaljer—og rammer forkert på tre af dem i forhold til det, du havde i tankerne. Når du har en spec.md med User Stories, Acceptance Scenarios og [NEEDS CLARIFICATION]-markører ved alle usikre punkter, er der intet at gætte på.
• Projekthukommelse. En måned senere kan du ikke huske, hvad du drøftede med agenten i chatten. Men spec.md, plan.md og tasks.md ligger i repoet, i mappen specs/###-feature/ ved siden af koden. De viser dig ikke kun, hvad der blev gjort, men også hvorfor.
• Skala. For en funktion, der involverer 1-2 filer, er forskellen knap nok mærkbar. For en funktion, der involverer 20 filer og 5 dataentiteter, er forskellen mellem “at skrive det hele om efter 4 timer” og “at det hele er kommet ind i hovedgrenen efter 4 timer”. AWS Kiro viste 95 % automatisering af forretningslogik ud fra en specifikation i TargetID-projektet.

Den største illusion ved vibe coding er, at det virker hurtigere i begyndelsen. En halv time, og så er der en prototype. Men efter en uge går prototypen i stykker, og det er nemmere at kassere den. Spec-Driven Development tager lidt længere tid i starten (en time i stedet for en halv time), men en uge senere arbejder du stadig i samme repo.

Sådan installerer du Spec Kit i Claude Code (4 trin)#

Trin 1. Installer uv. Du behøver kun at gøre det én gang; det bliver på dit system.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Kontrollér, at uv blev installeret:

uv --version

Trin 2. Installer Spec Kit. Én kommando:

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

Kontrollér:

specify --version

Trin 3. Initialisér repoet. Gå til projektmappen (eller opret en ny), og kør:

specify init --here --integration claude

Flaget --integration claude vælger Claude Code direkte. Uden det beder Spec Kit dig om at vælge en agent fra en interaktiv liste og spørger muligvis også efter en script-type (for macOS og Linux skal du lade den stå på sh). Hvis mappen ikke er tom, advarer Spec Kit om, at det vil flette sine filer sammen med dine: commit først dit arbejde, og kør derefter kommandoen igen med flaget --force.

Derefter vises følgende i repoet:

.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

Trin 4. Åbn Claude Code, og kontrollér slash-kommandoerne. Kør dette i samme mappe:

claude

Skriv /speckit i sessionen—kommandoerne speckit-* bør vises blandt forslagene. Hvis de ikke gør, skal du genstarte Claude Code, så den genindlæser .claude/skills/. Hvis du allerede har CLAUDE.md i projektroden, lader Spec Kit den være—det fungerer sammen med den i .specify/memory/constitution.md.

Spec Kit fungerer også uden Claude Code (det understøtter 30+ agenter), men denne guide dækker opsætningen specifikt med Claude. Hvis du vil installere to værktøjer med det samme, kan du se de separate guider om opsætning af CLAUDE.md og Plan Mode i Claude Code.

Spec Kit er den første byggesten i en “ansættelseskontrakt for en agent”. Den komplette opsætning omfatter alle tre: en AI-klon (din metode i form af Skills og underagenter), en Second Brain (strukturen business/, som agenten vender tilbage til hver gang) og kontekstteknik (Spec Kit, Plan Mode, /compact). Det er de tre søjler, som AI hallucinerer uden.

Sådan skriver du din første specifikation (Specify)#

Skriv i Claude Code:

/speckit-specify

Derefter beder agenten om en beskrivelse af funktionen. Brug et almindeligt sprog uden teknisk jargon på dette trin:

Jeg vil have en registreringsformular i min app. Brugeren indtaster e-mail
og adgangskode, modtager en bekræftelsesmail og lander efter bekræftelse
på dashboardet. Bekræftelsen udløber efter 48 timer. Hvis e-mailen stadig
ikke er bekræftet, slettes kontoen senest 5 minutter efter fristen;
en bekræftet konto må aldrig slettes.

I dette illustrative eksempel er sletningstolerancen afklaret til 5 minutter efter 48-timersfristen. Bekræft tolerancen før Plan til et rigtigt produkt; en præcis frist på 48 timer kræver et design og tests, der håndhæver det stærkere krav. Agenten sammensætter specs/001-registration/spec.md. Åbn den, så ser du en struktur i denne stil:

# 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æg mærke til [NEEDS CLARIFICATION: ...]-markørerne. Spec Kit indsætter dem med vilje, hvor agenten ikke fik et entydigt svar i din tekst. Før du går videre til Plan-fasen, skal du enten besvare dem manuelt i spec.md eller køre /speckit-clarify, hvorefter agenten gennemgår de uklare punkter og stiller spørgsmål i dialogen.

I Spec Kit erstatter den indbyggede kommando /speckit-clarify det mundtlige “stil mig spørgsmål”. Effekten er den samme: Du går ikke videre til Plan, før der ikke er flere [NEEDS CLARIFICATION]-markører i spec.md.

Der bør ikke stå teknologier i spec.md. Ingen omtale af React, Postgres, Prisma eller Redis. Specifikationen beskriver, hvad systemet gør set fra brugerens og virksomhedens perspektiv. Teknologistakken kommer i næste fase.

Hvad gør Claude i Plan-fasen?#

Når spec.md er klar, kører du:

/speckit-plan

Du kan eventuelt sende teknologiledetråde direkte med kommandoen:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude læser tre kilder: din spec.md, din CLAUDE.md (eller memory/constitution.md) og den eksisterende kode i repoet. Outputtet er en plan.md med en struktur omtrent som denne:

# 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 entiteterne og deres relationer. contracts/ indeholder API-kontraktskeletter (enten OpenAPI YAML eller TypeScript request/response-typer). Det er ikke kode—det er en beskrivelse af intentioner, som Claude senere omsætter til faktiske routes.

Den største fordel ved Plan-fasen er en ren kontekst. Claude forsøger ikke at holde både specifikationen og implementeringen i tankerne på samme tid. Den gennemtænker først tingene, registrerer beslutningen i en fil og går derefter videre.

Dernæst er der den valgfri kommando /speckit-analyze. Den køres efter Tasks-fasen og før Implement: Den gennemgår sættet spec.md + plan.md + tasks.md for modsigelser og kontrollerer, om alle specifikationens krav er dækket af planen og opgaverne. Den redigerer ikke filer; den producerer kun en rapport. Det er i bund og grund en formel fornuftskontrol inden implementeringen.

Sådan opdeler du arbejdet i opgaver (Tasks)#

Når du har spec.md og plan.md, kører du:

/speckit-tasks

Claude udvider planen til tasks.md:

# 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æg mærke til markeringerne parallel-safe og after T-NNN. Det er afhængighedsgrafen, der senere gør det muligt at køre flere faser parallelt. Hele Spec Kit-tilgangen til at sætte tempo på bygger på denne mekanisme: Nogle opgaver kan gives til fem forskellige Claude Code-sessioner på én gang, mens andre skal køres strengt sekventielt.

Spec Kit gør det automatisk med én kommando, lige fra starten.

Den valgfri kommando /speckit-taskstoissues tager tasks.md og opretter GitHub Issues fra listen, hver med et link tilbage til spec.md. Det er nyttigt, hvis du arbejder i et team eller vil følge fremskridtene gennem GitHub Projects.

Sådan implementerer du med underagenter (Implement)#

/speckit-implement

Claude begynder med den første opgave i tasks.md. Hver opgave gennemgår en kort cyklus: læs de relevante filer, skriv en diff, kør testene, kontrollér [x]. Underagenter kaldes automatisk, når der er behov for dem: én særskilt til kodegennemgang, én til at køre linteren og én til at kontrollere for regressioner.

Og særskilt om regler:

I Spec Kit er denne cyklus formaliseret. Du har spec.md som sandhedskilde, plan.md til tekniske beslutninger og tasks.md som tjekliste. Hvis Claude kommer på afveje på et hvilket som helst trin, går du tilbage til specifikationen og siger: “Det stemmer ikke med FR-003; lav det om.” Ingen lange prompts som “husk, hvad vi talte om...” — hele historikken ligger i filerne.

Hvis du har tilsluttet Dynamic Workflows i Opus 4.8, kan du sætte Spec Kit i fuldautomatisk tilstand: Én /speckit-implement-kommando, og Claude paralleliserer arbejdet, samler resultaterne og kontrollerer dem. Grænsen er 1000 underagenter på én gang. For de fleste funktioner er 10-30 nok.

Når alle [x]-felter er markeret, og kontrollen i næste afsnit svarer “Converged”, gennemgår du PR’en (eller en række PR’er, hvis der er mange opgaver) og merger den. Artefakterne—spec.md, plan.md, tasks.md—bliver liggende i repoet som funktionens dokumentation. Et år senere behøver du ikke reverse-engineere logikken ud fra koden.

Sådan kontrollerer du, at agenten ikke har overset noget (Converge)#

/speckit-converge

Først giver agenten et resumé af, hvad den fandt, med alvorlighedsgrader, og derefter et af to udfald. “Converged” betyder, at der ikke er nogen udeladelser, at tasks.md er byte for byte uændret, og at du kan gå videre til gennemgang. “Tasks appended” betyder, at der blev fundet udeladelser, at de blev tilføjet til afsnittet Convergence i tasks.md, og at agenten fortæller dig, hvor mange der er.

Converge redigerer eller sletter ikke kode; dens eneste skrivning er nye opgaver i tasks.md. Derfor kan du køre den uden bekymring, men først efter at /speckit-implement allerede har arbejdet sig gennem den aktuelle tasks.md. Hver efterfølgende gennemgang finder færre udeladelser.

Hvordan adskiller Spec Kit sig fra CLAUDE.md og Plan Mode?#

Sammenlign dem på tværs af 5 egenskaber:

I Spec Kit-termer er dette .specify/memory/constitution.md. Under initialiseringen kan Spec Kit enten bruge din eksisterende CLAUDE.md som grundlag for constitution eller oprette en separat fil ved siden af den. Jeg beholder normalt CLAUDE.md som den globale “kontrakt” (stack, ordliste, udrulningsprotokol) og bruger Spec Kit-constitution til regler, der gælder specifikt for funktioner—for eksempel “alle formularer valideres gennem Zod; ingen manuelle kontroller”.

Forbindelsen til Plan Mode er enklere. Plan Mode er en hurtig tilstand for “planlægning før kodning” i én session. Den fungerer godt til små ændringer (ret en fejl, refaktorer en funktion). Til en stor funktion kommer Plan Mode til kort, fordi én sessions kontekstvindue er for lille til en plan på 3000 linjer—som jeg forklarer direkte i live-sessionen:

Spec Kit er et konkret værktøj til kontekstteknik. Det flytter det “arkitektoniske klæde” fra chatten over i filer. Spec.md bliver i repoet, og hver ny Claude-session læser den igen—du behøver ikke gentage dig selv.

En opsætning til et stort projekt:

1. CLAUDE.md - stack, ordliste, hvad man ikke skal gøre. Den ligger i roden.
2. .specify/memory/constitution.md for Spec Kit—regler, der gælder specifikt for denne arbejdsgang.
3. specs/001-feature-A/spec.md, plan.md, tasks.md - første funktion.
4. specs/002-feature-B/spec.md, plan.md, tasks.md - anden funktion.
5. Til det daglige arbejde enten /speckit-implement (til færdige opgaver) eller /plan (et hurtigt ekstra tjek før en ændring).

Hvilke cases fungerer i den virkelige verden?#

Konkrete cases:

• AWS Kiro - lægemiddeludviklingsagent. I et blogindlæg fra AWS Industries dateret 18. februar 2026 beskriver teamet TargetID-projektet. Tre udviklere, tre uger, en lægemiddeludviklingsagent. Tallene i artiklen: Kiro genererede mere end 95 % af forretningslogikkens kode, hvilket sparede mere end 80 udviklingstimer. Desuden: “README-dokumentation skrevet af Kiro sparede os anslået 8 timer” og “40 % færre iterative prompt-og-fix-cyklusser”.
• Rackspace Technology. I samme AWS-blog rapporterer Rackspace: “gennemførte 52 ugers anslået arbejde på blot 3 uger”, “90 % stigning i effektiviteten”. Det er ikke længere en lille funktion—det er et helt virksomhedsprojekt.
• Væksten i GitHub Spec Kit. Den 31. maj havde repoet 107.000 stjerner. Denne vækstrate er et tydeligt signal om, at tilgangen vinder markedsandele.

For læseren betyder det, at tilgangen ikke er teoretisk: seriøse teams bruger den allerede i produktion.

Hvornår er Spec Kit IKKE egnet?#

Uegnet nr. 1 - små ændringer. Hvis opgaven er “omdøb en variabel”, “ret en slåfejl i teksten” eller “tilføj en log”, tager det længere tid at gennemgå Specify → Plan → Tasks end selve ændringen. Til små ændringer er Plan Mode eller blot en direkte prompt i Claude Code hurtigere.

Uegnet nr. 2 - liveeksperimenter. Når du endnu ikke ved, hvad du vil have, og har brug for at “prøve dig frem” i grænsefladen eller hurtigt sætte en prototype sammen for at se, “om den rammer plet”, er en specifikation meningsløs. Værdien ligger netop i, at du improviserer. Når det handler om at “lege med en idé”, er vibe netop det, der virker, ikke en specifikation.

Uegnet nr. 3 - legacykode med kompleks tilstand. Et stærkt modargument: “Virkeligheden ændrer sig hurtigere end specifikationer.” Tag fakturering af abonnementer som eksempel: Teamet beskrev faktureringscyklusser og skatteregler, og en uge senere bad Finance om europæisk moms—specifikationen var forældet før udgivelsen. Når forretningslogikken udvikler sig hurtigt, bliver vedligeholdelsen af specifikationer en byrde.

En yderligere risiko er en falsk følelse af kontrol: strukturerne er elegante, men agenter ignorerer ofte instruktioner eller følger omvendt skabelonerne alt for bogstaveligt. Resultatet er kode, der er strukturelt korrekt, men ikke passer til netop dit repo—specifikationen garanterer ikke, at agenten forstod den, sådan som du mente den.

I april 2026 advarede brancheanalytikere mod vandfaldsmodellen: At skrive en stor specifikation før kode er en vej, der allerede én gang har bragt branchen i knæ, dengang kravspecifikationer var 200 sider lange. Ingeniører har været forsigtige med denne tilgang lige siden, og den forsigtighed er berettiget.

Hvad skal man gøre ved det? Jeg foreslår en enkel regel: funktionens størrelse i forhold til den tid, det tager at skrive en specifikation. Hvis en funktion tager mindre end 2 timer at implementere, skal du ikke skrive en spec—Plan Mode er hurtigere. Hvis en funktion tager en uge, skal du helt klart bruge Spec Kit; tidsbesparelsen betaler den time lange specifikation fem gange tilbage. Mellem 2 timer og en uge må du bruge din egen vurdering, men jeg skriver personligt en spec selv til funktioner på en halv dag, fordi artefaktet i repoet er mere værd end de 30 minutter, man sparer.

Hvad nu: hvordan integrerer du Spec Kit i dit projekt?#

En konkret plan for de næste 7 dage:

• Dag 1. Installér uv og Spec Kit (5-10 minutter). Kontrollér, at /speckit-*-kommandoerne er dukket op i Claude Code. Prøv ikke at anvende dem på et eksisterende projekt—begynd med et nyt.
• Dag 2. Vælg en reel funktion, du planlægger at bygge. Kør /speckit-specify med en frit formuleret beskrivelse. Åbn spec.md, læs den, og besvar alle [NEEDS CLARIFICATION]. Gå ikke for hurtigt videre til Plan.
• Dag 3. Kør /speckit-plan med ledetråde om din stack. Læs plan.md, især afsnittet Architecture Decisions. Hvis noget ikke passer dig, skal du redigere det manuelt.
• Dag 4-5. Kør /speckit-tasks, derefter /speckit-analyze for at dobbelttjekke sættet af spec, plan og opgaver, og så /speckit-implement. Hold øje med, hvordan Claude markerer [x] i tasks.md. Den kan gå i stå et sted—det er normalt. Gå tilbage til spec.md, præcisér kravet, og genstart /speckit-implement med en specifik opgave. Når opgaverne er afsluttet, skal du køre /speckit-converge og gentage Implement- og Converge-sekvensen, indtil den svarer “Converged”.
• Dag 6-7. Gennemgå PR’en (eller rækken af PR’er). Merge den. Læs din spec.md og plan.md—de er din dokumentation for funktionen det næste år.

Det foreslår jeg, at du læser sideløbende:

• Sådan konfigurerer du CLAUDE.md i 2026 - grundlaget for Spec Kits constitution.
• Plan Mode i Claude Code - et hurtigt alternativ til små opgaver.
• Kontekstteknik i 2026 - hvorfor Spec Kit overhovedet fungerer.
• Skills, underagenter, MCP eller Plugins - hvad du kan føje til Spec Kit i din arbejdsgang.
• Dynamic Workflows i Claude Code - hvordan du starter mange underagenter på én gang i Implement-fasen.

Den komplette kontekst-arbejdsgang: AI-klon + Second Brain + Context Engineering.

Flere materialer findes på Ailoot.