# Spec Kit instellen in Claude Code in 2026: specificaties in plaats van prompts > Zo stel je GitHub Spec Kit in Claude Code in: vier fasen—Specify, Plan, Tasks, Implement. Ontdek hoe specificaties improvisatie kunnen vervangen. Source: https://ailoot.ai/blog/nl/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/nl/spec-kit-claude-code-spec-driven-development/ Language: nl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-37d690b0b61bfd0d8d9d872ee8519679d3f1bec6bd55d26d7716971613466ece
Belangrijkste conclusie Spec Kit is een tool van GitHub waarmee je een taakspecificatie in natuurlijke taal schrijft. Vervolgens stelt Claude Code een plan op, verdeelt het de taak in taken en schrijft het de code. Deze gids behandelt de installatie, sjablonen, de vier fasen van de workflow met een eindcontrole, en de koppeling met je CLAUDE.md.
[Ailoot-documentatie](https://ailoot.ai/docs/) — naslagmateriaal over het gebruik van de dienst.
## Wat gebeurde er in mei 2026 met vibe coding?
Belangrijkste conclusie GitHub Spec Kit verzamelde in acht maanden meer dan 107.000 sterren. AWS publiceerde een casestudy waarin 80+ uur besparing op één functie werd gemeld. De trend van de week in mei: specificaties als vervanging voor improvisatie.
Een jaar later, op 4 februari 2026, publiceerde hij een terugblikkende thread: In zijn presentatie op Sequoia Ascent 2026 verwoordde hij het nog preciezer: “Vibe coding verhoogt de ondergrens: hoeveel iedereen met software kan doen. Agentic engineering bewaart de bovengrens: de kwaliteitsnorm van professionele ontwikkeling.” Op hetzelfde podium liet hij een uitspraak vallen die deel werd van het jargon in de sector: “Je mag geen kwetsbaarheden introduceren vanwege vibe coding. Je blijft verantwoordelijk voor je software, net als voorheen.” Twee dingen gebeurden tegelijk. In september 2025 publiceerde GitHub de tool [Spec Kit](https://github.com/github/spec-kit); die verzamelde in acht maanden 107.000 sterren. In februari 2026 publiceerde AWS [een uitgebreide casestudy over geneesmiddelenontdekking](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) waarin werd gemeld: “95% van de bedrijfslogica gegenereerd op basis van de specificatie, wat 80+ uur bespaarde.” Tegen eind mei 2026 was er in de Engelstalige informatieomgeving consensus ontstaan: vibe coding als werkmethode is het beginnersniveau. Daarna komt Spec-Driven Development. Deze gids legt uit hoe je de aanpak installeert en toepast. ## Wat zijn Spec Kit en Spec-Driven Development?
Belangrijkste conclusie Spec-Driven Development (SDD) draait de gebruikelijke aanpak van een AI-agent om. Voorheen was de code de bron van waarheid en was de specificatie begeleidend papierwerk. Nu is de specificatie de bron van waarheid en wordt de code de laatste stap: de implementatie ervan. Spec Kit is een CLI-tool van GitHub die 4 fasen (Specify, Plan, Tasks, Implement) en een laatste Converge-controle omzet in gebruiksklare opdrachten voor Claude Code, Cursor, Copilot en 30+ andere agents.
De kern van de methodologie is vastgelegd in één zin uit de officiële documentatie van GitHub:

Spec-Driven Development verandert de hiërarchie: specificaties dienen niet de code; de code dient de specificaties. De specificatie wordt het primaire artefact en de code is de uitdrukking ervan in een bepaalde taal en een bepaald framework.

— GitHub Spec Kit-documentatie, https://github.com/github/spec-kit/blob/main/spec-driven.md
In de praktijk verloopt dit in 4 fasen (Spec Kit voegt daar nog een nulde fase aan toe: de grondwet, die hieronder wordt beschreven): 1. **Specify** - schrijf in natuurlijke taal een specificatie van wat je wilt. WAT er moet gebeuren en WAAROM. Niet HOE. 2. **Plan** - de agent neemt de specificatie en stelt een technisch plan op: welke technologieën, welke architectuur en welke componenten. 3. **Tasks** - de agent verdeelt het plan in specifieke, verifieerbare taken met afhankelijkheden. 4. **Implement** - de agent (of zijn subagents) voert de taken uit en schrijft de code. Na Implement heeft de huidige versie van Spec Kit een verificatiestap genaamd **Converge**: de agent controleert de voltooide code aan de hand van de specificatie, het plan en de taken, en voegt daarna alles wat ontbreekt toe aan `tasks.md`. Herhaal Implement en Converge totdat Converge “Converged” antwoordt. Elke fase staat in een apart markdownbestand in de repo. In Claude Code is elke fase een aparte slashopdracht: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`; de controle is `/speckit-converge`. De documentatie van Spec Kit schrijft dezelfde opdrachten met een punt (`/speckit.specify`), maar in Claude Code installeert Spec Kit ze als skills en roep je ze aan met een koppelteken. Gaat er bij een stap iets mis, bewerk dan het markdownbestand en voer de volgende fase opnieuw uit. Spec Kit is een specifieke implementatie van SDD. In mei 2026 had het al meer dan 30 integraties met verschillende AI-agents. Binnen één repo werkt Spec Kit op dezelfde manier met Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose en nog een dozijn andere agents. | Spec Kit-fase | Slashopdracht | Artefact in de repo | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (optioneel) | `/speckit-clarify` | bewerkingen in `spec.md` | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (optioneel) | `/speckit-checklist` | checklist voor de kwaliteit van vereisten | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (optioneel) | `/speckit-analyze` | rapport over spec, plan en taken | | Implement | `/speckit-implement` | code in het project | | Converge | `/speckit-converge` | oordeel “Converged” of nieuwe taken in `tasks.md` | Na een run bevat je repo dus niet alleen code, maar ook de specificatie, het plan en de taken. Een maand later kun je terugkeren naar het project, `spec.md` lezen en begrijpen wat er is gedaan en waarom. Dit is niet langer “vibe coding vergat dat de code bestond”; het is het werkgeheugen van het project. ## Waarom heeft een vibe coder die geen code schrijft dit nodig?
Belangrijkste conclusie Het grootste pijnpunt voor een vibe coder is onvoorspelbaarheid. Vandaag bouwt de agent in 20 minuten een werkende functie voor je; morgen levert hij bij een vergelijkbare taak spaghetti op. Spec Kit neemt de bron van die onvoorspelbaarheid weg: een vaag geformuleerde taak. Wanneer je met een sjabloon een specificatie schrijft, werkt de agent consistent omdat hij een ondubbelzinnige bron van waarheid heeft. Bovendien krijg je een blijvend artefact in de repo waar je een maand later op kunt terugkomen.
Spec Kit formaliseert planning in afzonderlijke stappen met vier slashopdrachten. De logica: scheid “erover nadenken” van “het implementeren”, zodat ze in verschillende contextvensters plaatsvinden. Elke fase krijgt een schone context die niet is vervuild door de vorige fase. Drie concrete voordelen voor een vibe coder: - **Voorspelbaarheid.** Wanneer je de agent vertelt “maak een registratieformulier met e-mailbevestiging”, raadt hij zelf 10 details en heeft hij er drie verkeerd ten opzichte van wat jij bedoelde. Met een `spec.md` met User Stories, Acceptance Scenarios en `[NEEDS CLARIFICATION]`-markeringen op elk onzeker punt valt er niets te raden. - **Projectgeheugen.** Een maand later weet je niet meer wat je met de agent in de chat hebt besproken. Maar `spec.md`, `plan.md` en `tasks.md` staan in de repo, in de map `specs/###-feature/` naast de code. Ze laten niet alleen zien wat er is gedaan, maar ook waarom. - **Schaal.** Bij een functie die 1-2 bestanden omvat, is het verschil nauwelijks merkbaar. Bij een functie met 20 bestanden en 5 data-entiteiten is het verschil dat tussen “na 4 uur alles opnieuw schrijven” en “na 4 uur staat alles in de hoofdbranch”. AWS Kiro liet in het TargetID-project zien dat 95% van de bedrijfslogica op basis van een specificatie geautomatiseerd werd. De grootste illusie van vibe coding is dat het in het begin sneller lijkt. Een halfuur later is er een prototype. Maar na een week breekt het prototype en is het makkelijker om het weg te gooien. Spec-Driven Development kost in het begin iets meer tijd (een uur in plaats van een halfuur), maar een week later werk je nog steeds in dezelfde repo. ## Spec Kit installeren in Claude Code (4 stappen)
Belangrijkste conclusie Spec Kit wordt geïnstalleerd via uv, een Python-pakketbeheerder van Astral. De opdracht zelf bestaat uit één regel. Ga na de installatie naar je repo, voer `specify init` uit met de vlag `--integration claude` (of kies Claude Code uit de lijst met agents) en je krijgt een kant-en-klare structuur met sjablonen voor de constitution, spec, plan en taken, plus een reeks `/speckit-*`-opdrachten direct in Claude Code. De installatie duurt 5 minuten als uv al geïnstalleerd is en 10 minuten als je uv vanaf nul installeert.
**Stap 1. Installeer uv.** Dit hoef je maar één keer te doen; daarna blijft het op je systeem staan. ```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" ``` Controleer of uv is geïnstalleerd: ```bash uv --version ``` **Stap 2. Installeer Spec Kit.** Eén opdracht: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Controleer: ```bash specify --version ``` **Stap 3. Initialiseer de repo.** Ga naar de map van je project (of maak een nieuwe aan) en voer uit: ```bash specify init --here --integration claude ``` Met de vlag `--integration claude` selecteer je Claude Code rechtstreeks. Zonder die vlag vraagt Spec Kit je een agent uit een interactieve lijst te kiezen en mogelijk ook een scripttype (laat dit voor macOS en Linux op `sh` staan). Als de map niet leeg is, waarschuwt Spec Kit dat het zijn bestanden met die van jou zal samenvoegen: commit eerst je werk en herhaal de opdracht daarna met de vlag `--force`. Daarna verschijnen de volgende bestanden in de repo: ``` .specify/ memory/ constitution.md # projectregels, ingevuld door /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 ``` **Stap 4. Open Claude Code en controleer de slashopdrachten.** Voer dit uit in dezelfde map: ```bash claude ``` Typ in de sessie `/speckit`; de `speckit-*`-opdrachten zouden in de suggesties moeten verschijnen. Zo niet, start Claude Code dan opnieuw op zodat het `.claude/skills/` opnieuw inleest. Als `CLAUDE.md` al in de hoofdmap van het project staat, laat Spec Kit dat bestand ongemoeid; het werkt ernaast, in `.specify/memory/constitution.md`. Spec Kit werkt ook zonder Claude Code (het ondersteunt 30+ agents), maar deze gids behandelt de configuratie specifiek met Claude. Wil je meteen twee tools installeren, bekijk dan de aparte gidsen over [CLAUDE.md instellen](https://ailoot.ai/blog/nl/claude-md-template/) en [Plan Mode in Claude Code](https://ailoot.ai/blog/nl/claude-code-plan-mode/). Spec Kit is het eerste bouwblok van een “arbeidsovereenkomst voor agents”. De complete configuratie omvat alle drie: een AI-kloon (jouw methodologie in de vorm van Skills en subagents), een Second Brain (de `business/`-structuur waarnaar de agent telkens terugkeert) en context engineering (Spec Kit, Plan Mode, /compact). Dit zijn de drie pijlers die AI-hallucinaties tegengaan. ## Je eerste specificatie schrijven (Specify)
Belangrijkste conclusie Spec Kit vraagt je een functie in vrije vorm te beschrijven en breidt die beschrijving vervolgens met een sjabloon uit tot een `spec.md`-bestand: User Stories met P1/P2/P3-prioriteiten, Acceptance Scenarios in Given/When/Then-formaat, Functional Requirements (FR-001, FR-002 enzovoort) en Success Criteria met meetbare resultaten. Waar de agent onzeker is, voegt die een markering `[NEEDS CLARIFICATION: ...]` toe; beantwoord die voordat je naar Plan gaat.
Typ in Claude Code: ``` /speckit-specify ``` De agent zal je vervolgens om een beschrijving van de functie vragen. Gebruik in deze stap gewone taal, zonder technisch jargon: ``` Ik wil een registratieformulier in mijn app. De gebruiker voert een e-mailadres en wachtwoord in, ontvangt een bevestigingsmail en komt na de bevestiging op het dashboard terecht. De bevestiging verloopt na 48 uur. Is de e-mail nog onbevestigd, verwijder het account dan binnen 5 minuten na die deadline; verwijder nooit een bevestigd account. ``` In dit illustratieve voorbeeld is de verwijdertolerantie verduidelijkt tot 5 minuten na de deadline van 48 uur. Bevestig die tolerantie voor een echt product vóór Plan; een exacte deadline van 48 uur vereist ontwerp en tests die die strengere eis afdwingen. De agent stelt `specs/001-registration/spec.md` samen. Open het bestand; je ziet een structuur zoals deze: ```markdown # Functiespecificatie: Gebruikersregistratie **Feature Branch**: `001-registration` **Aangemaakt**: 2026-05-31 **Status**: Concept **Input**: Gebruikersbeschrijving: "Ik wil een registratieformulier..." ## Gebruikersscenario’s en testen *(verplicht)* ### Primair gebruikersverhaal Als nieuwe gebruiker wil ik een account registreren met e-mailbevestiging, zodat ik met een geverifieerde identiteit toegang krijg tot het dashboard. ### Acceptatiescenario’s 1. **Als** ik op de registratiepagina ben, **Wanneer** ik een geldig e-mailadres en wachtwoord verstuur, **Dan** ontvang ik binnen 1 minuut een bevestigingsmail. 2. **Als** ik binnen 48 uur op de bevestigingslink heb geklikt, **Wanneer** ik op het dashboard terechtkom, **Dan** zie ik dat mijn e-mailadres in mijn profiel is bevestigd. 3. **Als** ik op de deadline van 48 uur niet heb bevestigd, **Wanneer** opruiming binnen de volgende 5 minuten draait, **Dan** wordt mijn account verwijderd en komt het e-mailadres vrij. 4. **Als** mijn account net geen 48 uur oud of al bevestigd is, **Wanneer** opruiming draait, **Dan** wordt het account niet verwijderd. ## Vereisten *(verplicht)* ### Functionele vereisten - **FR-001**: Het systeem MOET registratie accepteren via [VERDUIDELIJKING NODIG: alleen e-mail/wachtwoord, of ook SSO/OAuth?] - **FR-002**: Het systeem MOET de bevestigingsmail binnen 60 seconden versturen - **FR-003**: Bevestiging MOET na 48 uur verlopen; het systeem MOET nog onbevestigde accounts uiterlijk 5 minuten na die deadline verwijderen en MAG bevestigde accounts NIET verwijderen - **FR-004**: Het systeem MOET alle registratiepogingen loggen gedurende [VERDUIDELIJKING NODIG: hoelang bewaren we logs - 30 dagen, 90 dagen, voor altijd?] ### Belangrijke entiteiten - Gebruiker: email, password_hash, email_verified_at, created_at, deleted_at - ConfirmationToken: token, user_id, expires_at, used_at ## Succescriteria *(verplicht)* - **SC-001**: 95% van de bevestigingsmails wordt binnen 60 seconden afgeleverd (p95) - **SC-002**: 0 onbedoelde verwijderingen van bevestigde accounts - **SC-004**: Geen verwijdering vóór 48 uur; elk geschikt onbevestigd account is bij de geteste werklast op leeftijd 48 uur 5 minuten verwijderd - **SC-003**: Voltooiingspercentage van registraties > 60% (van openen van het formulier tot het dashboard) ``` Let op de markeringen `[NEEDS CLARIFICATION: ...]`. Spec Kit voegt die bewust overal toe waar de agent geen eenduidig antwoord uit je tekst heeft kunnen afleiden. Voordat je naar de fase Plan gaat, moet je de vragen handmatig beantwoorden in `spec.md` of `/speckit-clarify` uitvoeren; dan doorloopt de agent de onduidelijke punten en stelt vragen in het gesprek. In Spec Kit vervangt de ingebouwde opdracht `/speckit-clarify` het mondelinge “stel me vragen”. Het effect is hetzelfde: je gaat pas verder naar Plan als er geen `[NEEDS CLARIFICATION]`-markeringen meer in `spec.md` staan. Er horen geen technologieën in `spec.md` te staan. Geen vermeldingen van React, Postgres, Prisma of Redis. De specificatie beschrijft wat het systeem doet vanuit het perspectief van de gebruiker en het bedrijf. De technologiestack komt in de volgende fase. ## Wat doet Claude in de Plan-fase?
Belangrijkste conclusie De opdracht `/speckit-plan` neemt de voltooide specificatie en stelt een technisch plan op: welke technologieën worden gebruikt, welke architectuur, modules, data-entiteiten en API-contracten nodig zijn. Het plan wordt geschreven naar `specs/###-feature/plan.md`, contracten worden geëxporteerd naar een aparte map `contracts/` en het datamodel komt in `data-model.md`. In deze stap kent Claude je stack al via CLAUDE.md en de constitution, zodat het plan bij het bestaande project past in plaats van voor te stellen “laten we alles in Rust herschrijven”.
Voer uit zodra `spec.md` klaar is: ``` /speckit-plan ``` Je kunt eventueel technologieaanwijzingen rechtstreeks aan de opdracht toevoegen: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email ``` Claude leest drie bronnen: je `spec.md`, je `CLAUDE.md` (of `memory/constitution.md`) en de bestaande code in de repo. Het resultaat is een `plan.md` met ongeveer deze structuur: ```markdown # Implementatieplan: Gebruikersregistratie ## Technische context - Framework: Next.js 14 App Router - Database: PostgreSQL via Prisma - E-mail: Resend (één transport) - Validatie: Zod-schema in gedeelde lib - Authenticatie: NextAuth.js met credentials-provider ## Architectuurbeslissingen ### 1. Tokenopslag Tokens worden opgeslagen in de DB (tabel ConfirmationToken), niet in JWT. Reden: server-side intrekking nodig bij herregistratie met e-mailadres. ### 2. E-mailbezorging Asynchroon via cron `/api/cron/send-confirmation`, direct na registratie gestart. Resend verzorgt nieuwe pogingen. ### 3. Cron voor automatisch verwijderen Voer `/api/cron/cleanup-unconfirmed` elke minuut uit. Verwijder alleen rijen waarvoor `created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL` geldt. Het verduidelijkte voorbeeld staat maximaal 5 minuten verwijdervertraging toe. Controleer plannervertraging en voltooiingstijd tegen die grens; rapporteer een overschrijding als fout, niet als geslaagde dagelijkse opruiming. ## Datamodel Zie data-model.md ## API-contracten Zie contracts/ - POST /api/auth/register - POST /api/auth/confirm - GET /api/auth/resend-confirmation ## Implementatiefasen 1. Databasemigratie (Prisma-schema + migratiebestand) 2. API-routes (3 endpoints) 3. UI: registratieformulier + pagina voor geslaagde bevestiging 4. Cronjobs (verzenden + opschonen) 5. E-mailsjabloon 6. Integratietests ``` `data-model.md` beschrijft de entiteiten en hun relaties. `contracts/` bevat schetsen van API-contracten (OpenAPI YAML of TypeScript request- en responstypen). Dit is geen code, maar een beschrijving van de bedoeling die Claude later omzet in echte routes. Het belangrijkste voordeel van de Plan-fase is een schone context. Claude hoeft de specificatie en implementatie niet tegelijk in gedachten te houden. Eerst denkt het alles uit, legt de beslissing vast in een bestand en gaat daarna verder. Daarna is er de optionele opdracht `/speckit-analyze`. Die wordt na de fase Tasks en vóór Implement uitgevoerd: ze beoordeelt de set `spec.md + plan.md + tasks.md` op tegenstrijdigheden en controleert of alle specificatievereisten in het plan en de taken zijn opgenomen. De opdracht bewerkt geen bestanden; ze maakt alleen een rapport. In wezen is dit een formele sanitycheck vóór de implementatie. ## Werk opdelen in taken (Tasks)
Belangrijkste conclusie De opdracht `/speckit-tasks` verdeelt het plan in concrete taken. Elke taak bevat afhankelijkheden, een schatting en een markering: “kan parallel worden uitgevoerd” of “strikt sequentieel”. Het resultaat is `tasks.md`, met taken in checklistformaat `[ ] T-001: ...`. Je kunt deze taken daarna voor implementatie aanleveren met `/speckit-implement` of ze met `/speckit-taskstoissues` omzetten in GitHub Issues, waarna je ze over een team of verschillende parallelle Claude Code-sessies kunt verdelen.
Voer uit zodra je `spec.md` en `plan.md` hebt: ``` /speckit-tasks ``` Claude werkt het plan uit in `tasks.md`: ```markdown # Taken: Gebruikersregistratie ## Fase 1: Database (geen afhankelijkheden) - [ ] T-001: Voeg het User-model toe aan prisma/schema.prisma (veilig om parallel uit te voeren) - [ ] T-002: Voeg het ConfirmationToken-model toe aan prisma/schema.prisma (na T-001) - [ ] T-003: Genereer migratie `add-user-registration` (na T-002) ## Fase 2: API-contracten (geen afhankelijkheden) - [ ] T-004: Maak Zod-schema’s in shared/validation/auth.ts - [ ] T-005: Definieer TypeScript-types in shared/types/auth.ts (na T-004) ## Fase 3: Routes (afhankelijk van fase 1+2) - [ ] T-006: Implementeer POST /api/auth/register - [ ] T-007: Implementeer POST /api/auth/confirm - [ ] T-008: Implementeer GET /api/auth/resend-confirmation ## Fase 4: UI (parallel aan fase 3) - [ ] T-009: Bouw de pagina /register met formulier - [ ] T-010: Bouw de pagina /register/confirm/[token] - [ ] T-011: Bouw de pagina /register/success ## Fase 5: Cron + integratie (afhankelijk van fase 3+4) - [ ] T-012: Cron /api/cron/send-confirmation - [ ] T-013: Cron /api/cron/cleanup-unconfirmed - [ ] T-014: E-mailsjabloon registration-confirmation.tsx - [ ] T-015: Integratietests (Playwright), inclusief opruiming net vóór 48u, exact op 48u, verwijdering vóór 48u 5m, vertraagde-taakfout en bescherming van bevestigde accounts ## Opmerkingen - T-001, T-004, T-009-T-011 zijn veilig parallel uit te voeren (verschillende bestanden) - T-002 conflicteert met T-001 (zelfde bestand: schema.prisma) - voer ze sequentieel uit - T-006 vereist T-003 (migratie toegepast) en T-005 (types) ``` Let op de markeringen `parallel-safe` en `after T-NNN`. Dit is de afhankelijkheidsgraaf waarmee je later meerdere fasen parallel kunt uitvoeren. De hele versnellingsaanpak van Spec Kit berust op dit mechanisme: sommige taken kun je tegelijk aan vijf verschillende Claude Code-sessies geven, terwijl andere strikt sequentieel moeten gebeuren. Spec Kit doet dit automatisch met één opdracht, direct uit de doos. De optionele opdracht `/speckit-taskstoissues` neemt `tasks.md` en maakt GitHub Issues aan op basis van de lijst, elk met een koppeling naar `spec.md`. Dit is handig als je in een team werkt of de voortgang via GitHub Projects wilt bijhouden. ## Implementeren met subagents (Implement)
Belangrijkste conclusie De laatste fase, `/speckit-implement`, start de implementatie. Claude werkt `tasks.md` van boven naar beneden af en markeert voltooide taken met `[x]`. Je kunt meerdere parallelle Claude Code-sessies tegelijk uitvoeren, één fase per sessie. Binnen elke sessie start Claude subagents voor verschillende soorten werk: een reviewer voor code, een tester voor controles en een documentatieschrijver voor de README. Dit is de “1000 parallelle subagents” waar Anthropic over schreef bij de release van Opus 4.8; in Spec Kit is het gewoon een werkmodus, geen apart product.
``` /speckit-implement ``` Claude begint met de eerste taak in `tasks.md`. Elke taak doorloopt een korte cyclus: relevante bestanden lezen, een diff schrijven, tests uitvoeren en `[x]` aanvinken. Waar nodig worden subagents automatisch ingeschakeld: één voor codebeoordeling, één voor het uitvoeren van de linter en één voor het controleren op regressies. En over regels zegt hij afzonderlijk: In Spec Kit is deze cyclus geformaliseerd. Je hebt `spec.md` als bron van waarheid, `plan.md` voor technische beslissingen en `tasks.md` als checklist. Raakt Claude bij een stap van het spoor, dan ga je terug naar de specificatie en zeg je: “Dit komt niet overeen met FR-003; doe het opnieuw.” Geen lange prompts met “onthoud wat we hebben besproken...” — de volledige geschiedenis staat in de bestanden. Als je [Dynamic Workflows in Opus 4.8](https://ailoot.ai/blog/nl/claude-code-dynamic-workflows/) hebt gekoppeld, kun je Spec Kit volledig automatiseren: één opdracht `/speckit-implement` en Claude paralleliseert het werk, voegt de resultaten samen en controleert ze. De limiet is 1000 subagents tegelijk. Voor de meeste functies zijn 10-30 voldoende. Wanneer alle vakjes `[x]` zijn aangevinkt en de controle in de volgende sectie “Converged” oplevert, beoordeel je de PR (of een reeks PR’s als er veel taken zijn) en voeg je die samen. De artefacten — `spec.md`, `plan.md`, `tasks.md` — blijven in de repo als documentatie van de functie. Een jaar later hoef je de logica niet uit de code te reconstrueren. ## Controleren of de agent niets heeft gemist (Converge)
Belangrijkste conclusie Na Implement heeft de huidige versie van Spec Kit een controlestap genaamd `/speckit-converge`. De agent vergelijkt de voltooide code met `spec.md`, `plan.md` en `tasks.md`. Als alles overeenkomt, antwoordt die “Converged” en laat de bestanden ongemoeid. Vindt de agent omissies, dan voegt die ze als nieuwe taken toe aan het einde van `tasks.md`. Voer daarna `/speckit-implement` opnieuw uit, gevolgd door `/speckit-converge`, totdat je “Converged” krijgt.
``` /speckit-converge ``` Eerst geeft de agent een samenvatting van wat die heeft gevonden, met ernstniveaus, en daarna een van twee uitkomsten. “Converged” betekent dat er geen omissies zijn, `tasks.md` byte voor byte ongewijzigd blijft en je kunt overgaan tot de review. “Tasks appended” betekent dat er omissies zijn gevonden en toegevoegd aan het gedeelte Convergence in `tasks.md`; de agent vertelt je hoeveel het er zijn. Converge bewerkt of verwijdert geen code; de enige schrijfactie is het toevoegen van nieuwe taken aan `tasks.md`. Je kunt het dus zonder zorgen uitvoeren, maar pas nadat `/speckit-implement` de huidige `tasks.md` heeft afgewerkt. Bij elke volgende ronde worden minder omissies gevonden. ## Waarin verschilt Spec Kit van CLAUDE.md en Plan Mode?
Belangrijkste conclusie Dit is een veelgestelde vraag bij het vergelijken van deze tools. Het korte antwoord: CLAUDE.md is het “arbeidscontract” van de agent, één bron van waarheid voor het hele project. Plan Mode is eenmalig plannen vóór een specifieke opdracht. Spec Kit is de volledige levenscyclus van één functie: van beschrijving tot implementatie, met artefacten in de repo. Ze vervangen elkaar niet, maar vormen samen een systeem van drie lagen: globale context (CLAUDE.md) → projectcontext (Spec Kit-constitution) → functiecontext (spec.md + plan.md + tasks.md).
Vergelijk ze op 5 kenmerken: | Kenmerk | CLAUDE.md | Plan Mode | Spec Kit | |----|----|----|----| | Wanneer het wordt uitgevoerd | Elke sessie | Op verzoek (Shift+Tab of /plan) | Via slashopdracht /speckit-\* | | Levensduur | Hele project | Eén sessie | Eén functie | | Waar het staat | Hoofdmap van de repo | In Claude’s context | `specs/###-feature/*` | | Wat het opslaat | Stack, regels, woordenlijst | Huidig plan + observaties | spec + plan + tasks + contracts | | Sjabloon | Vrije vorm (reporegels) | Geen | Gestructureerde markdown | | Beste rol | Projectregels en stack | Dubbele controle vóór een grote wijziging | Volledige functiecyclus: van WAT tot CODE | In Spec Kit-termen is de tegenhanger van CLAUDE.md `.specify/memory/constitution.md`. In de termen van Spec Kit is dit `.specify/memory/constitution.md`. Tijdens de initialisatie kan Spec Kit je bestaande CLAUDE.md als basis voor de constitution gebruiken of ernaast een apart bestand maken. Zelf houd ik CLAUDE.md meestal als het globale “contract” (stack, woordenlijst, implementatieprotocol) en gebruik ik de Spec Kit-constitution voor regels die specifiek zijn voor deze workflow, bijvoorbeeld: “alle formulieren worden gevalideerd met Zod; geen handmatige controles.” De koppeling met Plan Mode is eenvoudiger. Plan Mode is een snelle modus voor “plannen voordat je code schrijft” binnen één sessie. Het werkt goed voor kleine wijzigingen (een bug oplossen, een functie herstructureren). Voor een grote functie schiet Plan Mode tekort, omdat het contextvenster van één sessie te klein is voor een plan van 3000 regels, zoals ik tijdens de livesessie rechtstreeks uitlegde: Spec Kit is een concreet hulpmiddel voor context engineering. Het verplaatst het “architectuurlaken” uit de chat naar bestanden. Spec.md blijft in de repo staan en elke nieuwe Claude-sessie leest het opnieuw; je hoeft jezelf niet te herhalen. Een configuratie voor een groot project: 1. **CLAUDE.md** - stack, woordenlijst, wat je niet moet doen. Het staat in de hoofdmap. 2. **.specify/memory/constitution.md** voor Spec Kit — regels die specifiek zijn voor deze workflow. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** - de eerste functie. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** - de tweede functie. 5. Voor dagelijks werk: `/speckit-implement` voor kant-en-klare taken of `/plan` voor een snelle dubbelcheck vóór een wijziging. ## Welke voorbeelden uit de praktijk werken?
Belangrijkste conclusie De Spec Kit- en SDD-aanpak heeft bij grote bedrijven al meetbare resultaten opgeleverd. Bij een project voor geneesmiddelenontdekking van AWS werd 95% van de bedrijfslogica gegenereerd op basis van een specificatie, met 80+ uur besparing op één functie. Rackspace Technology meldde dat 52 weken geschat werk in 3 weken werd voltooid, met meer dan 90% efficiëntiewinst. Spec Kit zelf verzamelde in acht maanden 107.000 GitHub-sterren.
Concrete voorbeelden: - **AWS Kiro - agent voor geneesmiddelenontdekking.** In een [blogbericht van AWS Industries](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) van 18 februari 2026 beschrijft het team het TargetID-project. Drie ontwikkelaars, drie weken, een agent voor geneesmiddelenontdekking. Volgens het artikel genereerde Kiro meer dan 95% van de code voor de bedrijfslogica en bespaarde het meer dan 80 ontwikkeluren. Ook: “README-documentatie geschreven door Kiro bespaarde ons naar schatting 8 uur” en “40% minder iteratieve prompt-en-fix-cycli.” - **Rackspace Technology.** In hetzelfde AWS-blog meldt Rackspace: “52 weken geschat werk voltooid in slechts 3 weken”, “90% efficiëntietoename.” Dit is geen kleine functie meer, maar een volledig enterpriseproject. Voor de lezer betekent dit dat de aanpak geen theorie is: serieuze teams gebruiken die al in productie. ## Wanneer is Spec Kit NIET geschikt?
Belangrijkste conclusie Spec Kit is niet overal geschikt. Er zijn drie duidelijke situaties waarin je het beter niet gebruikt: kleine bewerkingen (een bug oplossen, een variabele hernoemen), experimenten en prototypes (waarbij niet weten wat je wilt juist het doel van vibe coding is) en legacycode met een complexe toestand (waarbij de specificatie sneller veroudert dan je die kunt afmaken). Er zijn serieuze kritieken op deze toepassingen. Hun argumenten zijn het kennen waard, zodat je geen tijd verspilt aan specificaties die niet helpen.
**Niet geschikt #1 - kleine bewerkingen.** Als de taak “hernoem een variabele”, “herstel een typefout in de tekst” of “voeg een log toe” is, duurt het doorlopen van Specify → Plan → Tasks langer dan de bewerking zelf. Voor kleine bewerkingen zijn Plan Mode of een rechtstreekse prompt in Claude Code sneller. **Niet geschikt #2 - live-experimenten.** Als je nog niet weet wat je wilt en de interface wilt “verkennen” of snel een prototype wilt samenstellen om te zien “of het aanslaat”, heeft een specificatie geen zin. De waarde zit juist in het improviseren. Bij “spelen met een idee” werkt vibe coding goed, niet een specificatie. **Niet geschikt #3 - legacycode met complexe toestand.** Een sterk tegenargument is dat de werkelijkheid sneller verandert dan specificaties. Neem abonnementsfacturering: het team beschreef factureringscycli en belastingregels, maar een week later vroeg Finance om Europese btw — de specificatie was al verouderd vóór de release. Wanneer bedrijfslogica snel verandert, wordt het bijhouden van specificaties een last. Een bijkomend risico is een vals gevoel van controle: de structuren zijn elegant, maar agents negeren instructies vaak of volgen sjablonen juist te letterlijk. Het resultaat is code die structureel correct is, maar niet bij jouw specifieke repo past; de specificatie garandeert niet dat de agent die heeft begrepen zoals jij bedoelde. Industrieanalisten hebben gewaarschuwd voor waterfall: een grote specificatie schrijven voordat je code schrijft, is een pad dat de sector eerder al ten val bracht, in de tijd van vereisten van 200 pagina’s. Sindsdien zijn engineers voorzichtig met deze aanpak, en die voorzichtigheid is terecht. **Wat kun je eraan doen?** Ik stel een eenvoudige regel voor: vergelijk de omvang van de functie met de tijd die het schrijven van een specificatie kost. Duurt de implementatie van een functie minder dan 2 uur, schrijf dan geen spec; Plan Mode is sneller. Duurt de functie een week, gebruik dan zeker Spec Kit; de tijdsbesparing betaalt het uur dat de specificatie kost vijfvoudig terug. Zit de functie tussen 2 uur en een week, gebruik dan je oordeel. Zelf schrijf ik zelfs voor functies van een halve dag een spec, omdat het artefact in de repo meer waard is dan de 30 minuten die je bespaart. ## Wat nu: Spec Kit in je project integreren
Belangrijkste conclusie De eenvoudigste eerste stap is Spec Kit uitproberen op een nieuwe, kleine functie en niet op een heel bestaand project. Installeer het, initialiseer het in een repo, voer `/speckit-specify` uit voor één functie en bekijk de artefacten. Over een week of twee krijg je gevoel voor wanneer je ernaar moet overstappen en wanneer je snelle prompts kunt blijven gebruiken. De volledige methodologie combineert CLAUDE.md + Spec Kit + Skills + subagents.
Een concreet plan voor de komende 7 dagen: - **Dag 1.** Installeer uv en Spec Kit (5-10 minuten). Controleer of de opdrachten `/speckit-*` in Claude Code zijn verschenen. Probeer ze niet toe te passen op een bestaand project; begin met een nieuw project. - **Dag 2.** Kies een echte functie die je van plan bent te bouwen. Voer `/speckit-specify` uit met een vrije beschrijving. Open `spec.md`, lees het en beantwoord elke `[NEEDS CLARIFICATION]`. Haast je niet naar Plan. - **Dag 3.** Voer `/speckit-plan` uit met aanwijzingen over je stack. Lees `plan.md`, vooral het gedeelte Architecture Decisions. Als iets niet bij je past, bewerk het dan handmatig. - **Dag 4-5.** Voer `/speckit-tasks` uit, daarna `/speckit-analyze` om de set spec, plan en taken nogmaals te controleren, en vervolgens `/speckit-implement`. Kijk hoe Claude `[x]` aanvinkt in `tasks.md`. Het kan ergens vastlopen; dat is normaal. Ga terug naar `spec.md`, verduidelijk de vereiste en start `/speckit-implement` opnieuw met een specifieke taak. Zodra de taken zijn afgehandeld, voer je `/speckit-converge` uit en herhaal je de reeks Implement en Converge totdat de opdracht “Converged” oplevert. - **Dag 6-7.** Beoordeel de PR (of reeks PR’s). Voeg die samen. Lees je `spec.md` en `plan.md`; ze zijn de documentatie van je functie voor het komende jaar. Wat ik daarnaast zou aanraden om te lezen: - [CLAUDE.md instellen in 2026](https://ailoot.ai/blog/nl/claude-md-template/) - de basis voor de constitution van Spec Kit. - [Plan Mode in Claude Code](https://ailoot.ai/blog/nl/claude-code-plan-mode/) - een snel alternatief voor kleine taken. - [Context engineering in 2026](https://ailoot.ai/blog/nl/context-engineering/) - waarom Spec Kit überhaupt werkt. - [Skills, Subagents, MCP of Plugins](https://ailoot.ai/blog/nl/skills-subagents-mcp-plugins-claude-code/) - wat je voor je workflow aan Spec Kit kunt toevoegen. - [Dynamic Workflows in Claude Code](https://ailoot.ai/blog/nl/claude-code-dynamic-workflows/) - hoe je veel subagents tegelijk start voor de Implement-fase.
### Bronnen - [GitHub Spec Kit - repository](https://github.com/github/spec-kit) - [GitHub Spec Kit - officiële documentatie](https://github.github.com/spec-kit/) - [Spec-Driven Development - officiële methodologietekst](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [Specsjabloon - GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [AWS Industries Blog - Van spec naar productie: Kiro-agent voor geneesmiddelenontdekking (18 februari 2026)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Claude Code-documentatie - Subagents](https://code.claude.com/docs/en/sub-agents) - [Claude Code-documentatie - Skills](https://code.claude.com/docs/en/skills) - [Claude Code-documentatie - Commands](https://code.claude.com/docs/en/commands)
De volledige contextworkflow: AI-kloon + Second Brain + Context Engineering. Meer materiaal is beschikbaar op [Ailoot](https://ailoot.ai/). ## Vragen en antwoorden ### Waarom volstaat een dagelijkse opruimtaak niet voor verwijderen na 48 uur? Een account dat de deadline vlak na de dagelijkse run bereikt kan bijna een extra dag wachten. Verduidelijk de toegestane vertraging in de specificatie, kies een passend schema en test zowel de grens van 48 uur als maximale vertraging. ### Wat doe ik wanneer plan.md en spec.md elkaar tegenspreken? Ga terug naar de eis en los het verschil vóór implementatie op. Werk specificatie, plan, taken en acceptatiecontroles samen bij en gebruik daarna Analyze en uitvoeringscontroles om hetzelfde afgesproken gedrag te verifiëren. ## Ailoot · Het bedrijf en zijn projectenportefeuille Ailoot bouwt op opgebouwde operationele ervaring, een groot klantenbestand, een stabiele dienst en doorlopende KPI-controle. Het bedrijf en zijn projectenportefeuille: miljoenen klanten; maandelijkse verkopen in de miljarden. Ailoot gebruikt die operationele ervaring voor API-toegang tot AI-functies in klantproducten, agents, applicaties en automatiseringen.