Jak sdílet AI know-how v týmu: Claude Code pluginy a marketplace

📺 Záznam přednášky Petra Hovorky z Ackee Meets: Agentic Web Dev:

Proč by mělo deset vývojářů v jedné firmě vymyslet deset různých řešení téhož problému? AI transformace není o tom, že si každý nainstaluje Claude Code. Je o tom, jak nabyté superschopnosti sdílet – aby tým rostl společně a nováček naskočil do rozjetého vlaku během pár minut.

📋 TL;DR

• Agenti přestali být hračka a stali se běžným pracovním nástrojem. Tím se objevila nová výzva: jak řešení vymyslet jednou a sdílet ho dál.
• Sdílení není jen úspora práce. Přináší rychlejší učení celého týmu a hlavně konzistentní kvalitu AI výstupů napříč projekty a lidmi.
• Sdílení je jako cibule – má vrstvy: repo → projekt (více repozitářů) → tým → celá firma. Každá komponenta patří na jinou vrstvu.
• CLAUDE.md zůstává v repu a nikam dál. Skills, subagenti, hooks a MCP konfigurace se naopak sdílet dají. Plány z plan mode se nesdílejí.
• Na sdílení mezi repozitáři jsme zkoušeli npx skills od Vercelu (agentově nezávislé, ale jen skills a hooks) a nakonec zvolili nativní Claude Code pluginy distribuované přes marketplaces.
• Pravidlo, které drží pluginy zdravé: jeden plugin = jedna schopnost. Žádný obří frontend-plugin se vším.
• V Ackee máme tři úrovně marketplaces: projektový, týmový a celofiremní. Instalace je pak jedno /plugin, žádné kopírování skriptů.

⏳ Jak to začalo: od chytrého autocomplete k agentům

Cesta k tomu, že řešíte, jak sdílet AI know-how, má několik pater. To první přišlo v roce 2022 s GitHub Copilotem – AI jako chytrý autocomplete a hloupý programátor. Uměla dokončit řádek, ne vyřešit úkol.

V roce 2024 dorazili agenti. S přechodem na Cursor už AI zvládala jednoduché úkoly sama a začala si sahat i na věci mimo editor.

Na začátku roku 2026 přišel přechod na Claude Code a s ním i moment, kdy agent přestal být zajímavou hračkou a stal se běžným pracovním nástrojem. Co s ním jde reálně dokázat, jsme popsali v článku o přepisu legacy aplikace za týden, obecněji pak v textu o agentním vývoji a ADLC. A jak už to u běžných pracovních nástrojů bývá, přinesl vlastní sadu problémů.

🔄 Deset vývojářů, stejný problém, deset různých řešení

Úkoly, které dáváme AI, jsou často repetitivní. Z toho plynou dvě otázky, které si zpočátku nikdo neklade:

• Jak způsob řešení vymyslet jednou a aplikovat ho na stejný problém i v budoucnu?
• Jak tohle jednou vymyšlené řešení dostat k ostatním, kteří řeší to samé?

Bez odpovědi vzniká stav, který zná každá firma nad pěti lidmi: deset vývojářů narazí na stejný problém a každý si k němu vymyslí vlastní řešení. Devět z nich je zbytečných – a to desáté nikdo jiný nikdy neuvidí.

🧠 Proč sdílet: víc hlav víc ví a konzistentní kvalita

Kromě toho, že nemusíme znovu vymýšlet kolo, má sdílení dva méně zjevné efekty.

Víc hlav víc ví. Znalosti v týmu rostou mnohem rychleji, když se tvoří dohromady, než když se každý učí sám za sebe. Deset lidí, kteří deset různých objevů nikdy nesdílí, se za rok naučí zlomek toho, co by se naučili společně.

Konzistentní kvalita. Tohle je ten důležitější bod. Sdílené know-how srovnává úroveň AI výstupů napříč projekty i napříč členy týmu. Bez něj dostanete jednu codebase, kde agent píše přesně podle konvencí, a druhou, kde generuje kód, na který se bojíte podívat. Nemluvě o onboardingu – nováček si naklikáním pár pluginů rovnou stáhne firemní know-how, místo aby ho půl roku sbíral po Slacku.

🧅 AI cibule: co sdílet a na jaké vrstvě

Každý coding agent má sadu komponent – u Claude Code jsou to CLAUDE.md, skills, subagenti, hooks, MCP a LSP konfigurace, settings.json a plány z plan mode. Ostatní nástroje mají obdobné. Otázka „co z toho sdílet“ má jedinou správnou odpověď: záleží.

