Jak nastavit Spec Kit v Claude Code v roce 2026: specifikace místo promptů

Co se změnilo ve vibe codingu před zavedením Spec Kit?#

O rok později, 4. února 2026, zveřejnil retrospektivní vlákno:

Ve svém vystoupení na Sequoia Ascent 2026 to formuloval ještě přesněji: „Vibe coding zvyšuje základní úroveň — to, co každý zvládne v softwaru. Agentic engineering zachovává nejvyšší laťku — kvalitu profesionálního vývoje.“ Na stejném pódiu pronesl větu, která se dostala do slovníku oboru: „Kvůli vibe codingu nemůžete zavádět zranitelnosti. Za svůj software odpovídáte stejně jako dřív.“

V září 2025 GitHub vydal nástroj Spec Kit — za 8 měsíců nasbíral 107 000 hvězdiček. V únoru 2026 AWS zveřejnila podrobnou případovou studii o objevování léčiv s údajem „95 % obchodní logiky vygenerováno ze specifikace, úspora více než 80 hodin“.

Do konce května 2026 se v anglickojazyčném informačním prostoru ustálil konsenzus: vibe coding jako pracovní metoda je začátečnická úroveň. Dalším krokem je Spec-Driven Development. Tento návod vysvětluje, jak tento přístup nainstalovat a používat.

Co jsou Spec Kit a Spec-Driven Development?#

Základní myšlenku této metodiky vystihuje jedna věta z oficiální dokumentace GitHubu:

V praxi se tento přístup rozvíjí ve 4 fázích (Spec Kit přidává ještě fázi nula — constitution, popsanou níže):

1. Specify – v přirozeném jazyce napište specifikaci toho, co chcete. CO udělat a PROČ. Ne JAK.
2. Plan – agent vezme specifikaci a sestaví technický plán: jaké technologie použít, jakou zvolit architekturu a které komponenty vytvořit.
3. Tasks – agent rozdělí plán na konkrétní, ověřitelné úkoly se závislostmi.
4. Implement – agent (nebo jeho podagenti) postupuje podle úkolů a píše kód.

Po fázi Implement má současná verze Spec Kitu ověřovací krok nazvaný Converge: agent porovná hotový kód se specifikací, plánem a úkoly a vše, co chybí, přidá do tasks.md. Opakujte Implement a Converge, dokud Converge neodpoví „Converged“.

Každá fáze je samostatný soubor Markdown v repozitáři. V Claude Code je každá fáze samostatný lomítkový příkaz: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement; kontrola je /speckit-converge. Dokumentace Spec Kitu zapisuje stejné příkazy s tečkou (/speckit.specify), ale v Claude Code se Spec Kit instaluje jako dovednosti a spouští se s pomlčkou. Pokud se v kterémkoli kroku něco pokazí, upravte soubor Markdown a spusťte následující fázi znovu.

Spec Kit je konkrétní implementací SDD. V květnu 2026 měl již více než 30 integrací s různými AI agenty. V jednom repozitáři funguje Spec Kit stejně s Claude Code, Cursorem, GitHub Copilotem, Codex CLI, Windsurfem, Qwenem, Tabnine, Amazon Q, Geminim, Goose a dalšími.

Po dokončení běhu tedy váš repozitář obsahuje nejen kód, ale i jeho specifikaci, plán a úkoly. Za měsíc se můžete vrátit k projektu, přečíst si spec.md a pochopit, co bylo uděláno a proč. Už nejde o „vibe coding, při kterém se zapomnělo, že kód existuje“ — jde o pracovní paměť projektu.

Proč to potřebuje vibe coder, který nepíše kód?#

Spec Kit formalizuje plánování napříč samostatnými kroky pomocí 4 lomítkových příkazů. Logika: oddělit „promyšlení“ od „implementace“, aby probíhaly v různých kontextových oknech. Každá fáze dostane čistý kontext, který předchozí fáze nezaplnila.

Tři konkrétní výhody pro vibe codera:

• Předvídatelnost. Když agentovi řeknete „vytvoř registrační formulář s potvrzením e-mailu“, sám si domyslí 10 podrobností — a ve třech se netrefí do toho, co jste měli na mysli. Když máte spec.md s User Stories, Acceptance Scenarios a značkami [NEEDS CLARIFICATION] u každého nejasného bodu, není co hádat.
• Paměť projektu. Za měsíc si nevzpomenete, o čem jste s agentem v chatu mluvili. Ale spec.md, plan.md a tasks.md zůstávají v repozitáři, ve složce specs/###-feature/ vedle kódu. Ukazují nejen to, co bylo uděláno, ale i proč.
• Rozsah. U funkce zahrnující 1–2 soubory je rozdíl sotva znatelný. U funkce zahrnující 20 souborů a 5 datových entit je rozdíl mezi „po 4 hodinách všechno přepisovat“ a „po 4 hodinách je všechno v hlavní větvi“. AWS Kiro v projektu TargetID předvedlo 95% automatizaci obchodní logiky ze specifikace.

Hlavní iluze vibe codingu spočívá v tom, že zpočátku vypadá rychlejší. Půl hodiny a máte prototyp. Po týdnu se ale prototyp rozbije a je jednodušší ho zahodit. Spec-Driven Development zabere na začátku o něco déle (hodinu místo půl hodiny), ale i za týden budete stále pracovat ve stejném repozitáři.

Jak nainstalovat Spec Kit v Claude Code (4 kroky)#

Krok 1. Nainstalujte uv. Stačí to udělat jednou; zůstane ve vašem systému.

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

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

Ověřte, že se uv nainstalovalo:

uv --version

Krok 2. Nainstalujte Spec Kit. Jeden příkaz:

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

Ověření:

specify --version

Krok 3. Inicializujte repozitář. Přejděte do složky projektu (nebo vytvořte novou) a spusťte:

specify init --here --integration claude

Příznak --integration claude vybere přímo Claude Code. Bez něj vás Spec Kit vyzve, abyste vybrali agenta z interaktivního seznamu; může se také zeptat na typ skriptu (pro macOS a Linux ponechte sh). Pokud složka není prázdná, Spec Kit upozorní, že sloučí své soubory s vašimi: nejprve potvrďte svou práci commitem a pak příkaz zopakujte s příznakem --force.

Poté se v repozitáři objeví:

.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

Krok 4. Otevřete Claude Code a ověřte lomítkové příkazy. Spusťte ve stejné složce:

claude

V relaci zadejte /speckit — mezi návrhy by se měly objevit příkazy speckit-*. Pokud se nezobrazí, restartujte Claude Code, aby znovu načetl .claude/skills/. Pokud už máte v kořenové složce projektu CLAUDE.md, Spec Kit ho ponechá beze změny — funguje vedle něj v .specify/memory/constitution.md.

Spec Kit funguje i bez Claude Code (podporuje více než 30 agentů), ale tento návod se zaměřuje na nastavení s Claude. Pokud chcete hned nainstalovat dva nástroje, přečtěte si samostatné návody na nastavení CLAUDE.md a Plan Mode v Claude Code.

Spec Kit je prvním stavebním prvkem „pracovní smlouvy agenta“. Kompletní nastavení zahrnuje všechny tři části: klon AI (vaši metodiku v podobě Skills a podagentů), Second Brain (strukturu business/, ke které se agent pokaždé vrací) a inženýrství kontextu (Spec Kit, Plan Mode, /compact). To jsou tři pilíře, bez nichž AI halucinuje.

Jak napsat první specifikaci (Specify)#

V Claude Code zadejte:

/speckit-specify

Agent vás potom požádá o popis funkce. V tomto kroku používejte běžný jazyk bez technických výrazů:

I want a registration form in my app. The user enters an email
and password, receives a confirmation email, and after confirming
lands on the dashboard. Confirmation expires after 48 hours. If the
email is still unconfirmed, delete the account within 5 minutes after
that deadline; never delete a confirmed account.

V ilustrativním příkladu byla tolerance mazání vyjasněna na 5 minut po limitu 48 hodin. U skutečného produktu ji potvrďte před Plan; přesný limit 48 hodin potřebuje návrh a testy vynucující tento přísnější požadavek. Agent sestaví specs/001-registration/spec.md. Otevřete jej a uvidíte přibližně tuto strukturu:

# 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)

Věnujte pozornost značkám [NEEDS CLARIFICATION: ...]. Spec Kit je záměrně vkládá všude tam, kde agent z vašeho textu nedostal jednoznačnou odpověď. Před přechodem k fázi Plan na ně musíte buď odpovědět ručně v spec.md, nebo spustit /speckit-clarify; agent projde nejasné body a zeptá se vás v dialogu.

