What it means for product teams building with AI.
The questions arrive every week now, from different clients but in roughly the same shape.
"How could we automate this whole sequence?"
"Could agents handle these handoffs between us?"
"What would it take to get the manual touch points down to the minimum?"
Different products. Different teams. Same week. Each conversation goes deeper than "can you add AI." Clients are not asking for a button anymore. They are asking how the shape of their work changes when models can hold context, take actions in sequence, and pass tasks to one another with little human interruption.
Each time, I sit down with a blank doc and ask the same questions. By the end, I have something useful: a structured brief that tells my team whether the request is real, what to build, where humans should stay in the loop on purpose, and whether the whole thing is worth building at all.
But the doc is mine. The framework lives in my head. The next time a colleague handles one of these calls, they start from scratch too.
This is the problem skills solve. And if you are building anything with AI in 2026, they are the most important primitive most teams have not discovered yet.
A short history of how we got here
In 2023, we learned to prompt. "Write a PRD for X" got better with practice, but the quality of the output still depended on the wording of your last message.
In 2024 and 2025, the conversation moved to context engineering. People stopped chasing clever one-liners and started building richer inputs: system messages, examples, retrieved documents, structured templates. Prompting became less about the words and more about the setup.
In late 2025, Anthropic released Agent Skills, and the standard has since been adopted across the ecosystem. The shift is subtle, but the implication is large.
Prompting is a verb. Skills are a noun.
A prompt is what you do once. A skill is what your team has.
What a skill actually is
A skill is a folder. Inside that folder is a file called SKILL.md. At the top of the file, between two lines of ---, you write two things: a name and a description. Below the dashes, you write plain instructions in Markdown. That is it.
When you give Claude access to a skill, this is what happens. At the start of every session, Claude sees only the name and description, not the full body. That short description is what Claude uses to decide, on its own, whether the skill is relevant to your current request. If it is, Claude loads the full instructions and follows them. If it is not, the skill stays quietly in the background.
This pattern has a name: progressive disclosure. And it changes the economics of giving an AI specialized knowledge.
Before skills, if you wanted Claude to follow your team's framework every time, you had two options. Paste the framework into every prompt (tedious, error-prone). Or stuff it into a custom system message (works, but does not scale across many frameworks for many different tasks). Skills give you a third option. Write the framework once. Save it as a folder. Let Claude pull it in only when it actually applies.
A real example: turning AI conversations into structured briefs
Let me make this concrete with the skill I described at the start of this post.
The job: when a client asks how AI, automation, or agent workflows could change their work, I want to capture the conversation in a way that lets my team evaluate it consistently. Not "this client wants AI." But something more useful: what is the real job, where does AI actually fit, where should humans stay in the loop on purpose, what does success look like, what is the risk.
Here is what the SKILL.md looks like.
markdown
---
name: ai-initiative-brief
description: Turns raw notes from a client conversation about AI, automation, sequencing, or agent workflows into a structured discovery brief. Use when notes describe a client exploring how AI could change how their work happens, asking how to automate sequences, introduce agents, or reduce manual touchpoints.
---
# AI Initiative Brief
When given raw notes from a client conversation about AI, automation, or agent workflows, produce a structured brief with the following sections.
## 1. The underlying job
Restate what the client is actually trying to accomplish, in their words.
Avoid restating the request as "they want AI." Get to the job behind it.
## 2. AI fit check
For each part of the job, decide:
- Is this a job a language model is good at? (judgment, summarization, transformation, generation)
- Is this a multi-step workflow that could benefit from sequenced agents passing work between each other?
- Or is it deterministic work that just sounds like AI? (lookups, rules, dashboards)
The honest answer is sometimes "this part is not AI-shaped."
## 3. Scope and sequence
Describe the minimum useful version. Note where automation begins, where it ends, and where humans stay in the loop on purpose.
Anchor scope to what the client already does today.
## 4. Integration
Where in the client's existing workflow does this live? What systems and handoffs does it touch?
Note auth, data, and workflow constraints the conversation surfaced.
## 5. Success metrics
What changes for the client if this works? Use their language.
Quantify only if the client gave numbers; otherwise note the qualitative signal.
## 6. Risk and unknowns
What could make this not work? Model accuracy, agent reliability, handoff quality, data quality, change management, regulatory.
List what we still need to learn before scoping further.
## Output format
Markdown, ready to paste into Notion. Keep each section tight.
If a section cannot be filled from the notes, write "Not covered, ask in follow-up."That is the whole skill. Less than 50 lines.
Now, when anyone on the team pastes raw call notes into Claude and asks for a brief, they get the same structure I would produce. The judgment about what to look for, what to flag, and where to push back lives in the file, not in my head.
Why this matters more for product teams than almost anyone else
Most discussion of skills so far has come from engineering. That is understandable. The format is technical, the early use cases are technical (Anthropic shipped PDF, DOCX, PPTX, and XLSX skills first), and the docs assume you are comfortable in a terminal.
The actual leverage is somewhere else.
Product work compounds. The PRDs written three years ago shape the templates used today. The framework applied to one feature prioritization becomes the default for the next. The questions asked in a client call get sharper with every call. Skills are the first AI primitive that maps cleanly onto this. They let you take the parts of your judgment that have stabilized and encode them, so the next person on the team starts where you left off.
That is not a productivity gain. That is an organizational capability.
It is also why, when I heard Gabriel Hubert (CEO of Dust) say at Lead Innovation Day that leaders spend most of their time repeating themselves, skills came to mind immediately. They are the most direct answer to that problem I have seen in tooling. You write the rules once. The flock moves.
How to start, in 30 minutes
Pick one task you do at least weekly that follows the same shape every time. Not a complex multi-step workflow. One artifact, one judgment.
Open a text editor. Create a file called SKILL.md. Write the frontmatter (name and description, between --- markers). Write the instructions in Markdown, the way you would explain the task to a smart new hire. Save the folder.
Upload it to Claude (in claude.ai settings, or via the API if you are building product workflows). Run it against a real input. Notice where the output does not match what you would produce yourself. Edit the instructions. Run it again.
Within an hour, you have a working skill. Within a week of using it, you have a version that is better than the one in your head, because writing forces you to clarify what you actually do.
The shift
Prompting was a personal skill. You got better at it; the people next to you did not.
Skills make that knowledge transferable. They are how teams will encode their judgment in the AI era.
If you are building product, this is the moment to lead. The frameworks you have spent years building are the most valuable thing you can give an AI. Write them down. Save them as a folder. Let the team's judgment compound.
The flock moves together because the rules are encoded, and clear.
If you want to dig deeper, Anthropic's introduction to Agent Skills is a good starting point, and the open repository at github.com/anthropics/skills has real working examples to learn from.
