A Spec Kit beállítása Claude Code-ban 2026-ban: specifikációk promptok helyett

Mi történt a vibe codinggal 2026 májusában?#

Egy évvel később, 2026. február 4-én, közzétett egy visszatekintő szálat:

A Sequoia Ascent 2026 rendezvényen tartott előadásában ezt még pontosabban fogalmazta meg: „A vibe coding megemeli az alsó küszöböt — azt, hogy szoftverfejlesztésben mennyire képes mindenki teljesíteni. Az agentic engineering megőrzi a felső küszöböt — a professzionális fejlesztés minőségi mércéjét.” Ugyanazon a színpadon elhangzott egy mondata, amely bekerült az iparági szókincsbe: „A vibe coding miatt nem okozhatsz biztonsági réseket. Továbbra is felelős vagy a szoftveredért, ahogy eddig is.”

Két dolog történt párhuzamosan. 2025 szeptemberében a GitHub közzétette a Spec Kit eszközt — amely 8 hónap alatt 107 000 csillagot gyűjtött. 2026 februárjában az AWS közzétett egy részletes gyógyszerkutatási esettanulmányt, amely szerint „az üzleti logika 95%-a a specifikációból készült el, több mint 80 órát megtakarítva.”

2026 májusának végére konszenzus alakult ki az angol nyelvű információs térben: a vibe coding mint munkamódszer a kezdő szint. A következő lépés a Spec-Driven Development. Ez az útmutató bemutatja a megközelítés telepítését és alkalmazását.

Mi a Spec Kit és a Spec-Driven Development?#

A módszertan alapgondolatát a GitHub hivatalos dokumentációjának egy mondata ragadja meg:

A gyakorlatban ez 4 fázisban valósul meg (a Spec Kit még egy nulladik fázist is hozzáad — a constitutiont, amelyről alább lesz szó):

1. Specify - természetes nyelven írd le, mit szeretnél. Mit kell tenni és MIÉRT. Nem azt, HOGYAN.
2. Plan - az ügynök feldolgozza a specifikációt, és műszaki tervet állít össze: milyen technológiákat, milyen architektúrát és milyen komponenseket használjon.
3. Tasks - az ügynök konkrét, ellenőrizhető feladatokra bontja a tervet, a függőségekkel együtt.
4. Implement - az ügynök (vagy az alügynökei) végrehajtja a feladatokat, és megírja a kódot.

Az Implement után a Spec Kit aktuális verziójának van egy Converge nevű ellenőrzési lépése: az ügynök összeveti az elkészült kódot a specifikációval, a tervvel és a feladatokkal, majd a kihagyott elemeket hozzáadja a tasks.md fájlhoz. Futtasd az Implementet és a Converge-ot ciklusban addig, amíg a Converge azt nem válaszolja: „Converged.”

Minden fázis külön markdown-fájl a repóban. Claude Code-ban minden fázishoz külön slash parancs tartozik: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, míg az ellenőrzés parancsa /speckit-converge. A Spec Kit dokumentációja ugyanezeket a parancsokat ponttal írja (/speckit.specify), de Claude Code-ban a Spec Kit skillekként települ, és kötőjeles formában hívhatók meg. Ha bármelyik lépésnél valami nem stimmel, szerkeszd a markdown-fájlt, majd futtasd a következő fázist.

A Spec Kit az SDD egy konkrét megvalósítása. 2026 májusában már több mint 30 integrációja volt különböző AI-ügynökökkel. Egy repón belül a Spec Kit ugyanúgy működik Claude Code-dal, Cursorral, GitHub Copilottal, Codex CLI-vel, Windsurf-fel, Qwennel, Tabnine-nal, Amazon Q-val, Geminivel, Goose-szal és még egy tucat másikkal.

