July 15, 2026

DRY for your AI: stop copy-pasting rules into every project

As developers we have an almost sacred rule: don't repeat yourself. We apply it to everything… except AI, where we copy-paste the same rules, guides and prompts from one project to another by hand.

🧩 The problem: copy-pasting rules doesn't scale

Each repo ends up with its own version of the rules: nobody knows which is the good one, you improve a convention and the other ten go stale, and without them in front of it the AI makes things up. We're repeating ourselves. The fix, like with code: a single source of truth and a way to distribute it.

🧭 The solutions at a glance

Two pieces that complement each other:

1. A CLI that, with one command, injects and maintains the AI config in each repo — the "how we work in this project".
2. Packages that carry their own skills inside: you publish the library alongside the instructions for how to use it — the "how this tool is used".

🚀 Solution 1: a CLI that prepares the project's AI context

Instead of copy-pasting, you run a command from the project root and it gets configured. The CLI lives in its own repo (your source of truth) and each project serves itself what it needs. Throughout the article I'll use ai-ctx as an example; its code is on GitHub if you want to take a look.

🧱 Command structure: one action, one command

Each command distributes one type of configuration and does one thing:

✅ Blocks to select: install only what applies

A frontend doesn't need the backend rules, and vice versa. That's why installing is interactive: a selector where you check off categories (frontend, backend, shared) and only what you check gets in. A "menu"-style config, with no rules pulled in "just in case".

📚 The living index: the entry point for the agent

How does the agent know what's installed and where? With a living index (in ai-ctx, an app-context.md) that:

• Is generated from the real state: it lists the installed rules, guides and skills, with their description and location.
• Updates itself: it regenerates every time you install something.
• Preserves what you write: the team's notes live alongside the index and regeneration doesn't overwrite them.

A single place any agent (or new person) looks at to understand, at a glance, how the project is configured.

🧰 Tech stack

Standard Node tools are plenty: Node.js + TypeScript as the base, commander.js for the commands, @inquirer/prompts for the selectors and tsup to bundle as ESM runnable with npx.

🔧 How to build it, in broad strokes

1. One command per action, isolated in its own module. Adding a capability means adding a command.
2. Versioned asset catalogs in the CLI repo: your source of truth, traveling inside the published package.
3. Rewrite on install: rules carry placeholders (e.g. a monorepo's paths) that the CLI expands on the fly.
4. An index generated from the real state, not a manual list.

📦 Solution 2: reusable packages that ship their skills inside

The CLI solves "how we work here". But there's another equally costly repetition: explaining to the AI how each internal tool is used, something that changes with every version. The idea: the package publishes, alongside its code, the skills that teach how to use it.

A component library that, on top of exporting the components, includes a skill with how the UI is composed, which props to use and which antipatterns to avoid. The same for a @your-org/backend-core: how a service is built and which conventions to follow.

💡 Why this is so powerful

• Real versioning. The skill travels with the package version: if you have 2.3, the agent sees the 2.3 docs, not a README stuck at 1.0. No more gap between the real API and what the AI thinks exists.
• The agent knows how to build, not just what exists. A list of functions teaches nobody to assemble an app; a skill does: patterns, examples and "do this / not that".
• Fewer hallucinations and instant onboarding. The knowledge is packaged and distributed with npm install. Whoever installs it —person or agent— inherits it instantly.

🔗 How it fits with the CLI

The CLI installs and registers those skills; the package is the source that keeps them up to date. One distributes, the other is the versioned origin.

🏢 A central repo of AI configs for the whole company

If a source of truth is worth it for code, why not for all the organization's AI configuration? Imagine a central repo with the whole company's configs, not just engineering:

• Marketing: brand tone of voice, deck templates, copy guides that sound like the house.
• Sales: proposal templates, canned responses, qualification criteria.
• Support: style guides for replies, escalations, limits on what the AI can promise.

The benefit: the whole company rows in the same direction, and when something changes it's updated in one place. It's DRY at organization scale: one source of truth, distributed, instead of a thousand copies diverging in silence.

🔁 Day to day

With both pieces in place, the flow is almost boringly simple:

• New project → CLI with npx, select the blocks, and in seconds the repo has rules, guides and skills. The index is generated.
• You install an internal package → its skills come included and up to date. You configure nothing.
• You improve a rule → you change it at the source and projects catch up by re-running the command or updating the dependency.

🏁 Conclusion

DRY was never just for code. Applying it to your AI config turns the team's knowledge —how you write code, how your tools are used, how your brand sounds— into something versioned, distributable and consistent. Stop repeating yourself. With AI too.

🆚 CLI vs MCP: why not use MCP for everything?

MCP is excellent for connecting the AI to live data or APIs in real time, but using it for static code rules is over-engineering. The CLI wins because it injects the config directly into the repo: the rules are versioned in Git alongside the code. Clone the project two years from now and the AI respects that version's exact architecture, with no one having to spin up local MCP servers.

In short: CLI for versioned, static rules; MCP for dynamic context.