Kako leta 2026 nastaviti Spec Kit v Claude Code: specifikacije namesto pozivov

Kaj se je maja 2026 zgodilo z vibe codingom?#

Leto pozneje, 4. februarja 2026, je objavil retrospektivno nit:

V svojem govoru na Sequoia Ascent 2026 je to povedal še natančneje: »Vibe coding dviguje spodnjo mejo – koliko lahko vsakdo naredi na področju programske opreme. Agentic engineering ohranja zgornjo mejo – merilo kakovosti profesionalnega razvoja.« Na istem odru je izrekel misel, ki je vstopila v besednjak industrije: »Zaradi vibe codinga ne smete vnašati ranljivosti. Za svojo programsko opremo ste še vedno odgovorni, tako kot prej.«

Dve stvari sta se zgodili vzporedno. Septembra 2025 je GitHub objavil orodje Spec Kit – v 8 mesecih je zbralo 107.000 zvezdic. Februarja 2026 je AWS objavil podrobno študijo primera o odkrivanju zdravil, v kateri poroča, da je bilo »95 % poslovne logike ustvarjene iz specifikacije, kar je prihranilo več kot 80 ur«.

Do konca maja 2026 se je v angleško govorečem informacijskem prostoru izoblikovalo soglasje: vibe coding kot delovna metoda je začetniška raven. Naslednji korak je Spec-Driven Development. Ta vodič pojasnjuje, kako pristop namestiti in uporabljati.

Kaj sta Spec Kit in Spec-Driven Development?#

Osrednjo idejo metodologije povzema ena vrstica iz uradne dokumentacije GitHuba:

V praksi se to odvije v 4 fazah (Spec Kit doda še eno, ničelno fazo – ustavo, opisano spodaj):

1. Specify – v naravnem jeziku napišite specifikacijo tega, kar želite. KAJ narediti in ZAKAJ. Ne KAKO.
2. Plan – agent vzame specifikacijo in pripravi tehnični načrt: katere tehnologije, kakšna arhitektura in katere komponente.
3. Tasks – agent načrt razdeli na konkretne, preverljive naloge z odvisnostmi.
4. Implement – agent (ali njegovi podagenti) opravi naloge in napiše kodo.

Po fazi Implement ima trenutna različica Spec Kita korak preverjanja, imenovan Converge: agent preveri dokončano kodo glede na specifikacijo, načrt in naloge, nato pa v tasks.md doda vse, kar manjka. Cikel Implement in Converge ponavljajte, dokler Converge ne odgovori »Converged«.

Vsaka faza je ločena datoteka Markdown v repozitoriju. Vsaka faza je tudi ločen ukaz s poševnico v Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, medtem ko je ukaz za preverjanje /speckit-converge. Dokumentacija Spec Kita iste ukaze zapisuje s piko (/speckit.specify), vendar jih Spec Kit v Claude Code namesti kot veščine, ki jih prikličete z vezajem. Če gre na katerem koli koraku kaj narobe, uredite datoteko Markdown in znova zaženite naslednjo fazo.

Spec Kit je konkretna izvedba SDD. Maja 2026 je imel že več kot 30 integracij z različnimi agenti AI. V enem repozitoriju Spec Kit deluje enako s Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose in še kakim ducatom drugih.

Po izvedbi vaš repozitorij ne vsebuje le kode, temveč tudi njeno specifikacijo, načrt in naloge. Čez mesec dni se lahko vrnete k projektu, preberete spec.md in razumete, kaj je bilo narejeno ter zakaj. To ni več »vibe coding, ki je pozabil, da koda obstaja« – to je delovni spomin projekta.

Zakaj bi to potreboval vibe coder, ki ne piše kode?#

Spec Kit formalizira načrtovanje v ločenih korakih s 4 ukazi s poševnico. Logika: »premišljevanje« ločite od »izvajanja«, tako da potekata v različnih kontekstnih oknih. Vsaka stopnja dobi čist kontekst, ki ga prejšnja faza še ni zapolnila.

Tri konkretne prednosti za vibe coderja:

• Predvidljivost. Ko agentu rečete »naredi registracijski obrazec s potrditvijo po e-pošti«, si sam izmisli 10 podrobnosti – in pri treh ugiba drugače, kot ste si zamislili. Če imate spec.md z User Stories, Acceptance Scenarios in oznakami [NEEDS CLARIFICATION] ob vsaki nejasni točki, ni ničesar, o čemer bi moral ugibati.
• Spomin projekta. Čez mesec dni se ne boste spomnili, kaj ste se z agentom pogovarjali v klepetu. Toda spec.md, plan.md in tasks.md so v repozitoriju, v mapi specs/###-feature/ poleg kode. Pokažejo vam ne le, kaj je bilo narejeno, temveč tudi zakaj.
• Obseg. Pri funkciji, ki vključuje 1–2 datoteki, je razlika komaj opazna. Pri funkciji, ki vključuje 20 datotek in 5 podatkovnih entitet, pa je razlika med »po 4 urah vse prepisujem« in »po 4 urah je vse že v glavni veji«. AWS Kiro je v projektu TargetID pokazal 95-odstotno avtomatizacijo poslovne logike na podlagi specifikacije.

Glavna iluzija vibe codinga je, da je na začetku videti hitrejši. Pol ure in prototip je tu. Toda po enem tednu se prototip pokvari in lažje ga je zavreči. Spec-Driven Development na začetku traja nekoliko dlje (eno uro namesto pol ure), toda teden pozneje še vedno delate v istem repozitoriju.

Kako namestiti Spec Kit v Claude Code (4 koraki)#

1. korak. Namestite uv. To morate narediti samo enkrat; ostane v vašem sistemu.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Preverite, ali je bil uv nameščen:

uv --version

2. korak. Namestite Spec Kit. En ukaz:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Preverite:

specify --version

3. korak. Inicializirajte repozitorij. Pojdite v mapo projekta (ali ustvarite nov projekt) in zaženite:

specify init --here --integration claude

Zastavica --integration claude neposredno izbere Claude Code. Brez nje vas Spec Kit pozove, da na interaktivnem seznamu izberete agenta, lahko pa vas vpraša tudi za vrsto skripta (za macOS in Linux pustite sh). Če mapa ni prazna, vas bo Spec Kit opozoril, da bo združil svoje datoteke z vašimi: najprej objavite svoje delo, nato ukaz ponovite z zastavico --force.

Nato se bodo v repozitoriju pojavile naslednje datoteke in mape:

.specify/
  memory/
    constitution.md        # project rules, filled in by /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

4. korak. Odprite Claude Code in preverite ukaze s poševnico. To zaženite v isti mapi:

claude

V seji vnesite /speckit – med predlogi bi se morali prikazati ukazi speckit-*. Če se ne, znova zaženite Claude Code, da znova prebere .claude/skills/. Če imate v korenski mapi projekta že CLAUDE.md, ga Spec Kit pusti pri miru – deluje skupaj z njim v .specify/memory/constitution.md.

Spec Kit deluje tudi brez Claude Code (podpira več kot 30 agentov), vendar ta vodič obravnava nastavitev posebej za Claude. Če želite takoj namestiti dve orodji, si oglejte ločena vodiča o nastavitvi CLAUDE.md in načinu Plan Mode v Claude Code.

Spec Kit je prvi gradnik »pogodbe o zaposlitvi agenta«. Celotna postavitev vključuje vse tri: klon AI (vaša metodologija v obliki Skills in podagentov), Second Brain (struktura business/, h kateri se agent vsakič vrne) in inženiring konteksta (Spec Kit, Plan Mode, /compact). To so trije stebri, brez katerih AI halucinira.

Kako napisati prvo specifikacijo (Specify)#

V Claude Code vnesite:

/speckit-specify

Nato vas bo agent prosil za opis funkcije. Na tem koraku uporabite preprost jezik brez tehničnega žargona:

Želim registracijski obrazec v svoji aplikaciji. Uporabnik vnese e-poštni naslov
in geslo, prejme potrditveno e-pošto, po potrditvi pa pristane na nadzorni plošči. Možnost potrditve poteče po 48 urah. Če e-poštni
naslov še vedno ni potrjen, račun izbrišite v 5 minutah po tem roku;
potrjenega računa nikoli ne izbrišite.

V tem ponazoritvenem primeru je dopustna zamuda pri izbrisu določena na 5 minut po izteku 48-urnega roka. Pri resničnem izdelku to dopustno zamudo potrdite pred korakom Plan; natančen rok 48 ur zahteva zasnovo in teste, ki uveljavijo to strožjo zahtevo. Agent bo pripravil specs/001-registration/spec.md. Odprite ga in videli boste približno takšno strukturo:

# Feature Specification: User Registration

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.

### Acceptance Scenarios
1. **Given** I am on the registration page,
   **When** I submit valid email and password,
   **Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
   **When** I land on the dashboard,
   **Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
   **When** cleanup runs within the next 5 minutes,
   **Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
   **When** cleanup runs,
   **Then** the account is not deleted.

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
  email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
  delete still-unconfirmed accounts no later than 5 minutes after that
  deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
  CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
  account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)