Így egy futtatás után a repó nemcsak kódot, hanem a hozzá tartozó specifikációt, tervet és feladatokat is tartalmazza. Egy hónappal később visszatérhetsz a projekthez, elolvashatod a spec.md fájlt, és megértheted, mi készült el és miért. Ez már nem az a „vibe coding, amely elfelejti, hogy létezik a kód” — hanem a projekt munkamemóriája.

Miért van erre szüksége annak a vibe codernek, aki nem ír kódot?#

A Spec Kit 4 slash paranccsal formalizálja a tervezést külön lépésekre bontva. A logika ugyanaz: különválasztja az „átgondolást” a „megvalósítástól”, hogy ezek külön kontextusablakokban történjenek. Minden szakasz tiszta kontextust kap, amelyet az előző fázis még nem terhelt meg.

A vibe coder számára három konkrét előny:

• Kiszámíthatóság. Ha azt mondod az ügynöknek, hogy „készíts regisztrációs űrlapot e-mailes megerősítéssel”, az ügynök 10 részletet önállóan talál ki — és ezek közül három eltér attól, amit elképzeltél. Ha van egy spec.md fájlod User Stories, Acceptance Scenarios szakaszokkal és minden bizonytalan pontnál [NEEDS CLARIFICATION] jelöléssel, nincs mit találgatnia.
• Projektmemória. Egy hónappal később nem fogsz emlékezni, mit beszéltél meg az ügynökkel a csevegésben. A spec.md, a plan.md és a tasks.md viszont a repóban, a kód mellett található specs/###-feature/ mappában van. Megmutatják, mi készült el, és azt is, hogy miért.
• Skálázhatóság. Egy 1-2 fájlt érintő funkciónál alig észrevehető a különbség. Egy 20 fájlt és 5 adategységet érintő funkciónál a különbség aközött, hogy „4 óra után mindent újraírunk”, vagy hogy „4 óra után minden bekerült a fő branchbe”. Az AWS Kiro a TargetID projektben a specifikáció alapján az üzleti logika 95%-os automatizálását mutatta be.

A vibe coding fő illúziója, hogy kezdetben gyorsabbnak tűnik. Fél óra alatt kész is a prototípus. Egy hét múlva viszont elromlik, és egyszerűbb kidobni. A Spec-Driven Development valamivel több időt igényel az elején (fél óra helyett egy órát), de egy hét múlva is ugyanabban a repóban dolgozol.

A Spec Kit telepítése Claude Code-ba (4 lépés)#

1. lépés. Telepítsd az uv-t. Ezt csak egyszer kell megtenned; a rendszereden marad.

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

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

Ellenőrizd, hogy települt-e az uv:

uv --version

2. lépés. Telepítsd a Spec Kitet. Egy parancs:

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

Ellenőrzés:

specify --version

3. lépés. Inicializáld a repót. Lépj a projektmappádba (vagy hozz létre egy újat), majd futtasd:

specify init --here --integration claude

A --integration claude kapcsoló közvetlenül kiválasztja a Claude Code-ot. Enélkül a Spec Kit arra kér, hogy egy interaktív listából válassz ügynököt, és a szkript típusára is rákérdezhet (macOS és Linux esetén hagyd sh értéken). Ha a mappa nem üres, a Spec Kit figyelmeztet, hogy össze fogja fésülni a fájljait a tieiddel: először commitold a munkádat, majd ismételd meg a parancsot a --force kapcsolóval.

Ezután a következők jelennek meg a repóban:

.specify/
  memory/
    constitution.md        # projekt szabályai, kitöltése a /speckit-constitution paranccsal
  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. lépés. Nyisd meg a Claude Code-ot, és ellenőrizd a slash parancsokat. Futtasd ezt ugyanabban a mappában:

claude

A munkamenetben írd be: /speckit — a speckit-* parancsoknak meg kell jelenniük a javaslatok között. Ha nem jelennek meg, indítsd újra a Claude Code-ot, hogy újra beolvassa a .claude/skills/ mappát. Ha a projekt gyökerében már van CLAUDE.md, a Spec Kit érintetlenül hagyja — mellette működik, a .specify/memory/constitution.md fájlban.

