OpenSpec gir kodeagenten en spesifikasjon å jobbe mot, ikke bare en prompt

I et prosjekt der både mennesker og kodeagenter skriver kode, finnes beskrivelsen av hva som faktisk skal bygges som regel fire steder samtidig: i en issue, i en Slack-tråd, i hodet på den som startet, og i konteksten til agenten som skrev forrige runde. OpenSpec fra Fission-AI flytter den ene sanne versjonen inn i repoet som en spesifikasjon alle parter leser fra.

Verktøyet installeres globalt med npm install -g @fission-ai/openspec@latest og legger seg som skråstrek-kommandoer i kodeverktøyet du allerede bruker. /opsx:explore kartlegger problemet og koden rundt det, /opsx:propose skriver ut proposal.md, en specs/-katalog, design.md og tasks.md, /opsx:apply implementerer oppgavene fra spesifikasjonen, /opsx:verify sjekker at implementasjonen faktisk stemmer med den, og /opsx:archive legger ferdige endringer bort. Sløyfen er den samme enten du sitter i Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI eller OpenCode. Kompatibilitetslista på nettsiden navngir 38 verktøy og oppgir 33 til utover dem.

Det er verifiseringssteget som skiller OpenSpec fra en vanlig AGENTS.md. En instruksjonsfil forteller agenten hvordan den skal oppføre seg, men sier ingenting om hvorvidt resultatet ble det du ba om. /opsx:verify sammenligner det som ble bygget mot kravene som ble skrevet ned før arbeidet startet, og det er den sammenligningen som fanger at agenten løste en litt annen oppgave enn den du beskrev.

Prosjektet er MIT-lisensiert, står i versjon 1.13.0 og har 68 000 stjerner på GitHub. Fission-AI oppgir selv at det brukes av mer enn 265 000 utviklere i måneden, og at det opprettes en ny spesifikasjon hvert andre sekund. Tallene kommer fra leverandøren og er ikke uavhengig etterprøvd.

Hva bør du gjøre?

1. Start med et brownfield-prosjekt framfor et tomt repo. /opsx:explore er bygget for å lese seg inn i kode som allerede finnes, og det er der spesifikasjonsdriften gjør mest skade.
2. Kjør /opsx:verify som et eget steg, ikke sammen med /opsx:apply. Verdien ligger i at noe annet enn agenten som skrev koden vurderer om kravene er innfridd.
3. Sjekk specs/ inn i git. Spesifikasjonene er artefakter på linje med koden, og diffen på dem viser hvorfor kravene endret seg underveis.