Bodite pozorni na oznake [NEEDS CLARIFICATION: ...]. Spec Kit jih namenoma vstavi povsod, kjer agent iz vašega besedila ni dobil nedvoumnega odgovora. Pred prehodom na fazo Plan morate nanje odgovoriti ročno v spec.md ali zagnati /speckit-clarify; agent bo pregledal nejasne točke in vam v pogovoru zastavil vprašanja.

V Spec Kitu vgrajeni ukaz /speckit-clarify nadomesti izrečeni »postavljaj mi vprašanja«. Učinek je enak: na Plan ne nadaljujete, dokler v spec.md ne ostane nobena oznaka [NEEDS CLARIFICATION].

V spec.md ne sme biti tehnologij. Brez omemb Reacta, Postgresa, Prisme ali Redisa. Specifikacija opisuje, kaj sistem počne z vidika uporabnika in podjetja. Tehnološki sklad pride na vrsto v naslednji fazi.

Kaj Claude naredi v fazi Plan?#

Ko je spec.md pripravljen, zaženite:

/speckit-plan

Po želji lahko namige o tehnologijah podate neposredno v ukazu:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude prebere tri vire: vaš spec.md, vaš CLAUDE.md (ali memory/constitution.md) in obstoječo kodo v repozitoriju. Izhod je datoteka plan.md s približno takšno strukturo:

# Implementation Plan: User Registration

## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## Architecture Decisions

### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.

### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.

### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.

## Data Model
See data-model.md

## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests

data-model.md bo opisal entitete in njihove povezave. contracts/ bo vseboval ogrodja pogodb API (ali OpenAPI YAML ali tipe zahtev/odgovorov TypeScript). To ni koda – to je namen, ki ga bo Claude pozneje pretvoril v dejanske usmerjevalnike.

Glavna prednost faze Plan je čist kontekst. Claude ne poskuša hkrati ohranjati specifikacije in izvedbe v mislih. Najprej vse premisli, odločitev zapiše v datoteko in šele nato nadaljuje.

Naslednji je izbirni ukaz /speckit-analyze. Zaženete ga po fazi Tasks in pred Implement: pregleda komplet spec.md + plan.md + tasks.md glede protislovij ter preveri, ali so vse zahteve iz specifikacije zajete v načrtu in nalogah. Datotek ne ureja, temveč pripravi poročilo. V bistvu gre za formalno preverjanje smiselnosti pred izvedbo.

Kako razdeliti delo na naloge (Tasks)#

Ko imate spec.md in plan.md, zaženite:

/speckit-tasks

Claude razširi načrt v tasks.md:

# Tasks: User Registration

## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)

## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)

## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation

## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page

## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
  before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
  and protection of confirmed accounts

## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)

Bodite pozorni na oznaki parallel-safe in after T-NNN. To je graf odvisnosti, ki vam pozneje omogoči vzporedno izvajanje več faz. Celoten pristop pospeševanja s Spec Kitom temelji na tem mehanizmu: nekatere naloge lahko hkrati predate petim različnim sejam Claude Code, druge pa morajo nujno potekati zaporedno.

Spec Kit to naredi samodejno, takoj po namestitvi, z enim ukazom.

Izbirni ukaz /speckit-taskstoissues vzame tasks.md in iz seznama ustvari GitHub Issues, vsak s povezavo nazaj na spec.md. To je uporabno, če delate v ekipi ali želite spremljati napredek prek GitHub Projects.

Kako izvajati z uporabo podagentov (Implement)#

/speckit-implement

Claude začne s prvo nalogo v tasks.md. Vsaka naloga poteka v kratkem ciklu: prebere ustrezne datoteke, napiše diff, zažene teste in označi [x]. Po potrebi samodejno pokliče podagente: enega za pregled kode, drugega za zagon linterja in tretjega za preverjanje regresij.

Posebej pa še o pravilih:

V Spec Kitu je ta cikel formaliziran. spec.md je vir resnice, plan.md vsebuje tehnične odločitve, tasks.md pa je kontrolni seznam. Če Claude na kateri koli točki skrene s poti, se vrnete k specifikaciji in rečete: »To ni v skladu s FR-003; popravi.« Ni dolgih pozivov v slogu »spomni se, o čem sva se pogovarjala ...« – celotna zgodovina je v datotekah.

Če ste povezali Dynamic Workflows v Opus 4.8, lahko Spec Kit nastavite na popolnoma samodejni način: en ukaz /speckit-implement in Claude delo vzporedno razdeli, združi rezultate in jih preveri. Omejitev je 1000 podagentov hkrati. Za večino funkcij jih zadostuje 10–30.

