Knowledge sharing — ai-toolkit-internal repo + brown-bag cadence

Question 20 (Org enablement): How does the team share AI tooling know-how (skills, prompts, MCPs, tricks)?

Max-score answer: ai-toolkit-internal repo with skills/MCP/rules/hooks + regular brown-bag sessions.

Why it matters: The half-life of “best practice” in this space is ~3 months. A team that doesn’t share its findings re-learns the same lessons every quarter.

Why this matters in 2026 (3-month half-life)

The single most under-rated cost in an engineering org running AI tooling in 2026 isn’t licenses, isn’t compute, isn’t review bandwidth. It’s the re-learning tax: the recurring hit a team takes when every engineer independently re-discovers the same trick, the same MCP gotcha, the same prompt pattern, the same hook recipe that someone else on the team already solved last month.

The reason this tax is so brutal in 2026 is the rate of change underneath the tools. Claude Code shipped sub-agents, then plugins, then Skills, then Skills v2, then the unified plugin marketplace — all inside twelve months. Cursor reorganized around rules-then-agents-then-rules-again. OpenAI’s Codex CLI changed approval semantics twice. MCP servers went from /sse to /mcp industry-wide, the Skills format took over .cursorrules, and the way you stitch hooks, slash commands, and CLAUDE.md together has been rewritten roughly every quarter. The Pragmatic Engineer’s January–February 2026 survey put Claude Code at the #1 spot among AI coding tools, eight months after release; Cursor was #1 the year before. That’s the speed.

Empirically: the “best practice” we wrote down in February doesn’t survive May. Maybe 60% of it still applies, but the parts that changed are the parts that matter — the parts that decide whether your team is shipping with the new pattern or wrestling with the old one. We’ve started calling this the three-month half-life rule: any AI tooling guideline more than a quarter old has a coin-flip chance of being wrong, and a much worse chance of being optimal.

There are only two ways an engineering team survives this. Either every engineer keeps up individually — reading the changelogs, watching the announcements, lurking on X and Discord, rewriting their setup every weekend — which is what happens at companies with single-digit headcount and tooling-obsessed founders, and breaks the second you hire anyone normal. Or the team shares the load: one engineer learns about the new Skills format on Tuesday, demos it at Thursday’s brown-bag, commits the working version to ai-toolkit-internal on Friday, and by Monday morning every engineer in the company has it loaded.

That’s what the Q20 max-score answer encodes. The repo is the shared substrate. The brown-bag is the spreading mechanism. Together they convert one engineer’s hour of figuring-something-out into the whole team’s competence — and they do it on the cadence that matches how fast the underlying tools change.

What “max score” actually looks like (the repo + monthly brown-bag + recorded archive)

Three components, each doing exactly one job:

1. An ai-toolkit-internal repo. A single git repository under your org. Inside: every skill, every MCP config, every shared CLAUDE.md template, every hook script, every slash command, every prompt the team has found worth keeping. Folder structure is opinionated and stable. Ownership is real — a named team or guild reviews PRs. New engineers clone it on day one as part of their dotfiles bootstrap.

2. A monthly brown-bag. Thirty minutes on the calendar, same Thursday every month. The shape is rigid by design: one engineer demoes something they shipped (live, screen-shared, in the actual tool), and one engineer presents one new pattern they want the team to adopt. Twenty minutes of content, ten minutes of questions. Done.

3. A recorded archive. Every brown-bag is recorded — Loom, Zoom, internal video, doesn’t matter — and the link is dropped into the ai-toolkit-internal/archive/ README with a one-line summary and the date. Engineers who couldn’t make the live session watch the recording at 1.5x. New hires watch the last six. The archive is searchable, citable, and growing.

The synergy is what matters. The repo without the brown-bag is a dumping ground nobody reads. The brown-bag without the repo is a fun chat that evaporates the next day. The brown-bag without the archive is fine for the live attendees and invisible to everyone else, including the next engineer you hire. The full setup — repo, cadence, archive — is the configuration that actually beats the three-month half-life.

A concrete example of what this looks like in flight: an engineer notices on Wednesday that the new MCP /mcp endpoints have a 2-minute timeout that breaks long-running tools. She files a mcp/timeout-workaround/ skill in ai-toolkit-internal Thursday morning, demos the fix at Thursday’s brown-bag (the recurring slot), and by Monday every engineer’s next agent session loads the workaround automatically because the repo is wired into their ~/.claude/. Total elapsed wall-clock time from “one person knows” to “everyone has it”: four days. Without the system, that same fix gets explained on Slack three times, half the team never sees it, and the new hire who joins in June re-discovers it from scratch.

Current landscape (web-search-verified)

What goes in ai-toolkit-internal (skills, MCP configs, hook scripts, CLAUDE.md template, slash commands)

The 2026 convention — set by community references like the awesome-claude-code-toolkit ecosystem and reinforced across team writeups on “how to share Claude Code Skills with your team” — is to keep the repo opinionated and flat enough that an engineer can find anything in two clicks. The canonical layout:

acme/ai-toolkit-internal/
├── README.md                      # what this is, how to install, who owns it
├── bootstrap.sh                   # idempotent installer (see Q6, Q18)
├── CHANGELOG.md                   # every PR appends here
├── CODEOWNERS                     # ownership per directory
│
├── skills/                        # see Q6 — per-skill folder with SKILL.md
│   ├── refactor-auth/
│   ├── ship-polar-webhook-fix/
│   └── audit-worker-cost/
│
├── rules/                         # see Q5 — shared CLAUDE.md fragments + .claude/rules/
│   ├── style.md
│   ├── security.md
│   └── company-claude-md.template
│
├── mcp/                           # see Q7 — MCP server configs the team uses
│   ├── README.md                  # which MCPs we use, why, ownership
│   ├── stripe.mcp.json
│   ├── linear.mcp.json
│   ├── sentry.mcp.json
│   └── internal-deploy.mcp.json
│
├── hooks/                         # see Q18 — shared hook scripts
│   ├── pre-commit-secret-scan.sh
│   ├── session-start-sync.sh
│   └── stop-auto-pr.sh
│
├── commands/                      # slash commands shipped to ~/.claude/commands/
│   ├── ship.md
│   ├── review.md
│   └── audit-deps.md
│
├── prompts/                       # reusable prompt snippets (often referenced from skills)
│   ├── pr-description.md
│   └── incident-postmortem.md
│
├── templates/                     # starter files: new repo CLAUDE.md, AGENTS.md, etc.
│   ├── CLAUDE.md.template
│   └── AGENTS.md.template
│
└── archive/                       # brown-bag recordings index + ADRs
    ├── README.md                  # dated index with links + 1-line summaries
    └── adr-001-claude-vs-codex.md

The discriminating idea is that this is one repo. Not seven. Not a skills repo and a hooks repo and an MCP-configs repo and a slash-commands repo with separate CODEOWNERS and separate bootstrap scripts. One repo, because the engineer who just figured something out shouldn’t have to decide which repo their PR belongs to. They pick a folder, file the PR, and the maintainers route it if needed.

The other discriminating idea: install is one command. The bootstrap.sh script wires every folder into the right place on a developer’s machine — skills symlink into ~/.claude/skills/, MCP configs merge into the user-level MCP registry, hook scripts get symlinked into ~/.claude/hooks/, slash commands into ~/.claude/commands/, the CLAUDE.md template gets dropped into new repos by acme new-repo. One command, one source of truth, every tool wired up.

Brown-bag cadence (monthly, 30 min, one demo + one new pattern)

The brown-bag pattern that’s stuck across engineering orgs in 2026 has converged on something close to the original Spotify and Etsy model, with one important update for the AI tooling era: the show-and-tell is mandatory, the presentation is optional. The cadence:

Frequency: monthly. Weekly is too much (nothing new happens that fast in any one engineer’s day-to-day). Quarterly is too little (three months is the half-life — you can’t afford to wait that long to share). Monthly is the sweet spot. Same day, same time, same calendar slot, so it’s just the brown-bag not “the next brown-bag we have to schedule.”
Length: 30 minutes, hard. Calendar pressure is real. Engineers protect 30-minute slots; they actively avoid 60-minute ones. The 30-minute ceiling forces concision and makes attendance non-negotiable.
Shape: one demo + one new pattern. Twenty minutes of content split between two presenters. The demo is someone showing the team something they actually shipped — “here’s the skill I wrote for refactoring our Polar webhook handler, watch me use it.” The new-pattern slot is someone advocating for a change to how the team works — “Claude Code shipped sub-agents, here’s a setup that’s working for me, I want to put it in the repo.”
Owner: rotates. Each month a different engineer schedules and MCs. Lowers the bus factor, distributes signal-gathering, and forces every engineer to pay enough attention during the month to find a demo when their turn comes.
Output: a archive/YYYY-MM-DD.md entry. A one-paragraph summary, links to the recording and any PRs that landed in the repo as a result. The MC writes it on the day. Five minutes of work.

There’s one pattern that beats every other framing for getting reluctant teams to actually do brown-bags: the demo doesn’t need to be polished, but the repo PR has to land that week. The point of the brown-bag is not the talk — it’s the artifact. A demo that doesn’t produce a PR was a chat. A PR without a demo is a contribution. The brown-bag’s job is to be the forcing function that turns one into the other.

Recording + archiving (Loom, internal video, transcripts)

Recording the session is the difference between a brown-bag that scales and a brown-bag that doesn’t. Engineers who join after the live session — and that’s most engineers, since you have parents, time-zone gaps, on-call rotations, and competing meetings — need to be able to catch up on their own time. Three patterns work in 2026:

Zoom or Google Meet cloud recording. The simplest option. Recording lives in the platform; the link goes in archive/README.md. Downside: you’re trusting the platform’s retention policy.
Loom for short-form, focused demos. When the demo is “here’s a skill, here’s me running it, here’s what it produced,” Loom’s 5-10 minute clip format is often a better archive artifact than the full session. Many teams record both: the live session for the people who attend, a tighter Loom for the archive.
Internal video hosting (e.g., Mux, Cloudflare Stream, Confluence/Notion video). For teams that take compliance seriously, hosting the recording inside your perimeter is the right answer. Slightly more setup; permanent, searchable, and yours.

Two practices to add on top of any of these:

Transcripts. Whisper or the platform’s built-in transcription, dumped as a transcripts/YYYY-MM-DD.md file in the repo. This is where the search story gets real — six months later, when someone is looking for “that thing about MCP timeouts,” git grep over the transcripts finds the right session immediately.
A one-paragraph summary in the index. The TL;DR is what most people actually read. Five sentences: what was demoed, what the new pattern was, what changed in the repo, who presented, when. The recording is the source of truth; the summary is the index entry that makes the recording findable.

The point of all three layers — recording, transcript, summary — is that the brown-bag becomes a durable artifact. Six months later, a new hire learning your stack should be able to watch the last twelve sessions at 1.5x and arrive at the team’s current state of the art without ever having spoken to anyone. That’s the test.

The other half of the half-life problem is the inbound half: keeping up with what the rest of the industry is shipping. No internal repo or cadence is a substitute for actually watching what good teams elsewhere are doing. The set of inbound channels that’s stuck in 2026:

The awesome-claude-code-toolkit ecosystem. Curated repos cataloging community skills, agents, hooks, MCPs, and plugins. The most comprehensive ones list hundreds of skills, dozens of agents, and a constantly-updated index of working configs. They’re not gospel — most of what’s in them is fine but unremarkable — but the things that are remarkable are visible because they get pull requests, stars, and write-ups. Subscribing to releases is a cheap signal.
vercel-labs/agent-skills. The most carefully maintained corporate skill set on GitHub. When a top-tier vendor pattern shows up here, it’s worth a brown-bag slot.
The Cursor Directory and the awesome-cursorrules ecosystem. Same idea for Cursor users — patterns that work, contributed by working teams, sortable by stars and recency.
X (Twitter), Discord, the Pragmatic Engineer newsletter. The fastest-moving information lives in the live feeds. Anthropic’s, Cursor’s, and OpenAI’s developer-relations folks announce features on X first; community Discords (Anthropic’s Discord, the various Cursor and Claude Code Discords) surface the working configs minutes after a release. One engineer on the team rotating the “watch the live feeds for this month” role is enough.
Vendor changelogs. Anthropic, Cursor, OpenAI, GitHub Copilot, Continue.dev, Aider, Cline — every meaningful tool ships a changelog. Aggregating them in a Slack channel (changelog-aggregator, RSS-to-Slack, or a simple Cloudflare Worker that polls and posts) is one of the highest-ROI half-day investments an AI tooling lead can make.

