Imported from jantichy/claude (skills/project/SKILL.md). Install upstream with npx skills add jantichy/claude --skill project. Copyright stays with the author.

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í 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í skončit, není-li to git repozitář, kdežto tady je prázdný adresář bez .git legitimní vstup – je to režim create. 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=<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:

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.

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í:

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 , 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:

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

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

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é):

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:

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í):

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/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. 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 <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, založení CI 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é @importy, 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á:

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

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