Dzielenie wiedzy — repo ai-toolkit-internal + brown-bag cadence

Pytanie 20 (Wzmacnianie organizacji): Jak zespół dzieli się know-how o AI tooling (skills, prompty, MCP, triki)?

Maksymalna odpowiedź: Repo ai-toolkit-internal ze skills/MCP/rules/hooks + regularne brown-bag sessions.

Dlaczego to ważne: Półokres trwania “best practice” w tej przestrzeni to ~3 miesiące. Zespół, który się nie dzieli swoimi znaleziskami, uczy się tych samych rzeczy ponownie co kwartał.

Dlaczego to ważne w 2026 (półokres trwania 3 miesiące)

Najbardziej niedoceniany koszt w organizacji inżynierskiej korzystającej z AI tooling w 2026 to nie licencje, nie compute, nie review bandwidth. To podatek od ponownej nauki: powtarzający się hit, który zespół przyjmuje, gdy każdy inżynier niezależnie odkrywa ten sam trik, tę samą pułapkę MCP, ten sam wzorzec promptu, ten sam recipe na hook, który ktoś inny w zespole już rozwiązał miesiąc temu.

Powód, dla którego ten podatek jest tak brutalny w 2026, to tempo zmian pod spodem narzędzi. Claude Code shipował sub-agentów, potem plugins, potem Skills, potem Skills v2, potem ujednolicony plugin marketplace — wszystko w ciągu dwunastu miesięcy. Cursor zreorganizował się wokół rules-then-agents-then-rules-again. CLI OpenAI Codex dwa razy zmieniło semantykę approval. Serwery MCP przeszły z /sse na /mcp w skali całej branży, format Skills wygryzł .cursorrules, a sposób, w jaki spina się hooks, slash commands i CLAUDE.md, był przepisywany mniej więcej co kwartał. Survey Pragmatic Engineer z stycznia-lutego 2026 stawia Claude Code na #1 wśród narzędzi AI coding, osiem miesięcy po release; Cursor był #1 rok wcześniej. To jest tempo.

Empirycznie: “best practice”, którą zapisaliśmy w lutym, nie przeżywa maja. Może 60% z niej nadal działa, ale części, które się zmieniły, to części, które mają znaczenie — części, które decydują, czy zespół shipuje nowym wzorcem czy walczy ze starym. Zaczęliśmy to nazywać regułą trzymiesięcznego półokresu: każdy guideline AI tooling starszy niż kwartał ma szanse na bycie błędnym jak rzut monetą, a jeszcze gorszą szansę bycia optymalnym.

Są tylko dwa sposoby, w jakie zespół inżynierski przeżywa to wszystko. Albo każdy inżynier nadąża indywidualnie — czyta changelogi, ogląda ogłoszenia, czaja się na X i Discordzie, przepisuje swój setup w każdy weekend — co dzieje się w firmach z jednocyfrowym headcountem i tooling-obsesyjnymi foundersami, i pęka w sekundzie, kiedy zatrudnisz kogokolwiek normalnego. Albo zespół dzieli obciążenie: jeden inżynier dowiaduje się o nowym formacie Skills we wtorek, demouje go na czwartkowym brown-bagu, commituje działającą wersję do ai-toolkit-internal w piątek, i w poniedziałek rano każdy inżynier w firmie ma to załadowane.

To właśnie koduje maksymalna odpowiedź na Q20. Repo to wspólny substrat. Brown-bag to mechanizm rozsiewania. Razem konwertują godzinę odkrywania-czegoś jednego inżyniera w kompetencję całego zespołu — i robią to w cadence pasującym do tego, jak szybko zmieniają się narzędzia pod spodem.

Jak wygląda “max score” w praktyce (repo + miesięczny brown-bag + nagrane archiwum)

Trzy komponenty, każdy robi dokładnie jedno:

1. Repo ai-toolkit-internal. Jedno repozytorium git w Twojej organizacji. W środku: każdy skill, każda konfiguracja MCP, każdy współdzielony template CLAUDE.md, każdy skrypt hook, każdy slash command, każdy prompt, który zespół uznał za wart zachowania. Struktura folderów jest opinionated i stabilna. Ownership jest realny — nazwany zespół lub gildia reviewują PR-y. Nowi inżynierowie klonują to w day one jako część bootstrapu dotfiles.

