A Skill Is a Template, Not a Macro

Everyone is treating skills as a way to go faster. They were never about speed. They were about everyone doing the thing the same way.

Six people sent me their skills this week. Reusable packages that draft PRDs, score a backlog with RICE, turn interview notes into themes, format a stakeholder update before you have written a sentence. Smart people, real work, impressive demos. And a creeping sense that I have seen this movie before.

I have. It was called prompt engineering, and it was the thing to publish about six months ago. Before that it was custom slash commands, which have since been quietly absorbed into skills. The abstraction keeps getting repackaged, and each time the same crowd rushes to publish theirs, because publishing one has become the cheapest available way to signal that you are fluent in AI.

I want to argue something narrower and more useful than "this is hype." It is that we are using the wrong mental model for what a skill is, and the wrong model is producing a feed full of noise. The fix is one reframe.

A skill is not a macro. It is a template.

The difference is the whole point

A macro automates a sequence of commands. You record the steps, you press the button, the steps run. A macro can produce consistency as a side effect, a formatting macro keeps every report looking the same, but its native promise is execution. An Excel macro does not make the analyst's judgment better. It makes a known sequence faster and more repeatable.

A template is a different object with a different purpose. A template standardizes a deliverable. A PRD template, a RACI, a user-story format, a Jira ticket structure: none of these exist to save keystrokes. They exist so that everyone produces the artifact the same way, with the same fields, the same rigor, the same shape, so the next person can read it, trust it, and build on it without relearning the author's private conventions. A template is the visible form of something deeper: a shared standard for how the work gets done.

A skill is what a template becomes when you give it reasoning and let it run. It is a living template, a template plus a method: it carries the structure and the standard, and now it can also ask the clarifying questions, apply the framework, and fill the fields. That is useful, and real. But notice what it inherits from the template and not from the macro: its native promise is standardization, not speed. Speed is the benefit one person gets. Consistency is the benefit the team gets, and above a team of one, that is the only benefit that changes the work.

Once you see a skill as a template, the confused parts of the current moment resolve themselves.

Templates are earned, not performed

A good template is the last thing a practitioner makes, not the first. You write the PRD badly, then adequately, then well, fifty times. Only then do you know which sections actually decide whether the thing ships, where scope quietly creeps, which questions you keep forgetting to ask. The template is the compression of that hard-won judgment into a form your team can reuse. The judgment comes first. The template is its residue.

This is where a good skill does something a macro never could. A macro does the typing; a good template forces the thinking. A junior PM running a discovery skill authored by someone who has actually done discovery gets asked the questions they would not have known to ask, in the order that matters. The skill lets them perform, for a moment, above their own level. That is the opposite of a shortcut: it is a guardrail. But it only works if the judgment inside is sound, which sends you straight back to who built it and what they knew.

The skill feed inverts this. A skill is being published as the first artifact, before the work it is supposed to compress has been done, because the skill itself is the credential people are reaching for. That is the tell. A template you ship to make your team faster at good work is one thing. A template you ship to look like you do good work is another, and the second is most of what is flooding the timeline.

A skill should be the last artifact a credible practitioner ships, not the first thing someone ships to look credible. There is nothing wrong with publishing experiments; the field learns by sharing them. The problem starts when an experiment is marketed as expertise.

I would like to know whose judgment I am installing

When I install a skill, I am not installing a tool. I am installing someone's opinion about how to do the work. A "Jobs to Be Done" skill encodes a point of view about discovery. A prioritization skill encodes a theory of what matters. The moment I run it, that opinion is shaping my product.

So the only question that matters is whose opinion it is, and today I have almost no way to answer it.

It is in our nature to credential the people whose skill we depend on. We check a physician's training before we trust a diagnosis, ask a trainer for certifications, ask a contractor for a license and a portfolio of finished jobs. The point is to confirm, before the stakes are real, that this person can deliver what they promise. We do it instinctively, because the cost of being wrong is high and the work is hard to judge from the outside.