A Spec Kit Claude Code nélkül is működik (30+ ügynököt támogat), de ez az útmutató kifejezetten a Claude-dal történő beállítást mutatja be. Ha azonnal két eszközt szeretnél telepíteni, olvasd el a CLAUDE.md beállításáról és a Claude Code Plan Mode-járól szóló külön útmutatókat.

A Spec Kit az „ügynök munkaszerződésének” első építőeleme. A teljes beállítás mindhárom elemet tartalmazza: egy AI-klónt (a módszertanodat Skills és alügynökök formájában), egy Second Braint (a business/ struktúrát, amelyhez az ügynök minden alkalommal visszatér), és a kontextustervezést (Spec Kit, Plan Mode, /compact). Ez az a három pillér, amely nélkül az AI hallucinál.

Hogyan írd meg az első specifikációdat (Specify)#

Claude Code-ban írd be:

/speckit-specify

Ezután az ügynök kérni fogja a funkció leírását. Ennél a lépésnél hétköznapi nyelvet használj, technikai zsargon nélkül:

Regisztrációs űrlapot szeretnék az alkalmazásomba. A felhasználó megad egy e-mail-címet
és jelszót, kap egy megerősítő e-mailt, majd a megerősítés után
a vezérlőpultra jut. A megerősítés 48 óra elteltével lejár. Ha az
e-mail-cím még nincs megerősítve, a fiókot e határidő után 5 percen
belül töröljük; megerősített fiókot soha nem törlünk.

Ebben a szemléltető példában a megengedett törlési késést a 48 órás határidő után 5 percben pontosítottuk. Valódi terméknél ezt a tűrést a Plan előtt egyeztesd; egy pontosan 48 órás törlési határidőhöz az erősebb követelményt érvényesítő terv és tesztek kellenek. Az ügynök elkészíti a specs/001-registration/spec.md fájlt. Nyisd meg, és egy ehhez hasonló struktúrát fogsz látni:

# Funkcióspecifikáció: Felhasználói regisztráció

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "Regisztrációs űrlapot szeretnék..."

## Felhasználói helyzetek és tesztelés *(kötelező)*

### Elsődleges felhasználói történet
Új felhasználóként szeretnék e-mailes megerősítéssel fiókot regisztrálni,
hogy ellenőrzött személyazonossággal férhessek hozzá a vezérlőpulthoz.

### Elfogadási forgatókönyvek
1. **Given** a regisztrációs oldalon vagyok,
   **When** érvényes e-mail-címet és jelszót küldök be,
   **Then** 1 percen belül megkapom a megerősítő e-mailt.
2. **Given** 48 órán belül rákattintottam a megerősítő hivatkozásra,
   **When** a vezérlőpultra érkezem,
   **Then** a profilban megerősítettként látom az e-mail-címemet.
3. **Given** a 48 órás határidőnél még nem erősítettem meg,
   **When** a takarítás a következő 5 percen belül lefut,
   **Then** a fiókom törlődik, az e-mail-cím pedig újra felhasználható lesz regisztrációhoz.
4. **Given** a fiókom még nincs 48 órás, vagy már megerősítettem,
   **When** a takarítás lefut,
   **Then** a fiókom nem törlődik.

## Követelmények *(kötelező)*

### Funkcionális követelmények
- **FR-001**: A rendszernek el KELL fogadnia a regisztrációt ezen keresztül: [NEEDS CLARIFICATION:
  csak e-mail-cím/jelszó, vagy SSO/OAuth is?]
- **FR-002**: A rendszernek 60 másodpercen belül el KELL küldenie a megerősítő e-mailt
- **FR-003**: A megerősítésnek 48 óra elteltével LE KELL járnia; a rendszernek
  legkésőbb e határidő után 5 percen belül TÖRÖLNIE KELL a még meg nem erősített
  fiókokat, és NEM SZABAD törölnie a megerősített fiókokat