2. Miesięczny brown-bag. Trzydzieści minut w kalendarzu, ten sam czwartek każdego miesiąca. Forma jest sztywna z założenia: jeden inżynier demouje coś, co zashipował (na żywo, screen-share, w faktycznym narzędziu), i jeden inżynier prezentuje jeden nowy wzorzec, który chce, żeby zespół przyjął. Dwadzieścia minut treści, dziesięć minut pytań. Koniec.

3. Nagrane archiwum. Każdy brown-bag jest nagrywany — Loom, Zoom, internal video, bez znaczenia — i link wpada do README w ai-toolkit-internal/archive/ z jednoliniowym podsumowaniem i datą. Inżynierowie, którzy nie mogli być na żywo, oglądają nagranie na 1.5x. Nowi hires oglądają ostatnich sześć. Archiwum jest przeszukiwalne, cytowalne i rosnące.

Synergia jest tym, co ma znaczenie. Repo bez brown-baga to wysypisko, którego nikt nie czyta. Brown-bag bez repo to fajny czat, który wyparowuje następnego dnia. Brown-bag bez archiwum jest OK dla obecnych na żywo i niewidoczny dla wszystkich innych, włącznie z następnym inżynierem, którego zatrudnisz. Pełny setup — repo, cadence, archiwum — to konfiguracja, która naprawdę bije trzymiesięczny półokres.

Konkretny przykład tego, jak to wygląda w locie: inżynierka zauważa w środę, że nowe endpointy MCP /mcp mają 2-minutowy timeout, który łamie długo działające narzędzia. We czwartek rano fileuje skill mcp/timeout-workaround/ w ai-toolkit-internal, demouje fix na czwartkowym brown-bagu (powtarzalny slot), i w poniedziałek następna sesja agenta każdego inżyniera ładuje workaround automatycznie, bo repo jest wpięte w ich ~/.claude/. Całkowity czas zegarowy od “jedna osoba wie” do “wszyscy mają”: cztery dni. Bez systemu ten sam fix jest tłumaczony na Slacku trzy razy, połowa zespołu nigdy go nie widzi, a nowy hire dołączający w czerwcu odkrywa go od zera.

Aktualny krajobraz (zweryfikowany web-searchem)

Co wchodzi do ai-toolkit-internal (skills, konfiguracje MCP, skrypty hooks, template CLAUDE.md, slash commands)

Konwencja 2026 — ustawiona przez community references jak ekosystem awesome-claude-code-toolkit i wzmocniona przez team writeups na temat “how to share Claude Code Skills with your team” — to trzymanie repo opinionated i flat na tyle, żeby inżynier mógł znaleźć cokolwiek w dwóch kliknięciach. Kanoniczny layout:

acme/ai-toolkit-internal/
├── README.md                      # czym to jest, jak zainstalować, kto jest ownerem
├── bootstrap.sh                   # idempotentny installer (patrz Q6, Q18)
├── CHANGELOG.md                   # każdy PR dopisuje tutaj
├── CODEOWNERS                     # ownership per katalog
│
├── skills/                        # patrz Q6 — folder per skill z SKILL.md
│   ├── refactor-auth/
│   ├── ship-polar-webhook-fix/
│   └── audit-worker-cost/
│
├── rules/                         # patrz Q5 — fragmenty CLAUDE.md + .claude/rules/
│   ├── style.md
│   ├── security.md
│   └── company-claude-md.template
│
├── mcp/                           # patrz Q7 — konfiguracje MCP używane przez zespół
│   ├── README.md                  # które MCP, dlaczego, ownership
│   ├── stripe.mcp.json
│   ├── linear.mcp.json
│   ├── sentry.mcp.json
│   └── internal-deploy.mcp.json
│
├── hooks/                         # patrz Q18 — współdzielone skrypty hooks
│   ├── pre-commit-secret-scan.sh
│   ├── session-start-sync.sh
│   └── stop-auto-pr.sh
│
├── commands/                      # slash commands ładowane do ~/.claude/commands/
│   ├── ship.md
│   ├── review.md
│   └── audit-deps.md
│
├── prompts/                       # reużywalne snippety promptów (referencjowane ze skills)
│   ├── pr-description.md
│   └── incident-postmortem.md
│
├── templates/                     # plik startowe: nowy CLAUDE.md, AGENTS.md, etc.
│   ├── CLAUDE.md.template
│   └── AGENTS.md.template
│
└── archive/                       # indeks nagrań brown-bag + ADR-y
    ├── README.md                  # datowany indeks z linkami + 1-line summaries
    └── adr-001-claude-vs-codex.md

