Claude Code best practices pro tým: 7, které drží

Best practices pro Claude Code, na kterých v týmu záleží, nejsou tipy na prompty. Je to sedm pravidel, která drží, i když se nikdo nedívá: krátký CLAUDE.md, který hlídá CI, jeden sdílený plugin, oprávnění a hooky v repozitáři, jedno issue na jeden PR, test, který nejdřív selže, a reviewer, který kód nepsal. Každé vynucuje soubor nebo kontrola, ne paměť.

Takhle u nás běží každý repozitář a AI dnes píše veškerý náš kód. Zbytek článku ukazuje, jak je každá praktika vynucená, se skutečnými soubory.

Které praktiky Claude Code v týmu drží?

Tipy jednotlivce žijí v jedné hlavě. Týmová praktika potřebuje místo, kde je zapsaná, a kontrolu, která si všimne, když se rozbije:

Tabulku čtěte i jako pořadí. První čtyři stojí jedno odpoledne. Poslední tři mění, jak teče práce.

1. Proč držet CLAUDE.md krátký a jak to vynutit?

CLAUDE.md a všechny vždy načítané soubory s pravidly jdou do kontextu při každém požadavku. Průvodce náklady od Anthropicu doporučuje držet ho pod 200 řádků a postupy přesunout do skillů, které se načtou, jen když se použijí.

„Držme to krátké“ vydrží asi dva týdny. Proto to náš validátor počítá. Sčítá CLAUDE.md i všechna vždy načítaná pravidla dohromady, proto má strop 300 řádků, ne 200:

# CLAUDE.md + every .claude/rules/*.md that loads on every session
# (rules scoped with `paths:` load only under matching paths and are skipped)
if [ "$total_lines" -gt 300 ]; then
  log_critical "Context budget exceeded: $total_lines lines (max 300)."
fi

Běží v CI v každém repozitáři. Ve firemních a klientských repozitářích build shodí, v repozitářích s kódem varuje.

Druhá polovina je, kam pravidlo patří. Osobní pracovní styl patří do ~/.claude. Všechno, co musí dodržovat celý tým, patří do repozitáře.

Jak rozdělit pravidla mezi CLAUDE.md, AGENTS.md a osobní soubory, podrobně rozebíráme v článku Pravidla pro AI kód v týmu.

2. Proč jeden sdílený plugin místo kopií?

Dřív jsme skilly na plánování, stavbu a review kopírovali do každého repozitáře. Během pár týdnů se kopie rozešly a některé byly prázdné kostry. Disciplína to nevyřešila. Vyřešil to jeden plugin, wizrd, náš interní plugin a CLI pro Claude Code (není veřejný). Skilly, agenti a hooky žijí v jednom repozitáři a každý další si ho zapne dvěma řádky v nastavení:

{
  "enabledPlugins": { "wizrd@digitaliko": true },
  "extraKnownMarketplaces": {
    "digitaliko": { "source": { "source": "directory", "path": "services/wizrd" } }
  }
}

Oprava review skillu se teď dostane do každé session při jejím dalším startu. Jak je samotný plugin postavený, je v článku Claude Code skills a pluginy pro tým.

3. Proč dát oprávnění do repozitáře?

Protože deny v repozitáři přebije allow kdekoli jinde. Claude Code kontroluje nejdřív deny, pak ask, nakonec allow, a to napříč všemi soubory s nastavením. Tým tedy rozhodne jednou, v .claude/settings.json: deny pro soubory .env a klíče, ask před pushem, mergem nebo deployem, allow pro skripty, kterými si agent kontroluje vlastní práci.

Všechno osobní zůstává v ~/.claude/settings.json. Tvar a naše konkrétní položky jsou v článku Claude Code permissions: co smí agent a kdy bypass.

4. Proč blokovat hooky místo proseb v CLAUDE.md?

Věta v CLAUDE.md je prosba. Jednoho říjnového dne agent napsal AI podpis do několika popisů pull requestů v našich vlastních repozitářích, a to v session, jejíž CLAUDE.md přesně tohle zakazoval jasnými slovy.

Opravou byl PreToolUse hook, který prochází každý příkaz git commit, gh pr a gh issue včetně souborů předaných přes --body-file a vrací exit 2. Komentář na začátku skriptu to shrnuje nejlíp: „A rule is a request. This is the lock.“ Pravidlo je prosba, tohle je zámek.

