Mange AI-kodeprosjekter starter med en kort beskjed: «Bygg en app for dette.» Det kan gi en imponerende demo, men også mange antakelser som aldri ble skrevet ned. For en liten bedrift kan konsekvensen være feil funksjoner, ekstra leverandørkostnad eller en løsning som ingen vet hvordan skal vedlikeholdes. GitHub Spec Kit prøver å flytte noe av arbeidet fra improvisert prompting til en tydelig prosess.
Spec Kit er et åpent verktøysett for å koble strukturerte arbeidsprosesser til en kodeagent – en AI-assistent som kan lese og endre kode innenfor reglene dere setter. GitHub beskriver det som et verktøy for spesifikasjonsdrevet utvikling, feilsøking og vurdering av idéer. [1]
TL;DR
Du skriver først hva som skal bygges og hvorfor. Deretter avklarer du uklarheter, lager en teknisk plan, bryter planen ned i oppgaver og lar agenten implementere. Til slutt ber du agenten kontrollere om resultatet faktisk samsvarer med spesifikasjonen.
Dette kan gi mindre «vibecoding» og færre overraskelser. Men spesifikasjonen må fortsatt være god, og en utvikler må lese både planen og endringene.
To ord som er nyttige: En konstitusjon er prosjektets faste spilleregler. Scaffolding er startstrukturen med mapper, maler og konfigurasjon som prosjektet bygger videre på.
Den korte arbeidsflyten
GitHub sin hurtigstart viser en kortere flyt for mindre funksjoner:
- `/speckit-specify` beskriver hva som skal bygges og hvorfor.
- `/speckit-plan` velger teknologi og arkitektur.
- `/speckit-tasks` lager en avhengighetsordnet oppgaveliste.
- `/speckit-implement` bygger oppgavene.
- `/speckit-converge` kontrollerer om arbeidet er komplett.
For større eller mer risikofylte endringer kan du legge til `/speckit-constitution`, `/speckit-clarify`, `/speckit-checklist` og `/speckit-analyze` som ekstra kvalitetssperrer. [2]
Dokumentasjonen bruker også punktumvariant i enkelte beskrivelser, men den aktuelle hurtigstarten viser den hyfenbaserte formen `/speckit-specify`. Følg syntaksen som gjelder for integrasjonen og agenten du bruker.
Hva betyr «konstitusjon»?
En konstitusjon er prosjektets faste spilleregler. Det kan være krav om validering av alle brukerinput, testdekning for kritiske funksjoner, dokumentasjon eller en bestemt arkitektur.
Poenget er at reglene ikke skal gjentas i hver prompt. Agenten kan bruke dem som grunnlag når den lager spesifikasjon, plan og kode. For et norsk kundesystem kan konstitusjonen for eksempel kreve tilgangsstyring, logging og at persondata ikke skrives til utviklingslogger.
Et konkret eksempel
I stedet for å skrive «Lag en kundeside», kan spesifikasjonen beskrive at en innlogget bruker skal kunne se egne saker, svare på en sak og laste opp ett dokument. Den kan også si hva som ikke skal være med i første versjon.
Deretter kan planen beskrive hvordan data flyter mellom grensesnitt, API og database. Oppgavelisten kan dele arbeidet i innlogging, visning av saker, opplasting, validering og tester.
Dette gjør det lettere å oppdage hull før koden er skrevet. Hva skjer hvis dokumentet er for stort? Kan en bruker se en annen kundesak? Hva skal skje når API-et ikke svarer? Slike spørsmål hører hjemme i spesifikasjonen og sjekklisten, ikke bare i agentens siste forsøk på å reparere feilen.
Spec Kit og andre agenter
Spec Kit er ikke låst til én modell. Den offisielle integrasjonslisten inneholder blant annet Claude Code, Codex CLI, GitHub Copilot, Cursor, Hermes, OpenCode, OMP, Qwen Code og flere andre. [3]
Du kan initialisere et prosjekt med en bestemt integrasjon, eller bruke agent-nøytral scaffolding dersom flere i teamet bruker forskjellige verktøy. Det er praktisk i et team der én utvikler bruker Claude Code, en annen Codex og en tredje Copilot.
Herdr kan på sin side samle terminalene og sesjonene hvis du arbeider parallelt med flere kodeagenter. Artikkelen om Herdr handler om arbeidsflaten, mens Spec Kit handler om prosessen agenten følger.
Hva er forskjellen på Spec Kit og en vanlig skill?
En skill gir agenten en gjenbrukbar ferdighet eller fremgangsmåte. Spec Kit er bredere: Det gir kommandoer, maler, integrasjoner og prosesser som kan følges fra idé til verifisert implementasjon.
Det kan likevel brukes sammen med skills, harness engineering og prosjektregler. Artikkelen om ni lag i en AI-produksjonsarkitektur viser hvorfor spesifikasjon, evaluering, sikkerhet og observability bør bli tydelige deler av en løsning som skal i drift.
Begrensninger og sikkerhet
En spesifikasjon gjør ikke en agent selvstendig klok. Den kan fortsatt misforstå krav, velge en dårlig arkitektur eller skrive kode som ser riktig ut, men feiler i praksis. Derfor bør hvert steg gjennomgås før neste begynner.
Spec Kit kan også installere integrasjoner og kjøre skript. Les kildekoden og vurder tillatelser før du gir et nytt verktøy tilgang til et viktig prosjekt. GitHub dokumenterer selv at community-kataloger er for oppdagelse og ikke en sikkerhetsgodkjenning. [1]
For en liten bedrift er det lurt å starte med en liten endring. Bruk en eksisterende kodebase, skriv en kort spesifikasjon og krev at agenten viser plan, oppgaver og tester før implementering. Da får du nytten uten å gjøre hele prosjektet tungt.
Når passer det?
Spec Kit passer best når oppgaven er stor nok til at krav, arkitektur og avhengigheter kan bli uklare. En enkel tekstendring trenger ikke ni steg. En ny kundeportal, intern dokumentassistent eller integrasjon mot økonomisystem kan ha stor nytte av en slik prosess.
Målet er ikke å få agenten til å skrive mer. Målet er å få den til å gjette mindre.
Et godt første forsøk er å velge én liten endring, skrive hva som skal være annerledes og be agenten vise spesifikasjon, plan og testforslag før den skriver kode. Kom i gang med AI-agenter gir en tryggere ramme for tilganger og menneskelig kontroll, mens Herdr kan være aktuelt når flere kodeagenter skal organiseres samtidig.
Kilder
[1] GitHub Spec Kit — repository og oversikt