---
name: project
description: Skill se použije, když uživatel zadá "/project", nebo chce založit nový projekt v čistém adresáři, přenastavit už existující projekt (metadata projektu a jejich propsání do Repository details na GitHubu, git, worktree layout, standardní struktura docs/, autocommit, paměťová politika, typ projektu, doménové checklisty), anebo dorovnat dřív nastavený projekt na aktuální podobu standardů a konfigurační vrstvy – revize souladu struktury, dokumentace, sekcí CLAUDE.md, kontraktů a importů. Interaktivní wizard, který se ptá krok po kroku.
argument-hint: [create|adopt|update]
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]
---

# Project

## Co skill dělá

Interaktivně nastaví projekt v aktuálním adresáři a zapíše vše do projektového `CLAUDE.md`. Funguje ve třech režimech:

- **`create`** *(nový projekt)* – čistý adresář, všechno se zakládá od nuly.
- **`adopt`** *(existující projekt)* – adresář, ve kterém už něco je, ale chybí v něm otisk `/project` (blok metadat v `CLAUDE.md`) – ať proto, že skill v něm nikdy neběžel, nebo proto, že ho nastavovala starší verze. Zjistí se aktuální stav a nabídne se, co dorovnat na zvolené preference; nakonec proběhne i krok 14. Nic se nepřepisuje naslepo.
- **`update`** *(revize)* – projekt, který `/project` už jednou nastavil. Neptá se znovu na volby, které padly; místo toho **projde celý projekt proti aktuální podobě standardů** (`~/.claude/STRUCTURE.md`, `~/.claude/RULES.md`, doménové znalosti, konfigurační vrstva) a dorovná, co se mezitím rozešlo. Viz krok 14.

Režim **`update` je hlavní důvod, proč je skill opakovatelný.** Standardy a skilly se vyvíjejí dál, kdežto projekty založené za starého nastavení zůstávají stát – a rozdíl se z projektu sám nepozná. Druhý běh je tedy plnohodnotná kontrola, ne jen verifikace, že se nic nezměnilo.

## Co skill nedělá

- **Nepíše zadání ani plán.** Je první článek *Životního cyklu projektu* (`~/.claude/RULES.md`) a předává na `/discovery`, který zkoumá svět venku. Co se staví, řeší `/specify`, jak se to postaví `/architect`, rozpad na úkoly `/breakdown`. `docs/requirements.md`, `docs/architecture.md` ani `docs/plan.md` proto nezakládá.
- **Neprogramuje.** Ani scaffold, ani závislosti. Nastavuje projekt, ne aplikaci.
- **Nepřepisuje nic naslepo.** U existujícího projektu se na každý rozpor ptá.
- **Nenaplňuje soubory obsahem.** `docs/` zakládá prázdné, jen s nadpisem.
- **Nezapíná worktree layout sám.** Zvolí-li ho uživatel v kroku 4, provede se to, co `/worktree enable` – přeskládání adresáře a manipulace s `.git` jsou jeho věc, `/project` se jen ptá a zapisuje výsledek do `CLAUDE.md`.
- **Nemerguje ani neuklízí větve.** Ve worktree layoutu si větev na svou práci založí (krok 0), ale merge i úklid jsou na uživateli – zakládání větve je pravidlo layoutu, které instaluje `/worktree`, a dokončení větve vede `/merge`.
- **Nerediguje obsah dokumentace.** `update` hlídá **tvar** – kde soubor leží, jak se jmenuje, jak je uvnitř seřazený, jestli položka sedí do souboru, ve kterém je. Jestli je zapsané rozhodnutí správné nebo úkol dobře napsaný, neřeší; od toho jsou `/consistency` a `/review`.

## Zásady pro celý průběh

- **Postup se tu člení na kroky, ne na fáze** – jako v jediném skillu životního cyklu. Kritérium normy (`~/.claude/skills/SKILLS.md`, *Číslování a názvosloví*) zní, čí odpovědi tvoří výsledek: tady je výsledkem to, co uživatel naodpovídal, takže postup je sled otázek. Ostatní skilly něco samy najdou nebo vyrobí a ptají se až na nálezy – ty mají fáze, i když se ptají stejně často. Číslují se **plochou vzestupnou řadou bez písmen** (`~/.claude/skills/SKILLS.md`, *Číslování a názvosloví*). Kroky 5–8 zakládají standardní strukturu a byly kdysi jedním krokem s podkroky `6a`–`6c`; kritériu normy pro písmennou podfázi ale nevyhověly – jsou to fáze jedné volby, ne samostatné výstupy –, tak se z nich staly samostatné kroky.
- **Ve worktree layoutu nepracuj v `main/`.** Přijdeš-li do projektu, který ten layout **už má**, zapisuj do vlastní větve a jejího worktree – viz krok 0, *Nejdřív zjisti, kde stojíš*. Zakazuje to `~/.claude/WORKTREE.md`, *`main/` se nemaže a nepracuje se v něm*, a pro `/project` to platí dvojnásob: přepisuje `CLAUDE.md`, `README.md` a celé `docs/` – tedy soubory, které mají ostatní session rozečtené a rozepsané. (Zapíná-li layout teprve tenhle běh, výjimku a důvod má krok 0.)
- **Otázky pokládej jednu po druhé**, ne všechny najednou. U pevné sady možností použij **AskUserQuestion**, u otevřených otázek (popis projektu, URL remote) se ptej v chatu a počkej na odpověď.
- **Dvourychlostní režim.** Mechanické a jednoznačné věci udělej rovnou a jen je vypiš (založení chybějícího souboru, doplnění chybějící sekce). Sporné předlož uživateli – zejména cokoliv, co **přepisuje nebo maže existující obsah**.
- **Nikdy nepřepiš existující soubor bez zeptání.** Chybí-li soubor, založ ho. Existuje-li a je v rozporu se zvolenou preferencí, ukaž rozdíl a zeptej se.
- **V režimu `update` se na hotové volby neptej znovu.** Co je v `CLAUDE.md` zapsané a dává smysl, platí. Otázka se pokládá jen tam, kde `update` našel rozpor nebo mezeru – a klade se o tom rozporu, ne o celém kroku.
- Konvenci standardní struktury **neopisuj z hlavy** – řiď se `~/.claude/STRUCTURE.md`, který ji definuje. Tenhle skill je jen instalátor.