Decydująca idea jest taka, że to jest jedno repo. Nie siedem. Nie repo skills i repo hooks i repo MCP-configs i repo slash-commands z osobnym CODEOWNERS i osobnymi skryptami bootstrap. Jedno repo, bo inżynier, który właśnie coś rozkminił, nie powinien musieć decydować, do którego repo należy jego PR. Wybiera folder, fileuje PR, a maintainerzy go zroutują w razie potrzeby.

Druga decydująca idea: install to jedna komenda. Skrypt bootstrap.sh spina każdy folder we właściwe miejsce na maszynie developera — skills symlinkują się do ~/.claude/skills/, konfiguracje MCP mergują się do user-level MCP registry, skrypty hooków są symlinkowane do ~/.claude/hooks/, slash commands do ~/.claude/commands/, template CLAUDE.md jest dropowany do nowych repo przez acme new-repo. Jedna komenda, jedno źródło prawdy, każde narzędzie spięte.

Brown-bag cadence (miesięcznie, 30 min, jedno demo + jeden nowy wzorzec)

Wzorzec brown-bag, który przyjął się w organizacjach inżynierskich w 2026, zbiegł się do czegoś bliskiego pierwotnemu modelowi Spotify i Etsy, z jednym ważnym update’em na erę AI tooling: show-and-tell jest obowiązkowe, prezentacja jest opcjonalna. Cadence:

Częstotliwość: miesięcznie. Co tydzień to za dużo (nic nowego nie dzieje się w tym tempie w day-to-day pojedynczego inżyniera). Co kwartał to za mało (trzy miesiące to półokres — nie możesz pozwolić sobie tyle czekać z dzieleniem się). Co miesiąc to sweet spot. Ten sam dzień, ta sama godzina, ten sam slot w kalendarzu, żeby był po prostu brown-bag, a nie “następny brown-bag, który musimy zaplanować”.
Długość: 30 minut, twardo. Presja kalendarzowa jest realna. Inżynierowie chronią 30-minutowe sloty; aktywnie unikają 60-minutowych. Pułap 30 minut wymusza zwięzłość i sprawia, że obecność jest non-negotiable.
Forma: jedno demo + jeden nowy wzorzec. Dwadzieścia minut treści podzielone między dwóch prezenterów. Demo to ktoś pokazujący zespołowi coś, co faktycznie zashipował — “oto skill, który napisałem do refaktorowania naszego Polar webhook handlera, patrzcie jak go używam”. Slot na nowy wzorzec to ktoś argumentujący za zmianą w sposobie pracy zespołu — “Claude Code zashipował sub-agentów, mam u siebie działający setup, chcę go wrzucić do repo”.
Owner: rotuje. Każdego miesiąca inny inżynier umawia spotkanie i prowadzi. Obniża bus factor, dystrybuuje zbieranie sygnału i wymusza, żeby każdy inżynier zwracał wystarczającą uwagę w trakcie miesiąca, by znaleźć demo, gdy przyjdzie jego kolej.
Output: wpis archive/YYYY-MM-DD.md. Jednoakapitowe podsumowanie, linki do nagrania i wszelkich PR-ów, które wylądowały w repo w wyniku. MC pisze to tego samego dnia. Pięć minut pracy.

Jest jeden wzorzec, który bije każdą inną ramę dla zmuszenia opornych zespołów do faktycznego robienia brown-bagów: demo nie musi być wypolerowane, ale PR do repo musi wylądować w tym tygodniu. Sensem brown-baga nie jest wystąpienie — to artefakt. Demo bez PR było gawędą. PR bez demo to kontrybucja. Zadaniem brown-baga jest być forcing function, który zamienia jedno w drugie.

Nagrywanie + archiwizowanie (Loom, internal video, transkrypty)

Nagrywanie sesji to różnica między brown-bagiem, który się skaluje, a brown-bagiem, który się nie skaluje. Inżynierowie dołączający po sesji na żywo — a to większość inżynierów, bo masz rodziców, różnice stref czasowych, rotacje on-call i konkurujące meetingi — muszą móc dogonić to we własnym czasie. Trzy wzorce działają w 2026:

Cloud recording w Zoomie albo Google Meet. Najprostsza opcja. Nagranie żyje w platformie; link idzie do archive/README.md. Minus: ufasz polityce retencji platformy.
Loom dla krótkich, sfokusowanych demo. Kiedy demo to “oto skill, oto ja go uruchamiam, oto co wyprodukował”, 5-10 minutowy format clip Looma jest często lepszym artefaktem archiwalnym niż pełna sesja. Wiele zespołów nagrywa oba: sesję na żywo dla obecnych, ciaśniejszy Loom do archiwum.
Internal video hosting (np. Mux, Cloudflare Stream, Confluence/Notion video). Dla zespołów, które traktują compliance poważnie, hostowanie nagrania wewnątrz perymetru to właściwa odpowiedź. Trochę więcej setupu; permanentne, przeszukiwalne i Twoje.

Dwie praktyki do dorzucenia na wierzch któregokolwiek z nich:

Transkrypty. Whisper albo wbudowana transkrypcja platformy, dumped jako plik transcripts/YYYY-MM-DD.md w repo. To tutaj historia z wyszukiwaniem staje się realna — sześć miesięcy później, gdy ktoś szuka “tej rzeczy o timeoutach MCP”, git grep po transkryptach od razu znajduje właściwą sesję.
Jednoakapitowe podsumowanie w indeksie. TL;DR to to, co większość ludzi faktycznie czyta. Pięć zdań: co było zademonstrowane, jaki był nowy wzorzec, co zmieniło się w repo, kto prezentował, kiedy. Nagranie jest źródłem prawdy; podsumowanie jest wpisem indeksu, który sprawia, że nagranie jest znajdywalne.

Sensem wszystkich trzech warstw — nagrania, transkryptu, podsumowania — jest to, że brown-bag staje się trwałym artefaktem. Sześć miesięcy później nowy hire uczący się Twojego stacka powinien móc obejrzeć ostatnich dwanaście sesji na 1.5x i dojść do aktualnego state of the art zespołu bez rozmawiania z kimkolwiek. To jest test.

Reviewowanie tego, czym dzielą się inne firmy (Awesome Claude Code, Cursor Directory, X/Discord)

Druga połowa problemu półokresu to połowa inbound: trzymanie ręki na pulsie tego, co reszta branży shipuje. Żadne wewnętrzne repo ani cadence nie zastąpi faktycznego oglądania, co robią dobre zespoły gdzie indziej. Zestaw kanałów inbound, który przyjął się w 2026:

Ekosystem awesome-claude-code-toolkit. Kuratowane repozytoria katalogujące community skills, agentów, hooks, MCP i pluginy. Najbardziej kompleksowe listują setki skills, dziesiątki agentów i ciągle aktualizowany indeks działających konfiguracji. To nie ewangelia — większość tego, co tam jest, jest OK ale niewyróżniające się — ale rzeczy, które są wyróżniające się, są widoczne, bo dostają pull requesty, gwiazdki i write-upy. Subskrybowanie releasów to tani sygnał.
vercel-labs/agent-skills. Najstaranniej utrzymywany korporacyjny zestaw skills na GitHubie. Kiedy pojawia się tu top-tier vendor pattern, wart jest slotu brown-bag.
Cursor Directory i ekosystem awesome-cursorrules. Ta sama idea dla użytkowników Cursora — wzorce, które działają, contributowane przez pracujące zespoły, sortowalne po gwiazdkach i świeżości.
X (Twitter), Discord, newsletter Pragmatic Engineer. Najszybciej poruszające się informacje żyją w żywych kanałach. DevRel Anthropic, Cursora i OpenAI ogłaszają featury na X najpierw; community Discordy (Discord Anthropic, różne Discordy Cursora i Claude Code) wyciągają działające konfiguracje minuty po release. Jeden inżynier w zespole rotujący rolę “obserwujesz żywe kanały w tym miesiącu” wystarcza.
Changelogi vendorów. Anthropic, Cursor, OpenAI, GitHub Copilot, Continue.dev, Aider, Cline — każde sensowne narzędzie shipuje changelog. Agregowanie ich w kanale Slack (changelog-aggregator, RSS-to-Slack, albo prosty Cloudflare Worker, który polluje i postuje) to jedna z najwyższych ROI inwestycji półdniowych, które AI tooling lead może zrobić.

Wewnętrzne repo jest dla wszystkiego, co zweryfikowałeś, że działa w Twoim stacku. Kanały inbound są dla wszystkiego innego — puli kandydatów, z której wybierane są demo na brown-bag następnego miesiąca.

Krok po kroku: uruchamianie ai-toolkit-internal

Stwórz repo z kanonicznym layoutem.

