Jak nastavit CLAUDE.md v roce 2026: šablona a 6 pravidel

Materiály o vibe codingu: nástroje, případové studie, chyby. Návody Ailoot.

Proč potřebujete CLAUDE.md a proč bez něj Claude na projekt zapomíná?#

V úterý otevřete Claude Code a vysvětlíte: „Pracuji na tomto projektu, tohle jsou nástroje, tohle nedělej.“ Funguje to.

Ve čtvrtek už ten samý chat skončil, takže všechno opakujete. V sobotu znovu; v pondělí ještě jednou.

Tak vypadá práce s agentem bez CLAUDE.md: každé nové okno je stážista s čistým štítem, kterému musíte stále dokola říkat to samé. Dřív jsem při každé relaci strávil 5–10 minut tímto úvodním vysvětlováním. Zadání se prodlužovala, protože jsem musel všechen kontext předávat ručně. Výsledek byl přesto obecný: agent neznal moje publikum, ekonomiku ani principy.

S průběžně aktualizovaným CLAUDE.md úvodní vysvětlování odpadá. Všechna pravidla, která jste dřív opakovali v každém chatu, jsou v jednom souboru a načtou se automaticky na začátku každé relace. Zadání se zkrátí na „udělej X“ místo „pracuji na projektu Y, nástroje jsou Z, nedělej A ani B a ještě si zapamatuj C“.

Pak přestanou opakované chyby.

Každá chyba agenta je důvodem přidat do CLAUDE.md jeden řádek. Po měsíci máte živou „ústavu projektu“ a Claude přestane znovu a znovu padat do stejných známých pastí.

A je tu třetí vrstva: agent už nepíše do prázdna. Pomocí CLAUDE.md směruji Claude do složek s kontextem: kde hledat informace o publiku, cenách a brandingu. Bez tohoto směrování agent píše „kvalitní řešení“, aniž zná mou ekonomiku, takže výsledky jsou abstraktní, šablonovité a „jako od všech ostatních“.

Co je CLAUDE.md a v jakém pořadí ho Claude čte?#

Anthropic popisuje CLAUDE.md v oficiální dokumentaci takto:

Čtyři místa, kde Claude Code hledá CLAUDE.md, seřazená vzestupně podle priority:

Všechny čtyři soubory se načtou do kontextu současně. Pokud jsou pravidla v rozporu, Anthropic v dokumentaci přímo uvádí, že není známo, které z nich dostane přednost; Claude si může jedno z nich libovolně vybrat. Proto je jednodušší ponechat vše podstatné v projektovém CLAUDE.md a nevytvářet duplicity.

Je tu jeden technický detail, o kterém téměř nikdo nepíše, ale který vysvětluje řadu podivných chování.

Jinými slovy, CLAUDE.md není v přísném slova smyslu „systémový prompt“. Je to první uživatelská zpráva, kterou Claude uvidí. Jeho pravidla jsou tedy důrazná doporučení, nikoli zákony. Potřebuje-li pravidlo vynucení, použijte otestovaný hook pro pokrytou událost a oprávnění či izolaci prostředí pro širší hranici přístupu. Automatické spuštění hooku nečiní jeho kontroly úplnými. Hranici mezi hooks a CLAUDE.md vysvětlím níže.

Jak napsat minimální CLAUDE.md za 5 minut (šablona připravená k použití)?#

Níže je šablona, kterou jsem vyzkoušel v desítkách svých projektů. Udržuje soubor přibližně na 80–120 řádcích, tedy v souladu s doporučením Anthropic mířit pod 200 řádků. S touto šablonou agent dává nejrozumnější výsledky.

# [PROJECT NAME] - project navigation

This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.

## What this project is

**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].

Details are in `business/INDEX.md`.

## Reading order at the start of every session