- **FR-004**: A rendszernek minden regisztrációs kísérletet naplóznia KELL eddig: [NEEDS
  CLARIFICATION: meddig őrizzük meg a naplókat — 30 napig, 90 napig, örökre?]

### Főbb entitások
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Sikerkritériumok *(kötelező)*
- **SC-001**: A megerősítő e-mailek 95%-a 60 másodpercen belül kézbesül (p95)
- **SC-002**: 0 véletlenül törölt, már megerősített fiók
- **SC-004**: Nincs törlés 48 óra előtt; a tesztelt terhelés mellett minden
  jogosult, meg nem erősített fiók törlődik 48 óra 5 perces koráig
- **SC-003**: A regisztráció befejezési aránya > 60% (az űrlap megnyitásától a vezérlőpultig)

Figyelj a [NEEDS CLARIFICATION: ...] jelölésekre. A Spec Kit szándékosan illeszti be őket mindenhová, ahol a szövegedből nem kapott egyértelmű választ. Mielőtt továbblépnél a Plan fázisra, vagy manuálisan válaszolj rájuk a spec.md fájlban, vagy futtasd a /speckit-clarify parancsot; ekkor az ügynök sorra veszi a tisztázatlan pontokat, és párbeszédben tesz fel kérdéseket.

A Spec Kitben a beépített /speckit-clarify parancs váltja fel a kimondott „tegyél fel kérdéseket” kérést. A hatás ugyanaz: nem lépsz tovább a Plan szakaszra, amíg nem marad [NEEDS CLARIFICATION] jelölés a spec.md fájlban.

A spec.md fájlban nem szerepelhetnek technológiák. Ne említs Reactet, Postgrest, Prismát vagy Redist. A specifikáció azt írja le, mit csinál a rendszer a felhasználó és az üzlet szempontjából. A technológiai verem a következő fázisban kerül elő.

Mit csinál Claude a Plan fázisban?#

Ha a spec.md elkészült, futtasd:

/speckit-plan

Opcionálisan közvetlenül a parancsban is megadhatsz technológiai iránymutatást:

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

Claude három forrást olvas: a spec.md fájlt, a CLAUDE.md fájlodat (vagy a memory/constitution.md fájlt), és a repó meglévő kódját. Az eredmény egy, nagyjából ilyen felépítésű plan.md:

# Megvalósítási terv: Felhasználói regisztráció

## Műszaki kontextus
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validáció: Zod-séma a shared libben
- Auth: NextAuth.js with credentials provider

## Architektúra-döntések

### 1. Tokenek tárolása
A tokenek a DB-ben (ConfirmationToken tábla) tárolódnak, nem a JWT-ben.
Indok: szükség van szerveroldali visszavonásra az e-mail újbóli regisztrálásakor.

### 2. E-mail-kézbesítés
Aszinkron módon, egy cron `/api/cron/send-confirmation` útvonalon keresztül, amely közvetlenül
a regisztráció után indul el. Az újrapróbálkozást a Resend kezeli.

### 3. Automatikus törlést végző cron
Futtasd percenként a `/api/cron/cleanup-unconfirmed` feladatot. Csak azokat a sorokat töröld, ahol
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
A pontosított példa legfeljebb 5 perc törlési késést enged meg.
Ellenőrizd az ütemező késését és a végrehajtási időt ehhez a korláthoz képest;
a túllépést hibaként jelentsd, ne sikeres napi takarításként.

## Adatmodell
Lásd: data-model.md

## API-szerződések
Lásd: contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Megvalósítási fázisok
1. Adatbázis-migráció (Prisma-séma + migrációs fájl)
2. API-útvonalak (3 végpont)
3. UI: regisztrációs űrlap + sikeres megerősítési oldal
4. Cron jobok (küldés + tisztítás)
5. E-mail-sablon
6. Integrációs tesztek