Zakręć acme/ai-toolkit-internal (albo cokolwiek jest Twoim prefixem org). Dodaj osiem top-level folderów z layoutu powyżej plus README, CHANGELOG, CODEOWNERS i stub bootstrap.sh. Commit, push, tag v0. Pierwszy PR powinien być README tłumaczącym, do czego jest to repo, kto jest ownerem i jak zainstalować. Spraw, żeby ten PR był czytelny dla każdego inżyniera w org — to dokument, na który będą wskazywać nowym hires.
Posiej każdy folder jednym realnym artefaktem.

Puste foldery to cmentarze. Zanim ogłosisz repo, włóż jedną prawdziwą rzecz do każdego folderu: jeden produkcyjny skill do skills/, jedna konfiguracja MCP, której zespół faktycznie używa, do mcp/, jedna współdzielona reguła do rules/, jeden skrypt hook do hooks/, jeden slash command do commands/, jeden startowy CLAUDE.md.template do templates/. Teraz repo jest użyteczne day one, a nie aspiracyjnym szkieletem.
Napisz skrypt bootstrap i dogfood go.

Pożycz wzorzec z Q6 — sklonuj repo do ~/.acme-ai-toolkit/, symlinkuj każdy podkatalog do właściwego miejsca pod ~/.claude/, ~/.cursor/ i ~/.codex/. Zainstaluj slash commands. Spinaj konfiguracje MCP w user-level MCP registry. Uruchom go na swoim laptopie pięć razy z rzędu, żeby potwierdzić idempotency. Potem uruchom go na czystym VM — świeże dotfiles, świeży ~/.claude/. Napraw każde złamane założenie ścieżki, zanim jakikolwiek inny inżynier kiedykolwiek go uruchomi.
Zaplanuj cykliczny brown-bag i wybierz pierwszego MC.

Wstaw cykliczny 30-minutowy slot w kalendarzu zespołu. Ten sam dzień, ta sama godzina, każdy miesiąc. Wybierz pierwszego MC — zwykle AI tooling lead albo ktokolwiek jest ownerem repo. Zbrief go: “Twoim zadaniem jest znaleźć jednego inżyniera z demo i jednego z nowym wzorcem, i napisać wpis archiwum potem. To wszystko.” Zaplanuj slot drugiego miesiąca i MC trzeciego miesiąca w tym samym czasie, żeby cadence był widocznie zatwierdzony.
Przeprowadź pierwszy brown-bag ze swojego własnego demo.

Na pierwszą sesję MC demouje coś sam — typowo skrypt bootstrap, przechodząc przez to, co jest instalowane i dlaczego. Slot “nowy wzorzec” idzie do jakiejkolwiek pojedynczej zmiany, którą chcesz, żeby zespół przyjął następnie (często: “wszyscy powinni mieć zainstalowane to repo na swoim laptopie do końca tygodnia”). Zakończ sesję zaproszeniem kalendarzowym na następną i postem na Slacku linkującym nagranie i wpis archiwum.
Zrób z installu krok day-1 onboardingu.

Dodaj curl -fsSL https://acme.dev/ai-toolkit-internal/install | bash do skryptu setupu nowych hire. Pierwszy dzień nowego inżyniera powinien się skończyć z claude otwierającym się z każdym company skill, każdym współdzielonym MCP, każdym team hook i każdym slash command pre-loaded. Nigdy nie powinni musieć pytać Slacka “czy używamy X?” — odpowiedź jest w ich terminalu.
Nagradzaj kontrybucję publicznie.

Każdego miesiąca brown-bag jest miejscem, gdzie kontrybucje dostają widoczne uznanie. MC wymienia inżynierów, których PR-y wylądowały w repo w tym miesiącu. Engineering leads cytują kontrybucje do repo w 1:1. Jeśli kontrybuowanie do ai-toolkit-internal nie sprawia wrażenia nagradzanego, kontrybucje wysychają — a repo gnije w “rzecz, którą napisał lead”. Trzymaj pętlę społeczną ciasno.
Audytuj kwartalnie.

Co kwartał — raz na sezon, zgodnie z półokresem — przejdź repo pod kątem gnicia. Skills, które nie były ładowane od dwóch kwartałów, idą do archiwum. Konfiguracje MCP wskazujące na deprecated endpointy są naprawiane albo usuwane. Skrypty hook referencjonujące martwe URL-e są patchowane. Archiwum nagrań brown-bag to łatwa wersja tego: każdy wzorzec, który był “the new hotness” w lutym, ale nie przeżył do maja, to coś, co kwartalny audyt łapie.