Ko so vsa polja [x] označena in preverjanje v naslednjem razdelku vrne »Converged«, pregledate PR (ali več PR-jev, če je nalog veliko) in ga združite. Artefakti spec.md, plan.md, tasks.md ostanejo v repozitoriju kot dokumentacija funkcije. Čez leto dni vam logike ne bo treba rekonstruirati iz kode.

Kako preveriti, da agent ni ničesar spregledal (Converge)#

/speckit-converge

Najprej agent poda povzetek ugotovitev s stopnjami resnosti, nato pa sledi eden od dveh izidov. »Converged« pomeni, da ni ničesar izpuščenega, tasks.md ostane nespremenjen do bajta in lahko nadaljujete s pregledom. »Tasks appended« pomeni, da so bile najdene opustitve, dodane v razdelek Convergence v tasks.md, agent pa vam pove njihovo število.

Converge ne ureja ali briše kode; edini zapis so nove naloge v tasks.md. Zato ga lahko zaženete brez skrbi, vendar šele potem, ko je /speckit-implement že obdelal trenutno vsebino tasks.md. Vsak naslednji pregled najde manj opustitev.

Kako se Spec Kit razlikuje od CLAUDE.md in Plan Mode?#

Primerjajmo jih po 5 značilnostih:

V izrazoslovju Spec Kita je to .specify/memory/constitution.md. Med inicializacijo lahko Spec Kit za osnovo ustave uporabi vaš obstoječi CLAUDE.md ali ob njem ustvari ločeno datoteko. Sam CLAUDE.md običajno ohranim kot globalno »pogodbo« (sklad, glosar, protokol uvajanja), ustavo Spec Kita pa uporabim za pravila, značilna za posamezne funkcije – na primer »vsi obrazci se preverjajo z Zod; ročna preverjanja niso dovoljena«.

Povezava s Plan Mode je preprostejša. Plan Mode je hiter način »načrtovanja pred pisanjem kode« znotraj ene seje. Dobro deluje pri majhnih spremembah (odpravljanje napake, refaktoriranje funkcije). Pri veliki funkciji se Plan Mode ne obnese, ker je kontekstno okno ene seje premajhno za načrt s 3000 vrsticami – kot neposredno pojasnim v živi seji:

Spec Kit je konkretno orodje za inženiring konteksta. »Prt arhitekture« iz klepeta prenese v datoteke. Spec.md ostane v repozitoriju in vsaka nova seja Claude ga znova prebere – ni se vam treba ponavljati.

Postavitev za velik projekt:

1. CLAUDE.md – sklad, glosar, česa ne smete početi. Nahaja se v korenski mapi.
2. .specify/memory/constitution.md za Spec Kit – pravila, značilna za ta potek dela.
3. specs/001-feature-A/spec.md, plan.md, tasks.md – prva funkcija.
4. specs/002-feature-B/spec.md, plan.md, tasks.md – druga funkcija.
5. Za vsakodnevno delo uporabite /speckit-implement (za pripravljene naloge) ali /plan (za hitro dodatno preverjanje pred spremembo).

Kateri primeri iz resničnega sveta delujejo?#

Konkretni primeri:

• AWS Kiro – agent za odkrivanje zdravil. V objavi na blogu AWS Industries z dne 18. februarja 2026 ekipa opisuje projekt TargetID. Trije razvijalci, tri tedne, agent za odkrivanje zdravil. Številke iz članka: Kiro je ustvaril več kot 95 % kode poslovne logike in prihranil več kot 80 ur razvoja. Poleg tega: »Dokumentacija README, ki jo je napisal Kiro, nam je prihranila približno 8 ur« in »40 % manj ponavljajočih se ciklov pozivov in popravkov«.
• Rackspace Technology. V istem spletnem dnevniku AWS Rackspace poroča: »52 tednov ocenjenega dela smo opravili v samo 3 tednih« in »90-odstotno povečanje učinkovitosti«. To ni več majhna funkcija – gre za celoten poslovni projekt.

Za bralca to pomeni, da pristop ni teoretičen: resne ekipe ga že uporabljajo v produkciji.

Kdaj Spec Kit NI primeren?#

Ni primeren št. 1 – majhne spremembe. Če je naloga »preimenuj spremenljivko«, »popravi tipkarsko napako v besedilu« ali »dodaj dnevniški zapis«, bo pot skozi Specify → Plan → Tasks trajala dlje od same spremembe. Pri majhnih spremembah sta Plan Mode ali neposreden poziv v Claude Code hitrejša.