Ve Spec Kitu nahrazuje vestavěný příkaz /speckit-clarify vyslovené „ptej se mě“. Výsledek je stejný: k Plan nepokračujete, dokud v spec.md nezmizí všechny značky [NEEDS CLARIFICATION].

V spec.md by neměly být žádné technologie. Žádné zmínky o Reactu, Postgresu, Prismě ani Redis. Specifikace popisuje, co systém dělá z pohledu uživatele a firmy. Technologický stack přichází až v další fázi.

Co Claude dělá ve fázi Plan?#

Až bude spec.md připravený, spusťte:

/speckit-plan

Volitelně můžete do příkazu přidat nápovědu k technologiím:

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

Claude čte ze tří zdrojů: váš spec.md, váš CLAUDE.md (nebo memory/constitution.md) a existující kód v repozitáři. Výstupem je plan.md s přibližně touto strukturou:

# 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

Soubor data-model.md popíše entity a jejich vztahy. contracts/ bude obsahovat návrhy smluv API (buď OpenAPI YAML, nebo typy požadavků a odpovědí TypeScript). Nejde o kód — jde o záměr, který Claude později převede na skutečné routy.

Hlavní výhodou fáze Plan je čistý kontext. Claude se nesnaží mít současně v hlavě specifikaci i implementaci. Nejdřív vše promyslí, zapíše rozhodnutí do souboru a pak pokračuje.

Následuje volitelný příkaz /speckit-analyze. Spouští se po fázi Tasks a před Implement: kontroluje, zda si spec.md, plan.md a tasks.md neodporují, a zda plán a úkoly pokrývají všechny požadavky specifikace. Soubory neupravuje; vytvoří pouze zprávu. Jde v podstatě o formální kontrolu před implementací.

Jak rozdělit práci na úkoly (Tasks)#

Jakmile máte spec.md a plan.md, spusťte:

/speckit-tasks

Claude rozšíří plán do souboru 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)

Všimněte si značek parallel-safe a after T-NNN. Jde o graf závislostí, díky němuž lze později spustit několik fází paralelně. Na tomto mechanismu stojí celé zrychlení se Spec Kitem: některé úkoly můžete předat pěti různým relacím Claude Code najednou, zatímco jiné musí proběhnout přísně sekvenčně.

Spec Kit to dělá automaticky jediným příkazem, hned po instalaci.

Volitelný příkaz /speckit-taskstoissues vezme tasks.md a vytvoří z jeho seznamu GitHub Issues, každý s odkazem zpět na spec.md. Hodí se to při týmové práci nebo když chcete sledovat postup v GitHub Projects.

Jak implementovat pomocí podagentů (Implement)#

/speckit-implement

Claude začne prvním úkolem v tasks.md. Každý úkol projde krátkým cyklem: přečtení souvisejících souborů, vytvoření diffu, spuštění testů a označení [x]. Podagenty se podle potřeby volají automaticky: jeden pro kontrolu kódu, druhý pro spuštění linteru a třetí pro kontrolu regresí.

A samostatně také o pravidlech:

Ve Spec Kitu je tento cyklus formalizovaný. spec.md je zdroj pravdy, plan.md obsahuje technická rozhodnutí a tasks.md slouží jako kontrolní seznam. Pokud Claude v kterémkoli kroku odbočí, vrátíte se ke specifikaci a řeknete: „To neodpovídá FR-003; předělej to.“ Žádné dlouhé prompty typu „pamatuj, o čem jsme mluvili...“ — celá historie je v souborech.

Pokud jste propojili Dynamic Workflows v Opus 4.8, můžete Spec Kit nastavit do plně automatického režimu: jeden příkaz /speckit-implement a Claude paralelizuje práci, sloučí výsledky a zkontroluje je. Limit je 1000 podagentů současně. Pro většinu funkcí stačí 10–30.

Až budou všechna políčka [x] zaškrtnutá a kontrola v další části vrátí „Converged“, projděte PR (nebo řadu PR, pokud je úkolů mnoho) a sloučte ho. Artefakty — spec.md, plan.md, tasks.md — zůstanou v repozitáři jako dokumentace funkce. Za rok nebudete muset zpětně odvozovat její logiku z kódu.

