Artsiom Rudzenka

Posted on Aug 8

AI Skills Are Becoming Software. They Need Governance.

#ai #opensource #programming

We are starting to treat AI skills as software.

But we are still managing them like prompts.

That mismatch is easy to ignore while one developer has a handful of local instruction files. It becomes expensive when skills are shared across a team, loaded by several agent runtimes, and trusted to guide tools that can read repositories, run commands, or change production systems.

A reusable skill is no longer just text. It has an interface, dependencies, compatibility assumptions, failure modes, and a blast radius. It can become stale. It can conflict with another skill. It can be useful on one runtime and silently fail on another.

In other words, it has started to behave like a software artifact.

And software artifacts need governance.

The prompt model breaks at team scale

The first version of almost every agent workflow is a prompt: explain the task, add some examples, and ask the model to follow the rules.

Then the prompt grows. Architectural conventions are appended. Safety warnings accumulate. Tool-specific syntax appears. A second developer copies it and makes a small change. Another team creates a “cleaner” version. Six months later, nobody knows which copy is authoritative.

This is not primarily a context-window problem. It is a lifecycle problem.

When a skill is treated as a prompt	When a skill is treated as software
Copied between chats	Stored in a canonical repository
Changed without history	Versioned with meaningful diffs
Trusted because it reads well	Evaluated against explicit criteria
Bound to one agent host	Declares and tests portability
Reviewed informally	Passes review and security gates
Owned by whoever last edited it	Has an owner and lifecycle

The model may still execute the instructions probabilistically. The asset around those instructions does not have to be unmanaged.

What makes a skill a software artifact?

Not every prompt deserves a release process. The boundary is reuse plus consequence.

A skill crosses that boundary when it is expected to:

work repeatedly rather than once;
be discovered and activated from natural-language intent;
coordinate tools, scripts, files, or sub-agents;
behave consistently across projects or runtimes;
be maintained by more than one person; or
produce changes whose failure matters.

At that point, the skill has software-like properties:

An interface. Its name and description determine when an agent selects it. Its inputs, outputs, and verification steps form a contract.

Dependencies. It may rely on tools, MCP servers, scripts, reference files, or another skill.

Compatibility. Host-specific fields and capabilities can create divergent behavior across Claude Code, GitHub Copilot, Cursor, Codex, and Gemini CLI.

Quality attributes. Clarity, completeness, specificity, discoverability, testability, portability, and safety can all be assessed.

Risk. Instructions can normalize destructive commands, expose credential paths, trust hostile content, or hide behavior behind Unicode characters that look harmless.

Calling the file “Markdown” does not remove those properties.

Governance is not bureaucracy

Governance often sounds like a committee standing between an engineer and useful work. That is not the model I mean.

For skills, governance is a small set of answers:

What assets do we have?
Who owns them?
What contract does each asset promise?
Which runtimes and dependencies does it support?
What evidence is required before it is shared?
What should block a change, and what should merely warn?
How do we upgrade, deprecate, and remove it safely?

Good governance makes the safe path the easy path. It gives authors a standard, reviewers a shared vocabulary, and CI a deterministic baseline.

The goal is not to make every edit slow. It is to make the lifecycle visible.

Memory was the symptom, not the product

My own path to this idea began with an AI pair programmer that kept losing project context between sessions: architectural decisions, naming conventions, testing expectations, and the reasons behind earlier choices.

My first instinct was to write a bigger instruction file.

That helped—until it did not. The file became harder to navigate, harder to validate, and increasingly specific to one tool. The deeper issue was not that the model needed a larger memory. Project knowledge needed structure.

Instead of asking an agent to remember everything, I started packaging bounded procedures as skills: discoverable, reusable, versioned, reviewable, and portable.

The memory problem led to the architecture. Governance became the product.

A concrete experiment: Skill Governance Toolkit

I built the open-source Skill Governance Toolkit as a reference implementation of this approach.

It uses one canonical skills/ directory and a shared AGENTS.md source of project rules, while packaging the same six core meta-skills for Claude Code, GitHub Copilot, Cursor, OpenAI Codex CLI, and Google Gemini CLI.

Those meta-skills cover a practical lifecycle:

find an existing skill before creating another;
evaluate one skill across nine quality dimensions;
compare local and corporate variants;
audit a library for systemic issues;
convert host-specific skills into portable ones; and
initialize optional integrations.

The repository also includes a deterministic, read-only audit engine. The same checks can run locally or in CI through a CLI, interactively through MCP, or inside a locked-down Docker container. A changed-only gate can block newly introduced high-severity findings without forcing a team to fix all historical debt first.

This distinction matters:

deterministic checks handle reproducible facts such as malformed front matter, unsafe shell patterns, hidden characters, hardcoded paths, and missing contracts;
model-assisted evaluation handles semantic questions such as whether instructions are clear, examples are useful, or trigger phrases are discoverable.

Governance needs both. Asking an LLM to make every safety decision creates recursive trust. Asking a lexical scanner to judge clarity creates false confidence.

The questions we should ask in review

Once we see skills as software, the review changes. “Does this prompt look good?” is too weak.

We can ask instead:

Is its activation boundary specific enough to avoid collisions?
Does it state what it will and will not change?
Are inputs, outputs, and completion criteria explicit?
Can it run without one vendor’s private front matter?
Are required scripts and MCP servers declared?
Does a mutating workflow preview changes and support recovery?
Could untrusted content be mistaken for instructions?
What happens on interruption, retry, or partial failure?

These are ordinary engineering questions. That is exactly the point.

The shift

Prompt engineering asks: How do I phrase this instruction so the model follows it?

Skill engineering asks: How do I design, validate, distribute, and evolve this capability so a team can rely on it?

We will continue to write prompts. But the reusable ones are becoming something more consequential: interfaces between human intent, model behavior, and executable tools.

The teams that recognize that transition early will not merely have better prompts. They will have a maintainable capability system.

Next: Part 2 — Designing a Governance Layer for AI Skills examines the architecture: instruction layers, deterministic and semantic checks, portability, CI policy, and safe adoption.

Series: