OPSX-werkstroom
Feedback is welkom op Discord.
Wat is het?
OPSX is nu de standaardwerkstroom voor OpenSpec.
Het is een vloeiende, iteratieve werkstroom voor OpenSpec-wijzigingen. Geen stugge fasen meer — gewoon acties die je op elk moment kunt uitvoeren.
Waarom Dit Bestaat
De legacy OpenSpec-workflow werkt, maar is dichtgetimmerd:
- Instructies zijn hardgecodeerd — verborgen in TypeScript, je kunt ze niet wijzigen
- Alles-of-niets — één groot commando maakt alles aan, individuele onderdelen testen kan niet
- Vaste structuur — dezelfde workflow voor iedereen, geen aanpassing mogelijk
- Zwarte doos — als de AI-uitvoer slecht is, kun je de prompts niet bijstellen
OPSX opent het. Nu kan iedereen:
- Experimenteer met instructies — bewerk een template, kijk of de AI het beter doet
- Test op detailniveau — valideer elk artefact onafhankelijk
- Pas workflows aan — definieer je eigen artefacten en afhankelijkheden
- Snel itereren — wijzig een template, test direct, geen rebuild nodig
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── Bewerk je dit
│ (can't change) │ │ templates/*.md │◄── Of dit
│ ↓ │ │ ↓ │
│ Wachten op release │ │ Direct effect │
│ ↓ │ │ ↓ │
│ Hopelijk is het beter │ │ Test het zelf │
└────────────────────────┘ └────────────────────────┘Dit is voor iedereen:
- Teams — maak workflows die aansluiten bij hoe je daadwerkelijk werkt
- Power users — pas prompts aan om betere AI-uitvoer voor jouw codebase te krijgen
- OpenSpec-bijdragers — experimenteer met nieuwe benaderingen zonder releases
We leren allemaal nog wat het beste werkt. OPSX laat ons samen leren.
De Gebruikerservaring
Het probleem met lineaire workflows: Je bent “in de planningsfase”, dan “in de implementatiefase”, dan “klaar”. Maar echt werk werkt niet zo. Je implementeert iets, merkt dat je ontwerp verkeerd was, moet specs bijwerken, gaat verder met implementeren. Lineaire fases botsen met hoe werk daadwerkelijk verloopt.
OPSX-benadering:
- Acties, geen fases — aanmaken, implementeren, bijwerken, archiveren — doe elk op elk moment
- Afhankelijkheden zijn mogelijkmakers — ze tonen wat mogelijk is, niet wat verplicht volgt
proposal ──→ specs ──→ design ──→ tasks ──→ implementSetup
# Zorg dat openspec geïnstalleerd is — skills worden automatisch gegenereerd
openspec initHiermee worden skills aangemaakt in .claude/skills/ (of equivalent) die AI-coderingsassistenten automatisch detecteren.
Standaard gebruikt OpenSpec het core workflowsjabloon (propose, explore, apply, update, sync, archive). Wil je de uitgebreide workflowcommando's (new, continue, ff, verify, bulk-archive, onboard), configureer ze dan met openspec config profile en pas ze toe met openspec update.
Tijdens de setup word je gevraagd een projectconfiguratie (openspec/config.yaml) aan te maken. Dit is optioneel maar aanbevolen.
Projectconfiguratie
Met projectconfiguratie kun je standaardinstellingen vastleggen en projectspecifieke context in alle artefacten injecteren.
Configuratie aanmaken
De configuratie wordt aangemaakt tijdens openspec init, of handmatig:
# openspec/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flowsConfiguratievelden
| Veld | Type | Beschrijving |
|---|---|---|
schema | string | Standaardschema voor nieuwe wijzigingen (bv. spec-driven) |
context | string | Projectcontext die in alle artefactinstructies wordt geïnjecteerd |
rules | object | Per-artefact regels, gesleuteld op artefact-ID |
Hoe het werkt
Schemaprecedentie (hoogste naar laagste):
- CLI-vlag (
--schema <naam>) - Wijzigingsmetadata (
.openspec.yamlin de wijzigingsmap) - Projectconfiguratie (
openspec/config.yaml) - Standaard (
spec-driven)
Contextinjectie:
- Context wordt vóór de instructies van elk artefact geplaatst
- Wordt verpakt in
<context>...</context>tags - Helpt de AI de conventies van jouw project te begrijpen
Regelinjectie:
- Regels worden alleen geïnjecteerd voor overeenkomende artefacten
- Worden verpakt in
<rules>...</rules>tags - Verschijnen na de context, vóór de template
Artefact-ID's per schema
spec-driven (standaard):
proposal— Wijzigingsvoorstelspecs— Specificatiesdesign— Technisch ontwerptasks— Implementatietaken
Configuratievalidatie
- Onbekende artefact-ID's in
rulesgenereren waarschuwingen - Schemanamen worden gevalideerd tegen beschikbare schema's
- Context heeft een limiet van 50KB
- Ongeldige YAML wordt gemeld met regelnummers
Probleemoplossing
"Unknown artifact ID in rules: X"
- Controleer of artefact-ID's overeenkomen met je schema (zie lijst hierboven)
- Voer
openspec schemas --jsonuit om artefact-ID's per schema te zien
Configuratie wordt niet toegepast:
- Zorg dat het bestand op
openspec/config.yamlstaat (niet.yml) - Controleer de YAML-syntaxis met een validator
- Wijzigingen in de configuratie hebben direct effect (geen herstart nodig)
Context te groot:
- Context is beperkt tot 50KB
- Vat samen of verwijs naar externe documentatie
Commando's
| Commando | Wat het doet |
|---|---|
/opsx:propose | Maak een wijziging aan en genereer planningsartefacten in één stap (standaard snelle weg) |
/opsx:explore | Denk na over ideeën, onderzoek problemen, verduidelijk vereisten |
/opsx:new | Start een nieuwe wijzigingsskeleton (uitgebreide workflow) |
/opsx:continue | Maak het volgende artefact aan (uitgebreide workflow) |
/opsx:ff | Versnel planningsartefacten (uitgebreide workflow) |
/opsx:apply | Implementeer taken, werk artefacten bij waar nodig |
/opsx:update | Herzie de planningsartefacten van een wijziging en houd ze samenhangend |
/opsx:verify | Valideer implementatie tegen artefacten (uitgebreide workflow) |
/opsx:sync | Voeg delta-specificaties samen in de hoofdspecificaties (optioneel) |
/opsx:archive | Archiveer wanneer klaar |
/opsx:bulk-archive | Archiveer meerdere voltooide wijzigingen (uitgebreide workflow) |
/opsx:onboard | Begeleide doorloop van een end-to-end wijziging (uitgebreide workflow) |
Gebruik
Een idee verkennen
/opsx:exploreDenk na over ideeën, onderzoek problemen, vergelijk opties. Geen structuur vereist – gewoon een denkpartner. Als inzichten kristalliseren, stap over naar /opsx:propose (standaard) of /opsx:new//opsx:ff (uitgebreid).
Een nieuwe wijziging starten
/opsx:proposeMaakt de wijziging aan en genereert de planningsartefacten die nodig zijn vóór implementatie.
Als je uitgebreide workflows hebt ingeschakeld, kun je in plaats daarvan gebruiken:
/opsx:new # alleen skeleton
/opsx:continue # één artefact tegelijk aanmaken
/opsx:ff # alle planningsartefacten in één keerArtefacten aanmaken
/opsx:continueToont wat op basis van afhankelijkheden klaar is om aangemaakt te worden en maakt vervolgens één artefact aan. Herhaal dit om je wijziging stapsgewijs op te bouwen.
/opsx:ff add-dark-modeMaakt alle planningsartefacten in één keer aan. Gebruik dit wanneer je een duidelijk beeld hebt van wat je bouwt.
Implementeren (het flexibele deel)
/opsx:applyWerkt door taken heen, vinkt ze af terwijl je bezig bent. Als je meerdere wijzigingen tegelijk behandelt, kun je /opsx:apply <naam> uitvoeren; anders moet het uit de conversatie worden afgeleid en word je gevraagd te kiezen als het niet duidelijk is.
Een wijziging bijwerken
/opsx:update add-dark-mode - we slaan het thema nu op in een cookieHerziet de bestaande planningsartefacten van de wijziging en houdt ze samenhangend – in elke richting (een ontwerpaanpassing kan terugwerken op het voorstel). Alleen planningsartefacten: het bewerkt nooit code en het maakt nooit ontbrekende artefacten aan (daarvoor is /opsx:continue). Elke bewerking wordt eerst met jou bevestigd. Als de wijziging al geïmplementeerd was, wordt /opsx:apply aanbevolen zodat de code de herziene plannen bijwerkt. Als je herziening de intentie van de wijziging verandert, begin dan liever opnieuw – zie Wanneer bijwerken vs. opnieuw beginnen.
Delta-specificaties synchroniseren
/opsx:syncVoegt de delta-specificaties van de huidige wijziging samen in je hoofd-openspec/specs/ zonder te archiveren – de wijziging blijft actief. De volledige delta wordt toegepast: een requirement onder ## REMOVED wordt uit de hoofdspec verwijderd, een hernoemde wordt ter plekke hertiteld, en inhoud die de delta niet noemt blijft onaangeroerd. Synchroniseren is optioneel – bij archiveren word je gevraagd eerst te synchroniseren als je dat nog niet hebt gedaan. Gebruik het wanneer je de hoofdspecificaties vóór archivering wilt bijwerken, wanneer een parallelle wijziging moet voortbouwen op specs die deze zojuist heeft toegevoegd, of wanneer je de samengevoegde hoofdspec wilt controleren vóór archivering.
Afronden
/opsx:archive # Verplaats naar archief wanneer klaar (vraagt indien nodig eerst te synchroniseren)Wanneer bijwerken vs. opnieuw beginnen
Je kunt je voorstel of specificaties altijd vóór implementatie bewerken. Maar wanneer wordt verfijnen “dit is ander werk”?
Wat een voorstel vastlegt
Een voorstel definieert drie dingen:
- Intentie — Welk probleem los je op?
- Scope — Wat valt erbinnen/buiten?
- Aanpak — Hoe ga je het oplossen?
De vraag is: wat is er veranderd, en in welke mate?
Werk de bestaande wijziging bij wanneer:
Dezelfde intentie, verfijnde uitvoering
- Je ontdekt randgevallen waar je niet aan gedacht had
- De aanpak moet worden aangepast, maar het doel is onveranderd
- Implementatie toont aan dat het ontwerp iets afwijkt
Scope wordt smaller
- Je realiseert je dat de volledige scope te groot is, je wilt eerst een MVP leveren
- “Dark mode toevoegen” → “Dark mode toggle toevoegen (systeemvoorkeur in v2)”
Leer-gedreven correcties
- De codebase is niet gestructureerd zoals je dacht
- Een afhankelijkheid werkt niet zoals verwacht
- “CSS-variabelen gebruiken” → “In plaats daarvan Tailwind’s dark: prefix gebruiken”
Begin een nieuwe wijziging wanneer:
Intentie fundamenteel veranderd is
- Het probleem zelf is nu anders
- “Dark mode toevoegen” → “Uitgebreid themasysteem met aangepaste kleuren, lettertypen, witruimte”
Scope enorm is uitgebreid
- De wijziging is zo gegroeid dat het in wezen ander werk is
- Het originele voorstel zou na updates onherkenbaar zijn
- “Inlogbug repareren” → “Authenticatiesysteem herschrijven”
Het origineel afgerond kan worden
- De oorspronkelijke wijziging kan als “voltooid” gemarkeerd worden
- Nieuw werk staat op zichzelf, niet als verfijning
- Voltooi “Dark mode MVP toevoegen” → Archiveer → Nieuwe wijziging “Dark mode verbeteren”
De heuristieken
┌─────────────────────────────────────┐
│ Is dit hetzelfde werk? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Dezelfde intentie? >50% overlap? Kan het origineel
Hetzelfde probleem? Dezelfde scope? "klaar" zijn zonder
│ │ deze veranderingen?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
JA NEE JA NEE NEE JA
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
BIJWERKEN NIEUW BIJWERKEN NIEUW BIJWERKEN NIEUW| Toets | Bijwerken | Nieuwe wijziging |
|---|---|---|
| Identiteit | “Hetzelfde, verfijnd” | “Ander werk” |
| Scope-overlap | >50% overlapt | <50% overlapt |
| Voltooiing | Kan niet “klaar” zijn zonder wijzigingen | Kan origineel afronden, nieuw werk staat op zichzelf |
| Verhaal | Bijwerkketen vertelt een samenhangend verhaal | Patches zouden eerder verwarring dan verheldering brengen |
Het principe
Bijwerken bewaart context. Een nieuwe wijziging biedt helderheid.
Kies bijwerken wanneer de geschiedenis van je denkwerk waardevol is. Kies nieuw wanneer opnieuw beginnen duidelijker is dan patchen.
Zie het als git branches:
- Blijf committen zolang je aan dezelfde feature werkt
- Start een nieuwe branch wanneer het echt nieuw werk is
- Soms merge je een gedeeltelijke feature en begin je opnieuw voor fase 2
Wat is er anders?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Structuur | Eén groot voorstel-document | Losse artefacten met afhankelijkheden |
| Workflow | Lineaire fasen: plannen → implementeren → archiveren | Flexibele acties — doe op elk moment alles |
| Iteratie | Lastig om terug te gaan | Werk artefacten bij terwijl je leert |
| Aanpassing | Vaste structuur | Schema-gestuurd (definieer je eigen artefacten) |
Het belangrijkste inzicht: werk is niet lineair. OPSX stopt met doen alsof dat wel zo is.
Verdieping in de Architectuur
Deze sectie legt uit hoe OPSX onder de motorkap werkt en hoe het zich verhoudt tot de verouderde workflow. Voorbeelden in deze sectie gebruiken de uitgebreide commandoset (new, continue, etc.); standaard core-gebruikers kunnen dezelfde stroom omzetten naar propose → apply → sync → archive.
Filosofie: Fasen vs Acties
┌─────────────────────────────────────────────────────────────────────────────┐
│ VEROUDERDE WORKFLOW │
│ (Fase-gebonden, Alles-of-Niets) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANNINGS- │ ───► │ IMPLEMENTATIE│ ───► │ ARCHIVERINGS│ │
│ │ FASE │ │ FASE │ │ FASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Maakt ALLE artefacten in één keer │
│ • Kan niet terug om specificaties bij te werken tijdens implementatie │
│ • Fasepoorten dwingen lineaire voortgang af │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX WORKFLOW │
│ (Vloeiende acties, iteratief) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIES (geen fasen) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ willekeurige volgorde │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Maak artefacten één voor één OF versnelde weergave │
│ • Werk specificaties/ontwerp/taken bij tijdens implementatie │
│ • Afhankelijkheden maken vooruitgang mogelijk, fasen bestaan niet │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Componentarchitectuur
Verouderde workflow gebruikt hardgecodeerde sjablonen in TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ VEROUDERDE WORKFLOWCOMPONENTEN │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Hardgecodeerde sjablonen (TypeScript-strings) │
│ │ │
│ ▼ │
│ Tool-specifieke configureerders/adapters │
│ │ │
│ ▼ │
│ Gegenereerde commandobestanden (.claude/commands/openspec/*.md) │
│ │
│ • Vaste structuur, geen artefactbewustzijn │
│ • Wijziging vereist codeaanpassing + herbouw │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX gebruikt externe schema's en een afhankelijkheidsgraaf-engine:
┌─────────────────────────────────────────────────────────────────────────────┐
│ OPSX COMPONENTEN │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Schemadefinities (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Afhankelijkheden │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Globpatronen │ │
│ │ requires: [proposal] ◄── Ingeschakeld na proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Artefactgraaf-engine │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Topologische sortering (afhankelijkheidsvolgorde) │ │
│ │ • Statusdetectie (bestaan op bestandssysteem) │ │
│ │ • Rijke instructiegeneratie (sjablonen + context) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Skill-bestanden (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Cross-editor compatibel (Claude Code, Cursor, Devin) │
│ • Skills bevragen CLI voor gestructureerde data │
│ • Volledig aanpasbaar via schemabestanden │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Afhankelijkheidsgraaf-model
Artefacten vormen een gerichte acyclische graaf (DAG). Afhankelijkheden zijn activatoren, geen poorten:
proposal
(wortelknooppunt)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(vereist: (vereist:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(vereist:
specs, design)
│
▼
┌──────────────┐
│ TOEPASSINGS- │
│ FASE │
│ (vereist: │
│ tasks) │
└──────────────┘Statusovergangen:
GEBLOKKEERD ────────────► GEREED ────────────────► VOLTOOID
│ │ │
Ontbrekende Alle afh. Bestand bestaat
afhankelijkheden zijn VOLTOOID op bestandssysteemInformatiestromen
Verouderde workflow — agent ontvangt statische instructies:
Gebruiker: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Statische instructies: │
│ • Maak proposal.md aan │
│ • Maak tasks.md aan │
│ • Maak design.md aan │
│ • Maak delta specificatiebestanden │
│ │
│ Geen besef van wat bestaat of │
│ afhankelijkheden tussen artefacten │
└─────────────────────────────────────────┘
│
▼
Agent maakt ALLE artefacten in één keer aanOPSX — agent vraagt rijke context op:
Gebruiker: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Stap 1: Vraag huidige status op │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Eerst gereed │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Stap 2: Haal rijke instructies op voor gereed artefact │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Stap 3: Lees afhankelijkheden → Maak ÉÉN artefact aan → Toon wat ontgrendeld │
└──────────────────────────────────────────────────────────────────────────┘Iteratiemodel
Verouderde workflow — omslachtig om te itereren:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Wacht, het ontwerp is verkeerd"
│ │
│ ├── Opties:
│ │ • Bewerk bestanden handmatig (breekt context)
│ │ • Afbreken en opnieuw beginnen
│ │ • Doordrukken en later oplossen
│ │
│ └── Geen officieel 'teruggaan'-mechanisme
│
└── Maakt ALLE artefacten in één keer aanOPSX — natuurlijke iteratie:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "Het ontwerp is verkeerd"
│ │ │
│ │ ▼
│ │ Bewerk gewoon design.md
│ │ en ga verder!
│ │ │
│ │ ▼
│ │ /opsx:apply pakt op
│ │ waar je gebleven was
│ │
│ └── Maakt ÉÉN artefact aan, toont wat ontgrendeld is
│
└── Bouwt wijziging op, wacht op richtingAangepaste schema's
Maak aangepaste workflows met de schema-beheeropdrachten:
# Maak een nieuw schema vanuit het niets (interactief)
openspec schema init my-workflow
# Of fork een bestaand schema als startpunt
openspec schema fork spec-driven my-workflow
# Valideer je schemastructuur
openspec schema validate my-workflow
# Zie waar een schema vandaan komt (handig voor debuggen)
openspec schema which my-workflowSchema's worden opgeslagen in openspec/schemas/ (project-lokaal, versiebeheerd) of ~/.local/share/openspec/schemas/ (gebruiker-globaal).
Schemastructuur:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdVoorbeeld schema.yaml:
name: research-first
artifacts:
- id: research # Toegevoegd vóór proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Hangt nu af van research
- id: tasks
generates: tasks.md
requires: [proposal]Afhankelijkheidsgraaf:
research ──► proposal ──► tasksSamenvatting
| Aspect | Verouderd | OPSX |
|---|---|---|
| Sjablonen | Hardgecodeerd TypeScript | Externe YAML + Markdown |
| Afhankelijkheden | Geen (alles tegelijk) | DAG met topologische sortering |
| Status | Fase-gebaseerd mentaal model | Bestaan op bestandssysteem |
| Aanpassing | Bron bewerken, herbouwen | Maak schema.yaml |
| Iteratie | Fase-gebonden | Vloeiend, bewerk alles |
| Editorondersteuning | Tool-specifieke configureerder/adapters | Enkele skills-map |
Schemas
Schemas definiëren welke artefacten bestaan en hun afhankelijkheden. Momenteel beschikbaar:
- spec-driven (standaard): proposal → specs → design → tasks
# Beschikbare schemas weergeven
openspec schemas
# Alle schemas met hun oplosbronnen bekijken
openspec schema which --all
# Nieuw schema interactief aanmaken
openspec schema init my-workflow
# Bestaand schema vorken voor aanpassing
openspec schema fork spec-driven my-workflow
# Schemastructuur valideren vóór gebruik
openspec schema validate my-workflowTips
- Gebruik
/opsx:exploreom een idee te overwegen voordat je een wijziging doorvoert /opsx:ffals je weet wat je wilt,/opsx:continuetijdens het verkennen- Tijdens
/opsx:apply, als er iets niet klopt — corrigeer het artefact en ga dan verder - Taken volgen voortgang via selectievakjes in
tasks.md - Controleer de status op elk moment:
openspec status --change "name"
Feedback
Dit is nog ruw. Dat is bewust — we leren wat werkt.
Een bug gevonden? Ideeën? Sluit je aan op Discord of open een issue op GitHub.