------

## Krok 0 – Zjisti režim a stav

**Společný začátek drží `~/.claude/skills/PREFLIGHT.md`**, ale tenhle skill se od něj v jednom bodě **vědomě odchyluje**: bod 1 velí skillu, který git potřebuje, skončit, není-li to git repozitář – kdežto tady je prázdný adresář bez `.git` legitimní vstup, protože je to režim `create` a repozitář teprve zakládá. Zbytek bodu 1 (rozpoznání worktree layoutu) a bod 2 platí; body 3 až 5 odpadají, protože nad projektem, který teprve vzniká, není co kontrolovat ani diffovat.

### Nejdřív zjisti, kde stojíš

**Ve worktree layoutu** – kontejner s `.bare/` a jedním pracovním adresářem na větev (`~/.claude/WORKTREE.md`) – platí dvě věci, které mění zbytek běhu. Zjisti je **dřív než cokoliv jiného**: obojí rozhoduje o tom, kde budeš hledat i kam budeš psát.

**1. Vylez ke kontejneru.** Session se sice pouští z jeho kořene, ale `/project` se často volá i z `main/` nebo z worktree rozdělané větve – tam vedle souboru `.git` **žádné `.bare/` není**, takže bys layout vyhodnotil jako obyčejný repozitář a psal rovnou do `main/`. Rozliš podle `~/.claude/WORKTREE.md`, *Jak si skill najde projektový adresář*, a jdeš-li nahoru, řekni to nahlas. Jmenuje-li se hlavní větev jinak než `main`, její pracovní adresář zjistíš z `git --git-dir=<container>/.bare worktree list` a všechna „`main/`“ níž čti jako ji.

**2. Nepiš do `main/`, ale do vlastní větve.** `main/` je sdílený a slouží ke čtení – zakazuje to `~/.claude/WORKTREE.md`, *`main/` se nemaže a nepracuje se v něm*. Větev zakládej **líně, až u prvního zápisu**: inventura v tomhle kroku i revize v kroku 14 jsou čtení, takže běh, který nic nenajde, po sobě nenechá prázdnou větev ani naklonované `node_modules`. **Zápis je každá změna souboru v repozitáři** – nastavení mimo git (popisek v Repository details, souhlas se průběžnou kontrolou) větev nevyžaduje. Jakmile se má poprvé něco změnit:

```bash
git -C <container> worktree add <container>/project-update -b docs/project-update
```

- **Jméno podle režimu** – `docs/project-update`, `docs/project-adopt`. Prefix je vždycky `docs/`: skill nesahá na kód, jen na dokumentaci a konfiguraci.
- **Existuje-li větev z minulého běhu**, pokračuj v ní: má-li worktree, přejdi do něj; nemá-li ho, `worktree add` **bez `-b`** (s ním by to spadlo na `branch already exists`).
- Ověř, že hook převzal lokální stav z `main/` podle `~/.claude/WORKTREE.md`, *Lokální stav se bere z `main/`*, a přejdi do nového adresáře – **od téhle chvíle je projektovým adresářem on** (viz níž). Pozor na cesty, které máš přečtené z `main/`: číst se smí odtamtud, zapisovat se musí do větve.
- **Na konci práci ve větvi commitni**, i když projekt autocommit nemá: necommitnutá práce ve větvi merge zastaví (`/merge`).
- **Nemerguj.** Větev zůstane otevřená a merge je na výslovný pokyn uživatele (`~/.claude/WORKTREE.md`, *Větev žije, dokud uživatel neřekne jinak*). V kroku 15 jen řekni, jak se jmenuje.

**Zakládá-li worktree layout teprve tenhle běh** (krok 4 v režimu `create` nebo při konverzi), pravidlo se neuplatní: kontejner právě vzniká, žádná jiná session v něm neběží, takže zbytek běhu píše rovnou do `main/`.

### Projektový adresář

Pojem, na který se odkazuje zbytek skillu: **adresář, ve kterém leží `CLAUDE.md`, `README.md`, `docs/` a `.gitignore` tohohle projektu.**

| Kde běžíš | Projektový adresář |
|---|---|
| běžný repozitář | jeho kořen |
| worktree layout, čteš | `main/` |
| worktree layout, zapisuješ | pracovní adresář větve z bodu 2 výš |

Kořen kontejneru to **není nikdy** – nic v něm není ve gitu. Patří do něj jen rozcestník `CLAUDE.md` a `.claude/settings.local.json` (viz krok 4).

Pomocí **Glob** (ne Bash `git`, aby nenaskočila zbytečná chybová hláška) zjisti, co v adresáři je:

- `.git`, `.bare`, `README.md`, `.gitignore`,
- `CLAUDE.md` **i `main/CLAUDE.md`** – ve worktree layoutu je v kořeni jen rozcestník bez bloku metadat, takže otisk hledej v `main/` (viz *Projektový adresář* výš),
- standardní soubory **na obou možných místech**: `docs/todo.md` i kořenový `todo.md`, totéž pro `backlog.md`, `decisions.md`, `done.md` a `rules.md` – podle toho se v kroku 5 pozná režim,
- starší pojmenování `TODO.md` v kořeni,
- zdrojové soubory.

- **Prázdný nebo skoro prázdný adresář** → režim `create`.
- **Projekt, kterým už `/project` prošel** → režim `update`. Poznáš ho podle **bloku metadat na začátku projektového `CLAUDE.md`** – řádku `- **Slug:**`. Ten blok nezakládá nic jiného, takže je to spolehlivý otisk. Pokračuj krokem 14.
- **Cokoliv jiného** → režim `adopt`.

Řekni nahlas, který režim to je a podle čeho jsi to poznal. Trvá-li uživatel na plném průchodu průvodcem i nad nastaveným projektem, ber to jako pokyn a jeď režim `adopt`.

V režimech `adopt` i `update` si nejdřív udělej inventuru a **vypiš ji uživateli v pár řádcích**, ať oba víte, z čeho se vychází:

| Co zjistit | Jak |
|---|---|
| Git a jeho podoba | je `.git` adresář (běžný), nebo `.bare` + `.git` soubor (worktree layout)? má remote – ověř `git remote get-url origin`, ne `git remote`, který hlásí `origin` i tam, kde je jen sekce bez adresy, třeba z globálního `~/.gitconfig`? |
| Projektový `CLAUDE.md` | existuje? co v něm už je (autocommit, paměť, typ, importy)? |
| Standardní struktura | existuje `README.md`, `todo.md`, `backlog.md`, `done.md`, `decisions.md`, `rules.md` – a **kde**, v `docs/` nebo v kořeni? (určuje režim, viz krok 5) |
| *(worktree layout)* rozdělení souborů | leží projektové soubory v `main/`, nebo omylem v kořeni kontejneru? je v kořeni rozcestník s `@main/CLAUDE.md`? |
| Starší pojmenování | existuje `TODO.md` v rootu, `rozhodnuti.md`, `zasady.md` (na místě podle režimu z kroku 5)? (viz krok 5) |
| Typ projektu | odvoď z obsahu – `package.json`, zdrojové adresáře, převaha MD souborů |

*`adopt`:* pak řekni, že se teď budeš ptát postupně, a pokračuj krokem 1. V dalších krocích platí: **co už je nastavené a odpovídá volbě, nech být a jen to zmiň.** *`update`:* neptej se na nic a pokračuj krokem 14.

## Krok 1 – Metadata projektu

Formát bloku metadat definuje `~/.claude/STRUCTURE.md`, sekce *`CLAUDE.md`* – **neopisuj ho z hlavy, přečti si ho.** Řeší se čtyři údaje: **slug**, **lidský název**, **popisek** a **URL projektu**.

Slug je daný adresářem. Zbylé tři **navrhni sám** – u nového projektu z toho, co ti uživatel řekl, u existujícího z toho, co v repozitáři najdeš (`CLAUDE.md`, `README.md`, `package.json`, obsah). Předlož návrh k odsouhlasení, ať ho uživatel může jen potvrdit, nebo přepsat:

```
- **Slug:** rezervace
- **Název:** Rezervační systém
- **Popisek:** Rezervační systém pro školení, konference a webináře – správa událostí, účastníků, objednávek a faktur.
- **Web:** (žádný)
```

Vypisuj to jako **Markdown, ne jako blok kódu**, a řádky nezalamuj natvrdo – `~/.claude/RULES.md`, *Styl odpovědí*.

Zeptej se v chatu (ne AskUserQuestion – jde o volný text) a počkej na odpověď. **Nic si nevymýšlej**: nevíš-li, jestli projekt má veřejnou URL, zeptej se místo hádání.

*`adopt`:* najdeš-li v `CLAUDE.md` nebo `README.md` popis, který už platí, nabídni ho beze změny. Rozcházejí-li se popisy v `CLAUDE.md` a `README.md`, ukaž oba a nech rozhodnout, který je pravda.

## Krok 2 – Založení nebo doplnění CLAUDE.md

**Existuje-li už worktree layout** (z inventury v kroku 0, nebo protože ho zvolíš v kroku 4), je „projektový `CLAUDE.md`“ ten v **projektovém adresáři** – viz krok 0, *Projektový adresář*, a krok 4. U nového projektu, kde se o layoutu rozhoduje až v kroku 4, zapiš zatím do kořene; krok 4 soubor přesune.

Zapiš blok metadat na **začátek** `CLAUDE.md`, ve formátu podle `STRUCTURE.md`:

```
# Rezervační systém

Rezervační systém pro školení, konference a webináře – správa událostí, účastníků, objednávek a faktur.

- **Slug:** `rezervace`
- **Struktura:** docs/
- **Web:** https://rezervace.example.cz
- **Repozitář:** https://github.com/jantichy/rezervace
```

Řádky `Web` a `Repozitář` vynech, pokud neexistují. `Repozitář` doplň v kroku 3, jakmile je remote známý.

*`adopt`:* nezakládej znovu, doplňuj do stávajícího. Má-li soubor generický nadpis (`# CLAUDE.md`) nebo popis rozsypaný v sekci `## Projekt`, **navrhni jeho nahrazení blokem metadat** – ukaž rozdíl a nech si to potvrdit. Sekce, které přidávají další kroky, vkládej za stávající obsah; existující sekce téhož jména neduplikuj, ale aktualizuj.

## Krok 3 – Git

Zeptej se (AskUserQuestion), 4 možnosti:

- **Nic** – git se neřeší, přeskoč i kroky 4 a 7.
- **Jen lokální** – `git init`, žádný remote.
- **Remote (napojit na existující)** – `git init`, pak se v chatu zeptej na URL a spusť `git remote add origin <url>`.
- **Remote (založit nový)** – `git init`, pak AskUserQuestion na hostitele (GitHub / GitLab). U GitHubu s dostupným `gh` (`which gh`) se zeptej na viditelnost a spusť `gh repo create <directory-name> --private|--public --source=. --remote=origin`. Jinak vypiš instrukci „Založ prázdné repo na <platforma>, pak mi dej URL“ a počkej.

*`adopt`:* je-li git už inicializovaný, `git init` nespouštěj. **Ověř remote přes `git remote get-url origin`**, ne jen `git remote -v` – remote může existovat s prázdnou URL a `-v` to nepozná. Chybí-li nebo je-li rozbitý, nabídni doplnění.

### Propsání metadat do Repository details

*Jen u GitHubu s dostupným `gh`.* Description a website repozitáře nejdou nastavit souborem v repu – jsou to metadata na straně GitHubu. Propiš tam popisek a URL z kroku 1:

```bash
gh repo edit <owner>/<slug> -d "<description>" -h "<web>"
```

Nejdřív si přes `gh repo view <owner>/<slug> --json description,homepageUrl` **zjisti současný stav**. Liší-li se od popisku z kroku 1, ukaž rozdíl a přepiš. Je-li shodný, nech být a jen to zmiň. Web se nepředává, když projekt žádný nemá – prázdné `-h ""` existující hodnotu smaže.

Do bloku metadat v `CLAUDE.md` zároveň doplň řádek `Repozitář` s URL remote.