1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/<current plan>`,
   `mastery/<area>` or the feature folder in the code

Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.

## Repository structure

[NAME]/
├── CLAUDE.md            ← this file, navigation
├── about-me/            ← digital projection of you (how you think, what you value)
│   └── INDEX.md
├── business/            ← the business’s second brain
│   ├── INDEX.md
│   ├── audience/        ← customer profile
│   ├── products/        ← products, prices
│   ├── goals/           ← goals, metrics
│   └── economics/       ← unit economics, revenue
├── plans/               ← technical plans (one plan = one feature)
├── retrospectives/      ← reflections after each session
└── (project code)

### Where to find things

| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |

## Tools

[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].

## Repo rules

1. Never hardcode dynamic data (prices, dates, figures) -
   get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
   builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
   `grep "^VAR=" .env`.

## Big features = a plan in `plans/`

Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.

## End-of-feature cycle

After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.

## End-of-session reflection

In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.

## Language

Always respond in the user’s preferred language. Use hyphens only, not em dashes.

Chcete-li, aby Claude tuto šablonu automaticky vyplnil pro váš projekt, zadejte mu toto zadání. Přečte kontext a doplní pole v hranatých závorkách:

Create a CLAUDE.md file at the project root using this template:

[INSERT THE ENTIRE TEMPLATE FROM ABOVE]

Proceed as follows:

Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.

Fill in all the square-bracketed fields in the template based on what you find in those folders.

If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.

Usiluj o CLAUDE.md pod 200 řádky. Je-li delší, prověř duplicity a podrobné postupy přesuň do odkazovaných souborů. Zachovej zásadní plánování, reflexi a pravidla repozitáře a pak je otestuj na reprezentativních úkolech.

Show me the final file and ask what should be revised.

Always respond in the user’s preferred language.

Pokud zatím nemáte složky about-me/ a business/, nevadí. Claude položí upřesňující otázky a sestaví minimální CLAUDE.md podle dostupných informací. Složky můžete vytvořit později, až budete vědět, co do nich dát.

Jakých 6 pravidel udělá z CLAUDE.md živý dokument?#

Pravidlo 1. Udržujte ho pod 200 řádky

Anthropic to ve své oficiální dokumentaci říká stručně:

Dlouhý CLAUDE.md působí proti sobě dvěma způsoby. Zaprvé spotřebovává tokeny. Soubor s 800 řádky pokynů se načte do každého okna a v každé relaci spotřebuje několik tisíc tokenů z vašeho rozpočtu. U předplatného Pro s denním limitem to znatelně snižuje počet dostupných relací. Zadruhé model začne pravidla ignorovat.

Dokumentace doporučuje mířit pod 200 řádků kvůli kontextu a dodržování instrukcí. Nedokládá ostrou hranici selhání na řádku 201. Před přesunem detailů posuďte relevanci, rozpory, objem načtených tokenů a skutečné výsledky úkolů.

Pravidlo 2. Každou relaci zakončete reflexí

Do CLAUDE.md napište: „Na konci každé relace zaznamenej, co jsi udělal a zjistil, do retrospectives/YYYY-MM-DD_*.md.“ Po přidání tohoto řádku začne Claude každou relaci zakončovat reflexí sám; nemusíte ho o to žádat.

Proč se ohlížet:

• Za dva týdny můžete otevřít starou retrospektivu a vzpomenout si, proč jste zvolili daný postup.
• Když se k projektu po měsíci vrátíte, budete mít připravený přehled nedávných rozhodnutí.
• Pokud pracujete v týmu, partner si může retrospektivu přečíst a bez telefonátu pochopit aktuální stav za 2 minuty.

Pravidlo 3. Po dokončení každého úkolu vytvořte commit

V mém CLAUDE.md stojí: „Po dokončení každého úkolu vytvoř git commit s výstižným popisem.“ Claude pak sám začíná dělit práci na malé samostatné commity.

Získáte tím dvě věci. Zaprvé, pokud se něco pokazí, můžete vrátit jednu operaci, ne „všechno, co jsem dnes udělal“. Zadruhé, historie commitů se stane pracovním deníkem, který ukazuje, co se změnilo a v jakém pořadí.

Pravidlo 4. Vždy se podívejte do složky business/

U každého úkolu týkajícího se zákazníků, produktů nebo textů by měl agent nejprve otevřít business/INDEX.md a příslušný soubor, na který odkazuje. V mém CLAUDE.md výslovně stojí: „Při práci na UI nebo textech nejprve zkontroluj business/audience/avatar.md a business/assets/brand-guidelines.md.“

Bez tohoto pravidla píše Claude texty „v obecném stylu kvalitního webu“. S ním píše vaším stylem, pro vašeho zákazníka a bez zakázaných slov.

Pravidlo 5. Po každé chybě agenta přidejte pravidlo

Tohle je hlavní pravidlo, díky kterému CLAUDE.md zůstává živý.

Příklady z mého CLAUDE.md, které přibyly po konkrétních chybách:

• „Nikdy necommitujte cizí rozpracované soubory pomocí git add . – přidávejte soubory jednotlivě podle názvu.“
• „Před odesláním do main zkontroluj git log origin/main..main --oneline – pokud není prázdný, nic neposílej.“
• „Nevymýšlej si hodnoty – ber je z .env nebo z kódu. Zejména URL, uživatelská jména a tokeny.“

Každý z těchto řádků je stopou konkrétního incidentu. Jednou agent commitnul nedokončenou větev partnera. Jindy jsem zahrnul cizí neodeslané commity. Pak si agent vymyslel neexistující URL. Každá chyba se stane pravidlem a stejnou ránu si už nezpůsobíte znovu.

Pravidlo 6. Zabezpečení patří do .claude/settings.json, ne do CLAUDE.md

V CLAUDE.md můžete napsat „nesahej na .env“, ale je to žádost; Claude ji může porušit, protože CLAUDE.md se načítá jako uživatelská zpráva, nikoli jako zákon. Pro kritické zabezpečení použijte .claude/settings.json, kde můžete určité příkazy přísně blokovat.

Seznam příkazů, které blokuji v každém novém projektu:

• rm -rf (rekurzivní mazání libovolných souborů).
• Čtení celého .env (Read .env).
• export a curl v tomtéž příkazu (vzorec pro únik tajných údajů mimo systém).
• git push --force bez výslovného schválení.

Další návody najdete na Ailoot.

Jak je CLAUDE.md strukturovaný v aktivní firmě (rozbor souboru o 280 řádcích)?#

Většina příkladů CLAUDE.md na internetu jsou technické šablony pro vývojáře: „Používejte TypeScript“, „Nepište testy delší než 50 řádků.“ Pro podnikatele je takový CLAUDE.md k ničemu – nepokrývá obchodní stránku.

Níže je struktura mého pracovního CLAUDE.md. Odstranil jsem konkrétní pravidla a cesty, protože odrážejí mé interní provozní postupy. Strukturu a logiku částí však lze použít v jakémkoli projektu: doplňte vlastní okolnosti a získáte funkční soubor.

1. Stručný popis projektu (15 řádků). Co děláme, kdo je naše publikum a jaké produkty nabízíme. Ne shrnutí marketingového webu, ale přehled pro agenta, aby pochopil, „kam směřujeme“.

2. O mně (10 řádků). Odkaz na složku about-me/ – digitální podobu toho, jak přemýšlím. Tón, hodnoty, principy, zakázaná slova. Když Claude píše text „za mě“, nejprve si tuto složku přečte, aby odpovídal můj hlas.

3. Struktura repozitáře (20 řádků). Stromová struktura s komentáři: kde je kód, kde je obchodní kontext, kde jsou plány a reflexe. Bez této mapy Claude pokaždé naslepo hledá soubory.

4. Tabulka „kde co najít“ (25 řádků). Směrování od „otázka → soubor“. Například realitní kancelář může uvést „potřebuješ podmínky hypotéky → business/products/mortgage.md“ nebo „potřebuješ tón příspěvků → business/assets/voice.md“. Dosazujete vlastní soubory. Tato tabulka je srdcem CLAUDE.md. Bez ní agent hádá, ve kterém souboru odpověď najde. S ní jde přímo ke zdroji.

5. Klíčové principy projektu (40 řádků, 10–15 položek). Tato část se plní postupně a stojí nejvíc úsilí. Každá položka je stopou konkrétní chyby. Pravidla internetového obchodu by například mohla znít: „Nikdy nezadávej napevno ceny a dodací lhůty“, „nezveřejňuj produkt bez výslovného příkazu“ a „před zveřejněním nabídky ověř styl podle glosáře značky“. Tato část je „ústavou projektu“.

6. Provozní plánování (20 řádků). Tabulka spouštěcích frází, která mapuje „fráze uživatele → akce“. Například: „Když řeknu ‚naplánuj týden‘, otevři ops/monthly.md a vytvoř soubor pro tento týden.“ Claude se tak stane provozním asistentem, který chápe kontext příkazů.

7. Nástroje (5 řádků). Technologie. Stručně a bez vaty.

8. Publikování (15 řádků). Postup publikování změn do produkce krok za krokem: které příkazy spustit, v jakém pořadí a co zkontrolovat. Dřív jsem to pokaždé vysvětloval. Teď to Claude ví.

9–12. Zabezpečení (35 řádků). Čtyři samostatné podčásti: pravidla pro práci s .env, přístup k produkční databázi, bezpečné příkazy pro ukázky (záznamy obrazovky, streamy, snímky, aby se omylem neodhalily tokeny) a pravidla pro rotaci tajných údajů.

13. Složka plans/ (10 řádků). Standard pro plány: název souboru, struktura fází a obsah souhrnného bloku.

14. Složka retrospectives/ (5 řádků). Standard pro reflexi: šablona, název souboru a požadovaný obsah.

15. Data z živé databáze (15 řádků). Pravidlo pro označení „aktuálních dat“: když soubor říká, že čísla musí být aktuální, agent je získá ze zdroje místo toho, aby použil stará. Tím se odstraňuje riziko, že Claude použije včerejší čísla.

16. Jazyk (3 řádky). „Vždy odpovídej v jazyce preferovaném uživatelem. Používej pouze spojovníky, nikoli dlouhé pomlčky.“

Celkem přibližně 280 řádků. Překračuje to cíl stručnosti, soubor ale není neplatný. V příkladu zůstal užitečný; jeho ponechání má záviset na změřeném kontextu a reprezentativních testech. Tabulky automaticky nešetří tokeny proti próze.

Co dělá příkaz /init a proč nestačí?#

Anthropic v dokumentaci popisuje tento příkaz takto:

Co /init umí dobře:

• Zjistí nástroje podle souborů package.json, Cargo.toml a pyproject.toml.
• Vypíše příkazy pro sestavení a testování.
• Zachytí konvence z existujících souborů (.eslintrc, .prettierrc).
• Všimne si existujících pravidel Cursoru (.cursorrules, .cursor/rules/) a Copilotu a začlení příslušné části. V režimu CLAUDE_CODE_NEW_INIT=1 načte AGENTS.md.

Co /init neudělá:

• Nebude vědět, kdo je váš zákazník.
• Nezahrne zakázaná slova pro texty.
• Nepřidá pravidla týkající se chyb agenta (protože k žádným zatím nedošlo).
• Nevytvoří tabulku „kde co najít“ pro strukturu vaší firmy.

Správný postup je tedy tento:

1. Spusťte /init v Claude Code

   Získáte výchozí CLAUDE.md o 30–50 řádcích s nástroji a příkazy. To je technický základ.

2. Přidejte na něj šablonu z tohoto článku

   Použijte část „Minimální CLAUDE.md za 5 minut“. Přidejte části o navigaci, směrování a principech.

3. Vyplňte pole v hranatých závorkách

   Zadejte Claudovi pokyn „přečti můj projekt a vyplň šablonu“. Pokud složky business/ a about-me/ zatím neexistují, Claude položí upřesňující otázky.

4. Proveďte zátěžový test

   Řekněte Claudovi: „Přečti můj CLAUDE.md a najdi 10 nejednoznačností, kvůli kterým bys jako agent mohl špatně porozumět pokynům.“ Dostanete seznam úprav.

5. Potom se souborem pracujte

   Po každé chybě agenta přidejte řádek. Za měsíc budete mít CLAUDE.md přizpůsobený své firmě a průběžně aktualizovaný.

Zadání pro čtvrtý krok:

I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.

Your task is to stress-test it. Find 10 reasons we could potentially fail:

where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it

where there are gaps that would force you to make things up

where rules contradict one another

where I overestimate how much can be done in one day

where I underestimate things (this is even worse)

Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.

CLAUDE.md vs AGENTS.md vs MEMORY.md: kdo co čte v roce 2026?#

Hlavní otázka, která mate nováčky, zní: čte Claude Code soubor AGENTS.md? Před zářím 2026 byla odpověď „ne“: dokumentace Anthropic doporučovala vytvořit CLAUDE.md, který importuje AGENTS.md. Od verze 2.1.277 (vydané 18. září 2026) Claude Code čte soubor AGENTS.md přímo, ale pouze pokud v pracovní složce ani nadřazených složkách není CLAUDE.md, .claude/CLAUDE.md ani CLAUDE.local.md.

Pokud projekt má CLAUDE.md, Claude Code ve výchozím nastavení čte pouze ten a AGENTS.md přeskočí. Změnit to můžete v /config v části Project instructions: například nastavení claude-md-and-agents-md zajistí, že bude číst oba soubory. Ve všech verzích funguje i jiný způsob: přidat do CLAUDE.md import:

@AGENTS.md

## Claude Code

Additional rules for Claude Code that other agents don’t need.

Syntaxe @filename importuje další soubor. Claude si ho přečte a načte do kontextu spolu s CLAUDE.md. Import nezpůsobí dvojí načtení souboru, ani když Claude Code umí číst AGENTS.md samostatně.

Kdy potřebujete AGENTS.md. Pokud pracujete souběžně s Claude Code a Codex CLI, Cursorem nebo Copilotem, vytvořte AGENTS.md jako jediný zdroj pravdy, do CLAUDE.md vložte @AGENTS.md a navrch přidejte případná pravidla specifická pro Claude. Pokud taková pravidla nemáte, CLAUDE.md vytvářet nemusíte: od verze 2.1.277 bude Claude Code číst AGENTS.md samostatně. Pokud pracujete pouze v Claude Code, AGENTS.md nepotřebujete; použijte jen jeden CLAUDE.md. Všechny možnosti krok za krokem najdete v návodu, jak používat AGENTS.md a CLAUDE.md v jednom projektu.

Co je MEMORY.md? Od nedávné aktualizace si Claude Code automaticky ukládá poznámky o vás do ~/.claude/projects/<project-name>/memory/MEMORY.md. Patří mezi ně zvyklosti v konverzaci („uživatel preferuje stručné odpovědi“), opakující se fráze („zakázal emoji v kódu“) a poznatky o chování („pracuje na macOS, používá zsh“).

Jde o samostatný systém paměti, nikoli o CLAUDE.md. Nepíšete ho ručně; Claude ho vytváří na základě vašich konverzací. Pokud MEMORY.md obsahuje něco, co by se mělo stát pravidlem, přesuňte to do CLAUDE.md. Pokud obsahuje něco nepotřebného nebo nesprávného, můžete to ručně odstranit; je to textový soubor.

Jaká velikost CLAUDE.md je užitečná a jak prověřit dlouhý soubor?#

V každém okně Claude Code se do kontextu načítá několik vrstev: systémový prompt Anthropic (odhadem desítky tisíc tokenů), váš CLAUDE.md, soubory importované pomocí @, MEMORY.md, historie aktuálního chatu a obsah souborů, které Claude otevře. To vše se musí vejít do kontextového okna modelu (200K tokenů pro Sonnet, 1M pro Opus).

Čím větší CLAUDE.md je, tím méně prostoru zbývá na aktuální práci. Soubor o 1 000 řádcích má přibližně 8 000 tokenů a načítá se v každé relaci. U předplatného Pro (podle mé zkušenosti přibližně 10–12 „náročných“ zadání denně) to snižuje kapacitu o čtvrtinu.

Cena je jen jedna otázka. Dodržování může klesat při dlouhých, nerelevantních či rozporných instrukcích; univerzální počet spolehlivě dodržených pokynů neexistuje. Otestujte několik reprezentativních úkolů s kritickými pravidly, zaznamenejte chyby a porovnejte chování po cílené úpravě.

A teď orientační doporučení k velikosti:

• 80–120 řádků – pohodlný výchozí rozsah stručné mapy projektu, nikoli zaručené skóre dodržování.
• 150–200 řádků – podnět k prověření relevance a přesunu detailních postupů do odkazovaných souborů.
• 200–300 řádků – prohlédněte tokeny, duplicity a výsledky úkolů; 280řádkový firemní příklad výše může stále fungovat dobře.
• 400+ řádků – silný důvod k cílené kontrole, nikoli důkaz nepoužitelnosti. Zásadní omezení zachovejte a podrobnosti přesuňte až po ověření odkazů a pravidel.

Samotný počet řádků neprokazuje úspěch či selhání. Po úpravě zopakujte stejné reprezentativní úkoly a ověřte důležitá pravidla místo vymyšleného procenta poslušnosti.

Anthropic ve své dokumentaci uvádí přímý test:

Použijte tento test na každý řádek. Pokud je odpověď „stejně by to zvládl správně“, řádek odstraňte. CLAUDE.md není místo pro dokumentaci, historii rozhodnutí ani filozofii. Patří do něj jen pravidla, která agent potřebuje, aby něco nepokazil.

Jakých 7 chyb dělá CLAUDE.md nepoužitelným?#

Chyba 1. „Buď dobrý inženýr“

Nejčastější chyba. Lidé píšou do CLAUDE.md obecná přání: „piš čistý kód“, „používej osvědčené postupy“, „mysli jako zkušený inženýr“.

Tato slova nic neznamenají. Claude už v obecném smyslu píše „čistý kód“. Tyto řádky zabírají kontext, aniž ovlivňují jakékoli rozhodnutí.

Nahraďte „piš čistý kód“ pokyny „používej odsazení dvěma mezerami“, „v TypeScriptu nepoužívej any“ nebo „funkce nesmí mít více než 30 řádků“. Jsou konkrétní a ověřitelné.

Chyba 2. Opakování toho, co Claude už ví

Popisy běžných jazykových konvencí („v JavaScriptu jsou funkce plnohodnotnými objekty“, „TypeScript má statické typování“). Vysvětlování, jak funguje npm, git nebo docker.

Tohle všechno se Claude naučil při trénování. Opakování v CLAUDE.md nic nepřidává; jen ukrajuje z kontextu.

Chyba 3. Dlouhé pokyny krok za krokem přímo v CLAUDE.md

Dlouhé návody na to, „jak nasadit projekt“, „jak napsat migraci databáze“ nebo „jak vytvořit novou komponentu“. Desítky řádků s postupem krok za krokem.

Tohle není místo pro dlouhé návody krok za krokem. Patří sem jednořádková pravidla. Dlouhé pokyny umístěte do skills/ (samostatného mechanismu Claude Code, který se načítá podle potřeby) nebo do docs/. Do CLAUDE.md vložte jednorádkový odkaz: „Při vytváření migrace otevři docs/migrations.md.“

Chyba 4. Pravidla, která už kontroluje automatický analyzátor kódu

„Používej středníky“, „nenechávej nepoužívané importy“, „nepoužívej var“. ESLint, Prettier a Biome to všechno zachytí – jsou to lintery (nástroje pro automatickou kontrolu kódu).

Linter je deterministický: spustí se, najde chybu a opraví ji. Pravidlo v CLAUDE.md je pravděpodobnostní; agent na něj může zapomenout. Není důvod ho duplikovat – jednodušší je nastavit linter.

Chyba 5. Tajné údaje v CLAUDE.md

Viděl jsem hesla k testovacím účtům, testovací API tokeny a odkazy na přihlášené administrační panely. Všechno bylo v souboru uloženém v gitu a načítaném do kontextu modelu Anthropic.

Nikdy. Tajné údaje patří do .env, který je v .gitignore. CLAUDE.md by měl maximálně říkat: „Nečti celý .env; pro konkrétní proměnnou použij grep.“

Chyba 6. Skladiště o 500+ řádcích, které nikdo šest měsíců neuklízel

CLAUDE.md narostl, opakuje polovinu obsahu docs/, na několika místech si odporuje a nikdo si nepamatuje, co v něm je. Agent začne většinu ignorovat. Tým si stěžuje, že „Claude nedodržuje pokyny“, a přidává další pravidla, čímž situaci zhoršuje.

Známky zanedbaného CLAUDE.md: více než 300 řádků, opakovaná pravidla v různých částech, zastaralé odkazy na neexistující soubory a „historické“ poznámky jako „v roce 2024 jsme se rozhodli dělat to takhle, pak jsme si to rozmysleli“.

Náprava: každé dva týdny požádejte Claude, aby soubor zkontroloval Anthropicovým testem: „Kdyby se tento řádek odstranil, udělal by agent chybu?“ Smažte vše, u čeho je odpověď „ne“.

Chyba 7. CLAUDE.md vytvořený a zapomenutý

Jde o opak předchozí chyby. Soubor jste jednou dali dohromady, před dvěma měsíci, a od té doby jste se ho nedotkli. Mezitím se změnily nástroje, přibyly nové složky a objevily se nové chyby agenta. CLAUDE.md o ničem z toho neví, protože ho nikdo neaktualizoval.

Typickým znakem je, že v každé relaci opakujete stejný pokyn. „Nedělej X“, „nesahej na Y“, „pamatuj si Z“. Pokud jste ho zopakovali více než dvakrát, patří toto pravidlo do CLAUDE.md, ne do vaší hlavy.

Jak dosáhnout toho, aby se CLAUDE.md sám učil díky pravidlu „aktualizuj na konci relace“?#

Můj CLAUDE.md má krátkou část:

## Self-learning

At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?

If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).

I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.

Po přidání této části do CLAUDE.md se Claude začal na konci každé relace ptát: „Stalo se něco nového, co stojí za zaznamenání?“ Pokud ano, navrhl návrh pravidla, já ho upřesnil a vytvořil se soubor.

Po dvou měsících práce tímto způsobem mám ve složce about-me/feedback/ více než dvě desítky souborů – pravidel naučených z konkrétních chyb. Každý soubor je jednou stránkou ve formátu Pravidlo → Proč → Jak. Složka se stala „druhou pamětí“, která zaznamenává mé individuální preference a tabu.

Každá chyba se přestane opakovat, protože se z ní stane pravidlo, a pravidla se postupně hromadí a vzájemně posilují. Po půl roce Claude zná můj projekt lépe, než si ho po měsíční pauze pamatuji já.

Jak do CLAUDE.md přidat právní pravidla, marketing a provoz?#

Pro většinu týmů je CLAUDE.md čistě technický dokument: nástroje, příkazy pro sestavení, konvence programování. Je užitečný, ale představuje jen třetinu hodnoty.

Když CLAUDE.md udržuje podnikatel, dává smysl přidat obchodní části. Nejdůležitější jsou tři:

Právní pravidla (pro regulované trhy)

Pokud zveřejňujete texty v regulovaném odvětví (finance, medicína, reklama na léky, dětské produkty), mají zakázaná slova právní váhu a patří do CLAUDE.md jako výslovná pravidla. Ne do něčí hlavy ani na snímek obrazovky editora – do souboru, který agent vidí v každé relaci.

Příklad pro fintechový projekt bez bankovní licence:

Redakční poznámka: Následující ukázka znázorňuje formát interního pravidla pro konkrétní projekt. Nepředstavuje obecné povolení používat uvedené výrazy: přijatelnost tvrzení závisí na platných zákonech a právním postavení firmy.

🚨 KRITICKÉ – finanční formulace jsou zakázány. V materiálech určených zákazníkům nepoužívejte: „vklad“, „garantovaný výnos“ ani „investiční produkt“. Používejte: „spořicí účet“, „očekávaný výnos“ a „produkt s proměnlivou sazbou“. Důvodem jsou právní požadavky vztahující se na reklamu finančních služeb v tomto projektu.

Tento blok v CLAUDE.md dělá něco jednoduchého: pokaždé, když požádáte Claudea o text pro zákazníky, agent ho zkontroluje podle těchto zákazů. Bez pravidla se zakázaná slova objevují v každé třetí kampani. S ním na ně můžete zapomenout.

Stejný přístup funguje pro:

• Lékařské projekty (žádná tvrzení, že něco „léčí“ nebo „vyléčí“).
• Reklamu na léky (žádná tvrzení „nejúčinnější“; povinná varování).
• Jakékoli regulované odvětví s vlastními pravidly pro reklamu.

Marketingový styl a formát textů

Pokud pravidelně zveřejňujete texty (sociální sítě, newslettery, weby), stojí za to jejich formát popsat jedním odstavcem v CLAUDE.md. Zde je příklad toho, co může napsat influencer nebo agentura provozující komunikační kanál:

Při psaní příspěvků do kanálu se řiď style/posts.md. Používej povolené formátovací značky kanálu a vyhýbej se „nebezpečným“ speciálním znakům. Zakonči příspěvek CTA s UTM značkou podle této konvence: utm_source=<channel>&utm_medium=<type>&utm_campaign=<slug>.

Dřív Claude psal příspěvky „v obecném stylu marketingového webu“. Teď dodržuje váš formát, používá vaše UTM parametry a jeho texty nepůsobí jako psané umělou inteligencí.

Provozní návyky

Tabulky spouštěcích frází. Když vyslovíte určitou frázi, agent ví, které soubory otevřít a jaké kroky provést. Zde je příklad pro tým, který plánuje po týdnech:

„Naplánuj týden“ → otevři ops/monthly.md, vytvoř ve stejné složce YYYY-WNN.md a přesuň úkoly z ops/backlog.md pod příslušné dny. „Co je v backlogu?“ → přečti ops/backlog.md a vypiš obsah v seznamu. „Ukonči týden“ → vyplň část „Shrnutí týdne“ v souboru pro aktuální týden.

S takovými tabulkami se z Claudea stane „pomocník, který píše kód“, ale „operátor“, který zná rutinu vaší firmy. Každé pondělí řeknu „naplánujme týden“ a Claude otevře správné soubory, přečte si měsíční cíle a navrhne, jak úkoly rozdělit.

Jak zkontrolovat CLAUDE.md pomocí kontrolního seznamu o 12 bodech za 5 minut?#

1. Velikost. Je stručný, s přibližně 200 řádky jako cílem kontroly, nikoli stropem úspěchu či selhání?
2. Název. Jmenuje se přesně CLAUDE.md s velkými písmeny, nikoli claude.md?
3. Umístění. Je v kořenové složce projektu nebo v ./.claude/CLAUDE.md?
4. Popis projektu. Je z prvních 5 řádků jasné, co je projekt a komu slouží?
5. Nástroje. Jsou technologie vyjmenované výslovně a bez vaty?
6. Struktura. Obsahuje schéma repozitáře s vysvětlením?
7. Směrování. Obsahuje tabulku „otázka → soubor“ ukazující, kde hledat odpovědi?
8. Principy. Obsahuje část s pravidly začínajícími slovy „nikdy“ a „vždy“?
9. Konkrétnost. Je každé pravidlo ověřitelné? („Odsazuj 2 mezerami“, nikoli „piš krásně“.)
10. Průběžné aktualizace. Obsahuje pravidlo, aby agent „na konci relace zkontroloval, co přidat“?
11. Reflexe. Obsahuje pravidlo pro „zaznamenání shrnutí relace do retrospectives/“?
12. Zabezpečení. Jsou kritické zákazy (.env, rm -rf) také uvedeny v .claude/settings.json?

Pokud máte více než pět odpovědí „ne“, otevřete Claude a zadejte mu toto zadání:

Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.

Checklist:

Stručný pro daný úkol; kolem 200 řádků proveďte kontrolu bez považování počtu za tvrdý strop

Project description in the first 5 lines

Tools listed explicitly

Repository structure diagram included

“Question → file” table included

Principles section with rules included

Every rule is specific and verifiable

“Update at the end of the session” rule included

“Reflect at the end of the session” rule included

Critical prohibitions included in .claude/settings.json

No duplicates of the same rule in different sections

No dangling links to files that no longer exist

After the audit, give me a list of specific changes that will make the file living.

Co použít po CLAUDE.md: Plan Mode, Skills, nebo sub-agenty?#

CLAUDE.md je základ. Jakmile funguje, můžete přidat tři mechanismy Claude Code, které se vzájemně posilují.

Plan Mode. Režim, ve kterém Claude nejprve vytvoří plán změn, počká na vaše schválení a teprve pak začne pracovat. Aktivujte ho pomocí Shift+Tab nebo příkazem /plan. Řeší hlavní slabinu vibe codingu: „Požádal jsem Claudea, aby opravil jednu věc, a on přepsal polovinu projektu.“ V Plan Mode se to nestane – plán uvidíte dřív, než agent sáhne na soubory.

Skills. Samostatné soubory .md ve složce .claude/skills/, které obsahují znalosti pro konkrétní typ úkolu. Například skill „jak napsat migraci databáze“ obsahuje konkrétní postup, šablonu a příklady. Tyto znalosti nejsou v CLAUDE.md, protože by byly příliš rozsáhlé. Když však Claude narazí na úkol typu „napiš migraci“, načte příslušný skill a řídí se jím.

Sub-agenti. Pokud úkol vyžaduje velké množství kontextu (například kontrolu rozsáhlé funkce), Claude může spustit samostatného sub-agenta v jeho vlastním čistém kontextu. Sub-agent úkol zpracuje a vrátí výsledek, aniž zahltí kontext hlavního chatu.

Všechny tři mechanismy používají CLAUDE.md jako vstupní bod: na začátku práce ho přečtou, aby porozuměly kontextu projektu. Proto tyto funkce bez průběžně aktualizovaného CLAUDE.md fungují špatně. Nejdřív základ a pak další vrstvy.

Další krok. Vytvořte soubor CLAUDE.md v kořenové složce projektu, zkopírujte šablonu ze začátku tohoto článku a pomocí pomocného zadání vyplňte pole v hranatých závorkách. Pak se souborem pracujte: každou chybu agenta proměňte v nový řádek. Po dvou nebo třech týdnech přestane být CLAUDE.md „dokumentem, který jsme napsali a zapomněli na něj“ a stane se něčím, k čemu se Claude skutečně vrací při každé relaci.

Chcete-li kolem CLAUDE.md vybudovat kompletní rámec – složku business/ pro druhý mozek, složku about-me/ pro vaši digitální podobu, základní skills a nakonfigurovaný Plan Mode – použijte postupy a příklady v tomto článku. Návody Ailoot.

Pokračujte s Ailoot.