How to Build a Claude Code Plugin for Your Whole Engineering Team

How One Engineer's AI Agents Became the Whole Team's Operating System

The first version of the operating system was a zip file in Slack.

On a Wednesday in September I posted it in the engineering channel of a US auto-finance lender, the client I've spent this year with. "Here's the team that helps me with Claude. Adapt it to whatever works for you. In Uruguay people call me Pepe, so my helpers are the Pepitos." Four subagents, two workflows, an install script. Unzip it, open Claude Code inside the folder, say "install this".

The next morning the client's head of engineering asked for a demo at that afternoon's refinement. By five o'clock he had created a repository in the company's GitHub, drawn a chili with code goggles for the README, and written: "Congratulations on your very own repo. Please push your code and let's use this to grow."

Five weeks later that repo is a plugin any engineer there can install in a few minutes: seven subagents, four workflows, the team's rules, a shared knowledge base about their systems, and a status line that shows how much of your Claude plan you've burned. It has a version number, a test suite and twenty-one pull requests of history. I'll call it {client}-os here, because the client stays anonymous and because that is exactly what it is: the operating system Streaver runs on, planted inside a client.

Part one was the morning routine. Part two was the Pepitos. This is part three: what happens when the agents stop being yours.

Pepito got a face the day the repo was born, before I had pushed a single line. The team laughed. At home, my daughter laughs at the name itself: she knows they call me Pepe.

What is a team operating system for AI agents?

It is a Claude Code plugin in a versioned repository that installs the same agents, rules, workflows and knowledge on every engineer's machine, and updates all of them with a git pull. Nobody configures Claude by hand. The team configures it once, in code review, and every machine inherits the decision.

The idea isn't mine. Streaver runs on Streaver OS: the company as a repository, synced to every laptop, with identity enforced at the root, knowledge in one source of truth and one plugin per client engagement. I had been working inside it for months. So when the client asked me to share the Pepitos, the obvious move was the one Streaver had already made on itself, one level down: a plugin that lives in the client's own GitHub, owned by the client, that any of their engineers can install, and that I happen to maintain.

From a personal setup to a team Claude Code plugin

Three things changed, and none of them were the agents' prompts.

Everything personal came out. My agents knew my paths, my client's name, my ticket format, my Jira status names. Each became a setting the installer asks for once, and CI got a hygiene check that fails the build if a personal path, a person's name or anything shaped like a secret lands in the repo. The check exists because I didn't trust myself to remember.

Knowledge split into two layers. What an engineer learns about a repo, how to run it, which CI checks matter, the gotcha that costs an afternoon, lives in a shared bundle inside the plugin, updated by pull request. What the assistant learns about you, handoffs for interrupted tickets, your daily file, your own gotchas, lives in a personal folder on your machine: its own git repo, with a secret scanner on every commit, never pushed to the shared one. The librarian from part two reads both layers and writes only yours. When it finds something clearly team-wide, it says so, and the fix is a PR.

Symlinks became a plugin. My first setup symlinked agent files into Claude's config folder. That works for one laptop. For a team it means a pull on every machine, a symlink for every new file and no way to set a path per person. A Claude Code plugin gives one version for everyone, namespaced names so nothing collides with your own agents, and hooks that ship with the plugin and get reviewed like any code. The checkout you cloned is the marketplace: git pull is the update, and a session that starts on an old version says so.

What the Claude Code plugin installs on day one

The install is three lines you can read before you run them.

git clone <the client's repo>
cd <the client's repo>
./install.sh        # or .\install.ps1 on Windows

The script checks the prerequisites, registers the folder as a private Claude Code plugin marketplace, installs the plugin, creates your personal folder, installs the status line and opens a short wizard for the two things only a person can do: connecting Jira, GitHub and Slack with your own account, and a one-minute tour. Nothing is piped from the internet into a shell. No token is copied anywhere. Every step is logged, and ./uninstall.sh puts your settings back byte for byte. The client vets every tool its engineers use; a readable script in their own GitHub is the most transparent install there is.

The Claude Code status line

Then your status line looks like this:

Sonnet · ctx 34% · 5h 28% until 19:20 · 7d 82% · by Pepito 0.9.0