A záleží na tom, jak hluboko v cibuli se pohybujete. Protože sdílení má vrstvy.

Vrstvy jsou čtyři: repozitář, projekt (který může mít víc repozitářů), tým a celá firma. A pozor na směr, protože jsou ve hře dva. Distribuce jde odshora dolů: co žije na vyšší vrstvě, to se instaluje do těch nižších, ne naopak. Vznik je jiná věc – nápad se běžně zrodí v jednom repu a teprve když se osvědčí, povýší se o patro výš.

Konkrétně to vypadá takhle:

CLAUDE.md patří do repa a nikam jinam. Vždycky popisuje jednu konkrétní codebase, takže sdílet ho mezi projekty nemá smysl.

Skills, subagenti, hooks a MCP konfigurace jsou naopak ideální kandidáti – ale ne automaticky na nejvyšší vrstvě. Obecný skill na code review dává smysl sdílet na úrovni frontendového týmu, protože všechny frontendové projekty jedou na podobném stacku a stejných konvencích. Na celofiremní úroveň už ho vytáhnout nejde: každý tým má jiný stack a jiné konvence.

Plány z plan mode se nesdílejí. Váží se ke kontextu jedné konkrétní feature nebo opravy bugu, takže je nemá smysl dlouhodobě držet v main branchi. Občas se commitují na feature branch – když se na ní pracuje několik dní a ve víc instancích agenta, plán poslouží k udržení kontextu. Při mergi do hlavní větve ale letí ven.

🔌 Jak sdílet mezi repozitáři: npx skills, nebo Claude Code pluginy

V rámci jednoho repozitáře je sdílení vyřešené dvacet let – jmenuje se to git. Zajímavá otázka začíná až za jeho hranicí. Vyzkoušeli jsme dvě cesty.

npx skills má jednu velkou výhodu: není závislé na konkrétním coding agentovi. Nevýhoda je stejně jasná – sdílet umí skills a hooks, tedy méně, než jsme potřebovali. Chtěli jsme posílat dál i subagenty.

Volba proto padla na Claude Code pluginy – nativní řešení, které zabalí skills, subagenty, hooks i MCP konfiguraci a distribuuje je přes takzvané marketplaces.

📦 Anatomie pluginu: jeden plugin = jedna schopnost

Hned na začátku jsme si stanovili pravidlo, které se zpětně ukázalo jako klíčové: jeden plugin je jedna schopnost. Ta schopnost může být jediný skill, nebo celé workflow – skill plus hooky, subagenti a další součásti. Podstatné je, aby šlo o jednu zapouzdřenou schopnost, ne o skladiště nesouvisejících skillů.

Kdybychom si totiž udělali jeden obří frontend-plugin se vším, co kdy na frontendu potřebujeme, koupili bychom si dva problémy: do každého projektu bychom instalovali i věci, které tam nikdy nepoužijeme, a zbytečně bychom tím ujídali z omezeného kontextu agenta.

Struktura pluginu je pak vcelku nudná, což je dobře:

code-review-plugin/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── agents/
│   └── security-reviewer.md
├── hooks/
│   └── hooks.json
├── .mcp.json

V plugin.json jsou metadata – název, description a hlavně verze. Pluginy jsou totiž na rozdíl od marketplaces verzované, což je přesně to, co chcete, když skill používá pět projektů:

{
  "name": "code-review-plugin",
  "description": "Code review workflow: skill, security subagent a lint hooky",
  "version": "1.0.0"
}

Zbytek jsou složky s jednotlivými komponentami: skills/ s jedním nebo více skilly, agents/ s popisy subagentů, hooks/ a .mcp.json.

🏪 Marketplace: JSON, který drží pluginy pohromadě

Marketplace je v podstatě pole vašich pluginů definované jedním JSONem. Má název, popisek, vlastníka – a seznam pluginů, které obsahuje.

Za pozornost stojí, že plugin se odkazuje relativní cestou (./plugins/...), takže marketplace i pluginy mohou žít v jednom repozitáři. A že marketplace samotný verzi nemá – tu si nesou jednotlivé pluginy.

🏢 Hierarchie marketplaces: projekt, tým, firma

Vrstvy cibule se v praxi překlopily do tří úrovní marketplaces. U každé je typický obsah dost odlišný:

Projektový marketplace má smysl teprve tehdy, když projekt sahá do víc repozitářů. Pro jeden projekt v jednom repu je to zbytečná vrstva – tam stačí git. Když ale máte několik repozitářů se stejným release procesem, vyplatí se skill vytáhnout do pluginu a nemít ho všude rozkopírovaný.

Týmový marketplace je v našem případě frontendový. Protože všechny projekty jedou na skoro stejném stacku, mají i stejný linter a formatter – a tedy stejné hooky.

Celofiremní marketplace obsahuje jen to, co platí bez ohledu na platformu, ať jde o web, backend nebo mobil. Typicky práci s nástroji, které používá celá firma.

▶️ Instalace v praxi: jedno lomítko a settings.json

Praktická část je nečekaně krátká. V Claude Code otevřete /plugin, v záložce marketplaces dáte add marketplace a vložíte URL repozitáře. Ten se naklonuje a vy si vyberete, které pluginy chcete nainstalovat.

Zajímavá je volba pro koho instalujete. Buď jen pro sebe, nebo pro všechny, kdo na projektu pracují – v druhém případě zápis skončí v settings.json, který je v gitu. Jakmile si kolegové stáhnou změny, mají plugin taky. A pokud ho někdo používat nechce, zakáže si ho ve svém lokálním settings.local.json. Sdílené, ale ne vynucené.

Skill z pluginu se pak volá jako /nazev-pluginu:nazev-skillu.

Někdy naopak nechcete, aby si agent skill spouštěl sám a používal ho jen na vyžádání. Na to stačí zakázat jeho automatické vyvolání v settings.json:

{
  "permissions": {
    "deny": [
      "Skill(passwd-fe-release:release)"
    ]
  }
}

Marketplace se dá přidat i bez interaktivního průvodce, přímo do settings.json:

{
  "extraKnownMarketplaces": {
    "ackee-ai-marketplace": {
      "source": {
        "source": "git",
        "url": "https://gitlab.example.com/ai/ackee-ai-marketplace.git"
      }
    }
  }
}

Hlavní výhoda celého přístupu je ale správa. Plugin vytvoříte jednou, žije na jednom centrálním místě a ve /plugin u něj rovnou vidíte možnost update. Když skill vylepšíte, nemusíte ho ručně překopírovávat do pěti repozitářů a doufat, že jste na žádný nezapomněli – v každém projektu si ho updatujete, až se vám to hodí.

🧭 Co dát do CLAUDE.md (a co ne)

Když jsme u toho – v Ackee se ustálila jedna zásada: CLAUDE.md co nejmenší. Patří do něj to, co si agent nedokáže zjistit sám z codebase. Pravidla, jak se má chovat plan mode, nasměrování v monorepu, nezvyklosti architektury. Cokoliv, co si agent dohledá sám, tam být nemusí – jen by to ujídalo kontext.

Elegantní doplněk jsou rules, které se dají scopovat na konkrétní cesty. Nejsou to tvrdé invarianty, chovají se podobně jako CLAUDE.md, ale můžete si definovat pravidla, která se aktivují teprve při práci s určitými soubory. Třeba jen pro testy jedné platformy v monorepu.

🎯 Co si odnést

AI transformace ve firmě není součet individuálních instalací. Ten skutečný rozdíl nastává v momentě, kdy jednou vymyšlené řešení přestane být osobním trikem a stane se komponentou, kterou si kdokoliv nainstaluje jedním příkazem.

Recept je vědomě si rozmyslet, co patří do které vrstvy cibule – CLAUDE.md do repa, skills a hooky výš. Držet jeden plugin = jedna schopnost, ať nekrmíte projekty balastem. A postavit hierarchii marketplaces, aby update proběhl na jednom místě a ne v pěti repozitářích.

Tahle pravidla navíc nevznikla izolovaně na jednom místě – k jejich dnešní podobě přispěl i kolega z mobilního týmu a zbytek firmy je pak převzal. Přesně to je nejlepší možná ukázka toho, o čem celý článek je: nejlepší řešení nezůstane v jednom týmu.

A jak to máte nastavené vy? Rádi se přiučíme od zkušenějších – tohle jsou pravidla, která u nás vznikala v posledních měsících a určitě nejsou tesaná do kamene.

Celý příběh i s dotazy z publika najdete v záznamu přednášky. Termíny dalších Ackee Meets sledujte na Eventbritu a přihlaste se k newsletteru – příští takový obsah vám přijde přímo do schránky.