De /feature Workflow: van issue naar done

Features bouwen zonder structuur is een recept voor problemen. Je begint te coderen voordat je hebt nagedacht. Halverwege verlies je context. Je vergeet te testen. Documentatie? Daar kom je "later" aan toe. Later komt nooit.

In mijn James framework heb ik dit probleem opgelost met de /feature workflow. Zeven fases van Linear issue tot afgeronde feature, met automatische resume als je context kwijtraakt. In deze blog leg ik uit hoe het werkt en waarom elke fase er toe doet.

Wanneer triggert /feature?

Belangrijk: /feature triggert niet op alles. Als je zegt "bouw een checkout flow" of "maak die button rood", dan bouw ik gewoon. Geen workflow overhead voor simpele taken.

/feature triggert alleen wanneer:

Je een Linear issue ID noemt: "ODI-234" of "pak ENG-123 op"
Je expliciet /feature zegt: "/feature checkout flow"

Dit onderscheid is cruciaal. Een bugfix van drie regels heeft geen zeven-fasen workflow nodig. Een nieuwe feature met database changes, components, en API endpoints wel.

De 7 fases

Fase	Wat gebeurt er
0. Initialize	Check voor resume, maak tasks.md, hydrate Claude Tasks
1. Setup	Linear issue ophalen, status naar "In Progress"
2. Research	Researcher agent verzamelt context
3. Spec	Plan Mode voor specificatie, goedkeuring vragen
4. Implement	Bouwen met sub-task tracking
5. Test	Tester agent, fixer bij failures
6. Document	Documenter agent update .docs/ indien nodig
7. Complete	Linear naar "In Review", summary

Fases 1 en 2 draaien parallel. De rest is sequentieel met dependencies.

Phase 0-2: Setup en Research

De workflow begint met een check: is er al een feature in progress? Als ja, vraag ik of je wilt doorgaan of opnieuw wilt beginnen. Dit voorkomt dat je per ongeluk twee features door elkaar heen bouwt.

Daarna maak ik een tasks.md bestand aan in .docs/features/<slug>/. Dit bestand is de persistence layer. Alles wat ik doe wordt hier bijgehouden. Als je context reset, kan ik hier verder lezen.

Parallel met de Linear setup spawn ik de researcher agent. Deze verzamelt context: bestaande code patterns, relevante documentatie, conventies uit je .docs/ folder. De output gaat naar tasks.md onder "Research Notes".

Phase 3: Spec in Plan Mode

Dit is waar Spec-Driven Development en Plan Mode samenkomen. Ik ga in Plan Mode, wat betekent dat ik alleen kan lezen en zoeken, niet schrijven of uitvoeren.

In Plan Mode schrijf ik een specificatie:

Wat doet de feature?
Welke componenten worden aangemaakt of gewijzigd?
Hoe integreert het met bestaande code?
Wat zijn de edge cases?

Pas na jouw goedkeuring verlaat ik Plan Mode en begin ik met bouwen. Dit dwingt nadenken af voordat er code geschreven wordt. Geen "ik begin wel en zie wel waar ik uitkom".

Phase 4: Implement met sub-tasks

Voor ik ook maar één regel code schrijf, maak ik een sub-task checklist. Ook voor simpele features. Dit is niet optioneel.

### Sub-tasks
- [ ] Database: migration for orders table
- [ ] Model: Order with relationships
- [ ] Controller: CheckoutController
- [ ] Component: Livewire CheckoutFlow
- [ ] Routes: checkout routes

Elke sub-task krijgt een marker:

[ ] - niet gestart
[~] - mee bezig
[x] - klaar

Waarom zo expliciet? Resume. Als mijn context reset halverwege de implementatie, kan ik in tasks.md zien waar ik was. De [~] marker vertelt me welke sub-task ik aan het bouwen was. Git diff vertelt me hoever ik was gekomen.

Phase 5-6: Test en Document

Na implementatie spawn ik de tester agent. Deze draait de test suite en spawnt automatisch de fixer agent bij failures. Maximaal twee fix-pogingen per failure, daarna escalatie naar jou.

