Tipy a nastavení

Jak si to nastavit, když začínáš

Tohle je praktická stránka. Co pro mě vibecoding znamená a proč zrovna tahle parta nástrojů je vedle na Vibe Coding — sem to nepatří a nebudu to opakovat. Tady je čisté jak: co zapnout, jak to mít nastavené a v jakém pořadí, aby člověk, který s tím začíná, nešlapal po stejných minách jako já. Není to úplný manuál. Je to výběr toho, co se po desítkách sezení osvědčilo.

Začni souborem CLAUDE.md

První věc v každém projektu, ještě než napíšeš jediné zadání. Do kořene projektu dej soubor CLAUDE.md. Je to paměť projektu — model si ho načte na začátku každé konverzace. Bez něj začínáš pokaždé od nuly a model hádá: neví, co stavíš, čeho se nemá dotknout, ani kam si má psát poznámky. S ním drží kontext napříč sezeními a chová se konzistentně.

Co tam patří, konkrétně:

  • Co projekt dělá — dvě tři věty, k čemu to je a pro koho. Ne historie, ne marketing. Stačí, aby model věděl, do čeho sahá.
  • Pravidla — jazyk výstupu, styl, formát, čemu se vyhnout. Co napíšeš sem, nemusíš opakovat v každé zprávě.
  • Čeho se nedotýkat — konkrétní soubory, složky nebo postupy, které jsou citlivé. Tohle ušetří nejvíc škody.
  • Kam ukládat poznámky — cesta k paměťovým souborům, ať se zápisky nesypou náhodně po projektu.

Nadpisy si drž krátké a věcné. Klidně doslova:

# Co projekt dělá
# Pravidla
# Čeho se nedotýkat
# Kam ukládat poznámky

Skills, hooks, agenti

Tři různé věci, které lidé pletou. Vyplatí se vědět, kdy sáhnout po které.

Skill je znalostní soubor, který se aktivuje sám podle kontextu. Pravidlo, podle kterého poznáš, že něco patří do skillu: vysvětluješ to potřetí. Když stejnou věc — postup, konvenci, jak se co v projektu dělá — opakuješ do třetice, je čas to zapsat jednou a nechat to, ať se to nabídne samo, když je to relevantní. Přestaneš se opakovat a model přestane improvizovat.

Hook je to, co se má stát automaticky — kontrola před commitem, formátování po editaci, zákaz nějaké operace. Klíčový rozdíl: hook spouští systém, ne model. Takže se to stane pokaždé, ne jen když si model vzpomene. Cokoli, co opravdu nesmí vynechat (bezpečnostní kontrola, ověření buildu), patří do hooku, ne do prosby v zadání.

Agenti jsou paralelní samostatné kontexty na nezávislé úkoly. Každý agent je vlastní pracovní vlákno s vlastní pamětí. Hodí se, když máš víc věcí, které spolu nesouvisí a nemusí běžet za sebou.

Pusť agenty paralelně

Tohle je největší zrychlostní pákový bod, který se snadno přehlédne. Když máš víc nezávislých úkolů — třeba bezpečnostní kontrolu, revizi výkonu a kontrolu typů — nepouštěj je za sebou. Pošli je jako víc agentů v jedné zprávě. Každý dostane vlastní kontext, běží souběžně a vrátí výsledek. Tři úkoly za sebou jsou tři čekání; tři agenti zároveň je jedno.

Tvrdá podmínka, na které to jinak spadne: agenti si nesmí sahat do stejných souborů. Jeden zapisující na jeden soubor v jeden čas. Když dva agenti píšou do téhož souboru, přepíšou si práci a výsledek je nepoužitelný. Rozděl práci tak, aby každý vlastnil svoje soubory. Když to nejde rozdělit čistě, není to úloha pro paralelní běh.

MCP servery — jak je přidat

MCP server je most mezi modelem a službou. Bez něj model jen mluví; s ním reálně čte databázi, nasadí web, založí stránku. Přidání má tři kroky, ne dlouhý rituál:

  • Zaregistruj server do konfigurace Claude Code. To je jednorázový zápis, kde řekneš, jak se server spouští.
  • Klíč přes proměnnou prostředí, nikdy natvrdo do kódu. Token, heslo, API klíč — vždy přes proměnnou, ne vepsané do souboru.
  • Restartuj sezení a ověř, že se nástroje načetly. Dokud to neověříš konkrétně, nevíš, že to funguje — nehádej z toho, že příkaz proběhl.