A data-model.md ismerteti az entitásokat és a kapcsolataikat. A contracts/ API-szerződés-vázlatokat tartalmaz (OpenAPI YAML- vagy TypeScript-kérés/válasz típusok formájában). Ez még nem kód — azok a szándékok szerepelnek benne, amelyeket Claude később tényleges útvonalakká alakít.

A Plan fázis fő előnye a tiszta kontextus. Claude-nak nem kell egyszerre fejben tartania a specifikációt és a megvalósítást. Először átgondolja a feladatot, fájlban rögzíti a döntést, majd továbblép.

Ezután következik az opcionális /speckit-analyze parancs. A Tasks fázis után és az Implement előtt kell futtatni: áttekinti a spec.md + plan.md + tasks.md hármast, megkeresi az ellentmondásokat, és ellenőrzi, hogy a terv és a feladatok lefedik-e a specifikáció összes követelményét. Nem módosít fájlokat, csak jelentést készít. Lényegében ez egy formális ésszerűségi ellenőrzés a megvalósítás előtt.

A munka feladatokra bontása (Tasks)#

Ha már megvan a spec.md és a plan.md, futtasd:

/speckit-tasks

Claude a tervből tasks.md fájlt készít:

# Feladatok: Felhasználói regisztráció

## 1. fázis: Adatbázis (nincs függőség)
- [ ] T-001: Add hozzá a User modellt a prisma/schema.prisma fájlhoz (párhuzamosan végezhető)
- [ ] T-002: Add hozzá a ConfirmationToken modellt a prisma/schema.prisma fájlhoz (T-001 után)
- [ ] T-003: Hozd létre az `add-user-registration` migrációt (T-002 után)

## 2. fázis: API-szerződések (nincs függőség)
- [ ] T-004: Hozd létre a Zod-sémákat a shared/validation/auth.ts fájlban
- [ ] T-005: Definiáld a TypeScript-típusokat a shared/types/auth.ts fájlban (T-004 után)

## 3. fázis: Útvonalak (az 1. és 2. fázistól függ)
- [ ] T-006: Valósítsd meg a POST /api/auth/register útvonalat
- [ ] T-007: Valósítsd meg a POST /api/auth/confirm útvonalat
- [ ] T-008: Valósítsd meg a GET /api/auth/resend-confirmation útvonalat

## 4. fázis: UI (párhuzamosan a 3. fázissal)
- [ ] T-009: Készítsd el a /register oldalt az űrlappal
- [ ] T-010: Készítsd el a /register/confirm/[token] oldalt
- [ ] T-011: Készítsd el a /register/success oldalt

## 5. fázis: Cron + integráció (a 3. és 4. fázistól függ)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: registration-confirmation.tsx e-mail-sablon
- [ ] T-015: Integrációs tesztek (Playwright), beleértve a közvetlenül 48h előtti
  és a pontosan 48h időpontot, a törlést 48h 5m korig, a késő feladat hibáját
  és a megerősített fiókok védelmét

## Megjegyzések
- A T-001, T-004, T-009-T-011 párhuzamosan végezhető (különböző fájlok)
- A T-002 ütközik a T-001-gyel (ugyanaz a fájl: schema.prisma) - egymás után kell futtatni
- A T-006-hoz szükség van a T-003-ra (alkalmazott migráció) és a T-005-re (típusok)

Figyeld meg a parallel-safe és az after T-NNN jelöléseket. Ez a függőségi gráf teszi majd lehetővé, hogy több fázis párhuzamosan fusson. A Spec Kit teljes gyorsítási megközelítése ezen a mechanizmuson alapul: egyes feladatokat egyszerre öt különböző Claude Code-munkamenetnek is átadhatsz, másokat viszont szigorúan egymás után kell végezni.

A Spec Kit ezt automatikusan, egyetlen paranccsal, azonnal elvégzi.