Częste pułapki

Używanie Slacka (albo Notion, albo Confluence) jako archiwum. Najczęstszy fail. Inżynierowie postują sprytne znalezisko w #engineering albo #ai-tooling, wątek dostaje kilka thumbs-upów, i potem jest niewidoczny. Search Cię nie uratuje — search Slacka jest zły, a nawet gdyby nie był, nikt nie szuka w Slacku “jak ustawiamy MCP”. Slack jest do żywej rozmowy. Repo jest do trwałych artefaktów. Mylenie ich to failure mode.

Brak ownera. Repo, które jest odpowiedzialnością każdego, nie jest niczyją. PR-y siedzą tygodniami, CHANGELOG się starzeje, brown-bag jest odwoływany, bo nikt nie ownuje planowania. Nazwij ownera — tooling lead, gildię architektoniczną, AI rep platform team — i daj mu mały budżet czasu (10% to właściwy ballpark) na utrzymanie tego. Bez ownership problem półokresu połyka samo repo.

Brak cadence. Repo bez brown-baga jest czytane raz i zapomniane. Inżynierowie kontrybuują, gdy shipują rzecz; uczą się z nawzajem swoich kontrybucji tylko jeśli jest regularna forcing function do patrzenia na to, co nowego. Pomiń brown-bag, a repo staje się cmentarzem w ciągu kwartału.

Brak modelu kontrybucji. Jeśli jedyni ludzie fileujący PR-y to maintainerzy, zbudowałeś system dystrybucji top-down, a nie system wzmacniania zespołu. Cały sens to long tail — każdy inżynier eventualnie shipujący coś do repo. Obniż próg: zachęcaj do PR “ogarnąłem coś małego”. Pair-write pierwsze PR z nowymi kontrybutorami. Świętuj małe kontrybucje równie głośno jak duże.

Godzinowe brown-bagi. Stres kalendarzowy zabija obecność. Pierwszy raz, kiedy zaplanujesz 60-minutową sesję, połowa zespołu ją odpuści; drugi raz brown-bag umiera. Twardy sufit 30 minut. Jeśli temat naprawdę potrzebuje więcej, to dwa sloty w dwóch miesiącach, nie jeden długi.

Demo bez PR. Brown-bag, który składa się z “oto rzecz, którą zrobiłem, fajna co?, anyway wracajmy do roboty”, jest pogaduchą. Dyscyplina jest taka: demo liczy się tylko, jeśli PR ląduje w repo w tym tygodniu. Inaczej wiedza zostaje w głowie demoującego, a brown-bag staje się rozrywką.

Traktowanie outside content jako źródła prawdy. Zespół, który subskrybuje releasy awesome-claude-code-toolkit i nigdy nie próbuje żadnego z wzorców, konsumuje, nie uczy się. Kanały inbound są pulą kandydatów; repo to miejsce, gdzie rzeczy idą po zweryfikowaniu w Twoim codebase. Pobranie community skill verbatim do produkcji bez brown-bag walkthrough to sposób, w jaki zespoły shipują subtelnie zepsute wzorce.

Pozwolenie, by repo rosło niekontrolowanie. Bez kwartalnego audytu repo akumuluje martwe artefakty szybciej niż żywe — a im więcej martwych artefaktów, tym trudniej inżynierom znaleźć żywe. Bądź gotów archiwizować agresywnie. Repo z 30 skills, którym ufasz, bije repo z 200 skills, którym nie ufasz.

Pomijanie nagrania. Brown-bag bez nagrania dociera tylko do ludzi, którzy akurat byli na meetingu. To zła grupa docelowa — większość wartości jest w asynchronicznym nadrabianiu. Nagranie, transkrypt i jednoakapitowe podsumowanie razem kosztują pięć minut i quadruplują zasięg.

Jak zweryfikować, że jesteś na miejscu

Dalsza lektura

Q5 · Wspólne reguły agenta Warstwa managed policy + per-repo CLAUDE.md + .claude/rules/, która żyje w folderze rules/ repo.

Q6 · Wspólne skills Podzbiór tego playbooka dla skill-repo — ten sam wzorzec instalacji, skupiony konkretnie na artefaktach SKILL.md.

Q18 · Governance hooków Folder hooks/ repo, z dodatkowym naciskiem na podpisane skrypty i audit traile.

Zrób CTO Scorecard 25 pytań, ~12 minut. Ocena tier + plan 30/60/90 + risk register.