U GitLabu a jiných hostitelů tenhle krok přeskoč a řekni uživateli, že popisek si tam musí nastavit ručně.

## Krok 4 – Layout repozitáře

*Jen pokud v kroku 3 padla jiná volba než „Nic“.*

Zeptej se (AskUserQuestion): jak má být projekt rozbalený na disku?

- **Jeden pracovní adresář (jednoduché)** – klasika: `.git` a rozbalený projekt přímo v adresáři. Vhodné, když nad projektem pracuješ vždy v jedné session.
- **Worktree layout (paralelní práce)** – kontejner s `.bare` a jedním pracovním podadresářem na větev. Vhodné, když chceš nad projektem běžet ve víc Claude session naráz, aniž si přepisují soubory. Popis viz `~/.claude/WORKTREE.md`.

### Když padne worktree layout

**Postup zřízení kontejneru neopisuj z hlavy** – proveď totéž co `/worktree enable` (viz `~/.claude/skills/worktree/SKILL.md`). Má variantu pro nový projekt i pro konverzi existujícího repozitáře, včetně povinné zálohy, ověření diffem a úklidu zamrzlého `.bare/index`, a sám zapíše rozcestník do kořene kontejneru.

U existujícího projektu jde o **přeskládání adresáře** – řekni to nahlas a nech si ho potvrdit, než začneš.

### Dva `CLAUDE.md` – tohle si přečti pozorně

Ve worktree layoutu jsou `CLAUDE.md` **dva** a mají různý účel. Zaměnit je je nejčastější chyba tohohle skillu, protože kořen kontejneru **není pracovní strom** – nic v něm není ve gitu a nikdy to nepůjde commitnout.

| Soubor | Co v něm je | Píší do něj kroky |
|---|---|---|
| `<container>/CLAUDE.md` (kontejner) | jen popis layoutu, odchylky a import toho druhého | pouze tenhle krok 4 |
| projektový `CLAUDE.md` (v `main/`, nebo ve tvé větvi) | všechno ostatní – metadata, struktura, autocommit, paměť, typ, příkazy, doménové importy | každý krok, který něco zapisuje: 2 a 3 (metadata), 5 a 7 (struktura), 9–13, a dorovnání ve 14 |

**Kdykoli dál v tomhle skillu čteš „projektový `CLAUDE.md`“, myslí se ten v projektovém adresáři** (krok 0, *Projektový adresář*) – tedy v `main/`, nebo ve tvé větvi, zapisuješ-li. Totéž platí pro `README.md`, `docs/*` a `.gitignore`; do kořene kontejneru nepatří ani jeden z nich. Jedinou výjimkou je `.claude/settings.local.json`: ten patří do **kořene kontejneru**, protože odtud se pouští session a odtud si ho Claude Code čte. Tenhle skill ho **nezakládá** – vznikal v kroku, který zmizel se zrušeným autopromptem –, ale existuje-li, patří tam.

Do `<container>/CLAUDE.md` (do **kontejneru**) patří **jen rozcestník** a nic víc. Zapsal ho už `/worktree enable` a jeho znění drží `~/.claude/skills/worktree/SKILL.md` – neopisuj ho odsud znovu. Doplň do jeho sekce *Odchylky* to, co víš o tomhle projektu: jestli se hlavní větev jmenuje jinak než `main` (u staršího projektu) a co konkrétně se přebírá z `main/`, nebo že zatím není co.

Import `@main/CLAUDE.md` ve rozcestníku je nutný: `CLAUDE.md` z podadresáře se načte až on-demand, když z něj něco čteš, kdežto session startuje v kontejneru. Bez importu by pravidla projektu na začátku session vůbec nebyla v kontextu. Relativní cesta se resolvuje vůči souboru, který import obsahuje.

**Pravidla projektu do rozcestníku nekopíruj.** Dvě kopie se rozejdou a načtou se pak obě.

*`create`:* krok 2 už `CLAUDE.md` založil v kořeni, protože tehdy ještě nebylo rozhodnuto o layoutu. **Přesuň ho teď do `main/`** (`mv <container>/CLAUDE.md <container>/main/CLAUDE.md`) a v kořeni na jeho místo napiš rozcestník. Totéž udělej s čímkoli dalším, co v kořeni mezitím vzniklo a patří do projektu.

*Konverze existujícího projektu:* původní `CLAUDE.md` se přesunul do `main/` spolu se zbytkem repozitáře a **je správně tam** – nech ho být, jen do něj dál doplňuj. V kořeni založ nový, prázdný rozcestník.

Po tomhle kroku si **ověř výsledek** a vypiš ho uživateli: v kořeni smí být jen `.bare/`, `.git`, `CLAUDE.md` (rozcestník), `.claude/` a pracovní adresáře větví; `README.md`, `docs/` a projektový `CLAUDE.md` musí být v projektovém adresáři (u nově zakládaného layoutu `main/`).

Upozorni uživatele, že **při příštím spuštění dostane dialog na schválení externího importu a musí ho odsouhlasit** – při odmítnutí se importy pro ten projekt trvale vypnou a dialog se už neukáže.

### Náprava špatně rozděleného kontejneru

*`adopt`, kde worktree layout už je.* Najdeš-li v kořeni kontejneru projektové soubory, které tam nepatří – plnohodnotný `CLAUDE.md` s pravidly místo rozcestníku, `README.md`, `docs/` – nabídni nápravu: přesun do projektového adresáře a nahrazení kořenového `CLAUDE.md` rozcestníkem. Je to zápis, takže tady vzniká větev podle kroku 0, *Nejdřív zjisti, kde stojíš*, běžíš-li ještě nad `main/`. Ukaž konkrétní seznam souborů a nech si to potvrdit, protože jde o přesouvání obsahu.

Existují-li oba `CLAUDE.md` a mají překrývající se sekce, **obsah slouč do projektového `CLAUDE.md`** a v kořeni nech jen rozcestník; nikdy jeden z nich mlčky nepřepiš.

Přesun je `git mv` jen tehdy, je-li zdroj verzovaný – v kořeni kontejneru **nikdy není**, takže tam jde o obyčejný `mv`. Po přesunu je v projektovém adresáři commitni.