Hooky mají vlastní slabinu: můžou potichu mlčet a přesto procházet. Čtyři kontroly, které to odhalí, jsou v článku Claude Code hooks: proč naše hooky nedělaly nic.

5. Proč jedno issue na jeden PR?

Session agenta zapomíná. GitHub issue ne. Každý úkol začíná jako issue s popisem, co znamená „hotovo“, napsaným tak, aby reviewer mohl odpovědět ano, nebo ne, a končí jedním pull requestem s Closes #N.

To dává tři věci, které chatová session nedá. Plán je vidět dřív, než práce začne. Dva agenti můžou pracovat souběžně, každý ve vlastním git worktree na vlastní větvi, a nepřekážejí si. A zmergované pull requesty jsou changelog, takže nikdo nepíše výkaz práce.

Uvnitř session pomáhá plan mode. Kde přestává stačit týmu, je v článku Claude Code plan mode: kdy stačí týmu?

6. Proč musí test nejdřív selhat?

Agent umí napsat testy, které projdou, ať kód funguje, nebo ne. Naše brána proto spustí nové nebo změněné testy proti základní větvi, ještě bez opravy. Pokud projdou i tam, nic nedokazují a pull request jde zpátky. Počítá se jen test, který je bez změny červený a se změnou zelený. Celý mechanismus je v článku Red-green TDD s AI agentem.

7. Proč má kód zkontrolovat jiný agent?

Agent, který kód napsal, už přesvědčil sám sebe. Čerstvá session, která čte jen diff, najde, co autor přeskočil. Náš CI reviewer dostane seznam nástrojů jen pro čtení (git diff, git log, gh pr diff, Read, Grep) a checklist pro review z repozitáře. Komentuje. Nikdy neschvaluje. Ochrana větve vyžaduje člověka, takže merge je vždy lidské rozhodnutí. Nastavení a prompt jsou v článku AI code review: Claude Code v CI.

Kde má tým začít?

Ne všemi sedmi najednou. Pořadí, které fungovalo nám:

První tři kroky zaberou v existujícím repozitáři den. Čtvrtý je zvyk a trvá pár týdnů komentářů v review, než tým začne psát issues, které agent dotáhne bez doptávání.

Kde je váš tým dnes?

Počítejte, co už ve vašich repozitářích je, ne co lidé říkají, že dělají:

Nastavení, hooky, bránu a review workflow si můžete zkopírovat z našeho Claude Code production starteru pod licencí MIT.

Chcete tyto praktiky ve vašich repozitářích?

Nastavujeme je přímo v repozitářích týmu, společně s vývojáři, v rámci služby AI-native SDLC pro vývojové týmy. AI dnes píše veškerý náš kód a za výsledek ručí senior. Od roku 2023 jsme dodali 15+ produkčních projektů.

Ozveme se do dvou pracovních dnů a společně vybereme, co vyřešíme jako první.

Pokud si chcete nejdřív promluvit, domluvte si meeting na 15 minut s Filipem.

Která ze sedmi by se ve vašem týmu rozbila jako první, kdyby ji nikdo nekontroloval?

Časté otázky

Jaké jsou nejdůležitější best practices pro Claude Code?

Pro tým: krátký CLAUDE.md s vynuceným limitem, skilly a hooky sdílené jako jeden plugin, oprávnění v repozitáři, blokování hooky místo proseb v textu, jedno issue na jeden PR, každá změna doložená testem, který nejdřív selže, a review jiným agentem, než ji zmerguje člověk.

Jak dlouhý má být CLAUDE.md?

Tak krátký, aby se vyplatil při každém požadavku. Anthropic doporučuje pod 200 řádků. My počítáme CLAUDE.md a všechny vždy načítané soubory s pravidly dohromady a ve firemních a klientských repozitářích nad 300 řádků CI selže.

Patří nastavení Claude Code do gitu?

Týmová část ano: .claude/settings.json s oprávněními a hooky patří do repozitáře. Osobní preference jdou do ~/.claude/settings.json a lokální výjimky do .claude/settings.local.json, který v gitu není.

Jak sdílet Claude Code skilly v týmu?

Jako plugin, který si každý repozitář zapne v nastavení. Kopie skillů v jednotlivých repozitářích se během týdnů rozejdou, jeden plugin dá každé session stejné skilly, agenty a hooky.

Je plan mode best practice pro každý úkol?

Pro průzkum před větší změnou ano. V týmu ale plán musí žít i tam, kde ho přečtou ostatní, třeba v issue s akceptačními kritérii, ne jen v session jednoho vývojáře.