Az opcionális /speckit-taskstoissues parancs a tasks.md alapján GitHub Issue-kat hoz létre a listából, mindegyikhez visszamutató hivatkozással a spec.md fájlra. Hasznos, ha csapatban dolgozol, vagy a GitHub Projects segítségével szeretnéd nyomon követni a haladást.

Megvalósítás alügynökökkel (Implement)#

/speckit-implement

Claude a tasks.md első feladatával kezdi. Minden feladat egy rövid cikluson megy végig: a releváns fájlok elolvasása, diff írása, tesztek futtatása, [x] ellenőrzése. Szükség esetén automatikusan alügynököket hív: egyet a kódellenőrzésre, egyet a linter futtatására, egyet pedig a regressziók ellenőrzésére.

És külön a szabályokról:

A Spec Kitben ez a ciklus formalizálva van. A spec.md az igazság forrása, a plan.md a műszaki döntéseket rögzíti, a tasks.md pedig ellenőrzőlista. Ha Claude bármelyik lépésnél letér az útról, visszatérsz a specifikációhoz, és azt mondod: „Ez nem felel meg az FR-003-nak; dolgozd át.” Nincs szükség hosszú, „emlékezz, mit beszéltünk meg...” kezdetű promptokra — a teljes előzmény a fájlokban van.

Ha csatlakoztattad a Dynamic Workflows funkciót az Opus 4.8-ban, a Spec Kitet teljesen automatizált módba állíthatod: egy /speckit-implement parancs, és Claude párhuzamosítja a munkát, egyesíti az eredményeket, majd ellenőrzi őket. A felső határ egyszerre 1000 alügynök. A legtöbb funkcióhoz 10-30 is elég.

Ha minden [x] négyzet ki van pipálva, és a következő szakasz ellenőrzése „Converged” eredményt ad, ellenőrizd a PR-t (vagy több feladat esetén a PR-ok sorozatát), majd vond be a változtatásokat. Az artefaktumok — spec.md, plan.md, tasks.md — a repóban maradnak a funkció dokumentációjaként. Egy év múlva nem kell visszafejtened a logikát a kódból.

Hogyan ellenőrizd, hogy az ügynök nem hagyott-e ki semmit (Converge)#

/speckit-converge

Először az ügynök összefoglalja a megállapításait, súlyossági szintekkel együtt, majd kétféle eredmény egyikét adja. A „Converged” azt jelenti, hogy nincs hiányosság, a tasks.md bájtra pontosan változatlan maradt, és továbbléphetsz az ellenőrzésre. A „Tasks appended” azt jelenti, hogy hiányosságokat talált, hozzáadta őket a tasks.md Convergence szakaszához, és közli, hány új feladat van.

A Converge nem szerkeszti és nem törli a kódot; egyedül új feladatokat ír a tasks.md fájlba. Ezért nyugodtan futtathatod, de csak azután, hogy a /speckit-implement már végigment az aktuális tasks.md fájlon. Minden további ellenőrzési kör egyre kevesebb hiányosságot talál.

Miben különbözik a Spec Kit a CLAUDE.md-től és a Plan Mode-tól?#

Hasonlítsuk össze őket 5 jellemző alapján:

A Spec Kit kifejezéseivel ez a .specify/memory/constitution.md. Inicializáláskor a Spec Kit használhatja a meglévő CLAUDE.md-t a constitution alapjaként, vagy létrehozhat mellette külön fájlt. Én általában a CLAUDE.md-t tartom meg globális „szerződésként” (technológiai verem, szójegyzék, telepítési protokoll), a Spec Kit constitutiont pedig a munkafolyamatra jellemző szabályokhoz használom — például: „minden űrlap Zoddal ellenőrzendő; kézi ellenőrzés nem használható.”

A Plan Mode-dal való kapcsolat egyszerűbb. A Plan Mode egyetlen munkamenet „tervezés kódírás előtt” gyors módja. Jól működik kisebb változtatásoknál (hiba javítása, függvény újraszervezése). Nagy funkcióknál a Plan Mode alulmarad, mert egyetlen munkamenet kontextusablaka túl kicsi egy 3000 soros tervhez — ahogy az élő foglalkozáson is kifejtem:

A Spec Kit a kontextustervezés kézzelfogható eszköze. Az „építészeti terítőt” a csevegésből fájlokba helyezi át. A Spec.md a repóban marad, és minden új Claude-munkamenet ismét elolvassa — nem kell újra és újra elmondanod ugyanazt.

Egy nagy projekt beállítása:

1. CLAUDE.md - technológiai verem, szójegyzék, kerülendő dolgok. A gyökérmappában található.
2. .specify/memory/constitution.md a Spec Kithez — a munkafolyamatra jellemző szabályok.
3. specs/001-feature-A/spec.md, plan.md, tasks.md - első funkció.
4. specs/002-feature-B/spec.md, plan.md, tasks.md - második funkció.
5. A napi munkához vagy a /speckit-implement parancsot használd (kész feladatokhoz), vagy a /plan parancsot (gyors ellenőrzés módosítás előtt).

Mely valós példák működnek?#

Néhány konkrét eset:

• AWS Kiro - gyógyszerkutatási ügynök. Egy AWS Industries-blogbejegyzésben a 2026. február 18-án megjelent cikkben a csapat a TargetID projektet mutatja be. Három fejlesztő, három hét, egy gyógyszerkutatási ügynök. A cikk adatai szerint a Kiro az üzleti logika kódjának több mint 95%-át generálta, több mint 80 fejlesztői órát megtakarítva. Továbbá: „A Kiro által írt README-dokumentáció becslésünk szerint 8 órát takarított meg”, és „40%-kal kevesebb iteratív prompt-javítás ciklusra volt szükség.”
• Rackspace Technology. Ugyanebben az AWS-blogban a Rackspace a következőkről számol be: „52 hétre becsült munkát mindössze 3 hét alatt végeztünk el”, „90%-os hatékonyságnövekedés.” Ez már nem kis funkció — teljes vállalati projekt.
• A GitHub Spec Kit növekedése. Május 31-ére 107 000 GitHub-csillagot gyűjtött. Ez a növekedési ütem világosan jelzi, hogy a megközelítés piaci részesedést szerez.

Az olvasó számára ez azt jelenti, hogy a megközelítés nem elméleti: komoly csapatok már éles környezetben használják.

Mikor NEM alkalmas a Spec Kit?#

Nem megfelelő #1 - apró módosítások. Ha a feladat „nevezz át egy változót”, „javíts ki egy elírást a szövegben” vagy „adj hozzá egy naplóbejegyzést”, a Specify → Plan → Tasks folyamat tovább tart, mint maga a módosítás. Apró módosításokhoz gyorsabb a Plan Mode vagy egy közvetlen prompt a Claude Code-ban.

Nem megfelelő #2 - élő kísérletezés. Ha még nem tudod, mit akarsz, és „körbe kell nézned” a felületen vagy gyorsan összeraknod egy prototípust, hogy lásd, „működik-e”, akkor a specifikáció értelmetlen. Az érték éppen abban rejlik, hogy improvizálsz. Az „ötlettel való játszadozás” szintjén pontosan a vibe működik, nem a specifikáció.

Nem megfelelő #3 - összetett állapotú örökölt kód. Erős ellenérv, hogy a valóság gyorsabban változik, mint a specifikációk. Az előfizetéses számlázás példájában a csapat leírta a számlázási ciklusokat és adószabályokat, majd egy héttel később a pénzügyesek európai áfát kértek — a specifikáció már a kiadás előtt elavult. Ha az üzleti logika gyorsan változik, a specifikációk karbantartása teherré válik.

További kockázat a hamis kontrollérzet: a struktúrák elegánsak, az ügynökök viszont gyakran figyelmen kívül hagyják az utasításokat, vagy éppen ellenkezőleg, túl szó szerint követik a sablonokat. Az eredmény szerkezetileg helyes, de a konkrét repóhoz nem illő kód lehet — a specifikáció nem garantálja, hogy az ügynök úgy értette meg, ahogyan szántad.