The internal repo is for everything you’ve verified works in your stack. The inbound channels are for everything else — the candidate pool from which next month’s brown-bag demos get chosen.

Step-by-step: launching ai-toolkit-internal

Create the repo with the canonical layout.

Spin up acme/ai-toolkit-internal (or whatever your org prefix is). Add the eight top-level folders from the layout above plus a README, a CHANGELOG, a CODEOWNERS, and a bootstrap.sh stub. Commit, push, and tag v0. The first PR should be the README explaining what this repo is for, who owns it, and how to install it. Make that PR readable by every engineer in the org — it’s the doc they’ll point new hires at.
Seed every folder with one real artifact.

Empty folders are graveyards. Before you announce the repo, put one real thing in each folder: one production skill in skills/, one MCP config the team is actually using in mcp/, one shared rule in rules/, one hook script in hooks/, one slash command in commands/, one starter CLAUDE.md.template in templates/. Now the repo is useful on day one, not an aspirational scaffold.
Write the bootstrap script and dogfood it.

Borrow the pattern from Q6 — clone the repo to ~/.acme-ai-toolkit/, symlink each subdirectory into the right place under ~/.claude/, ~/.cursor/, and ~/.codex/. Install slash commands. Wire the MCP configs into the user-level MCP registry. Run it on your own laptop five times in a row to confirm idempotency. Then run it on a clean VM — fresh dotfiles, fresh ~/.claude/. Fix every broken path assumption before another engineer ever runs it.
Schedule the recurring brown-bag and pick the first MC.

Put a recurring 30-minute slot on the team calendar. Same day, same time, every month. Pick the first MC — usually the AI tooling lead or whoever owns the repo. Brief them: “your job is to find one engineer with a demo and one with a new pattern, and to write the archive entry afterward. That’s it.” Schedule the second month’s slot and the third month’s MC at the same time, so the cadence is visibly committed.
Run the first brown-bag from your own demo.

For the first session, the MC demos something themselves — typically the bootstrap script, walking through what gets installed and why. The “new pattern” slot goes to whatever single change you want the team to adopt next (often: “everyone should be installing this repo on their laptop by end of week”). End the session with a calendar invitation to the next one and a Slack post linking the recording and the archive entry.
Make the install a day-1 onboarding step.

Add curl -fsSL https://acme.dev/ai-toolkit-internal/install | bash to the new-hire setup script. A new engineer’s first day should end with claude opening with every company skill, every shared MCP, every team hook, and every slash command pre-loaded. They should never have to ask Slack “do we use X?” — the answer is in their terminal.
Reward contribution publicly.

Every month, the brown-bag is the place where contributions get visible recognition. The MC names the engineers whose PRs landed in the repo that month. Engineering leads cite repo contributions in 1:1s. If contributing to ai-toolkit-internal doesn’t feel rewarded, contributions dry up — and the repo decays into “the thing the lead wrote.” Keep the social loop tight.
Audit quarterly.

Every quarter — once a season, in line with the half-life — sweep the repo for rot. Skills that haven’t been loaded in two quarters get archived. MCP configs pointing at deprecated endpoints get fixed or removed. Hook scripts that reference dead URLs get patched. The archive of brown-bag recordings is the easy version of this: any pattern that was “the new hotness” in February but didn’t survive to May is the kind of thing the quarterly audit catches.