Jak ověřit, že agent na nic nezapomněl (Converge)#

/speckit-converge

Nejprve agent shrne, co zjistil, a uvede úrovně závažnosti; potom nastane jeden ze dvou výsledků. „Converged“ znamená, že nebyly nalezeny žádné nedostatky, tasks.md zůstává bajt po bajtu beze změny a můžete přejít ke kontrole. „Tasks appended“ znamená, že byly nalezeny nedostatky, přidaly se do části Convergence v tasks.md a agent vám sdělí jejich počet.

Converge neupravuje ani nemaže kód; jediný zápis představují nové úkoly v tasks.md. Můžete ho tedy spustit bez obav, ale až poté, co /speckit-implement zpracoval aktuální tasks.md. Každý další průchod najde méně nedostatků.

Jak se Spec Kit liší od CLAUDE.md a Plan Mode?#

Porovnejme je podle 5 vlastností:

V terminologii Spec Kitu jde o .specify/memory/constitution.md. Při inicializaci může Spec Kit použít váš existující CLAUDE.md jako základ pro constitution, nebo vedle něj vytvořit samostatný soubor. Já obvykle nechávám CLAUDE.md jako globální „smlouvu“ (stack, glosář, protokol nasazení) a constitution Spec Kitu používám pro pravidla konkrétní funkce — například „všechny formuláře se ověřují přes Zod; žádné ruční kontroly“.

Vztah k Plan Mode je jednodušší. Plan Mode je rychlý režim „plánování před psaním kódu“ v rámci jediné relace. Hodí se pro malé změny (opravu chyby, refaktoring funkce). U velké funkce Plan Mode ztrácí výhodu, protože kontextové okno jediné relace je příliš malé pro plán o 3000 řádcích — jak vysvětluji přímo na živém setkání:

Spec Kit je konkrétní nástroj pro inženýrství kontextu. Přesouvá „architektonickou plachtu“ z chatu do souborů. Spec.md zůstává v repozitáři a každá nová relace Claude si ho znovu načte — nemusíte se opakovat.

Nastavení pro velký projekt:

1. CLAUDE.md – stack, glosář a co nedělat. Nachází se v kořenové složce.
2. .specify/memory/constitution.md pro Spec Kit — pravidla specifická pro tento pracovní postup.
3. specs/001-feature-A/spec.md, plan.md, tasks.md – první funkce.
4. specs/002-feature-B/spec.md, plan.md, tasks.md – druhá funkce.
5. Při každodenní práci použijte /speckit-implement (pro připravené úkoly) nebo /plan (rychlá kontrola před změnou).

Které případy z praxe fungují?#

Konkrétní případy:

• AWS Kiro — agent pro objevování léčiv. V příspěvku na blogu AWS Industries z 18. února 2026 tým popisuje projekt TargetID. Tři vývojáři, tři týdny, agent pro objevování léčiv. Čísla z článku: Kiro vygenerovalo více než 95 % kódu obchodní logiky a ušetřilo více než 80 hodin vývoje. Také: „Dokumentace README napsaná nástrojem Kiro nám ušetřila odhadem 8 hodin“ a „o 40 % méně cyklů promptů a oprav“.
• Rackspace Technology. Ve stejném blogovém příspěvku AWS Rackspace uvádí: „dokončili jsme práci odhadovanou na 52 týdnů za pouhé 3 týdny“ a „efektivita vzrostla o 90 %“. Nejde už o malou funkci — je to celý podnikový projekt.
• Růst GitHub Spec Kit. Do 31. května 2026 měl repozitář 107 000 hvězdiček. Toto tempo růstu jasně ukazuje, že přístup získává podíl na trhu.

Pro čtenáře to znamená, že tento přístup není teoretický: seriózní týmy ho už používají v produkci.

Kdy se Spec Kit NEHODÍ?#

Nevhodné č. 1 — drobné úpravy. Pokud je úkolem „přejmenovat proměnnou“, „opravit překlep v textu“ nebo „přidat log“, projít Specify → Plan → Tasks zabere déle než samotná úprava. U drobných úprav je rychlejší Plan Mode nebo prostý přímý prompt v Claude Code.