Ni primeren št. 2 – poskusi v živo. Če še ne veste, kaj želite, in morate »pobrskati« po vmesniku ali hitro sestaviti prototip, da vidite, »ali bo deloval«, je specifikacija nesmiselna. Vrednost je prav v tem, da improvizirate. Na ravni »igranja z zamislijo« deluje prav vibe, ne specifikacija.

Ni primeren št. 3 – podedovana koda s kompleksnim stanjem. Močan protiargument: »Resničnost se spreminja hitreje kot specifikacije.« Kot primer vzemimo obračunavanje naročnin: ekipa opiše obračunska obdobja in davčna pravila, teden pozneje pa Finance zahtevajo evropski DDV – specifikacija je zastarela, še preden je izdaja pripravljena. Ko se poslovna logika hitro spreminja, postane vzdrževanje specifikacij breme.

Dodatno tveganje je lažen občutek nadzora. Članek Martina Fowlerja to preučuje: strukture so elegantne, vendar agenti pogosto prezrejo navodila ali pa, nasprotno, predloge upoštevajo dobesedno. Rezultat je koda, ki je strukturno pravilna, a ne ustreza vašemu konkretnemu repozitoriju – specifikacija ne zagotavlja, da jo je agent razumel tako, kot ste nameravali.

Aprila 2026 so analitiki v panogi opozorili na slapovni pristop: pisanje obsežne specifikacije pred kodo je pot, ki je nekoč že potopila industrijo, v času 200-stranskih zahtev. Inženirji so od takrat do tega pristopa previdni in njihova previdnost je upravičena.

Kaj storiti. Predlagam preprosto pravilo: velikost funkcije primerjajte s časom, potrebnim za pisanje specifikacije. Če bo izvedba funkcije trajala manj kot 2 uri, ne pišite specifikacije – Plan Mode je hitrejši. Če bo funkcija trajala teden dni, vsekakor uporabite Spec Kit; prihranek časa bo enourno pisanje specifikacije povrnil petkratno. Pri času med 2 urama in enim tednom presodite sami, čeprav osebno napišem specifikacijo tudi za funkcije, ki trajajo pol dneva, ker je artefakt v repozitoriju vreden več kot prihranjenih 30 minut.

Kaj sledi: kako vključiti Spec Kit v svoj projekt?#

Konkreten načrt za naslednjih 7 dni:

• 1. dan. Namestite uv in Spec Kit (5–10 minut). Preverite, ali so se v Claude Code pojavili ukazi /speckit-*. Ne poskušajte jih uporabiti v obstoječem projektu – začnite z novim.
• 2. dan. Izberite resnično funkcijo, ki jo nameravate zgraditi. Zaženite /speckit-specify s prostim opisom. Odprite spec.md, ga preberite in odgovorite na vsako oznako [NEEDS CLARIFICATION]. Ne hitite na Plan.
• 3. dan. Zaženite /speckit-plan z namigi o svojem tehnološkem skladu. Preberite plan.md, zlasti razdelek Architecture Decisions. Če vam kaj ne ustreza, to uredite ročno.
• 4.–5. dan. Zaženite /speckit-tasks, nato /speckit-analyze za dodatno preverjanje kompleta specifikacije, načrta in nalog, nato pa še /speckit-implement. Opazujte, kako Claude v tasks.md označuje naloge z [x]. Morda se bo kje zataknil – to je običajno. Vrnite se na spec.md, pojasnite zahtevo in znova zaženite /speckit-implement za določeno nalogo. Ko so naloge zaključene, zaženite /speckit-converge ter ponavljajte zaporedje Implement in Converge, dokler ne odgovori »Converged«.
• 6.–7. dan. Preglejte PR (ali več PR-jev). Združite ga. Preberite spec.md in plan.md – to je dokumentacija vaše funkcije za prihodnje leto.

Vzporedno predlagam še naslednje branje:

• Kako leta 2026 nastaviti CLAUDE.md – osnova za ustavo Spec Kita.
• Plan Mode v Claude Code – hitra alternativa za majhne naloge.
• Inženiring konteksta leta 2026 – zakaj Spec Kit sploh deluje.
• Skills, Subagents, MCP ali Plugins – kaj dodati Spec Kitu za svoj potek dela.
• Dynamic Workflows v Claude Code – kako za fazo Implement hkrati zagnati veliko podagentov.

Celoten potek dela s kontekstom: klon AI + Second Brain + inženiring konteksta.

Več gradiva je na voljo na Ailoot.