De documenter agent bekijkt de changes en bepaalt of .docs/ updates nodig zijn. Niet elke feature vereist documentatie updates. Een nieuwe API endpoint wel. Een kleine refactor niet.

Beide fases zijn automatisch, niet optioneel. Je kunt ze niet skippen. Dit is bewust: testen en documenteren zijn precies de dingen die developers "later" doen. Later komt nooit.

Phase 7: Complete

De Linear issue gaat naar "In Review" met een comment die samenvat wat er gebouwd is:

Completed: Checkout flow with Stripe integration

Files changed:
- database/migrations/create_orders_table.php
- app/Models/Order.php
- app/Livewire/CheckoutFlow.php
- resources/views/livewire/checkout-flow.blade.php

Tests: ✓ passing
Docs: ✓ updated

De tasks.md status gaat naar "completed". Alle checkboxes staan op [x].

De integraties

Linear

/feature integreert met Linear via een CLI tool in ~/James/bin/linear. Geen MCP server, geen constant context verbruik. Gewoon een bash script dat de GraphQL API aanroept.

De CLI ondersteunt multi-workspace. In .docs/README.md configureer je per project welke workspace en welk team:

linear:
  team: ODI
  workspace: mauricehofman

API keys staan in ~/James/.env. De workflow haalt automatisch issue details op, zet de status naar "In Progress" aan het begin en "In Review" aan het eind.

Sentry

Voor features die bug fixes bevatten of risicovol zijn, check ik Sentry voor en na implementatie. De ~/James/bin/sentry CLI haalt issues op, toont stacktraces, en kan issues resolven.

sentry issues myproject "is:unresolved level:error"
sentry stacktrace 12345
sentry resolve 12345

Als de feature een Sentry error moest oplossen, resolve ik die automatisch in Phase 7. Zo blijft je Sentry dashboard clean.

Postman

Bij features met nieuwe API endpoints update ik de Postman collection via de postman CLI. Request URLs, bodies, auth configuratie. Alles gesynchroniseerd met wat er gebouwd is.

Resume: halverwege oppakken

Context resets zijn onvermijdelijk bij grote features. Na 50+ tool calls of een paar uur werk raakt de context vol. Vroeger betekende dit: opnieuw beginnen en hopen dat je weet waar je was.

Met /feature niet. De tasks.md bevat alles:

Welke fases zijn klaar (checkboxes)
De goedgekeurde spec
Research notes
Sub-task voortgang met [~] markers
Beslissingen die onderweg genomen zijn

Bij resume lees ik tasks.md, check git diff voor werk in progress, en ga verder waar ik was. Geen informatie verlies. Geen dubbel werk.

Na /feature: /done

Als de feature klaar is, draai ik /done. Dit is de end-of-session workflow die alles afrondt:

Larastan - static analysis, veilige type errors fixen
Simplifier - recent gewijzigde code opschonen
Documenter - laatste check op .docs/ updates
Changelog - één regel toevoegen
Commit & push

De combinatie /feature + /done dekt de hele cyclus. Van issue tot commit, gestructureerd en reproduceerbaar.

Waarom dit werkt

Structuur verslaat discipline. Je hoeft niet te onthouden om te testen, want de workflow dwingt het af. Je hoeft niet te onthouden waar je was, want tasks.md onthoudt het. Je hoeft niet te onthouden om Linear te updaten, want Phase 7 doet het automatisch.

Het voelt misschien als overhead voor kleine features. Daarom triggert /feature niet op alles. Maar voor features die groter zijn dan een bugfix is deze structuur het verschil tussen "het werkt ergens" en "het is klaar".

Zelf implementeren

Je hoeft niet het hele framework over te nemen. Begin met:

Een tasks.md template voor features
Plan Mode gebruiken voor specs
Sub-task checklists met [ ]/[~]/[x] markers

Dat alleen al voorkomt de meeste problemen. De integraties met Linear, Sentry, en Postman zijn nice-to-have, niet must-have.

Wil je AI-gedreven development in je eigen workflow? In mijn trainingen help ik teams hun eigen versie van dit soort workflows op te zetten. Of neem contact op als je eerst wilt sparren over je aanpak.