Skip to main content
A skill is a reusable unit of know-how — a runbook, a procedure, a pattern — that any agent can load. Skills are how you give the Komodor Agentic Operation Platform (KAOP) your team’s operational knowledge without rewriting an agent’s instructions every time the procedure changes.

Why a skill rather than instructions

An agent’s instructions describe what it is. A skill describes how a particular job is done. Keeping them apart buys three things that matter at fleet scale:
  • Reuse. One escalation procedure, loaded by every agent that might need it.
  • Change without redeploy. Publishing a new version reaches attached agents on their next run, with nothing restarting.
  • Attribution. A run records which skills were available to it and which it actually opened, so a library can be judged rather than assumed.
A skill also declares the tools it works through. That makes it reviewable at a glance: a procedure that says it writes through a cluster’s delete API is a different proposition from one that only reads metrics, and you can see which it is without reading the whole thing.

A library has two sources

Most skills come from a Git repository. Komodor publishes a default one that stocks a new account’s library, and you add your own repositories beside it. Every skill names its origin, and one sourced from a repository links straight to its file. The other source is the account itself: a skill created in KAOP, for a procedure that is local to your team and has nowhere else to live. These two behave differently, which is the reason to know which you are looking at. A repository skill is reviewed the way code is — an author, a history, a pull request, and a place your team already argues about whether a procedure is right. A skill created in the account has none of that behind it.
Put a skill in a repository when more than one person should have an opinion about it. Create it in the account when it is a local procedure that would never survive review because nobody outside your team needs to care.

Approval

A skill in the library is not automatically one an agent may load. Every skill carries an approval state, and the library separates approved skills from those pending approval. A pending skill is one no reviewer has accepted yet. Approval is the gate between a proposal and something the fleet will execute.
Approval is about the skill, not the attachment. An approved skill still reaches an agent only when it is attached, and the agent count on each row tells you how many have attached it — which is how you find the skills in your library that nothing is using.

What a skill contains

A skill renders to a fixed structure, and writing to that structure is what makes it usable by an agent that has your tools but none of your context.
“If error rate exceeded 2% for five minutes, check the last three deploys before looking at infrastructure” is actionable; “investigate carefully” is not, and the difference shows up in the run.

Versions

Skills are versioned, and the distinction to know is what does and does not create a version. Editing a name, description or label does not. Publishing new content does — and so does rolling back, because the old content is republished as a new latest version rather than erasing the one in between. History stays a true record of what was in force when, which an audit of a three-week-old run depends on. Compare versions shows what changed between any two, which is the shortest route from “this agent started behaving differently” to the edit that did it.

Attaching a skill

Attaching carries one decision: track latest and pick up every new version as it is published, or pin a version and stay there until someone repins it.
Publishing a new version takes effect on the next run of every agent bound at latest; runs already in flight finish on the version they started with. Pin an agent you cannot afford to surprise, and repin it deliberately.

How an agent finds the right skill

Skills are not all pasted into the prompt. An agent gets a short index of everything attached to it — each skill’s name and description — and opens a skill’s body when it decides the skill applies. Two consequences for how you write them. The description is the routing decision — it is what the agent reads when choosing, so a vague one produces a skill that is never opened. And a skill’s body is only loaded when the agent opens it, so detail in the body is cheaper than ambiguity in the description, though a skill opened on every run is paid for on every run.

Next steps

Knowledge base

The other half — facts an agent looks up, rather than procedure it follows.

Runs & evidence

Where a run shows which skills it loaded.