Claude Code mods: k čemu je využije programátor, designér i manažer

Claude Code umí hooky: shellové skripty, které se spustí před voláním nástroje nebo po něm a třeba zablokují git push --force na main. Jak je nastavit, popisuje samostatný průvodce. Addy Osmani 1. 10. 2026 na blogu claude.dev představil další vrstvu: mody.

Podle Osmaniho jsou mody „a way to fit Claude Code to how you work“, tedy způsob, jak si Claude Code přizpůsobit tomu, jak pracuješ. Mod je kus JavaScriptu nebo TypeScriptu, který běží přímo v Claude Code. Nemusí jen reagovat na události, umí je i přepsat nebo vyřídit sám. A umí kreslit vlastní UI: panel vedle konverzace, pás nad promptem, tlačítka. Nemusíš ho přitom psát sám, stačí ho Claudovi popsat.

Jedna věc se v nadšení snadno přehlédne: mod běží s tvými oprávněními.

Co je mod a čím se liší od hooku

Blog to shrnuje jednou větou: „Under the hood, mods are hooks, and they ship inside plugins.“ Mod je tedy sada JS nebo TS handlerů, která se distribuuje uvnitř pluginu. Claude Code je zavolá při události, jako je volání nástroje nebo odeslaný prompt. (Dokumentace to rozepisuje podrobně.)

Rozdíl oproti klasickým hookům Osmani popisuje takhle: „A settings hook runs a shell command for each event and passes JSON over stdin and stdout. A mod is loaded once and stays in the session.“ Settings hooky přitom nikam nemizí, administrátorská dokumentace výslovně píše: „Nothing about them is deprecated.“

Handler dostane $ (API Claude Code), e (data události) a next (další handler v řetězci, podobně jako middleware). Událost tak může sledovat (Observe), změnit (Rewrite) nebo vyřídit sám (Answer). Ukázka je spojuje do jednoho handleru a vychází z příkladu v dokumentaci událostí:

export function register(on) {
  on('tool.call', { tool: 'Bash' }, async ($, e, next) => {
    // Answer: událost vyřídí sám, next nezavolá
    if (/git push .*--force/.test(e.command)) {
      return { deny: 'Force push z agenta nepouštíme.' }
    }
    // Rewrite: pošle dál upravenou událost
    if (e.command.startsWith('npm ')) {
      return next({ ...e, command: e.command.replace(/^npm /, 'pnpm ') })
    }
    // Observe: zapíše příkaz do transcriptu a pustí ho dál
    $.ui.log('Bash: ' + e.command)
    return next(e)
  })
}

$.ui.log přidá do přepisu konverzace (transcriptu) tlumený řádek, který Claude nečte.

Srovnání s dalšími způsoby rozšíření podle dokumentace, zjednodušeně:

Všechny čtyři se dají zabalit do jednoho pluginu.

Co všechno mod umí

Mod může kreslit do bočního panelu (pane), do pásu nad promptem, do status line i do krátkých vyskakovacích hlášek (toastů). Dál umí registrovat slash příkazy a nástroje pro Clauda, spouštět procesy, volat HTTP a poslat samostatný dotaz na model, třeba levný Haiku. Kompletní seznam je v referenci.

Blog předvádí tři ukázkové mody:

• Token Weather kreslí nad promptem „počasí“ kontextového okna: procento zaplnění a vývoj za posledních 12 tahů (tah je jedna odpověď Clauda).
• Blast Radius podrží riskantní příkaz typu rm -rf, git reset --hard nebo force push, udělá dry-run a dopad ukáže v panelu s tlačítky Proceed a Cancel.
• Replay Theater zaznamená úpravy souborů během tahu a příkazem /replay je dovolí projít diff po diffu.

Než začneš vybírat podle role

Jedna podmínka platí pro všechny nápady níže: UI modu existuje jen uvnitř Claude Code. Hooky i UI fungují v CLI (včetně terminálu v editoru a v JetBrains) a v záložce Code v desktopové aplikaci Claude, kde se obejdeš bez terminálu. Ve VS Code chat panelu, v claude -p, v Agent SDK a v cloudu běží jen hooky bez UI. V Desktop WSL session mody neběží vůbec.

Mod můžeš Claudovi jen popsat a on ho napíše přes vestavěný skill plugin-authoring. Takový mod se ale načte jen v dané session, pro trvalé použití ho musíš zkopírovat do vlastního pluginu. A kód si přečíst, protože poběží s tvými oprávněními.

Všechno níže jsou nápady postavené na schopnostech výše, ne hotové mody. Příklady z dokumentace, na které se odkazuju, jsou na stránce Mods API.

Programátoři

Nejrychlejší start je vzít některou z ukázek v blogu a nechat Clauda, ať ji upraví podle tebe. Dál se nabízí:

• Pojistka před destruktivními příkazy podle vzoru Blast Radius, jen s vlastními pravidly týmu: terraform destroy, prisma migrate reset nebo mazání větví.
• Stav CI a PR ve status line, který se každou minutu obnoví přes gh pr checks (příklad v dokumentaci).
• Rozpočet kontextu: pás s varováním, že se blíží kompakce. Data o kontextu, limitech a ceně vrací $.session.usage().
• Hlídač rozsahu změn: toast, když Claude upraví soubor mimo adresář, na kterém se má pracovat.

Grafici a designéři

Do Figmy ani jiných aplikací mod nekreslí, data si ale přes HTTP stáhnout umí. Pokud designér s Claude Code sahá na frontend nebo design systém, nabízí se:

• Hlídač design tokenů: při úpravě CSS nebo komponenty upozorní toastem na natvrdo zapsanou barvu nebo pixely mimo tokeny. Případně zápis podrží a nechá rozhodnout tlačítkem.
• Kontrola proti Figmě: stejný hlídač, jen porovnává s hodnotami staženými přes Figma REST API. Potřebuje k tomu přístupový token do Figmy.
• Náhled palety v panelu: v desktopové aplikaci přes prvek Svg, v terminálu přes Raster z barevných buněk.
• Příkaz /a11y-check: spustí lokální kontrolu kontrastu nebo lint a výsledek ukáže v panelu.
• Formulář zadání v panelu: pár polí a výběrů (komponenta, varianta, breakpoint), které mod po odeslání pošle Claudovi jako prompt.

Management a PM

Pokud PM Claude Code sám používá, dávají smysl tyhle nápady:

• /standup: shrnutí změn za posledních N dní z gitu, volitelně učesané modelem (příklad v dokumentaci).
• /triage: levný model zařadí text tiketu jako bug, feature nebo dotaz (příklad v dokumentaci).
• Nástroj „ticket lookup“ pro Clauda, napojený přes HTTP na interní tracker, aby Claude při práci znal stav tiketu.

Pro manažera je zajímavější týmová rovina. Mody se distribuují uvnitř pluginů přes marketplace, takže tým si může udržovat vlastní repozitář se sadou modů jako sdílený standard: stejné pojistky, stejné příkazy. Z toho plynou rozhodnutí, která patří manažerovi:

• Kdo mody píše, reviewuje a udržuje. Je to kód, který běží na strojích celého týmu.
• Kolik smějí stát. Každé volání modelu z modu čerpá z uživatelova plánu nebo API klíče.
• Jestli povolit jen schválené mody. Firma to umí vynutit nastavením allowManagedModsOnly, technické detaily jsou v sekci o bezpečnosti.

QA a ops

Pro QA se nabízí mod, který po skončení každého tahu spustí testy dotčené změnami a výsledek ukáže v panelu. Stejnou logiku lze zaregistrovat i jako ruční příkaz /test-affected. U delších sad pozor: spuštění procesu má výchozí timeout 30 s. Druhý nápad je zamítnout commit nebo push, dokud testy neprojdou, a v zamítnutí uvést důvod.

Pro ops je nejbližší varianta Blast Radius pro produkci: mod zadrží kubectl nebo terraform s produkčním kontextem a nechá ho potvrdit tlačítkem. Dál se nabízí status line se stavem on-callu nebo incidentu, obnovovaná přes HTTP, a policy mod, který třeba loguje volání nástrojů. Jak se takový mod zapojí, popisuje administrátorská dokumentace.

Bezpečnost: mod běží s tvými oprávněními

Blog píše, že mod běží „in a sandbox of its own, with no DOM and no Node“. Dokumentace zároveň říká „Mods aren't sandboxed.“ Obojí platí, jen o něčem jiném. Izolovaný je JS runtime, ne oprávnění. Přes $ mod pracuje se soubory, procesy a sítí jako ty.

Osmani dodává, že mod píše jeho vydavatel, ne Anthropic. Podle dokumentace mod vidí všechny prompty a volání nástrojů, umí je přepsat, umí za tebe odeslat prompt, schválit volání nástroje bez dotazu a utrácet z tvého plánu. Sandboxing Bashe se na procesy spuštěné modem nevztahuje. Co mod nezmění, je obsah permission promptu.

Pro čtenáře průvodce hooky je tu důležité upřesnění: hook z běžných settings souborů může mod přebít, firemní hook z managed settings ne.

Podrobněji pro adminy: mod umí vrátit allow a schválit volání, které zablokoval PreToolUse hook mimo managed settings, nebo které by pravidlo ask nechalo potvrdit. Blokace z PreToolUse hooků v managed settings je konečná, ty běží před všemi mody. Pravidla deny mají přednost jen tam, kde se načte vestavěný guard sec-default (stroj s managed settings nebo plán Team či Enterprise), a ani tam se netýkají souborů a procesů, které mod obsluhuje sám. Hook ani mod navíc nenahradí ochranu na serveru. Dokumentace u příkladu s blokací pushe píše: „To block pushes to main for everyone, protect the branch on your Git host.“

Co z toho plyne v praxi:

• Ber cizí mody jako cizí balíčky. Osmani radí „read the repo first and only install from people you trust“.
• Před instalací spusť claude plugin validate. Statickou analýzou vypíše, na jaké události mod reaguje a co volá, aniž by ho spustil.
• Při podezření vypni jeden mod přes /plugin, všechny na jednu session přes --safe-mode, trvale přes "disableAllHooks": true, které ale vypne i běžné hooky.
• Ve firmě může admin povolit jen mody organizace a vestavěné mody (allowManagedModsOnly) a přidat vlastní policy mod. Detaily jsou v administrátorské dokumentaci.

Jak začít

Podle blogu potřebuješ Claude Code 2.1.287 nebo novější a mody jsou ve výchozím stavu zapnuté. Plugin s modem tvoří manifest .claude-plugin/plugin.json, soubor hooks/hooks.json s odkazem na modul a samotný modul s funkcí register, bez Node a bez build kroku. Testuje se přes claude plugin test, ladí přes claude --debug.

Závěr

Mody posouvají Claude Code z nástroje, který konfiguruješ, na nástroj, který si přestavíš.

Jestli chceš začít, vezmi jeden konkrétní opruz z vlastního workflow, popiš ho Claudovi a výsledný kód si přečti dřív, než ho necháš běžet natrvalo.