## Krok 5 – Standardní struktura: režim umístění

Kroky 5 až 8 zakládají standardní strukturu. **Řiď se `~/.claude/STRUCTURE.md`** – ten je autoritativní, tyhle tři kroky jsou jen provedení.

Standardní soubory leží buď v `docs/`, nebo přímo v kořeni projektu. Obojí je rovnocenné.

*`create`:* zeptej se (AskUserQuestion, jedna otázka):

| Volba | Popis pro uživatele |
|---|---|
| `docs/` (výchozí) | Meta-vrstva odděleně od vlastní práce. Sedí na projekt s kódem nebo obsahem. |
| `root` | Soubory přímo v kořeni. Sedí na knowledge base a malé projekty, kde by `docs/` byl prázdný obal. |

*`adopt`:* režim **detekuj a rovnou zapiš**, neptej se. Leží-li `todo.md` nebo `decisions.md` v kořeni → `root`; leží-li v `docs/` → `docs/`; nenajdeš-li ani jedno → `docs/`. Co jsi zjistil a zapsal, **řekni nahlas** v závěrečném souhrnu. Najdeš-li soubory na obou místech, je to nepořádek, ne třetí režim – vypiš, co je kde, a nech si vybrat, na který režim to srovnat.

**Ve worktree layoutu** se tím vším myslí projektový adresář – `main/`, nebo tvá větev –, ne kořen kontejneru (krok 0, *Projektový adresář*).

Zapiš do bloku metadat v `CLAUDE.md`, za řádek `Slug`:

```
- **Struktura:** docs/
```

## Krok 6 – Standardní struktura: které soubory založit

Povinný je jen `CLAUDE.md`. U zbytku se zeptej (AskUserQuestion, `multiSelect: true`, vše předvybrané):

| Soubor | Popis pro uživatele |
|---|---|
| `README.md` | Co projekt je, pro člověka. U privátního projektu bez publika nemusí být. |
| `todo.md` + `backlog.md` + `done.md` | Fronta rozhodnutých úkolů, zásobník nezávazných nápadů a záznam hotového. **Jedna volba pro všechny tři** – samostatně nedávají smysl. |
| `decisions.md` | Co jsme rozhodli a proč, včetně zamítnutých variant. |
| `rules.md` | Principy, ve kterých se projekt pohybuje. |

Nezaložený soubor **není odchylka** – vznikne, až bude potřeba. Do `CLAUDE.md` (krok 7, *Zápis*) vypiš jen ty, které vznikly.

`requirements.md`, `architecture.md` a `plan.md` **nezakládej**, vznikají prací přes `/specify`, `/architect` a `/breakdown`.

### Produktové podklady

Druhá otázka, **jen u projektu, kde se staví produkt** – ne u konfiguračního repozitáře, znalostní báze pro sebe ani jednorázového nástroje. Jejich definici drží `~/.claude/STRUCTURE.md`, *Produktové podklady*; tady se jen vybírá.

`AskUserQuestion`, `multiSelect: true`, **nic předvybrané** – opačně než u standardních souborů. Většina projektů nemá ani jeden a předvybraný seznam by je odklikl všechny:

| Soubor | Popis pro uživatele |
|---|---|
| `demand.md` | Proč to vůbec stavět – kdo má ten problém, jak ho dnes řeší a čím je doložené, že ho chce řešit jinak. Má smysl i u interního nástroje a zakázky. |
| `competition.md` | Kdo je konkurence, co umí, za kolik – a čím se proti nim vymezíme. Nemá smysl u interního nástroje ani zakázky. |
| `risks.md` | Co je na produktu rizikové a co se kvůli tomu v návrhu změní. |
| `scenarios.md` | Co s produktem uživatel dělá, krok za krokem. Slouží i testování, nápovědě a FAQ. |
| `glossary.md` | Jak se v téhle doméně čemu říká. Vyplatí se, plete-li se víc entit naráz. |
| `pricing.md` | Tarify, limity, trial, co po expiraci – jen u produktu, který se prodává. |

**`operation.md` se tady nevybírá a není to opomenutí.** Zakládá ho až první běh `/evaluate` nad nasazeným projektem – dokud není co nasadit, není o čem rozhodovat, a závazek vést podklad o provozu by u projektu před prvním vydáním nic neznamenal. Ostatní podklady jsou naopak rozhodnutí, které se dá udělat hned.

**Soubory nezakládej.** Prázdný `competition.md` předstírá úvahu, která se nestala. Vybrané jen **zapiš do `CLAUDE.md`** (krok 7, *Zápis*) jako závazek; vzniknou prací v `/discovery` a `/specify`, a `/cleanup` pak podle toho seznamu pozná chybějící dokument od nechtěného.

*`adopt` a `update`:* co už existuje, ber jako zvolené. Existuje-li soubor, který v `CLAUDE.md` zapsaný není, doplň zápis; je-li zapsaný a nevznikl, zmiň to a nech rozhodnout, jestli se čeká, nebo se závazek ruší.

*`adopt`:* co už existuje, ber jako zvolené; ptej se jen na to, co chybí.

## Krok 7 – Standardní struktura: obsah

`README.md` u nového projektu: nadpis s **lidským názvem** a popiskem z kroku 1 jako prvním odstavcem – tam se popisek smí rozvést do víc vět. U existujícího projektu zkontroluj, že nadpis a první odstavec sedí s blokem metadat v `CLAUDE.md`; rozcházejí-li se, srovnej je. Soubory v `docs/` zakládej **prázdné, jen s nadpisem** – obsah nevymýšlej dopředu.

**README je pro člověka, ne pro Clauda.** Definici, co do něj patří a co ne, má `~/.claude/STRUCTURE.md`, sekce `README.md`; drž se jí doslova. U existujícího projektu README **projdi celé** a co je normativní pokyn pro Clauda – pravidla práce v repozitáři, konvence pojmenování, povinnost něco udržovat, odkaz na to, čím se má Claude řídit – přesuň do `CLAUDE.md`, `docs/rules.md` nebo `docs/decisions.md` podle povahy. Nekopíruj, přesouvej: informace má žít na jednom místě.

### Migrace staršího pojmenování