Model, context, the five-hour and seven-day usage windows, and the version of the OS you're running. Every percentage turns yellow at 70 and red at 90. And the commands from part two are there, now with a version number: implement a ticket, review a pull request, debug a production error, answer a question about the data warehouse with evidence.

The first install failed, and the OS fixed itself

The day I demoed it, the head of engineering tried the installer on Linux. It stopped: the secret scanner it required isn't in most Linux package managers. He wrote it in the team channel we had opened ten minutes earlier: "First blocker for me is: gitleaks isn't available on Linux."

I tagged Claude in the thread. Not Claude Code on my laptop: the Claude app in Slack, connected to the repo. Make the scanner optional, with a fallback that downloads the official release binary and checks its checksum, and a warning if all of that fails. It opened a draft PR from the thread, wrote the tests, fixed the two findings the other AI reviewer raised and replied on each, and created the Jira ticket under the epic. When I pointed out the ticket wasn't in the team's format, it rewrote it. By mid-afternoon the fix was merged as version 0.4.3, with the head of engineering confirming the install worked. I never opened my editor.

Eleven days later the same Slack Claude wrote a ticket in another channel, freehand. I asked why it wasn't using the OS's format. "Because I didn't know it existed: nothing in this channel's notes pointed me at it. I'm pulling the template from the repo now and will use it from now on." That's when I understood what the repo had become. The format isn't mine anymore. It's where the team's answer lives, and even an agent that runs on nobody's laptop goes there to find it.

Claude Code rules and hooks that came from the team

The week after the merge, the head of engineering posted a cheat sheet: which Claude model for which kind of task. Two days later that table was a rule in the OS and a hook that reads it before every prompt. Ask the most expensive model for something the sheet assigns to a cheaper one, and Claude stops once, says which model fits and why, and offers the switch. Reply "continue" and it stays quiet for the rest of the session. It doesn't forbid. It teaches, once.

A DevOps colleague wanted infrastructure to go through the team's shared CDK library instead of raw constructs. That became a rule and a gate: a write that builds raw infrastructure where the library has the piece is denied once, with three options. A data teammate had built an agent that answers questions about the warehouse; the head of engineering asked us to fold it in "so all agents can live together", and it became a skill anyone can run. The branch name in my status line, coloured by the state of its pull request, I copied from a teammate's bar. The deny list, no deploys from a laptop, no piped installers, no reading .env files, no production database from a terminal, came from Streaver OS, where it already existed.

None of these were mine to write. The OS is where the team's answers go so nobody gives them twice. Part two closed with "the Pepitos propose, I decide". The team version: the OS proposes, the team decides. Every rule got there through a pull request a person approved, and one command takes them all back out.

The hardest part was teaching, not coding

The installer wasn't the hard part, and neither were the agents. The hard part was making the OS educational without making it annoying.

A rule you enforce silently gets worked around. A rule you explain once gets adopted. So every gate behaves the same way: it stops once, says why, offers a way forward, and never asks again in that session. At 100% of your plan's usage window, before the next tool call, Claude pauses and asks whether to continue on extra usage or switch to a cheaper model from where the work stands. Past 80% of the context window, it suggests compacting, once.

My favourite example is small. I asked it to move two tickets to In Progress. The permission rules refused the Jira transition twice, and the rules say not to insist through another route. So it answered: "Move them to In Progress by hand in Jira. Two clicks." It had the credentials. It had a rule. It handed me the two clicks instead of finding a way around. That is the behaviour I'd spent ten weeks trying to write down, and now every engineer who installs the plugin gets it on day one.

Your company becomes a plugin

Here is what I learned planting one of these inside a client. The agents are the easy part. The client-specific parts are four: the knowledge bundle about their repos, the ticket format their people want to read, the connectors they use, and two names in the manifests. Fork those, keep everything else. The installers, the hooks, the gates, the two-layer knowledge, the Friday routine that turns a week of review comments into rules for the coder: all of it travels as is.

That is the line on the Streaver OS page made literal: your engagement becomes a plugin on day one. We rebuilt our own company first, then put the same shape inside a client's GitHub, in their name, reviewed by their head of engineering, now their VP of Engineering and AI, with their rules in it. It runs on macOS and Linux today; Windows is written to spec and waiting for its pilot. What comes next is helping people write their own routines, the way part one's morning brief started, and raising the bar on code and documentation with every Friday review.

The chili is still in the README. It wasn't my idea either.