Should AI skills follow the org chart or the process?

Both, and they have to be joined. A skill belongs to a role, which looks after it and is allowed to change it. A step in a written process names the skill, and that settles when it’s used. Drop either half and a company’s skill library breaks, in two different ways.

I’ve run Tallyfy, a workflow software company, since 2014, so I come at this from the process side. Process software has put a “who” on every step for years. In Tallyfy you can assign a step to a job title and choose the person who fills it each time the process launches. AI skills add a third column to that table: the thing that helps with the step.

That column can be filed by role or by process, and each filing answers one question well. The org chart answers who looks after this skill and who may change it. The process answers when the skill is used and what comes either side of it. A company needs both answers written down somewhere a person can find them.

What breaks when skills follow only the org chart?

The obvious way to file skills is by role, and Anthropic’s own guide to skills for enterprises does it. It suggests role-based bundles, such as a sales bundle of CRM and pipeline skills, so that each person’s active set stays focused. There’s a sound reason for that. The same guide warns that with too many skills active, Claude “might fail to select the right Skill.”

Filed only by role, each person has their tools and nobody has the order of work. A sales bundle tells a salesperson which skills they hold. It can’t tell them that the quote comes before the discount approval, or that a manager signs that approval with no skill involved. Nor does it know that Finance needs the approved figure before it can invoice. That knowledge lives in the job, and the bundle has no idea the job exists. What bothers me about role bundles is that they look finished, so nobody goes looking for the missing part.

Claude doesn’t supply the order either. A skill’s description is what Claude matches your request against when it decides whether to use the skill. That settles whether a skill fits a request. It says nothing about where the request sits in a piece of work, and the matching can miss. One Claude Code user reported in March 2026 that a custom git skill was skipped about half the time, on tasks where Claude already had habits of its own. Anthropic’s Claude Code docs treat timing as something a person may want to hold on to: they offer a setting that stops Claude using a skill unprompted, recommended “for workflows with side effects or that you want to control timing”.

There’s a second gap. The registry in that enterprise guide gives each skill a field for the “Team or individual responsible for maintenance.” A team is nobody in particular. Filing by role gives a skill a keeper only when one named person holds that role, so write the person’s name down as well.

This is where I square the argument with two earlier posts. In the ERP agent post I told companies to stop shaping agents like their departments, because value moves between departments, and to share a skill with every function once someone has built it. I still think that. A skill can sit on steps in many processes, used by people in many roles, while one role looks after it. That post also called departments a governance structure, and deciding who may change a skill is governance.

In the CLAUDE.md hierarchy post I argued against a file tree that copies the org chart, one folder level per layer of management. That’s about where files live and which rule wins. Who looks after a skill is one line in a register, and it needs no folder of its own.

Who looks after a skill filed by process?

Often nobody. Filing by process fixes the order and loses the keeper. A process library tells you that the claim gets checked before a manager approves the refund. It doesn’t tell you who may change the credit-note skill when credit notes start coming out wrong. With nobody named, a complaint about the skill lands on whoever happens to hear it, and the skill stays as it was.

GitLab’s handbook makes the ownership case firmly. Its page Prompts are Process says “A skill in any platform is process” and wants every one of them “Owned, not orphaned.” It names three homes for that ownership: the function the work belongs to, a code repository, or a central team for company-wide work. I agree with nearly all of it. Where I part ways is the document. GitLab treats the skill as the process. I’d keep the written process as the thing people follow and put the skill on the one step it helps with, because most jobs have steps no skill should touch.

Written processes have their own well-known failure, which is drifting away from what people do. I went through why in the post on processes that improve themselves, so one line will do here: a process stays accurate while people run it, and a step that names a skill gets run.

Three layers on one map

The map has three layers. A role is a kind of person and the jobs they repeat, such as Support or Finance. A process is one of those jobs written as numbered steps. A skill is a packaged set of instructions that Claude loads when a task needs it. Every step names one of two things: the skill that helps with it, or the person who decides.

Every skill names the role that looks after it, meaning the role that may change it and signs off changes others suggest. One skill can appear on steps in several processes, run by people in several roles, and still have one role looking after it. Followed down from a step, the map shows which skill is used and when. Followed up from a skill, it shows who answers for it and every step that depends on it.

Below is a made-up refund drawn that way.

Step 2 has no skill, on purpose. A manager approves the refund. Writing that down is as useful as naming the skills, because it tells everyone where the work stops for a person. If you already keep written processes, the whole change is one more column: on each step, the skill or the person.

When I say a step calls a skill, I mean the step names it in writing. In Your AI has no whoami I pointed out that a skill loads when the task matches its description, whoever happens to be asking, and nothing here changes that. A written step doesn’t fire anything by itself. It tells the person at step 3 which skill to use, and in Claude Code they can start their message with a slash and the skill’s name. The step takes the guesswork out of which skill applies.

Does a skill stay current because people run it?

Partly. I made the simpler version of this point in the Claude Projects post, where shared prompts keep up to date through daily use. Use helps. It isn’t enough on its own, and the gap is where skills quietly go bad.

A skill can run every day and be wrong every day. Lee Barnes at Forte Group, which sells AI quality work, walks through a familiar pattern: an AI feature drifts after launch, the test suite stays green because it still checks launch-day inputs, and six weeks on the support tickets start to read differently. He writes that “the visibility usually comes from the wrong place”, meaning complaints and bad tickets.

Running a skill doesn’t prove it helps, either. A benchmark of 98 public coding skills, revised in October 2026, found that 92 had no statistically significant effect, and adding skills moved the average pass ratio from 76.6% to 76.9%. The harmful ones pulled the agent toward their own templates, over the task’s explicit instructions. Those are coding skills tested by researchers, and a company’s credit-note skill may do better, but nobody would have learned any of it by watching the skills run.

What keeps a skill current is a miss reaching the people allowed to fix it, and the map is what carries it there. The person at the step sees the miss first: the credit note shows last year’s tax rate, or the reply quotes a policy that changed in March. The step tells them which skill produced it. The skill’s entry tells them which role looks after it, and that role has a named person. A skill used outside its home department gains the most from this, because that’s where a miss is easiest to lose.

Claude’s own publishing setup expects someone in that seat. Anthropic’s help page on skills says that when an organization requires review, an updated skill goes through review and “everyone who uses the skill stays on the approved version until the update is approved.” Somebody has to approve, and the named person in the role that looks after the skill is the natural choice. The enterprise guide also says to “Rerun evaluations periodically to detect drift or regressions”, which is worth doing. A miss reported at a step arrives sooner, on the day it happens.

Blue Sheen, the AI advisory firm where I’m a founding partner, builds this map with companies that want help, and its homepage walks through one example job step by step.

If you’re starting today, pick the job your team repeats most and write it as numbered steps. Put a skill or a deciding person on each step and a named keeper next to each skill, then tell everyone that a miss goes to that keeper.