7 berichten getagd met "OpenSpec"

Most teams already write down what they are going to build. They open a ticket: "As a user I want a search box, so that I can find pets quickly." That sentence has served software teams for twenty years. At Conduction we write specs instead. The reason is simple: the developer reading the ticket is now an LLM, not a colleague, and an LLM needs a different kind of brief. This opener explains why, before the rest of the series gets into the how.

A spec tells you what one feature must do. But "build a search box" leaves a hundred questions unanswered that have nothing to do with search. Which data layer? Vue 2 or Vue 3? Where do modals live? Which licence header? Answering those per spec would be madness, and an AI would answer them differently every time. That is what ADRs are for. They are the standing context that every spec is built on top of. This part explains what they are, how they are written, and how Conduction splits them across the fleet.

In Part 1 you learned that a scenario describes behaviour in GIVEN / WHEN / THEN form. In Part 2 you wrote one. This part closes the loop. A scenario is a test you have not run yet, and OpenSpec gives you a mechanical way to prove that every scenario in a spec is exercised by a real browser test. The @e2e annotation and the gate that enforces it are what turn "write a spec" into a safe sandbox for AI. They are also the single biggest thing that separates spec coding from vibe coding.

Let op — dit is een optionele, situationele tutorial. De meeste developers zullen nooit een retrofit hoeven draaien. Het dagelijkse werk in een Conduction-app — changes schrijven, tasks implementeren, PRs openen — raakt geen van de commando's hieronder. Je kunt Deel 1 + 2 afronden en direct doorgaan naar de Hydra-leerlijn of de Claude skills-leerlijn zonder iets te missen.

Dit deel is alleen relevant in één specifiek geval: een oudere Conduction-app moet alsnog onder de huidige OpenSpec-conventie gebracht worden. Een klein aantal van onze apps is gebouwd voordat openspec/specs/ en de @spec-tag-conventie bestonden — ze hebben werkende code, maar geen specs en geen annotaties die vanuit code terug wijzen naar requirements. Als zo'n app ooit in lijn met de conventie gebracht moet worden, is dit de playbook ervoor. We lopen de retrofit-playbook van begin tot eind door.

Spec-gedreven ontwikkeling draait de gebruikelijke volgorde om. Je schetst niet eerst de feature, schrijft de code, en documenteert daarna misschien wat je hebt gebouwd. Je schrijft eerst de specificatie — in Markdown, met RFC 2119-sleutelwoorden en GIVEN/WHEN/THEN-scenario's — en een AI-agent (Hydra) implementeert code die daaraan voldoet. De rol van de mens schuift een niveau omhoog: jij ontwikkelt context, geen code.

Dat klinkt idealistisch totdat je het in de praktijk ziet werken. De apps van Conduction worden vandaag in productie op deze manier gebouwd. Deze tutorial loopt door de workflow: wat OpenSpec daadwerkelijk is, hoe ADR's op organisatie- en app-niveau features samenhangend houden, wat de explore- en apply-skills doen, en hoe de kwaliteits- en gatekeeping-harness het resultaat valideert voordat er ook maar iets in main landt.

OpenSpec is een lichtgewicht framework voor spec-driven development: eerst opschrijven wat een feature moet doen, dan pas code schrijven. In deze module van twaalf minuten leer je wat OpenSpec is, welke begrippen erin zitten, en waarom we het bij Conduction onder vrijwel elk project gebruiken. Aan het eind sta je klaar voor deel 2, waarin je je eerste change daadwerkelijk schrijft.

Tijd om OpenSpec aan het werk te zien. In dit deel maak je in een Conduction-project je eerste echte change — van leeg mapje, via een spec-delta met requirement en scenario, naar een gevalideerd voorstel klaar voor implementatie. We doen dat met de Claude Code-skills /opsx-new en /opsx-ff.