# Kaip 2026 m. nustatyti Spec Kit Claude Code aplinkoje: specifikacijos vietoj užklausų > Kaip įdiegti GitHub Spec Kit į Claude Code: 4 etapai – Specify, Plan, Tasks, Implement. Šiame vadove paaiškinama, kaip pakeisti improvizuotą programavimą struktūruotu planu ir specifikacija. Source: https://ailoot.ai/blog/lt/spec-kit-claude-code-spec-driven-development/ Canonical: https://ailoot.ai/blog/lt/spec-kit-claude-code-spec-driven-development/ Language: lt Publisher: Ailoot (https://ailoot.ai/) Translation: guide-219 Revision: sha256-9b589c35bc98707ecd9b0045afaf7429be8f5aad2bf6950bd32b34b31eed8df6
Svarbiausia mintis Spec Kit yra GitHub įrankis, leidžiantis natūralia kalba parašyti užduoties specifikaciją, o tada Claude Code sudaro planą, suskaido jį į užduotis ir parašo kodą. Tai ne teorija: per 8 mėnesius įrankis surinko 107 000 „GitHub“ žvaigždučių, AWS šią metodiką panaudojo vaistų atradimo projektui sukurti per 3 savaites vietoj kelių mėnesių. Šiame vadove aptariamas diegimas, šablonai, 4 darbo eigos etapai ir galutinis patikrinimas bei tai, kaip susieti įrankį su jūsų CLAUDE.md.
[Ailoot dokumentacija](https://ailoot.ai/docs/) – informacinė medžiaga apie naudojimąsi paslauga.
## Kas nutiko vibe coding 2026 m. gegužę?
Svarbiausia mintis Per 8 mėnesius GitHub Spec Kit surinko 107 000 žvaigždučių, o AWS paskelbė atvejo analizę, kurioje nurodoma, kad vienai funkcijai sutaupyta daugiau kaip 80 valandų. Savaitės tendencija gegužę: specifikacija kaip improvizacijos pakaitalas.
Po metų, 2026 m. vasario 4 d., jis paskelbė retrospektyvų įrašų ciklą: Savo kalboje „Sequoia Ascent 2026“ jis tai suformulavo dar tiksliau: „Vibe coding pakelia grindis – tai, kiek kiekvienas gali nuveikti programinės įrangos srityje. Agentic engineering išsaugo lubas – profesionalaus kūrimo kokybės kartelę.“ Toje pačioje scenoje jis pasakė frazę, įėjusią į industrijos žodyną: „Negalite įvesti pažeidžiamumų dėl vibe coding. Kaip ir anksčiau, vis tiek esate atsakingi už savo programinę įrangą.“ Du dalykai įvyko tuo pačiu metu. 2025 m. rugsėjį GitHub paskelbė įrankį [Spec Kit](https://github.com/github/spec-kit) – per 8 mėnesius jis surinko 107 000 žvaigždučių. 2026 m. vasarį AWS paskelbė [išsamią vaistų atradimo projekto atvejo analizę](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/), kurioje nurodoma: „95 % verslo logikos sugeneruota pagal specifikaciją, sutaupant daugiau kaip 80 valandų.“ Iki 2026 m. gegužės pabaigos anglakalbėje informacinėje erdvėje susiformavo bendras požiūris: vibe coding kaip darbo metodas yra pradedančiųjų lygis. Toliau eina Spec-Driven Development. Šiame vadove paaiškinama, kaip šį metodą įdiegti ir taikyti. ## Kas yra Spec Kit ir Spec-Driven Development?
Svarbiausia mintis Spec-Driven Development (SDD) apverčia įprastą darbo su DI agentu tvarką. Anksčiau tiesos šaltinis buvo kodas, o specifikacija – jį lydintys dokumentai. Dabar tiesos šaltinis yra specifikacija, o kodas tampa paskutiniu jos etapu – įgyvendinimu. Spec Kit yra GitHub CLI įrankis, paverčiantis 4 etapus (Specify, Plan, Tasks, Implement) ir galutinį Converge patikrinimą paruoštomis naudoti komandomis Claude Code, Cursor, Copilot ir daugiau kaip 30 kitų agentų.
Metodikos pagrindinė idėja nusakyta viena eilute oficialioje GitHub dokumentacijoje:

Spec-Driven Development pakeičia hierarchiją: specifikacijos nėra skirtos kodui – kodas skirtas specifikacijoms. Specifikacija tampa pagrindiniu artefaktu, o kodas – jos išraiška konkrečia kalba ir konkrečioje sistemoje.

— GitHub Spec Kit dokumentacija, https://github.com/github/spec-kit/blob/main/spec-driven.md
Praktikoje tai vyksta 4 etapais (Spec Kit prideda dar vieną, nulinį etapą – konstituciją, aprašytą toliau): 1. **Specify** – natūralia kalba parašykite norimo rezultato specifikaciją. KĄ daryti ir KODĖL. Ne KAIP. 2. **Plan** – agentas pagal specifikaciją sudaro techninį planą: kokias technologijas naudoti, kokia bus architektūra ir kokie komponentai reikalingi. 3. **Tasks** – agentas suskaido planą į konkrečias, patikrinamas užduotis su priklausomybėmis. 4. **Implement** – agentas (arba jo poagentai) vykdo užduotis ir rašo kodą. Po Implement dabartinėje Spec Kit versijoje yra tikrinimo etapas, vadinamas **Converge**: agentas patikrina užbaigtą kodą pagal specifikaciją, planą ir užduotis, o tada į `tasks.md` įtraukia tai, kas buvo praleista. Kartokite Implement ir Converge ciklą, kol Converge atsakys „Converged“. Kiekvienas etapas yra atskiras Markdown failas saugykloje. Claude Code aplinkoje kiekvieną etapą atitinka atskira pasvirojo brūkšnio komanda: `/speckit-specify`, `/speckit-plan`, `/speckit-tasks`, `/speckit-implement`, o tikrinimo komandą – `/speckit-converge`. Spec Kit dokumentacijoje tos pačios komandos užrašytos su tašku (`/speckit.specify`), tačiau Claude Code aplinkoje Spec Kit jas įdiegia kaip įgūdžius, iškviečiamus su brūkšneliu. Jei bet kuriame etape kas nors nepavyksta, redaguokite Markdown failą ir pakartokite kitą etapą. Spec Kit yra konkretus SDD įgyvendinimas. 2026 m. gegužę jis jau turėjo daugiau kaip 30 integracijų su skirtingais DI agentais. Toje pačioje saugykloje Spec Kit vienodai veikia su Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose ir dar keliolika kitų. | Spec Kit etapas | Pasvirojo brūkšnio komanda | Artefaktas saugykloje | |----|----|----| | Constitution | `/speckit-constitution` | `.specify/memory/constitution.md` | | Specify | `/speckit-specify` | `specs/###-feature/spec.md` | | Clarify (neprivaloma) | `/speckit-clarify` | `spec.md` pakeitimai | | Plan | `/speckit-plan` | `specs/###-feature/plan.md` | | Checklist (neprivaloma) | `/speckit-checklist` | reikalavimų kokybės kontrolinis sąrašas | | Tasks | `/speckit-tasks` | `specs/###-feature/tasks.md` | | Analyze (neprivaloma) | `/speckit-analyze` | specifikacijos, plano ir užduočių ataskaita | | Implement | `/speckit-implement` | projekto kodas | | Converge | `/speckit-converge` | verdiktas „Converged“ arba naujos užduotys faile `tasks.md` | Taigi po darbo saugykloje lieka ne tik kodas, bet ir jo specifikacija, planas bei užduotys. Po mėnesio galite sugrįžti į projektą, perskaityti `spec.md` ir suprasti, kas buvo padaryta ir kodėl. Tai jau nebe „vibe coding, kai pamirštama, kad kodas egzistuoja“ – tai projekto darbinė atmintis. ## Kodėl to reikia vibe coder, kuris nerašo kodo?
Svarbiausia mintis Pagrindinė vibe coder problema yra nenuspėjamumas. Šiandien agentas per 20 minučių sukuria veikiančią funkciją; rytoj, gavęs panašią užduotį, parašo makaronų kodą. Spec Kit pašalina šio nenuspėjamumo priežastį – miglotai suformuluotą užduotį. Kai specifikaciją parašote pagal šabloną, agentas dirba nuosekliai, nes turi vienareikšmį tiesos šaltinį. Be to, saugykloje gaunate išliekantį artefaktą, prie kurio galite grįžti po mėnesio.
Spec Kit planavimą atskirais etapais įformina 4 pasvirojo brūkšnio komandomis. Logika tokia: „viską apgalvoti“ atskiriama nuo „įgyvendinti“, kad šie darbai vyktų skirtinguose konteksto languose. Kiekvienam etapui suteikiamas švarus kontekstas, kurio neužteršė ankstesnis etapas. Trys konkrečios naudos vibe coder: - **Nuspėjamumas.** Kai agentui pasakote „sukurk registracijos formą su patvirtinimu el. paštu“, jis pats nusprendžia dėl 10 detalių ir tris iš jų supranta kitaip, nei norėjote. Kai turite `spec.md` su User Stories, Acceptance Scenarios ir `[NEEDS CLARIFICATION]` žymomis ties kiekvienu neaiškiu punktu, nėra ko spėlioti. - **Projekto atmintis.** Po mėnesio neprisiminsite, ką aptarėte su agentu pokalbyje. Tačiau `spec.md`, `plan.md` ir `tasks.md` liks saugykloje, aplanke `specs/###-feature/` šalia kodo. Jie parodys ne tik tai, kas buvo padaryta, bet ir kodėl. - **Mastelis.** Kai funkcija apima 1–2 failus, skirtumas beveik nepastebimas. Kai ji apima 20 failų ir 5 duomenų esybes, skirtumas yra tarp „po 4 valandų viską perrašyti“ ir „po 4 valandų viskas jau pateko į pagrindinę šaką“. AWS Kiro „TargetID“ projekte pademonstravo, kad 95 % verslo logikos galima automatizuoti pagal specifikaciją. Pagrindinė vibe coding iliuzija yra ta, kad pradžioje atrodo greičiau. Pusvalandis, ir jau turite prototipą. Bet po savaitės prototipas sugenda, todėl lengviau jį išmesti. Spec-Driven Development pradžioje trunka šiek tiek ilgiau (valandą, o ne pusvalandį), tačiau po savaitės vis dar dirbate toje pačioje saugykloje. ## Kaip įdiegti Spec Kit Claude Code aplinkoje (4 žingsniai)
Svarbiausia mintis Spec Kit diegiamas per uv – Python paketų tvarkyklę iš Astral. Pati komanda užima vieną eilutę. Įdiegę pereikite į savo saugyklą, paleiskite `specify init` su vėliava `--integration claude` (arba agentų sąraše pasirinkite Claude Code) ir gausite paruoštą struktūrą su konstitucijos, specifikacijos, plano ir užduočių šablonais bei `/speckit-*` komandų rinkiniu tiesiai Claude Code aplinkoje. Jei uv jau įdiegtas, diegimas trunka 5 minutes, o jei diegiate nuo pradžių – 10 minučių.
**1 žingsnis. Įdiekite uv.** Tai reikia atlikti tik vieną kartą; programa liks jūsų sistemoje. ```bash # macOS / Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" ``` Patikrinkite, ar uv įdiegtas: ```bash uv --version ``` **2 žingsnis. Įdiekite Spec Kit.** Viena komanda: ```bash uv tool install specify-cli --from git+https://github.com/github/spec-kit.git ``` Patikrinkite: ```bash specify --version ``` **3 žingsnis. Inicijuokite saugyklą.** Pereikite į projekto aplanką (arba sukurkite naują) ir paleiskite: ```bash specify init --here --integration claude ``` Vėliava `--integration claude` tiesiogiai parenka Claude Code. Be jos Spec Kit paprašys pasirinkti agentą iš interaktyvaus sąrašo, taip pat gali paklausti skripto tipo (macOS ir Linux atveju palikite `sh`). Jei aplankas netuščias, Spec Kit įspės, kad sujungs savo failus su jūsų failais: pirmiausia užfiksuokite savo darbą, tada pakartokite komandą su vėliava `--force`. Po to saugykloje atsiras: ``` .specify/ memory/ constitution.md # projekto taisyklės, pildomos naudojant /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 žingsnis. Atidarykite Claude Code ir patikrinkite pasvirojo brūkšnio komandas.** Paleiskite tai tame pačiame aplanke: ```bash claude ``` Sesijoje įveskite `/speckit` – pasiūlymuose turėtų atsirasti `speckit-*` komandos. Jei jų nėra, paleiskite Claude Code iš naujo, kad jis iš naujo perskaitytų `.claude/skills/`. Jei projekto šaknyje jau turite `CLAUDE.md`, Spec Kit jo nelies – jis veikia greta jo, faile `.specify/memory/constitution.md`. Spec Kit veikia ir be Claude Code (palaiko daugiau kaip 30 agentų), tačiau šiame vadove aprašoma sąranka būtent su Claude. Jei norite iškart įdiegti du įrankius, skaitykite atskirus vadovus apie [CLAUDE.md nustatymą](https://ailoot.ai/blog/lt/claude-md-template/) ir [Plan Mode Claude Code aplinkoje](https://ailoot.ai/blog/lt/claude-code-plan-mode/). Spec Kit yra pirmasis „agento įdarbinimo sutarties“ elementas. Visa sąranka apima tris dalykus: DI kloną (jūsų metodiką Skills ir poagentų pavidalu), Second Brain (struktūrą `business/`, į kurią agentas kaskart sugrįžta) ir konteksto inžineriją (Spec Kit, Plan Mode, /compact). Tai trys ramsčiai, be kurių DI haliucinuoja. ## Kaip parašyti pirmąją specifikaciją (Specify)
Svarbiausia mintis Spec Kit prašo laisva forma aprašyti funkciją, o tada pagal šabloną išplečia aprašymą į `spec.md` failą: User Stories su P1/P2/P3 prioritetais, Acceptance Scenarios Given/When/Then formatu, Functional Requirements (FR-001, FR-002 ir t. t.) ir Success Criteria su išmatuojamais rezultatais. Kai agentui kas nors neaišku, jis įterpia žymą `[NEEDS CLARIFICATION: ...]` – prieš pereidami prie Plan turite į ją atsakyti.
Claude Code aplinkoje įveskite: ``` /speckit-specify ``` Tada agentas paprašys aprašyti funkciją. Šiame etape vartokite paprastą kalbą, venkite techninio žargono: ``` Noriu, kad mano programėlėje būtų registracijos forma. Naudotojas įveda el. pašto adresą ir slaptažodį, gauna patvirtinimo laišką, o jį patvirtinęs patenka į valdymo skydelį. Patvirtinimas nustoja galioti po 48 valandų. Jei el. paštas vis dar nepatvirtintas, paskyrą ištrinkite per 5 minutes po to termino; niekada netrinkite patvirtintos paskyros. ``` Šiame iliustraciniame pavyzdyje trynimo tolerancija patikslinta iki 5 minučių po 48 valandų termino. Tikram produktui ją patvirtinkite prieš Plan; tiksliam 48 valandų terminui reikia griežtesnį reikalavimą užtikrinančio dizaino ir testų. Agentas sudarys `specs/001-registration/spec.md`. Atidarykite jį ir pamatysite maždaug tokią struktūrą: ```markdown # 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) ``` Atkreipkite dėmesį į žymas `[NEEDS CLARIFICATION: ...]`. Spec Kit jas sąmoningai įterpia visur, kur agentas iš jūsų teksto negavo vienareikšmio atsakymo. Prieš pereidami prie Plan etapo, turite arba patys atsakyti į jas `spec.md` faile, arba paleisti `/speckit-clarify`; tada agentas dialogo metu aptars neaiškius punktus ir užduos klausimus. Spec Kit aplinkoje įtaisyta komanda `/speckit-clarify` pakeičia žodinį prašymą „užduok man klausimus“. Rezultatas toks pat: prie Plan nepereinama, kol `spec.md` nebelieka žymų `[NEEDS CLARIFICATION]`. Faile `spec.md` neturėtų būti technologijų. Nemini React, Postgres, Prisma ar Redis. Specifikacija aprašo, ką sistema daro naudotojo ir verslo požiūriu. Technologijų rinkinys parenkamas kitame etape. ## Ką Claude daro Plan etape?
Svarbiausia mintis Komanda `/speckit-plan` pagal užbaigtą specifikaciją sudaro techninį planą: kokias technologijas naudoti, kokia bus architektūra, kokių modulių, duomenų esybių ir API sutarčių reikia. Planas įrašomas į `specs/###-feature/plan.md`, sutartys eksportuojamos į atskirą aplanką `contracts/`, o duomenų modelis patenka į `data-model.md`. Šiame etape Claude jau žino jūsų technologijų rinkinį iš CLAUDE.md ir konstitucijos, todėl planas tinka esamam projektui, užuot siūlęs „perrašykime viską Rust kalba“.
Kai `spec.md` bus paruoštas, paleiskite: ``` /speckit-plan ``` Pasirinktinai komandoje galite tiesiogiai nurodyti technologijų gaires: ``` /speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email ``` Claude perskaito tris šaltinius: jūsų `spec.md`, jūsų `CLAUDE.md` (arba `memory/constitution.md`) ir esamą kodą saugykloje. Rezultatas – `plan.md` su maždaug tokia struktūra: ```markdown # 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` aprašys esybes ir jų ryšius. Aplanke `contracts/` bus API sutarčių ruošiniai (OpenAPI YAML arba TypeScript užklausų ir atsakymų tipai). Tai dar ne kodas – tai ketinimas, kurį Claude vėliau pavers tikrais maršrutais. Pagrindinis Plan etapo pranašumas – švarus kontekstas. Claude nebando vienu metu įsiminti ir specifikacijos, ir įgyvendinimo. Pirmiausia viską apgalvoja, užrašo sprendimą į failą, o tada pereina prie kito etapo. Toliau eina pasirinktinė komanda `/speckit-analyze`. Ji paleidžiama po Tasks etapo ir prieš Implement: patikrina `spec.md + plan.md + tasks.md` rinkinį, ieško prieštaravimų ir tikrina, ar plane bei užduotyse numatyti visi specifikacijos reikalavimai. Failų ji neredaguoja, tik pateikia ataskaitą. Iš esmės tai formalus sveiko proto patikrinimas prieš įgyvendinimą. ## Kaip suskaidyti darbą į užduotis (Tasks)
Svarbiausia mintis Komanda `/speckit-tasks` suskaido planą į konkrečias užduotis. Prie kiekvienos nurodomos priklausomybės, įvertis ir žyma, ar ją „galima vykdyti lygiagrečiai“, ar „būtina vykdyti nuosekliai“. Rezultatas yra `tasks.md`, kuriame užduotys pateikiamos kontrolinio sąrašo formatu `[ ] T-001: ...`. Tada galite perduoti jas įgyvendinti su `/speckit-implement` arba paversti GitHub Issues naudodami `/speckit-taskstoissues` ir paskirstyti komandai ar kelioms lygiagrečiai veikiančioms Claude Code sesijoms.
Kai turite `spec.md` ir `plan.md`, paleiskite: ``` /speckit-tasks ``` Claude išplečia planą į `tasks.md`: ```markdown # 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) ``` Atkreipkite dėmesį į žymas `parallel-safe` ir `after T-NNN`. Tai priklausomybių grafas, leidžiantis vėliau kelis etapus vykdyti lygiagrečiai. Visas Spec Kit paspartinimo metodas remiasi šiuo mechanizmu: kai kurias užduotis galima vienu metu perduoti penkiems skirtingiems Claude Code seansams, o kitas būtina vykdyti tik nuosekliai. Spec Kit tai atlieka automatiškai, viena komanda, iš karto. Pasirinktinė komanda `/speckit-taskstoissues` paima `tasks.md` ir sukuria sąrašo GitHub Issues, kurių kiekviena susieta su `spec.md`. Tai naudinga, jei dirbate komandoje arba norite sekti pažangą per GitHub Projects. ## Kaip įgyvendinti su poagentais (Implement)
Svarbiausia mintis Paskutinis etapas `/speckit-implement` pradeda įgyvendinimą. Claude paeiliui vykdo `tasks.md` užduotis iš viršaus į apačią, atliktas pažymėdamas `[x]`. Vienu metu galite paleisti kelias lygiagrečias Claude Code sesijas – kiekvienai skirti po vieną etapą. Kiekvienoje sesijoje Claude skirtingiems darbams pasitelkia poagentus: kodo peržiūrai, testavimui ir README dokumentacijai rašyti. Tai ir yra „1000 lygiagrečių poagentų“, apie kuriuos Anthropic rašė išleidusi Opus 4.8 – Spec Kit aplinkoje tai tiesiog darbo režimas, o ne atskiras produktas.
``` /speckit-implement ``` Claude pradeda nuo pirmosios `tasks.md` užduoties. Kiekviena užduotis pereina trumpą ciklą: perskaitomi susiję failai, parašomas pakeitimas, paleidžiami testai ir pažymima `[x]`. Prireikus poagentai iškviečiami automatiškai: vienas kodo peržiūrai, kitas linteriui paleisti, dar kitas regresijoms patikrinti. O apie taisykles jis sako: Spec Kit aplinkoje šis ciklas įformintas. Turite `spec.md` kaip tiesos šaltinį, `plan.md` techniniams sprendimams ir `tasks.md` kaip kontrolinį sąrašą. Jei Claude bet kuriame etape nukrypsta nuo kelio, grįžtate prie specifikacijos ir sakote: „Tai neatitinka FR-003; padaryk iš naujo.“ Nebereikia ilgų užklausų „prisimink, ką aptarėme...“ – visa istorija yra failuose. Jei jau esate susieję [Dynamic Workflows Opus 4.8 aplinkoje](https://ailoot.ai/blog/lt/claude-code-dynamic-workflows/), galite visiškai automatizuoti Spec Kit darbą: viena komanda `/speckit-implement`, ir Claude lygiagrečiai vykdo darbą, sujungia rezultatus bei juos patikrina. Vienu metu galima naudoti iki 1000 poagentų. Daugumai funkcijų pakanka 10–30. Kai pažymėti visi `[x]` langeliai ir kitoje dalyje aprašytas patikrinimas pateikia „Converged“, peržiūrėkite PR (arba kelis PR, jei užduočių daug) ir sujunkite jį. Artefaktai – `spec.md`, `plan.md`, `tasks.md` – lieka saugykloje kaip funkcijos dokumentacija. Po metų nereikės atkurti logikos iš kodo. ## Kaip patikrinti, ar agentas nieko nepraleido (Converge)
Svarbiausia mintis Po Implement dabartinėje Spec Kit versijoje yra tikrinimo etapas `/speckit-converge`. Agentas palygina užbaigtą kodą su `spec.md`, `plan.md` ir `tasks.md`. Jei viskas sutampa, jis atsako „Converged“ ir failų neliečia. Jei randa praleistų dalykų, įtraukia juos kaip naujas užduotis `tasks.md` pabaigoje. Tada vėl paleidžiate `/speckit-implement`, po jo – `/speckit-converge`, ir kartojate, kol gaunate atsakymą „Converged“.
``` /speckit-converge ``` Pirmiausia agentas pateikia rastų dalykų santrauką ir jų svarbos lygius, tada nurodo vieną iš dviejų rezultatų. „Converged“ reiškia, kad nieko nepraleista, `tasks.md` liko nepakeistas iki baito ir galima pereiti prie peržiūros. „Tasks appended“ reiškia, kad rasta praleistų dalykų, jie įtraukti į `tasks.md` skyrių Convergence, o agentas nurodo jų skaičių. Converge kodo neredaguoja ir netrina; vienintelis jo įrašas – naujos užduotys faile `tasks.md`. Todėl galite jį paleisti nesijaudindami, bet tik po to, kai `/speckit-implement` jau įvykdė tuo metu esančias `tasks.md` užduotis. Kiekvieno paskesnio patikrinimo metu praleistų dalykų lieka vis mažiau. ## Kuo Spec Kit skiriasi nuo CLAUDE.md ir Plan Mode?
Svarbiausia mintis Lyginant šiuos įrankius kyla dažnas klausimas. Trumpas atsakymas: CLAUDE.md yra agento „darbo sutartis“, vienas viso projekto tiesos šaltinis. Plan Mode – vienkartinis planavimas prieš konkrečią užklausą. Spec Kit apima visą vienos funkcijos gyvavimo ciklą: nuo aprašymo iki įgyvendinimo, o artefaktus saugo saugykloje. Jie vienas kito nepakeičia, o sudaro trijų sluoksnių sistemą: bendrasis kontekstas (CLAUDE.md) → projekto kontekstas (Spec Kit konstitucija) → funkcijos kontekstas (spec.md + plan.md + tasks.md).
Palyginkime juos pagal 5 savybes: | Savybė | CLAUDE.md | Plan Mode | Spec Kit | |----|----|----|----| | Kada veikia | Kiekvienos sesijos metu | Pagal užklausą (Shift+Tab arba /plan) | Pasvirojo brūkšnio komanda /speckit-* | | Trukmė | Visas projektas | Viena sesija | Viena funkcija | | Kur saugomas | Saugyklos šaknyje | Claude kontekste | `specs/###-feature/*` | | Kas saugoma | Technologijų rinkinys, taisyklės, žodynėlis | Dabartinis planas ir pastebėjimai | spec + plan + tasks + contracts | | Šablonas | Laisva forma (saugyklos taisyklės) | Nėra | Struktūruotas Markdown | | Geriausias vaidmuo | Projekto taisyklės ir technologijų rinkinys | Pakartotinis patikrinimas prieš didelį pakeitimą | Visas funkcijos ciklas: nuo KĄ iki KODO | Spec Kit terminais tai yra `.specify/memory/constitution.md`. Inicijuojant Spec Kit, galima naudoti esamą CLAUDE.md kaip konstitucijos pagrindą arba šalia jo sukurti atskirą failą. Aš paprastai CLAUDE.md palieku kaip bendrąją „sutartį“ (technologijų rinkinys, žodynėlis, diegimo protokolas), o Spec Kit konstitucijoje aprašau konkrečias darbo eigos taisykles, pavyzdžiui, „visos formos tikrinamos per Zod; rankiniu būdu netikrinama“. Ryšys su Plan Mode paprastesnis. Plan Mode yra greitas „planavimas prieš rašant kodą“ vienos sesijos režimu. Jis tinka nedideliems pakeitimams (klaidai ištaisyti, funkcijai refaktorizuoti). Dirbant su didele funkcija Plan Mode nusileidžia, nes vienos sesijos konteksto langas per mažas 3000 eilučių planui – kaip tiesiogiai paaiškinu tiesioginiame užsiėmime: Spec Kit yra konkretus konteksto inžinerijos įrankis. „Architektūros staltiesė“ iš pokalbio perkeliama į failus. Spec.md lieka saugykloje, o kiekviena nauja Claude sesija jį perskaito iš naujo – jums nereikia kartotis. Didelio projekto sąranka: 1. **CLAUDE.md** – technologijų rinkinys, žodynėlis, ko nedaryti. Failas yra šaknyje. 2. **.specify/memory/constitution.md** Spec Kit aplinkoje – konkrečios šios darbo eigos taisyklės. 3. **specs/001-feature-A/spec.md, plan.md, tasks.md** – pirmoji funkcija. 4. **specs/002-feature-B/spec.md, plan.md, tasks.md** – antroji funkcija. 5. Kasdieniam darbui naudokite `/speckit-implement` (paruoštoms užduotims) arba `/plan` (greitam patikrinimui prieš pakeitimą). ## Kokie realūs atvejai jau veikia?
Svarbiausia mintis Spec Kit ir SDD metodai didelėse įmonėse jau davė išmatuojamų rezultatų. AWS vaistų atradimo projekte: 95 % verslo logikos sugeneruota pagal specifikaciją, vienai funkcijai sutaupyta daugiau kaip 80 valandų. „Rackspace Technology“: 52 savaičių darbas sutrumpintas iki 3 savaičių, efektyvumas padidėjo +90 %. Pats Spec Kit per 8 mėnesius surinko 107 000 „GitHub“ žvaigždučių.
Konkretūs atvejai: - **AWS Kiro – vaistų atradimo agentas.** 2026 m. vasario 18 d. paskelbtame [AWS Industries tinklaraščio įraše](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) komanda aprašo „TargetID“ projektą. Trys kūrėjai, trys savaitės, vaistų atradimo agentas. Straipsnyje pateikiami skaičiai: Kiro sugeneravo daugiau kaip 95 % verslo logikos kodo ir sutaupė daugiau kaip 80 kūrimo valandų. Taip pat: „Kiro parašyta README dokumentacija sutaupė maždaug 8 valandas“ ir „40 % mažiau užklausos pataisymo ciklų“. - **„Rackspace Technology“.** Tame pačiame AWS tinklaraščio įraše „Rackspace“ nurodo: „52 savaičių numatytą darbą užbaigė vos per 3 savaites“, „efektyvumas padidėjo 90 %“. Tai jau ne maža funkcija, o visas įmonės projektas. - **GitHub Spec Kit augimas.** Iki 2026 m. gegužės 31 d. saugykla pasiekė 107 000 žvaigždučių. Per tris savaites prisidėjo +14 000 žvaigždučių. Toks augimo tempas aiškiai rodo, kad šis metodas užima vis didesnę rinkos dalį. Skaitytojui tai reiškia, kad šis metodas nėra teorinis – rimtos komandos jį jau taiko gamybinėje aplinkoje. ## Kada Spec Kit NETINKA?
Svarbiausia mintis Spec Kit tinka ne visur. Yra trys aiškios sritys, kuriose jo nereikėtų naudoti: smulkūs pakeitimai (klaidos taisymas, kintamojo pervadinimas), eksperimentai ir prototipai (kai nežinojimas, ko norite, ir yra pati vibe coding esmė) bei sudėtingos būsenos senas kodas (kai specifikacija pasensta greičiau, nei spėjate ją užbaigti). Verta žinoti šiuos argumentus, kad neeikvotumėte laiko specifikacijoms, kurios nepadeda.
**Netinka Nr. 1 – smulkūs pakeitimai.** Jei užduotis yra „pervadinti kintamąjį“, „ištaisyti rašybos klaidą tekste“ arba „pridėti žurnalo įrašą“, Specify → Plan → Tasks eiga truks ilgiau už patį pakeitimą. Smulkiems pakeitimams Plan Mode arba tiesioginė užklausa Claude Code aplinkoje yra greitesnė. **Netinka Nr. 2 – tiesioginiai eksperimentai.** Kai dar nežinote, ko norite, ir reikia „pasibastyti“ po sąsają arba greitai surinkti prototipą, kad pamatytumėte, „ar jis prigis“, specifikacija beprasmė. Vertę suteikia pats improvizavimas. Kai tiesiog „žaidžiate su idėja“, tinka būtent vibe coding, o ne specifikacija. **Netinka Nr. 3 – senas kodas su sudėtinga būsena.** Stiprus kontrargumentas: tikrovė kinta greičiau už specifikacijas. Pavyzdžiui, komanda aprašė atsiskaitymo ciklus ir mokesčių taisykles, o po savaitės finansų skyrius paprašė įtraukti Europos PVM – specifikacija paseno dar prieš išleidimą. Kai verslo logika greitai keičiasi, specifikacijų priežiūra tampa našta. Papildoma rizika – klaidingas kontrolės jausmas. Martino Fowlerio straipsnyje tai nagrinėjama taip: struktūros elegantiškos, bet agentai dažnai ignoruoja instrukcijas arba, priešingai, pernelyg pažodžiui laikosi šablonų. Dėl to kodas būna struktūriškai tvarkingas, bet netinka konkrečiai jūsų saugyklai – specifikacija negarantuoja, kad agentas ją suprato taip, kaip norėjote. Pramonės analitikai įspėjo dėl krioklio modelio: didelės specifikacijos rašymas prieš kodą yra kelias, kuris jau kartą nuvedė industriją į aklavietę – dar 200 puslapių reikalavimų laikais. Nuo tada inžinieriai į šį metodą žiūri atsargiai, ir ne be priežasties. **Ką daryti?** Siūlau paprastą taisyklę: palyginkite funkcijos dydį su specifikacijos rašymo trukme. Jei funkcijai įgyvendinti reikės mažiau nei 2 valandų, specifikacijos nerašykite – Plan Mode greitesnis. Jei funkcijai prireiks savaitės, būtinai naudokite Spec Kit; sutaupytas laikas penkis kartus atsvers valandą, skirtą specifikacijai. Jei reikia nuo 2 valandų iki savaitės, spręskite patys, nors aš asmeniškai rašau specifikaciją net ir pusdienio trukmės funkcijoms, nes saugykloje išliekantis artefaktas vertingesnis už sutaupytas 30 minučių. ## Kas toliau: kaip integruoti Spec Kit į savo projektą?
Svarbiausia mintis Lengviausia pradėti nuo naujos nedidelės funkcijos, o ne nuo viso esamo projekto. Įdiekite Spec Kit, inicijuokite jį saugykloje, paleiskite `/speckit-specify` vienai funkcijai ir peržiūrėkite artefaktus. Po savaitės ar dviejų jau suprasite, kada jį rinktis, o kada pakanka greitų užklausų. Visa metodika apima CLAUDE.md + Spec Kit + Skills + poagentus.
Konkretus planas artimiausioms 7 dienoms: - **1 diena.** Įdiekite uv ir Spec Kit (5–10 minučių). Patikrinkite, ar Claude Code aplinkoje atsirado `/speckit-*` komandos. Nebandykite jų taikyti esamam projektui – pradėkite nuo naujo. - **2 diena.** Pasirinkite tikrą funkciją, kurią planuojate sukurti. Paleiskite `/speckit-specify` su laisvos formos aprašymu. Atidarykite `spec.md`, perskaitykite jį ir atsakykite į kiekvieną `[NEEDS CLARIFICATION]`. Neskubėkite pereiti prie Plan. - **3 diena.** Paleiskite `/speckit-plan` ir nurodykite savo technologijų rinkinio gaires. Perskaitykite `plan.md`, ypač skyrių Architecture Decisions. Jei kas nors netinka, pataisykite rankiniu būdu. - **4–5 diena.** Paleiskite `/speckit-tasks`, tada `/speckit-analyze`, kad dar kartą patikrintumėte specifikacijos, plano ir užduočių rinkinį, o po to – `/speckit-implement`. Stebėkite, kaip Claude `tasks.md` pažymi `[x]`. Kartais darbas užstrigs – tai normalu. Grįžkite į `spec.md`, patikslinkite reikalavimą ir iš naujo paleiskite `/speckit-implement`, nurodydami konkrečią užduotį. Kai užduotys bus įvykdytos, paleiskite `/speckit-converge` ir kartokite Implement bei Converge seką, kol gausite atsakymą „Converged“. - **6–7 diena.** Peržiūrėkite PR (arba jų seriją). Sujunkite jį. Perskaitykite savo `spec.md` ir `plan.md` – tai bus funkcijos dokumentacija ateinantiems metams. Ką siūlyčiau skaityti lygiagrečiai: - [Kaip nustatyti CLAUDE.md 2026 m.](https://ailoot.ai/blog/lt/claude-md-template/) – Spec Kit konstitucijos pagrindas. - [Plan Mode Claude Code aplinkoje](https://ailoot.ai/blog/lt/claude-code-plan-mode/) – greita alternatyva mažoms užduotims. - [Konteksto inžinerija 2026 m.](https://ailoot.ai/blog/lt/context-engineering/) – kodėl Spec Kit apskritai veikia. - [Skills, Subagents, MCP ar Plugins](https://ailoot.ai/blog/lt/skills-subagents-mcp-plugins-claude-code/) – ką pridėti prie Spec Kit savo darbo eigai. - [Dynamic Workflows Claude Code aplinkoje](https://ailoot.ai/blog/lt/claude-code-dynamic-workflows/) – kaip Implement etape vienu metu paleisti daug poagentų.
### Šaltiniai - [GitHub Spec Kit – saugykla](https://github.com/github/spec-kit) - [GitHub Spec Kit – oficiali dokumentacija](https://github.github.com/spec-kit/) - [Spec-Driven Development – oficialus metodikos tekstas](https://github.com/github/spec-kit/blob/main/spec-driven.md) - [Spec šablonas – GitHub](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) - [AWS Industries tinklaraštis – From spec to production: Kiro drug discovery agent (2026 m. vasario 18 d.)](https://aws.amazon.com/blogs/industries/from-spec-to-production-a-three-week-drug-discovery-agent-using-kiro/) - [Claude Code dokumentacija – poagentai](https://code.claude.com/docs/en/sub-agents) - [Claude Code dokumentacija – įgūdžiai](https://code.claude.com/docs/en/skills) - [Claude Code dokumentacija – komandos](https://code.claude.com/docs/en/commands)
Visa konteksto darbo eiga: DI klonas + Second Brain + konteksto inžinerija. Daugiau medžiagos rasite [Ailoot](https://ailoot.ai/). ## Klausimai ir atsakymai ### Kodėl kasdienio valymo nepakanka 48 valandų trynimo reikalavimui? Paskyra, pasiekusi terminą vos po kasdienio paleidimo, gali laukti beveik dar parą. Specifikacijoje patikslinkite toleruojamą trynimo vėlavimą, pasirinkite jį atitinkantį tvarkaraštį ir išbandykite 48 valandų slenkstį bei didžiausią vėlavimą. ### Ką daryti, kai plan.md prieštarauja spec.md? Prieš įgyvendinimą grįžkite prie reikalavimo ir išspręskite neatitikimą. Specifikaciją, planą, užduotis ir priėmimo patikras atnaujinkite kartu, tada Analyze bei įgyvendinimo patikromis patvirtinkite tą pačią sutartą elgseną. ## Ailoot · Įmonė ir jos projektų portfelis Ailoot remiasi sukaupta veiklos patirtimi, plačia klientų baze, stabiliomis paslaugomis ir nuolatine KPI kontrole. Įmonė ir jos projektų portfelis: milijonai klientų; mėnesio pardavimai siekia milijardus. Ailoot šią veiklos patirtį pritaiko teikdama API prieigą prie DI funkcijų klientų produktuose, agentuose, programose ir automatizavimo sprendimuose.