Ask three developers on your team how they get an agent to write code that fits your conventions. You will get three different answers - and probably a slightly embarrassed pause, because the honest answer is usually “I have a prompt I keep pasting.”
That is where most teams are in 2026: everyone has private prompts, a personal config file, their own way of driving the agent. None of it is shared, none of it is reviewed, none of it is versioned. We would never accept that for our build tooling. We accept it for the thing that now writes a large share of our code.
Tribal knowledge does not scale - and never did
The symptoms are easy to spot once you look:
- The good prompt lives in one person’s head. Someone worked out how to get the agent to follow your API conventions perfectly. Nobody else has it. When they are on holiday, output quality drops.
- Onboarding is folklore. A new joiner asks “how do you use AI here?” and gets a shrug plus a link to somebody’s gist.
- Quality depends on who is typing. Same task, same repo, wildly different agent output - because the invisible context differs per person.
- Improvements do not compound. Every developer learns the same lessons separately, and the lessons die with the session.
There is a name for the fix, and it is not new: treat these instructions as infrastructure - versioned, reviewed, shared artifacts that encode tacit team knowledge into executable form, so quality stays consistent regardless of who is at the keyboard.
Graduate prompts into artifacts
The useful mental model I have landed on is a ladder. A one-off prompt sits at the bottom - fine, ephemeral, nobody cares. But the moment a workflow becomes repeatable, shared, and business-critical, it should graduate into a structured artifact: an instruction file, a skill, a custom agent definition, or a plugin your whole team installs.
Skills sit in a sweet spot between a bare prompt and a full agent system: reusable, composable, version-controlled, and portable. That is exactly what makes them shippable.
Concretely, here is what belongs in the package:
- Coding conventions the agent must follow. Your naming, structure, error handling, testing style - the things you would otherwise repeat in every code review.
- Project context. How this system fits together, what the shared packages are, which patterns are blessed, what is deprecated.
- Reusable task skills. The workflows your team does repeatedly: add an endpoint, create a component, write a migration, prepare a release.
- Review checklists. The security and accessibility bars I wrote about - encoded so the agent applies them before a human ever looks.
- Guardrails. What the agent must never do: touch production data, invent APIs, commit to main, leak internal details.
Ship it like software, because it is software
Once those artifacts exist, the workflow becomes gloriously familiar - and that is the whole point:
- Onboarding becomes “install the plugin.” New developer, day one: one install command, and their agent already knows your conventions, your architecture, and your red lines. No folklore.
- Improvements ship as releases. Someone finds a better way to make the agent handle your error contracts? It becomes a versioned change everyone picks up on their next update - instead of a Slack message three people saw.
- Changes go through review. A pull request against the shared instructions is exactly as reviewable as a pull request against code. “Should the agent really be allowed to do that?” becomes a normal review comment.
- Version pinning gives you control. Teams adopt improvements deliberately, and a bad change can be rolled back like any other release.
I have written before about DRY where it matters - auth components, CI pipelines. This is the same argument for the newest shared surface in your organization: your team’s AI behavior. Five people maintaining five private prompt libraries is five copies drifting apart.
Governance: who owns the shared brain?
One question decides whether this works or rots: who approves changes to the shared instructions?
My guidance, mirroring what I would say for any shared package:
- A named owner. Someone curates coherence and says no to bloat. Unowned instruction sets become landfill.
- Changes are PRs, with a reason. “The agent kept doing X, so we told it Y” belongs in the commit message. Future you will want the why.
- Keep it small and specific. A 4,000-line instruction file is not context; it is noise, and models follow it about as reliably as humans read a 40-page onboarding PDF. Prefer a few sharp rules over exhaustive coverage.
- Let failures write the rules. The best entries are corrections: the agent broke the formatter once, so a line was added and it never happened again. That is the feedback loop that makes the system learn without any training.
- Prune regularly. Instructions rot exactly like documentation and design tokens do.
The one honest caveat
There is a failure mode worth naming: shared instructions can ossify bad practice. If your conventions are outdated, you have now automated them across every developer and every agent, at speed. The package amplifies whatever you put in it - which is an argument for reviewing it seriously, not for skipping it.
The same applies to the trap of over-standardizing. Leave room for a developer to deviate deliberately on a specific task. Paved road, not prison - same as with project templates.
The mise en place
Walk into a professional kitchen before service and you will see the same ritual everywhere: mise en place - everything in its place. Stations prepped identically, sauces made, tools where they belong, every cook working to the same standards. It looks like bureaucracy from the outside. It is the opposite: it is what lets a kitchen move fast under pressure without the food falling apart. Nobody has to ask where the salt is or how the sauce is made. The setup is shared, and the creativity goes into the cooking.
A home cook improvises their setup every time, because it is only ever them. That is where most engineering teams are with AI right now - a dozen private kitchens, each with its own arrangement, each rediscovering where the salt should live.
Do the mise en place. Ship the setup as a package, version it, review it, prune it. Then let your team spend their attention on the actual cooking - which was always the part that needed a human.