Klíče patří do .env nebo do správce tajemství, který je mimo repozitář. Nikdy do souboru, který jde na Git. Tohle není volitelné a vrací se to k tomu níž.

Git a commity

  • Git na všechno. Každý projekt vlastní repozitář hned, ne „až to bude hotové“. Ztracené sezení se přežije, ztracený kód bez historie ne. Repozitář zakládej u prvního smysluplného commitu, ne na konci.
  • Malé commity. Jedna změna, ověřit, další. Když smícháš refactor, novou funkci a opravu do jednoho commitu a ono se to rozbije, nepoznáš čím. Oddělené commity znamenají, že chybu izoluješ za minutu, ne za den.
  • Build verify před push. Než cokoli odešleš, ať build projde čistě lokálně. Rozbitý build na vzdáleném serveru se hledá výrazně hůř než ten samý problém na svém stroji, kde vidíš všechno.

Bezpečnost a tajemství

Nejlevnější pravidlo s nejvyšší cenou za porušení. Drž se ho od první minuty, ne až po prvním průšvihu.

  • Žádné klíče v kódu ani v Gitu. API klíče, hesla, tokeny — nikdy přímo v souboru, který se verzuje. Jednou pushnutý tajný klíč je v historii navždy, i když ho potom smažeš.
  • .env nebo trezor mimo repozitář. Tajemství žijí v .env nebo ve správci tajemství, který není součástí repozitáře.
  • Ověř, že citlivé soubory jsou v .gitignore. Nestačí předpokládat, že to tak je. Mrkni do .gitignore a potvrď, že .env a podobné soubory tam opravdu jsou, dřív než commituješ.
  • Záloha před úpravou důležité konfigurace. Před zásahem do settings.json, CLAUDE.md nebo .env si udělej .bak kopii. Stojí to sekundu, vrátí to data zpět, když se něco pokazí.

Cross-review druhým modelem

Co jde ven nebo je důležité, ať přečte jiný model, dřív než se to schválí. Tady tu roli dělá Gemini. Důvod je prostý: jeden model si sám sebe nezkritizuje — druhý model nemá důvod chválit první a aktivně v tom hledá díry. Není to ground truth, je to druhý pár očí; každou výtku si ještě ověř, ne každá sedí. Proč zrovna takhle a proč zrovna druhý model rozepisuju vedle na Vibe Coding — sem patří jen to, že se to dělá a kdy.

Paměť a průběžné poznámky

Sezení se může ztratit. Paměťový soubor zůstane. Z toho plyne celý postup:

  • Projektová paměť. CLAUDE.md plus poznámkové soubory, na které z něj odkážeš. Jedno místo, kam se ukládá, co se kdy stalo a proč.
  • Zapisovat průběžně, ne až na konci. Po každé změně — nasazení, oprava, úprava konfigurace — zápis hned, ne dávkově „potom“. To „potom“ nepřijde, sezení skončí dřív.
  • Stav před vyčištěním kontextu ulož. Než se kontext zkrátí nebo vyčistí, ulož aktuální stav do paměti. Jinak model po vyčištění neví, kde jste skončili, a začne dělat věci znovu.

Smysl celého tohohle bloku je jediný: stejná chyba se nemá opakovat podruhé. Když je zapsaná, neopakuje se. Když není, opakuje se spolehlivě.

Ověřuj konkrétní zkouškou, ne dojmem

Nikdy netvrď „načteno“, „připraveno“ nebo „funguje“ z toho, že příkaz proběhl bez chyby. Proběhlý příkaz není totéž co funkční výsledek. Ověř to konkrétní zkouškou — otevři stránku v prohlížeči, zavolej koncový bod, zkontroluj, že se nástroj opravdu načetl. Když zkoušku nemáš, řekni to na rovinu („spuštěno, ale neověřeno“), místo abys tvrdil hotovo. Půl ověřené práce, o které víš, že je půl, je lepší než celá, o které si jen myslíš, že je celá.

Když se zasekneš, oprav přímo

Když něco nejde nebo se to rozbije, oprav to přímo — ne pět agentů, co donekonečna něco sledují a hlásí, že stále nic. Decizní akce poráží monitorovací smyčku. Když je něco potřeba zkontrolovat, zkontroluj to jednou a podle výsledku jednej. Když pustíš agenta na něco pozaďového, ať vrátí konkrétní použitelný výsledek, ne nekonečné „čekám“. Sledování není práce; oprava je práce.

Tohle je výběr toho, co se osvědčilo, ne úplný manuál. Co konkrétně tu běží, co funguje a co se rozbilo, je upřímně popsané na Vibe Coding.