Common pitfalls

Using Slack (or Notion, or Confluence) as the archive. The most common failure. Engineers post a clever finding in #engineering or #ai-tooling, the thread gets a few thumbs-ups, and then it’s invisible. Search will not save you — Slack’s search is bad, and even if it weren’t, nobody searches Slack for “how do we set up an MCP.” Slack is for live conversation. The repo is for durable artifacts. Conflating them is the failure mode.

No owner. A repo that’s everyone’s responsibility is no one’s. PRs sit for weeks, the CHANGELOG goes stale, the brown-bag gets cancelled because nobody owns scheduling. Name an owner — a tooling lead, an architecture guild, the platform team’s AI rep — and give them a small budget of time (10% is the right ballpark) to maintain it. Without ownership, the half-life problem swallows the repo itself.

No cadence. A repo without a brown-bag is read-once and forgotten. Engineers contribute when they ship the thing; they only learn from each other’s contributions if there’s a regular forcing function to look at what’s new. Skip the brown-bag and the repo becomes a graveyard within a quarter.

No contribution model. If the only people who file PRs are the maintainers, you’ve built a top-down distribution system, not a team enablement system. The whole point is the long tail — every engineer eventually shipping something into the repo. Lower the bar: encourage “I figured out something small” PRs. Pair-write the first PR with new contributors. Celebrate small contributions as loudly as big ones.

Hour-long brown-bags. Calendar dread kills attendance. The first time you schedule a 60-minute session, half the team skips it; the second time, the brown-bag dies. Hard ceiling at 30 minutes. If a topic genuinely needs longer, it’s two slots over two months, not one long one.

Demos with no PR. A brown-bag that consists of “here’s a thing I did, isn’t it cool, anyway back to work” is a chat. The discipline is: the demo only counts if a PR lands in the repo that week. Otherwise the knowledge stays in the demoer’s head and the brown-bag becomes entertainment.

Treating outside content as the source of truth. A team that subscribes to awesome-claude-code-toolkit releases and never tries any of the patterns is consuming, not learning. Inbound channels are the candidate pool; the repo is where things go after they’ve been verified in your codebase. Pulling a community skill verbatim into production without a brown-bag walkthrough is how teams ship subtly broken patterns.

Letting the repo sprawl unfiltered. Without the quarterly audit, the repo accumulates dead artifacts faster than living ones — and the more dead artifacts, the harder it is for engineers to find the live ones. Be willing to archive aggressively. A repo with 30 skills you trust beats a repo with 200 skills you don’t.

Skipping the recording. A brown-bag without a recording reaches only the people who happened to be in the meeting. That’s the wrong target audience — most of the value is the asynchronous catch-up. The recording, transcript, and one-paragraph summary together cost five minutes and quadruple the reach.

Knowledge sharing — ai-toolkit-internal repo + brown-bag cadence

Why this matters in 2026 (3-month half-life)

What “max score” actually looks like (the repo + monthly brown-bag + recorded archive)

Current landscape (web-search-verified)

What goes in ai-toolkit-internal (skills, MCP configs, hook scripts, CLAUDE.md template, slash commands)

Brown-bag cadence (monthly, 30 min, one demo + one new pattern)

Recording + archiving (Loom, internal video, transcripts)

Step-by-step: launching ai-toolkit-internal

Common pitfalls

How to verify you’re there

Further reading

Knowledge sharing — ai-toolkit-internal repo + brown-bag cadence

Why this matters in 2026 (3-month half-life)

What “max score” actually looks like (the repo + monthly brown-bag + recorded archive)

Current landscape (web-search-verified)

What goes in ai-toolkit-internal (skills, MCP configs, hook scripts, CLAUDE.md template, slash commands)

Brown-bag cadence (monthly, 30 min, one demo + one new pattern)

Recording + archiving (Loom, internal video, transcripts)

Reviewing what other companies share (Awesome Claude Code, Cursor Directory, X/Discord)

Step-by-step: launching ai-toolkit-internal

Common pitfalls

How to verify you’re there

Further reading