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/standards/structure.md, ~/.claude/standards/rules.md, doménové znalosti, konfigurační vrstva) a dorovná, co se mezitím rozešlo. Viz krok 14.

Vedle standardního projektu, ve kterém Claude sám tvoří, zakládá i operativní projekt – adresář s uživatelovými vlastními dokumenty, nad kterým Claude jen pracuje a jehož jedinou stopou jsou soubory CLAUDE.md – v kořeni a ve složkách témat. Průvodce je v něm zkrácený na pár otázek; drží ho operative.md.

Pod ~/Clients rozliší klientskou složku a podprojekt klienta a ke kterémukoliv režimu přidá, co k nim patří: profil klienta, fakturační soubor a odkazy na ně v ~/Context. Drží to client.md.

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/standards/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/standards/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/standards/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/standards/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/standards/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/standards/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 <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/standards/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/standards/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,
• 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 – u operativního projektu revizí v operative.md (Standardní, nebo operativní projekt níž).
• Cokoliv jiného → režim adopt.

Leží-li projektový adresář pod ~/Clients, načti si client.md a řiď se jím ve všech krocích, které jmenuje – rozliší klientskou složku od podprojektu a u klienta pozná převod profilu, který už leží v ~/Context – režim se tím nemění.

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

Standardní, nebo operativní projekt

Operativní projekt je adresář, který patří uživateli a má jeho vlastní pořádek – smlouvy, výpisy, dokumenty, tabulky, videa –, a Claude nad ním jen pracuje; jedinou jeho stopou je CLAUDE.md (~/.claude/standards/structure.md, Operativní projekt: režim CLAUDE.md). Standardní projekt je všechno ostatní – to, kde Claude sám tvoří kód, dokumentaci nebo texty.

• update: má-li blok metadat - **Struktura:** CLAUDE.md, je to operativní projekt – neptej se a jdi rovnou na Revizi v operative.md.
• create a adopt: hned po určení režimu se zeptej (AskUserQuestion): Standardní projekt / Operativní projekt. Doporučenou volbu odvoď z adresáře: převaha uživatelových dokumentů (.docx, .pdf, .xlsx, video) bez kódu i bez docs/, nebo umístění pod ~/Documents, ukazuje na operativní; kód, docs/, ~/Projects nebo ~/Clients na standardní.

Padne-li operativní, načti si operative.md a řiď se jen jím – kroky 1–15 se neprocházejí a celý zbytek tohohle souboru se týká standardního projektu. Je to dělené proto, že operativní projekt má jiný cíl, ne jen méně kroků: zatímco standardní projekt Claude staví, v operativním má na disku zanechat co nejmenší stopu.

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/standards/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 odvoď z názvu projektu: malými, bez diakritiky, spojovníky místo mezer (structure.md, CLAUDE.md). Nese ho repozitář, adresář ne – ten se řídí konvencí disku (~/Projects/<Name> s velkým počátečním písmenem), takže se od slugu smí lišit. 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/standards/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 8.
• 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 <slug> --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:

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

Přepnutí režimu docs/ ↔ root se dělá jen na pokyn uživatele, nebo když se v adopt srovnávají soubory z obou míst. update ho sám nenabízí, protože oba režimy jsou rovnocenné a projekt v kterémkoliv z nich je v souladu. Postup, ve kterém se nic nesmí vynechat:

1. Čistý pracovní strom, ve worktree layoutu vlastní větev (Zásady pro celý průběh). Přesun smíchaný s cizí rozdělanou prací se pak nedá vrátit.
2. git mv každý soubor a adresář, který structure.md umisťuje podle režimu a v projektu existuje – standardní soubory, produktové podklady i research/. Nevypisuj si je z hlavy, ber je z structure.md. Existuje-li na cílovém místě soubor téhož jména, nepřesouvej ho, ukaž oba a zeptej se.
3. Přepis odkazů předej /replace přes nástroj Skill, s dvojicemi starých a nových cest. Upozorni ho, že relativní odkazy uvnitř přesunutých souborů (../README.md) mění hloubku. Ruční sed jednoho vzoru tyhle odkazy i zmínky v běžném textu mine.
4. Přepiš řádek Struktura v bloku metadat a sekci Struktura a dokumentace podle Kroku 7.
5. Ověř a commitni jako jeden celek: na starém místě nezůstal žádný standardní soubor, kontrola odkazů z kontraktu příkazů prošla, nebo ji nahraď grepem starých cest. Commit, který soubory přesune bez přepsaných odkazů, nechá v historii stav s mrtvými odkazy.

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, /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/standards/product.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:

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 /end 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/standards/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ě.

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/standards/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 `/end`.

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/skills/skills.md, Běhový stav). Řá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 – sekci ## Autocommit v projektovém CLAUDE.md – a uveď ho v otázce, ať uživatel ví, co mění.

Chybí-li v zapnuté sekci řádek @~/.claude/skills/autocommit/autocommit.md, doplň ho a řekni to – 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/standards/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/standards/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 ~/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á ~/Context/Coding/quality.md, Vrstvy kontroly a co do které patří; ří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/hooks/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 ~/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 ~/Context/Coding/quality.md.

Krok 13 – Doménové checklisty

Zeptej se v 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šechny checklisty 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. Pod ~/Clients se profil neimportuje odtamtud: klient podle client.md, Klient, podprojekt ho neimportuje vůbec (Podprojekt).

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/standards/structure.md celý – definuje, které soubory jsou, co do kterého patří a jak je uvnitř seřazený;
• ~/.claude/standards/rules.md – zejména Životní cyklus projektu (jaké kroky životního cyklu dnes existují) a Kam co zapsat (kam co patří);
• ~/Context/Coding/quality.md – jen u projektu, ve kterém se něco spouští;
• ~/.claude/standards/worktree.md – jen u worktree layoutu;
• výpisy ls ~/.claude/skills/ a ls ~/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 ~/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, 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í.
• (klientská složka, create a adopt) profil a fakturační soubor – co se založilo nebo převedlo –, odkazy v ~/Context a jejich commit, a výpis ~/Clients/*/invoicing.md, ve kterém fakturovaný klient je; u převodu i nalezené odkazy na starou cestu profilu.
• (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é
• stojí-li výsledek na větvi, /merge, pak /clear, a krok osy až v nové session v <container>/main – v mezeře za tímhle skillem nic jiného nestojí, /review ani /oponent ne (~/.claude/standards/lifecycle.md, Co smí stát v které mezeře)
• u dorovnaného projektu (update, adopt) se rovnou pracuje – další krok je /next, ne krok osy