Nevhodné č. 2 — živé experimenty. Pokud ještě nevíte, co chcete, a potřebujete se „porozhlédnout“ v rozhraní nebo rychle sestavit prototyp, abyste zjistili, „jestli to funguje“, je specifikace zbytečná. Hodnota spočívá právě v improvizaci. Na úrovni „pohrávání si s nápadem“ funguje právě vibe, nikoli specifikace.

Nevhodné č. 3 — starší kód se složitým stavem. Silný protiargument: realita se mění rychleji než specifikace. Představte si fakturaci předplatného: tým popsal fakturační cykly a daňová pravidla, ale o týden později Finance požádaly o evropskou DPH — specifikace zastarala ještě před vydáním. Když se obchodní logika rychle vyvíjí, údržba specifikací se stává přítěží.

Dalším rizikem je falešný pocit kontroly. Zabývá se tím článek Martina Fowlera: struktury jsou elegantní, ale agenti často ignorují pokyny, nebo se naopak šablon drží příliš doslovně. Výsledkem je kód, který je správný po stránce struktury, ale nehodí se do vašeho konkrétního repozitáře — specifikace nezaručuje, že jí agent porozuměl tak, jak jste zamýšleli.

V dubnu 2026 varovali průmysloví analytici před vodopádovým přístupem: psát rozsáhlou specifikaci ještě před kódem je cesta, která už jednou potopila celé odvětví, v době dvousetstránkových požadavků. Inženýři jsou od té doby k tomuto přístupu obezřetní a oprávněně.

Co s tím. Navrhuji jednoduché pravidlo: porovnejte velikost funkce s časem potřebným k napsání specifikace. Pokud implementace funkce zabere méně než 2 hodiny, specifikaci nepište — rychlejší je Plan Mode. Pokud funkce zabere týden, Spec Kit rozhodně použijte; úspora času vám hodinovou specifikaci mnohonásobně vrátí. Mezi 2 hodinami a týdnem se rozhodněte sami, ale já osobně píšu specifikaci i pro funkce na půl dne, protože artefakt v repozitáři má větší hodnotu než ušetřených 30 minut.

Co dál: jak začlenit Spec Kit do projektu?#

Konkrétní plán na příštích 7 dní:

• Den 1. Nainstalujte uv a Spec Kit (5–10 minut). Ověřte, že se v Claude Code objevily příkazy /speckit-*. Nezkoušejte je použít na existující projekt — začněte novým.
• Den 2. Vyberte skutečnou funkci, kterou plánujete vytvořit. Spusťte /speckit-specify s volným popisem. Otevřete spec.md, přečtěte si ho a zodpovězte všechny značky [NEEDS CLARIFICATION]. S přechodem k Plan nespěchejte.
• Den 3. Spusťte /speckit-plan s nápovědou ohledně svého stacku. Přečtěte si plan.md, zejména část Architecture Decisions. Pokud vám něco nevyhovuje, upravte to ručně.
• Dny 4–5. Spusťte /speckit-tasks, potom /speckit-analyze, abyste zkontrolovali soubor se specifikací, plánem a úkoly, a pak /speckit-implement. Sledujte, jak Claude v tasks.md označuje [x]. Někde se může zaseknout — to je normální. Vraťte se do spec.md, upřesněte požadavek a znovu spusťte /speckit-implement s konkrétním úkolem. Až budou úkoly dokončené, spusťte /speckit-converge a opakujte posloupnost Implement a Converge, dokud neodpoví „Converged“.
• Dny 6–7. Zkontrolujte PR (nebo sérii PR). Sloučte ho. Přečtěte si spec.md a plan.md — budou dokumentací vaší funkce pro příští rok.

Co bych doporučil číst souběžně:

• Jak nastavit CLAUDE.md v roce 2026 — základ constitution ve Spec Kitu.
• Plan Mode v Claude Code — rychlá alternativa pro malé úkoly.
• Inženýrství kontextu v roce 2026 — proč Spec Kit vůbec funguje.
• Skills, Subagents, MCP nebo Plugins — co přidat ke Spec Kitu pro váš pracovní postup.
• Dynamic Workflows v Claude Code — jak ve fázi Implement spouštět mnoho podagentů současně.

Kompletní pracovní postup s kontextem: klon AI + Second Brain + inženýrství kontextu.

Další materiály najdete na Ailoot.