Your agent config is code. Start treating it like it.
Why your SKILL.md is infrastructure, not a preference — and what happens when you treat it that way.
Most people are still calling this "better prompting." I don't think that's right.
What's actually happening: we're moving from one-off instructions to software-defined environments. When I started building agent teams for my projects, I thought in terms of prompts. Now I think in terms of files. SKILL.md, CLAUDE.md, .clinerules, action schemas — each one is a deployable artifact with a specific scope and lifecycle.
The difference matters more than it sounds.
A prompt is temporary. A skill file is infrastructure. When I write a SKILL.md for one of my agents, I'm authoring behavior: what it does, in what order, under what constraints, and when it stops. That's configuration code. It belongs in version control, gets reviewed when it changes, and gets maintained like anything else in your stack.
I learned this the hard way. Early versions of my agent setups were sprawling instruction blobs I'd partially remember and inconsistently apply. New behavior introduced in one session would disappear in the next. The agent's reliability was inversely proportional to how long it had been since I'd touched the config.
Once I started treating these files like actual code — committed to git, organized by concern, with clear inheritance — everything got more predictable. Not because the models improved. Because the configuration did.
The layering pattern
A setup worth copying in 2026:
A root config for global defaults and guardrails
Skill modules for work you do repeatedly
Project-level overrides that inherit from the base
Memory files that persist context across sessions
One configuration for writing. Another for product work. Another for ops. Each tuned, versioned, owned by you.
The alternative is relying on vibes and hoping the agent remembers what you told it last week.
The security surface nobody's thinking about
If behavior lives in files, those files are part of your attack surface. Not theoretically — practically.
Third-party skill files should be treated like third-party dependencies:
Review them before running them
Scope permissions to what's actually needed
Don't give an agent write access when it only needs to read
Most people haven't applied basic hygiene standards to their agent configs yet. That gap will close, probably after something goes wrong.
What to actually do
Put your config files in git. Write commit messages that explain why a rule changed, not just what changed. Build skills that do one thing and can be tested in isolation.
Think through your precedence model deliberately: what's global, what's project-specific, what can a single user override. Those answers exist — they just require thinking it through rather than letting the config accumulate by accident.
A well-built agent stack can be cloned, backed up, handed off, and iterated. It's your operating layer. Treat it like one.