2026 áprilisában iparági elemzők a waterfall-modell veszélyére figyelmeztettek: nagy specifikációt írni a kód előtt olyan út, amely egyszer már a mélybe taszította az iparágat, a 200 oldalas követelménydokumentumok korában. A mérnökök azóta is óvatosak ezzel a megközelítéssel, és ez az óvatosság indokolt.

Mit tegyél? Egyszerű szabályt javaslok: vesd össze a funkció méretét azzal az idővel, amely a specifikáció megírásához kell. Ha egy funkció megvalósítása kevesebb mint 2 órát venne igénybe, ne írj specifikációt — a Plan Mode gyorsabb. Ha egy funkció egy hétig tartana, mindenképpen használd a Spec Kitet; az időmegtakarítás ötszörösen megtéríti az egyórás specifikációt. A 2 óra és egy hét közötti tartományban használd a saját ítélőképességedet, bár én személy szerint még egy fél napos funkcióhoz is írok specifikációt, mert a repóban lévő artefaktum többet ér, mint a megspórolt 30 perc.

Mi a következő lépés: hogyan építsd be a Spec Kitet a projektedbe?#

Konkrét terv a következő 7 napra:

• 1. nap. Telepítsd az uv-t és a Spec Kitet (5-10 perc). Ellenőrizd, hogy megjelentek-e a /speckit-* parancsok a Claude Code-ban. Ne próbáld egy meglévő projektre alkalmazni — kezdj egy újjal.
• 2. nap. Válassz ki egy valódi funkciót, amelyet meg szeretnél építeni. Futtasd a /speckit-specify parancsot szabad formájú leírással. Nyisd meg a spec.md fájlt, olvasd el, és válaszolj minden [NEEDS CLARIFICATION] jelölésre. Ne siess a Plan fázisra.
• 3. nap. Futtasd a /speckit-plan parancsot a technológiai vermedre vonatkozó iránymutatással. Olvasd el a plan.md fájlt, különösen az Architecture Decisions szakaszt. Ha valami nem felel meg, szerkeszd kézzel.
• 4-5. nap. Futtasd a /speckit-tasks parancsot, majd a /speckit-analyze parancsot a specifikáció, a terv és a feladatok együttes ellenőrzéséhez, végül pedig a /speckit-implement parancsot. Figyeld, hogyan pipálja ki Claude a [x] jelöléseket a tasks.md fájlban. Lehet, hogy valahol elakad — ez normális. Térj vissza a spec.md fájlhoz, pontosítsd a követelményt, és indítsd újra a /speckit-implement parancsot egy konkrét feladattal. Ha minden feladat lezárult, futtasd a /speckit-converge parancsot, majd ismételd meg az Implement és Converge lépéseket, amíg a válasz „Converged” nem lesz.
• 6-7. nap. Ellenőrizd a PR-t (vagy a PR-ok sorozatát). Vond be a változtatásokat. Olvasd el a spec.md és a plan.md fájlokat — ezek lesznek a funkció dokumentációi az elkövetkező évben.

Amit párhuzamosan érdemes elolvasni:

• A CLAUDE.md beállítása 2026-ban - a Spec Kit constitution alapja.
• Plan Mode a Claude Code-ban - gyors alternatíva kisebb feladatokhoz.
• Kontextustervezés 2026-ban - miért működik egyáltalán a Spec Kit.
• Skills, Subagents, MCP vagy Plugins - mit adj hozzá a Spec Kithez a munkafolyamatodhoz.
• Dynamic Workflows a Claude Code-ban - hogyan indíts egyszerre sok alügynököt az Implement fázishoz.

A teljes kontextus-munkafolyamat: AI-klón + Second Brain + Kontextustervezés.

További anyagok az Ailoot oldalon érhetők el.