For AI skills, none of that exists. No license, no rating, no track record, no review, no way to tell whether the author has ever done the work the skill claims to encode. The marketplace ships the artifact and strips the one signal we reach for everywhere else.

There is a real distinction underneath this, and it is why "just share it, open source works" does not quite apply. Open-source code can be objectively tested. It compiles or it does not; the test suite passes or it fails. Judgment cannot be compiled. A PRD skill or a discovery skill encodes a way of thinking, and there is no unit test for a way of thinking. It can only be vetted by reputation or by team consensus. That is precisely why provenance matters more for skills than it does for code, not less.

What I see instead is a flood of black boxes from anonymous creators. A 200-kilobyte zip from a username, promising to encode product discovery, with no way to tell whether the person behind it has ever shipped a product, and no way to tell whether the zip even runs. I would love to install a discovery skill Marty Cagan stood behind, a positioning skill from Geoffrey Moore, a growth skill Gibson Biddle endorsed, or a Claude Code skill shaped by someone like Cat Wu, who actually builds the tools. I do not need the author to be famous. I need to know they have standing in the problem they are trying to encode. The point is not celebrity; reputation is a signal, not a guarantee. The point is accountable authorship: a named person with real standing who will own it when it gives bad advice.

A film at least passed through someone before it reached me. A bad public skill often passed through no accountable owner at all.

Where a skill actually belongs

Here is the part almost no one is saying. Public skills have their place: a skill from a trusted author is a fine way to learn a method, a starter kit, a way good practice spreads between teams. The public repository is good for discovery. But the natural home for an authoritative skill, one your team actually runs on real work, is a team.

Five product managers in the same unit will write a RACI five different ways, structure a user story five different ways, file a Jira ticket five different ways. Every one of those differences is a small tax on everyone who has to read the next person's work. Multiply it across a quarter and a roadmap and you get the real cost of unstandardized product work, which was never the typing. It was the rereading, the reconciling, the relearning of each colleague's private format.

A shared, organization-endorsed skillset removes that tax. When a group of PMs runs the same skills, the deliverables become predictable: same prerequisites, same structure, same definition of done. The value is not "look how AI-proficient I am." It is harmonization and collaboration, the same value a template always delivered, now with reasoning attached.

And inside an organization, a skill can be governed the way a real standard is: authored by someone accountable, versioned as the practice evolves, reviewed against actual outcomes, and retired when the team's thinking moves on. That is the layer the public marketplace cannot supply and a team supplies by default.

Design solved this years ago and gave it a name. Five designers will draw five buttons, so design teams built shared component libraries and design systems. The point of a design system was never to make any one designer faster. It was consistency, velocity across the team, and a lower cost of working together.

A team skillset is a design system for product deliverables. That is the model, and it is a proven one. A good design system is not bureaucracy; a bad one is. It earns its place by lowering the cost of working together, not by adding a gate.

And inside an organization, the provenance problem solves itself. You know who authored the skill, they are accountable, and the team endorsed it because it represents how they have decided to work. "Is this authoritative" becomes answerable. The anonymous public skill was always the strange case. The team skill is the obvious one.

What it can and cannot carry

One honest line, so the reframe does not overclaim. A skill can carry codified judgment, the framework, the checklist, the questions a good practitioner always asks, and apply it. What it cannot do is make the specific call in the room. It can standardize the inputs; it cannot guarantee the truth of them. The RICE skill runs the arithmetic; it cannot tell you whether to believe the reach number you typed in. The discovery skill asks the right questions; it cannot decide which customer's pain is load-bearing and which is noise. The dangerous part of a prioritization skill was never the formula. It is the false confidence that arrives when subjective inputs come out looking like arithmetic. The skill hands you the frame; your judgment is still spent on the decision. The template was always there to free you for the part that was actually hard. The skill is the same bargain, kept better.

So the skill feed is not evidence of a discipline leveling up. It is mostly evidence of a tool being used backward: shipped first instead of last, by anyone instead of by authorities, into the public instead of into the team, and sold as speed when its real gift was consistency. The skills worth having are the ones with a name behind them and a team around them. Everything else is a macro wearing a template's clothes.