git:20260907.cd3a564 to git:20260907.c75afd2

---

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`, 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 – jsou to pravidla layoutu, ne tenhle skill, a instaluje je `/worktree`.

- **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í sessions 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

### 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=<projekt>/.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 <projekt> worktree add <projekt>/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`).

- Převezmi 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á: nad necommitnutým stromem merge neprojde (`~/.claude/WORKTREE.md`, *Dokončení větve*).

- **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`, `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ýš), `README.md`, `.gitignore`; 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 žádný není, kvůli globálnímu `~/.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 <název-adresáře> --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 "<popisek>" -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 sessions 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 |

|---|---|---|

| `<projekt>/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 `<projekt>/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 <projekt>/CLAUDE.md <projekt>/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` 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. Definici všech pěti 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 |

|---|---|

| `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á. |

**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ž také, 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/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

**Kroky životního cyklu do popisu typu nevypisuj**, odkaz na *Životní cyklus projektu* v `~/.claude/RULES.md` stačí. Je to zvláštní případ obecného pravidla *Neopisuj seznam, který má vlastní zdroj pravdy* (`~/.claude/skills/SKILLS.md`, *Jak se píše text uvnitř*), kde stojí i to, čím se vykoupilo.

Typů je šest, ale AskUserQuestion bere najednou nejvýš čtyři volby. Ptej se proto ve dvou úrovních – nejdřív na oblast, pak na typ uvnitř ní. Uživatel klikne nejvýš dvakrát a žádný typ se neztratí.

**První otázka** (AskUserQuestion): „Čeho se projekt hlavně týká?“ Tři volby:

| Volba | Co následuje |

|---|---|

| Vývoj software a webů | druhá otázka: **Vývoj** / **Web** |

| Analytika | druhá otázka: **Nasazení webové analytiky** / **Data a výzkum** |

| Obsah | typ je rovnou **Psaní a obsah**, druhá otázka odpadá |

Oblasti jsou schválně dělené podle **povahy práce, ne podle použité technologie** – vývoj software a webů je stavění, analytika je měření a vyhodnocování, obsah je psaní. Až přibude další typ, patří do té oblasti, jejíž povahu sdílí; pokud do žádné, je to signál, že chybí čtvrtá oblast, ne že se má nacpat do nejbližší.

**Až se oblasti zaplní.** Dvouúrovňová otázka má strop 16 typů (4 oblasti × 4 typy). Až na něj narazíš, nepřidávej třetí úroveň – přejdi na **N kol po čtyřech**: jedno kolo na každou oblast, `multiSelect: true`, uvozené „Co všechno z oblasti <oblast> pro tenhle projekt platí? Když nic, nic nezaškrtávej.“ Kol může být libovolně mnoho, takže limit AskUserQuestion přestane omezovat.

Ta změna má důsledek, který je potřeba unést vědomě: projekt tím přestane mít jeden typ a bude mít **sadu typů** – klidně prázdnou (= **Ostatní**), klidně **Vývoj** i **Web** zároveň. Do `CLAUDE.md` pak nelep popisy pod sebe mechanicky: slož je do jednoho odstavce a **vyřeš rozpory**. „Vývoj“ předepisuje proces zadání a plánu, „Web“ ho výslovně nechce – když padnou oba, rozhodni podle hlavní náplně projektu a napiš jen to, co platí.

Volbu „Ostatní“ mezi možnosti **nedávej** – AskUserQuestion ji nabízí sám jako „Other“. Když ji uživatel použije, typ je **Ostatní** a druhá otázka odpadá.

Do `CLAUDE.md` přidej sekci `## Typ projektu` s krátkým popisem:

- **Vývoj** – „Vývojářský projekt – postupuj podle *Životního cyklu projektu* v `~/.claude/RULES.md`, celého a v pořadí, které tam stojí.“ Navíc přidej pravidlo: „Před implementací nové funkce nejdřív aktualizuj příslušný dokument v `docs/` (doc-first).“

- **Web** – „Webové rozhraní – obsah, struktura, šablony, ne proces zadání a plánu.“

- **Nasazení webové analytiky** – „Implementace měření na cizím webu – revize existujícího nastavení, měřicí plán, GTM, GA4, consent, reklamní systémy. Výstupem je funkční a doložitelné měření plus dokumentace, ne aplikační kód.“ Navíc přidej pravidlo: „Každá změna v měření musí být před publikováním ověřená v Preview/DebugView a po nasazení znovu na produkci; do `docs/decisions.md` patří i to, co se měřit záměrně nebude a proč.“

- **Psaní a obsah** – „Projekt zaměřený na psaní a obsah, ne na vývoj software – bez procesu zadání a plánu.“

- **Data a výzkum** – „Jednorázová datová/výzkumná analýza – výstupem jsou zjištění a report, ne nasazovaný kód.“

- **Ostatní** – „Projekt mimo výše uvedené kategorie.“

## Krok 12 – Kontrakt příkazů a průběžná kontrola

**Jen u projektu, ve kterém se něco spouští** – tedy typ *Vývoj*, *Web*, nebo kdekoliv, kde v repozitáři najdeš `package.json`, `composer.json`, `Makefile`, `pyproject.toml` a podobně. U obsahového, znalostního nebo výzkumného projektu **krok přeskoč a řekni to jednou větou**; kontrakt tam nemá co dělat.

**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 <projektový adresář>` 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ží.

**Šablonu sekce, význam klíčů, mechaniku průběžné kontroly i to, co se nenastavuje příkazem, ale konfigurací** (přísnost překladače, metriky složitosti, `.semgrep/`), **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 prozaické odkazy. 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 *Co do tohoto souboru nepatří* (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

## 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/`) – 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á.

**Další krok:** /discovery, staví-li se produkt pro trh, jinak rovnou /specify – u dorovnaného projektu se rovnou pracuje

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>.`