This year I watched an underwriter go from learning what a GUI is to editing an agent definition in markdown by day four of a one-week sprint. Product managers, delivery managers, lawyers, relationship managers, and brand people at my company have all built skills or agents in 2026, and on one podcast episode a colleague and I wrote a working SKILL.md live in Microsoft Copilot Chat in about thirty minutes.
That's the good news and the problem at the same time, because anything that easy to make gets made a lot, and it's hard to tell whether a given skill makes the work any better. Vendors now ship ready-made plugins for legal, marketing, sales, product management and more, and they encourage companies to customize them for their own work.
Writing a skill feels like writing a document, so the natural next step is to check the formatting and share it. Research published this summer suggests that isn't enough. A team at NVIDIA ran 145 skills through the usual static checks and nearly all of them passed, but those scores had no measurable relationship to whether a skill helped an agent finish its task, and some skills made results worse without any scan catching it. I ran into a small version of this myself when a plugin validator approved a package that the installer then rejected, because the validator had only read the manifest.
So I've started treating plugins and skills the way I would any product. What follows is mostly product management with different nouns, the same craft I've coached for years applied to a new subject.
Decide who owns what
The first decision we made wasn't a technical one. Our product and delivery councils own their standards, and Product Operations owns turning each standard into a skill and keeping that skill current. That split is about decision rights, the same question I ask in every operating model engagement. Without it, a skill drifts into one person's opinion of how product management should work. With it, every skill traces back to something a council adopted, and I can show the line from the skill to the standard.
Draw the boundaries first
We build one plugin per function. Each standard is written once and copied into every skill that reads it, and a check before release keeps those copies from drifting apart. Tools and connectors live outside the plugin, so a single org-wide approval for a connector replaces a security decision at every install.
That's product taxonomy applied to plugins. Where you draw a boundary decides who can change what without asking anyone else, and that holds for a plugin as much as for a team.
Name skills for the moment someone is in
Skills are named for moments rather than documents. Framing a decision and synthesizing insights are things a product manager is doing on a Tuesday afternoon, while a PRD template is an artifact they produce along the way. Designing around the moment is the same discipline as designing around the job a customer is trying to get done.
It also changes what a skill does when it runs into a gap. Ours point out the gap instead of filling it, because a skill that invents the missing customer evidence to finish a template looks helpful right up until someone makes a decision based on it.
Start with one, end to end
The first release was a product management plugin with two skills, and we took it all the way from standard to skill to evaluation to install before building anything else. A thin slice shows you where the problems are, and two of the first ones we hit had nothing to do with the skills themselves. One was the validator gap I mentioned, and the other was a skill description that ran 1,133 characters against a 1,024-character limit and blocked the install.
Compared to what?
This is where I'd push hardest. Every skill goes through an evaluation cycle before release. Each test case runs against no skill at all and against the closest thing you could buy off the shelf, on two different models, and then a coach who didn't write the skill grades the results. The current version clears 108 of 116 checks, compared with 66 for the version practitioners have installed today.
Those are small tests we run ourselves rather than a benchmark, and I say that every time I share them. The baseline matters more than the score. Early on we had a run where the new version beat the old one 100 percent to 84, and it looked great until I asked what it had been compared against. The answer was the old version. Nobody had re-tested the current skill against no skill at all, so we knew it was better than before without knowing whether it was better than nothing, and every test case has run against no skill since.
The off-the-shelf comparison matters for a different reason, since it turns build versus buy into a question you can answer with evidence instead of opinion.
Guidance, not a control
We treat a skill as guidance, so it has no hooks or system permissions and never blocks anyone's work. Where a skill does check something, it looks for a demonstrable outcome rather than a particular method, which is what I'd ask of any team: show me what changed, not which steps you followed.
Plan for the model to change underneath you
Products have a lifecycle, and skills have an odd one, because a skill can get worse without anyone touching it. In the NVIDIA research, a newer model raised the no-skill baseline enough to shrink a skill's measured benefit, and the authors recommend re-testing after every model update. They also found that crowding hurts: with 50 skills visible at once, the agent passed only about half of its tasks.
The platform is part of that lifecycle. I tested whether our plugins carry over to Microsoft 365 Copilot Cowork and wrote up what I found with every claim labeled by how we know it, whether that's vendor documentation, our own dated test, a house rule, or a tenant setting. These platforms change fast, and the label tells a reader how much weight each claim can carry.
Where this goes next
In April I wrote a discussion paper for senior leaders called "Designing Agents like Products," about using product taxonomy as a design framework for organizations of agents. At the time it was mostly a thesis. Since then, plugins and skills have made me work through each of the decisions above for real, because they're the parts that get built first.
The path I describe to teams goes instruct, codify, compose. You start by instructing the AI, codify what works into skills, and then compose those skills into agents and agentic workflows. If the skills underneath don't have owners, boundaries, and a baseline, the agents built on top of them inherit every one of those gaps.
If you're building skills inside a large organization and working through the same questions, I'd like to compare notes: joshvande@gmail.com.