*`adopt`:* najdeš-li starší varianty, nabídni přejmenování přes AskUserQuestion (jedna otázka na všechny nálezy dohromady, protože jde o jedno rozhodnutí):

| Staré | Nové |
|---|---|
| `TODO.md` v rootu | `todo.md` na místě podle režimu |
| `rozhodnuti.md` | `decisions.md` |
| `zasady.md` | `rules.md` |
| `prd.md` | `requirements.md` |
| `design.md` | `architecture.md` |

Cílové umístění se řídí režimem z kroku 5. `TODO.md` velkými písmeny v kořeni **není** režim `root` – je to staré pojmenování, které se migruje tak jako tak.

Přejmenovávej přes `git mv`, ať se zachová historie. Po přejmenování **projdi celý repozitář a aktualizuj všechny odkazy** na staré názvy – v `CLAUDE.md`, `README.md`, dokumentaci i komentářích. Existuje-li cílový soubor už taky, obsah **slouč** a na sloučení upozorni; nikdy nepřepisuj.

### Zápis do CLAUDE.md

Přidej sekci – konkrétní deklaraci, ne opis konvence:

Vypiš **jen soubory, které v projektu opravdu jsou**, s cestou podle zvoleného režimu:

```
## Struktura a dokumentace

Projekt drží standardní strukturu podle `~/.claude/STRUCTURE.md`:

- `README.md` – co projekt je, pro člověka (ne instrukce pro Clauda)
- `docs/todo.md` – co je odložené na později, ale rozhodnuté, že se to udělá
- `docs/backlog.md` – nezávazné nápady, o kterých se nerozhodlo; vybírá se z nich, když se řeší, co dál
- `docs/done.md` – co je hotové
- `docs/decisions.md` – co jsme rozhodli a proč, včetně zamítnutých variant
- `docs/rules.md` – principy, ve kterých se projekt pohybuje

Všechny tyhle soubory **aktualizuj průběžně sám a bez vyžádání**, ve chvíli, kdy rozhodnutí padne, princip se vybrousí nebo se něco odloží. Nečekej na konec session ani na `/cleanup`.
```

Vybral-li uživatel v kroku 6 nějaké **produktové podklady**, připoj pod ten seznam druhý – i u těch, které ještě nevznikly. Je to závazek, ne inventura:

```
**Produktové podklady**, které tenhle projekt vede (zakládají se prací, ne dopředu):

- `docs/demand.md` – proč to stavíme, čím je poptávka doložená a jaký je verdikt (`/discovery`)
- `docs/competition.md` – kdo je konkurence, co umí a jaká je proti nim naše pozice (`/discovery`)
- `docs/risks.md` – co je na produktu rizikové a co se kvůli tomu v návrhu změnilo (`/discovery`)
- `docs/scenarios.md` – co s produktem uživatel dělá, krok za krokem (`/specify`)

Platí pro ně táž povinnost průběžné aktualizace jako pro soubory výš.
```

Nevybral-li žádný, **sekci nezakládej** – prázdný nadpis tvrdí, že se na to zapomnělo.

## Krok 8 – .gitignore

*Jen pokud v kroku 3 padla jiná volba než „Nic“.* Chybí-li `.gitignore`, založ ho s tímto jádrem a dopiš podle zjevného stacku:

```
.DS_Store
.env
.env.local
node_modules/
dist/
build/
.next/
out/
.vercel
*.log
.idea/
.vscode/
.claude/run/
```

`.claude/run/` je běhový stav přerušitelných skillů (`~/.claude/STRUCTURE.md`, *Běhový stav skillů*). **Řádek doplň i do existujícího `.gitignore`**, který ho ještě nemá – mění se po každé odpovědi, takže v projektu se zapnutým autocommitem by se donekonečna commitoval. Zbytek existujícího souboru nech být.

Existuje-li, **nepřepisuj ho** – jen doplň chybějící řádky z jádra a vypiš, co jsi přidal.

## Krok 9 – Autocommit

Zeptej se (AskUserQuestion): zapnout autocommit? Ano/Ne. Při ano proveď totéž co `/autocommit enable` (viz `~/.claude/skills/autocommit/SKILL.md`).

*`adopt`:* nejdřív **zjisti aktuální stav** – hledej sekci `Autocommit` v projektovém `CLAUDE.md` **bez ohledu na úroveň nadpisu** (`##` i `###`) a bez ohledu na to, pod čím je zanořená. Aktuální stav uveď v otázce, ať uživatel ví, co mění. Je-li zapnutý, ale zapsaný jinak než nadpisem `## Autocommit` v nejvyšší úrovni – typicky podnadpisem pod zaniklou sekcí `## Automatické akce` –, **srovnej ho na dnešní tvar** a řekni to. Jinak ho `/autocommit` příště nenajde a bude ho hlásit jako vypnutý.

    **Totéž udělej, chybí-li v sekci řádek `@~/.claude/skills/autocommit/autocommit.md`** – bez něj je to přepínač, který nic nespíná, protože pravidla commitování se do projektu dostanou jedině tím importem.

## Krok 10 – Paměťová politika

Zeptej se (AskUserQuestion): „Má Claude v tomto projektu ukládat poznatky do trvalé Memory, nebo vše explicitně do lokálních .md souborů?“ Možnosti: **Jen lokální .md soubory (doporučeno)** / **Normální chování (Memory povolena)**.

Při první volbě přidej do `CLAUDE.md`:

```
## Paměť

Neukládej nic do trvalé Memory (`~/.claude/projects/.../memory/`). Vše, na čem se domluvíme – rozhodnutí, kontext, poznámky – ukládej explicitně do souborů projektu podle `~/.claude/STRUCTURE.md`. Ty jsou jediný zdroj pravdy pro tento projekt, i když harness bude nabádat k zápisu do Memory.
```

## Krok 11 – Typ projektu

**Katalog typů, jejich popisy a doplňující otázku u typu *Vývoj* drží [`types.md`](types.md).** Načti si ho a řiď se jím; je tam i to, co dělat, až se dvouúrovňová otázka zaplní.

Do `CLAUDE.md` z něj vzejde sekce `## Typ projektu` s krátkým popisem. **Kroky životního cyklu do něj nevypisuj**, odkaz na *Životní cyklus projektu* v `~/.claude/RULES.md` stačí – je to zvláštní případ pravidla *Neopisuj seznam, který má vlastní zdroj pravdy* (`~/.claude/skills/SKILLS.md`, *Jak se píše text uvnitř*).

## Krok 12 – Kontrakt příkazů a kontrolní vrstvy

**Tenhle krok se nepřeskakuje podle typu projektu.** Dřív se u obsahového a znalostního projektu vynechával celý, protože „kontrakt tam nemá co dělat“ – to bylo špatně. Testovat jde i projekt bez aplikace: netestuje se chování, ale **tvar** – mrtvé odkazy, existence sekcí, povinná struktura záznamu, schéma dat a soulad seznamu v dokumentaci s tím, co je na disku. Doklad je `~/.claude`, konfigurace bez jediné aplikace a s nejsilnější kontrolní vrstvou ze všech projektů.

Liší se tedy **co se vybere**, ne jestli se krok udělá. Rozhoduj podle `~/Dev/context/coding/quality.md`, *Vrstvy kontroly a co do které patří*: u vývojářského projektu bývá celý kontrakt a CI, u znalostního typicky jen `test` a `lint` nad vlastní strukturou. **Nemá-li projekt opravdu co spustit ani čím, řekni to i s tím, co tím odpadá** – to je legitimní výsledek, ale musí být výsledkem rozhodnutí, ne přeskočení.

**Kam patří soubory s testy**, říká `~/.claude/STRUCTURE.md`, *Testy*; řídí se runnerem projektu, ne preferencí.

**Návrh napiš sám, uživatel ho jen potvrdí.** Přečti `package.json` (`scripts`), `composer.json`, `Makefile` nebo obdobu a vyplň, co projekt opravdu má. **Nevymýšlej příkazy, které v projektu nejsou** – řádek, který nikam nevede, je horší než chybějící řádek.

Zapiš do projektového `CLAUDE.md` sekci `## Kontrakt příkazů` a **jen ty klíče, které projekt opravdu umí spustit**; u klíče, který chybí, napiš pod seznam, co tím odpadne. Vypiš uživateli příkaz `~/.claude/verify.sh --allow <project-directory>` a nech ho spustit **jeho** – souhlasem se zapíná kontrola, která nepustí Clauda ukončit práci nad červeným stavem, a spustit si ji za něj by ji zbavilo smyslu. Ve worktree layoutu vypiš `main/` nebo svou větev, **nikdy kořen kontejneru**: souhlas se počítá z `git rev-parse --git-common-dir`, takže z kteréhokoliv worktree platí pro celý repozitář, ale v kořeni kontejneru žádný kontrakt neleží.

*`adopt`:* **má-li projekt kód, ale žádné testy** (kontrakt bez `test`, nebo `test`, který nic nespouští), zapiš do jeho `todo.md` jako **první položku** charakterizační testy podle `~/Dev/context/coding/quality.md`, *Převzatý kód bez testů* – zmapovat klíčové moduly, zachytit dnešní chování v pořadí podle citlivých míst, teprve pak měnit. Řekni to v souhrnu: do té doby je průběžná kontrola zelená z prázdnoty.

**Šablonu sekce, význam klíčů, mechaniku průběžné kontroly, založení CI i to, co se nenastavuje příkazem, ale konfigurací** (přísnost překladače, metriky složitosti, `.semgrep/`, LSP plugin, zákazy), **drží `~/.claude/skills/project/checks.md`.** Řiď se jím; prahy jsou v `~/Dev/context/coding/quality.md`.

## Krok 13 – Doménové checklisty

Zeptej se **ve třech tematických kolech** (`multiSelect: true`, nejvýš čtyři volby na kolo), co všechno se v projektu bude dělat, a vybrané doménové znalosti zapiš do projektového `CLAUDE.md` jako **tvrdé `@import`y**, ne jako odkazy v běžném textu. Volby předvyplň podle typu z kroku 11, ale nech rozhodnout uživatele – vývojářský projekt bývá zároveň web, web bývá zároveň administrace.

**Znění kol, všech devět checklistů i s cílem importu, předvyplnění podle typu projektu, profil organizace a důvod, proč se importuje a neodkazuje, drží `~/.claude/skills/project/checklists.md`.** Řiď se jím, neopisuj ho z hlavy.

Importuj **jen to, co je pro projekt opravdu relevantní** – každý import stojí kontext v každé session. Upozorni uživatele, že při příštím spuštění dostane dialog na schválení externího importu a **musí ho odsouhlasit**.

**Tímhle krok 13 končí. V režimu `adopt` teď jdi do kroku 14** a projekt zreviduj proti aktuálnímu standardu; teprve po něm následuje souhrn. V režimu `update` se sem nedojde – krok 14 tam proběhl místo průchodu otázkami.

## Krok 14 – Soulad se standardem

*Ve všech režimech kromě `create`.* Projde se **celý projekt proti tomu, jak standardy vypadají dnes**, a co se rozešlo, se dorovná. Kdy se krok dělá:

| Režim | Kdy |
|---|---|
| `update` | **místo** průchodu otázkami – volby, které kdysi padly, se znovu nepokládají |
| `adopt` | **po** krocích 1–13, těsně před souhrnem – teprve tam je ustaveno, jak má projekt vypadat |
| `create` | vůbec; v adresáři, který právě vznikl, není co revidovat |

**Proč i u existujícího projektu:** otisk `/project` (blok metadat) v něm chybí i tehdy, když ho nastavovala starší verze skillu, která blok ještě nezakládala. Takový projekt vypadá jako neošetřený, ale dokumentaci má z doby, kdy platil jiný standard – a to je zrovna ten případ, na který je tenhle krok.

**Standard si načti, neopisuj ho z hlavy.** Rozdíl mezi projektem a tvou pamětí není nález – tvoje paměť je zrovna to, co je zastaralé. Než začneš kontrolovat, přečti si:

- `~/.claude/STRUCTURE.md` **celý** – definuje, které soubory jsou, co do kterého patří a jak je uvnitř seřazený;
- `~/.claude/RULES.md` – zejména *Životní cyklus projektu* (jaké kroky životního cyklu dnes existují) a *Kam co zapsat* (kam co patří);
- `~/Dev/context/coding/quality.md` – jen u projektu, ve kterém se něco spouští;
- `~/.claude/WORKTREE.md` – jen u worktree layoutu;
- výpisy `ls ~/.claude/skills/` a `ls ~/Dev/context/*/` – aktuální inventář skillů a doménových znalostí, proti kterému se ověřují odkazy a importy.

**Ve worktree layoutu** je tenhle krok do prvního dorovnání jen čtení – jakmile se má něco změnit, založ si větev podle kroku 0, *Nejdřív zjisti, kde stojíš*, a zapisuj do ní.

Postupuj po oblastech z katalogu níž. U každé platí **dvourychlostní režim** ze *Zásad*: co je mechanické a jednoznačné, oprav rovnou a jen to vypiš; co přepisuje nebo maže existující obsah, předlož a nech potvrdit. **Vyžaduje-li nález volbu**, kterou umí jen některý z dalších kroků (typ projektu, doménové importy, kontrakt příkazů), udělej ten krok – v režimu `adopt` je to návrat, v `update` se otevírá jen kvůli tomu nálezu – tady je popsané, *co se kontroluje*, tam *jak se to nastavuje*.

**Oblasti revize – co v každé ověřit a kde je pravda – drží `~/.claude/skills/project/standard.md`.** Projdi je všechny; je tam i *Obsah dokumentačních souborů*, tedy vnitřní tvar `todo.md`, `backlog.md`, `done.md`, `decisions.md` a `README.md`, což je nejdražší část revize.

### Výstup

Než začneš cokoliv měnit, **vypiš nálezy jako seznam** – co je v pořádku shrň jednou větou, každý rozpor uveď zvlášť s tím, co se s ním stane (opravím rovnou / potřebuju rozhodnout). Teprve pak jednej. Uživatel tak vidí rozsah dřív, než se sáhne na soubory.

Otázky pokládej **přes AskUserQuestion**, kdykoliv jde o volbu z pevné sady – tedy skoro vždy, protože nález má typicky dvě až tři možná vyústění (opravit / nechat být / rozhodnout jinak). Volný text si nech na to, co se z možností vybrat nedá.

**Nenajdeš-li nic, řekni to a skonči** – běh bez zásahu je platný výsledek revize, ne důvod něco vymýšlet.

**V režimu `update` tímhle běh končí – pokračuj rovnou krokem 15.** Kroky 1–13 se přeskakují celé; otevírá se z nich jen ten, který si vyžádal konkrétní nález. V režimu `adopt` se sem naopak přichází až od konce kroku 13 a souhrn následuje stejně.

### Proč se nikam neukládá, proti čemu se revidovalo naposledy

Nabízí se do projektu zapsat otisk – datum posledního běhu nebo hash `~/Dev/context` – a příště projít jen to, co se od té doby změnilo. **Vědomě se to nedělá.** Soulad se standardem je odvoditelný z toho, jak soubory vypadají teď, kdežto zapsaný otisk je tvrzení, které nikdo neověřuje: rozejde se se skutečností a vypadá přitom pořád stejně. Hlavně by ale zúžil kontrolu na diff standardu, a tím minul přesně ten případ, kvůli kterému skill vznikl – rozejití, které se do projektu nikdy nepropsalo, protože ho tehdy nikdo nezpropagoval. Ten v žádném diffu od posledního běhu není.

## Krok 15 – Závěrečný souhrn

Vypiš přehledně:

- **Co bylo založeno** (`create`) nebo **co se změnilo a co zůstalo** (`adopt`).
- Metadata projektu (název, popisek, web) a kam všude se propsala, git a remote, layout repozitáře, standardní struktura, provedené migrace názvů, **kontrakt příkazů a zda se tím zapnula průběžná kontrola, konfigurační kontroly (přísnost překladače, metriky složitosti, `.semgrep/`, LSP plugin, zákazy) – co se změnilo, co se jen navrhlo a co čeká na potvrzení**, autocommit, paměťová politika, typ, importované checklisty.
- **Co uživatel musí udělat ručně** – zejména odsouhlasení dialogu externích importů při příštím spuštění.
- *(worktree layout)* **Na jaké větvi výsledek leží**, že je ve větvi commitnutý a že merge do hlavní větve čeká na jeho pokyn. Neměnilo-li se nic, žádná větev nevznikla – řekni to místo toho.

V režimu `adopt` vypiš i **co jsi záměrně nechal být a proč** – ať je vidět, že to nebylo opomenutí. A protože v tomhle režimu proběhl těsně předtím krok 14, **připoj za souhrn i jeho tři skupiny** (dorovnáno / čeká na rozhodnutí / vědomě nechal být) – jinak revize proběhne, ale její výsledek se nikde neukáže.

*Režim `update`:* souhrn je jiný – nevypisuje nastavení, ale **rozdíl proti standardu**. Tři skupiny: co bylo dorovnáno, co čeká na rozhodnutí uživatele a co jsi vědomě nechal být i s důvodem. Oblasti, které vyšly čistě, shrň jednou větou; jejich výčet nikoho nezajímá.

Zakonči jednou z těchto vět, nikdy ničím vágním mezi tím:

- `Projekt je nastavený, můžeš v něm začít pracovat.`
- `Nastavený úplně není – zbývá: <konkrétní seznam>.`

V režimu `update` jednou z těchto:

- `Projekt je v souladu s aktuálním standardem.`
- `V souladu úplně není – zbývá: <konkrétní seznam>.`

**Kudy dál** je poslední blok odpovědi, za verdiktem – tvar a pravidla, kdy odrážka musí vypsat celý řetěz včetně ukončení session, drží `~/.claude/skills/HANDOFF.md`. Odtud vede:

- `/discovery`, staví-li se cokoliv pro lidi – u projektu bez trhu z něj odpadá jen konkurence, ne poptávka a rizika
- `/specify` rovnou jen u přírůstku, kde je „proč“ rozhodnuté a zapsané
- u dorovnaného projektu (`update`, `adopt`) se rovnou pracuje – další krok je `/next`, ne krok osy