The install command is no longer your most important CTA

Q: What is a skill, or SKILL.md, for an AI agent?

A skill is a folder with a single SKILL.md file: machine-readable metadata plus plain-language instructions that teach an AI agent how to use a specific tool or complete a specific job. Anthropic formalized the format as Agent Skills, and by 2026 more than a dozen agents read it, including Claude Code, Cursor, Codex, Gemini CLI, and GitHub Copilot.

For fifteen years the most important line on a developer tool’s homepage was an install command. That is quietly changing. The new unit of onboarding is a skill: a single markdown file that teaches any AI agent how to hire your tool for a job. Teams that ship a great one will own the agentic funnel. Teams that only ship an install command will be invisible to the fastest-growing class of users.

The hero section is changing, and most teams have not noticed

Open a typical developer tool homepage today and the hero still leads with a command to copy, something like npx create-app@latest. That is the call to action developer tools have shipped for years. One line, copy it, paste it, you are in.

Now look at what is starting to sit next to that command on newer sites. A second block that reads, roughly: Tell your agent to: read our skill and get me set up. The primary instruction is no longer aimed at you. It is aimed at the agent working on your behalf.

This is a small visual change and a large strategic one. For most of the last decade the person reading your quickstart and the person running your tool were the same human. That assumption is breaking. The first entity that reads your docs, runs your install command, and hits your API is now, very often, a coding agent that a human pointed at your homepage and walked away from.

If your onboarding only speaks to the human, you are optimizing for the user who is showing up less and less.

A skill is an onboarding guide for a new hire

Here is the analogy that makes this click. An agent is a brilliant, fast, slightly overconfident generalist. It has never worked at your company and it has never used your product. A skill is the onboarding guide you hand that new hire on day one: here is what we do, here is how you get set up, here is the one path that works, here is what to do when it breaks.

Technically, a skill is almost nothing. It is a folder with a single SKILL.md file: a few lines of machine-readable metadata at the top and plain instructions below. Anthropic formalized this as Agent Skills, and by early 2026 the same format was read by more than a dozen agents including Claude Code, Cursor, Codex, Gemini CLI, and GitHub Copilot. One file, many agents.

What makes it different from your existing docs is progressive disclosure. The agent does not read your whole skill all the time. It loads three tiers on demand: the name and description at startup (30 to 50 tokens, just enough to know the skill exists), the full SKILL.md only when a task matches, and any deeper reference files only when a step actually needs them. Your docs are a library the human browses. A skill is a playbook the agent opens at the exact moment it has your job to do, and ignores the rest of the time.

That is the whole idea. Now the important part: why it matters more than it looks.

Tools change, the job does not

Clayton Christensen told a story about milkshakes. A fast-food chain wanted to sell more of them, so it studied who bought them. It turned out a huge share sold before 8am, to solo commuters, who drank them alone in the car. The job was not “drink a tasty shake.” The job was “make my boring commute survivable with one hand on the wheel.” The milkshake was not competing with other milkshakes. It was competing with bananas, bagels, and boredom. People do not buy products. They hire them for a job.

Developer tools are milkshakes. The developer’s job is durable: get live data into my app, stand up a content backend, add payments, ship a search index. The tool they hire to do it changes constantly. Frameworks, databases, and APIs come and go. The job stays the same.

In the agentic era the hiring chain gets one link longer. The developer no longer hires your tool directly. The developer hires an agent, and the agent hires your tool. That is the shift that should reorganize how you think about onboarding. Your buyer used to read your positioning. Now an agent parses your SKILL.md, decides in a few hundred tokens whether you can do the job, and either wires you in or moves to the next option. If your tool is not legible to the agent, you are the milkshake nobody at the counter knows how to order.

And the pool of people giving orders is exploding. Andrej Karpathy’s phrase “vibe coding” named the moment building software stopped requiring you to write every line yourself. That raised the floor: people who never shipped code can now describe an outcome and get working software. Skills are how a raised-floor builder succeeds with your specific tool without ever reading your docs. The agent reads them instead. So a great skill does not just improve onboarding for existing developers. It opens your market to everyone who can describe a job in a sentence.

The anatomy of a skill that works

Abstract advice is useless here, so here is what the best agent onboarding skills in the wild have in common. Six traits, each of which you can copy. None of them are glamorous, and all of them are the difference between an agent that succeeds on the first try and one that gives up and tells its human “I could not get this working.”

Start with the metadata, because it is where the agent decides whether to even keep reading. An illustrative skeleton:

---
name: acme
description: |
  Acme gives agents reliable, structured access to X. One install sets
  up the CLI, the build skills, and the workflow skills. Route the agent
  to the right path after install.
---

The description is the trigger, not marketing. The frontmatter description is the single most important field in the file, because it is the 30-token summary the agent uses to decide whether to open the skill at all. Write what the tool does for an agent and what the install produces, in the agent’s own task language. It should read like a job spec, not a tagline.
One install, mapped to jobs. The strongest skills expose a single install command, then immediately map what it produced to distinct jobs: which command do I run right now, how do I add this to a codebase, what is the finished deliverable. The agent is routed by the job it has, not by a feature list.
Choose your path. Instead of one linear happy path, good skills branch: need the tool during this session, go one way; wiring it into app code, another; producing a finished deliverable, a third; need an account first, a fourth. That is how you serve a generalist that could arrive with any of a dozen intents.
Tell the agent to verify. After install, the best skills run a status check and one real call into a check file before doing any actual work. That single habit prevents the worst agentic failure mode, an agent confidently building on top of a broken setup.
Close the loop to the human for auth. A good credential path spells out how the agent asks the human to authorize a key, polls for it, and saves it, including the exact URL to open. It respects the boundary: the agent does the work, the human grants access.
Fail gracefully. The best skills define a fallback for when the human cannot sign up right now, clearly marked as limited. A skill would rather help a little than fail completely.

You can see these traits in the open Agent Skills examples Anthropic publishes, and in the growing set of dev tools now shipping a skill next to their install command. I ship one for this site too, at anilkumark.de/skill.md, so an agent can read it and answer questions about my work. The pattern is converging fast, which is exactly why it is worth getting right early.

The hard part is keeping it alive

Here is the trap. A skill is not a landing page you ship once. It is training data that has to move at the speed of your product. The moment your install command changes, an endpoint is renamed, or a default flips, a stale skill starts actively lying to every agent that reads it. And an agent does not shrug off a wrong instruction the way a human skims past an outdated screenshot. It runs the dead command, fails, and reports back that your tool is broken. Stale documentation is a nuisance. A stale skill is a broken product experience.

So treat the skill like code, not like content. Keep one source of truth, not a copy pasted into five places. Version it. Write evals that actually run the skill end to end in CI, so a renamed flag breaks your build instead of your users’ agents. Give it an owner. This is the difference between what compounds and what decays: a maintained skill gets more valuable every time your product improves, while a fire-and-forget skill quietly rots into your worst support channel.

How to write one, in five moves

Start from the job, not the feature. Open with what the agent is trying to accomplish, for example “get reliable data into this app,” not “we have seven endpoints.”
Write the description for the trigger. Spend disproportionate effort on the frontmatter description. If the agent cannot tell from 30 tokens that you can do its job, nothing else in the file matters.
One golden path, then branches. Give the agent a single obvious route for the common case, and explicit paths for the forks. No choose-your-own-adventure for the 80 percent case.
Make every step verifiable. After each meaningful action, state the expected result and give a command to confirm it. Agents recover from checkpoints, not from vibes.
Design the fallback and the failure. Say what to do when auth is not available, when a call fails, and when your tool is the wrong choice. Which brings us to the last point.

Agent-readiness is the new differentiation

When your tool and a competitor’s can technically do the same job, the agent does not pick the one with the better brand. It picks the one it can succeed with fastest and most reliably. Agent-readiness is becoming the new developer experience, and developer experience has always been the real moat for dev tools.

There is a counterintuitive move that wins here, and it comes straight from how developers evaluate tools: tell the truth, including when not to use you. A skill that says “for this narrow case, a lighter tool is a better fit, here is how to tell” earns trust with the human behind the agent, because that human eventually reads the transcript. The tool that only ever says “use me” is the one that gets an agent stuck, and a stuck agent is the fastest way to lose a builder who was one prompt away from adopting you.

What this means for us, and who “us” even is now

For years, “builder” meant “person who writes code.” That definition is dissolving. A builder is now anyone who can direct an agent to get a job done, and that is a far larger market than the set of people who can write a for-loop. Your onboarding now has three audiences at once: the developer, the agent acting for the developer, and the non-coder who is directing the agent and reading the result.

If you build or market a developer tool, the practical takeaways are direct. Your ideal customer profile now includes an agent as a first-class user. Your SKILL.md is a distribution channel, not a docs afterthought. Your install command still matters, but it is table stakes, the thing that runs after the agent has already decided you can do the job. I gave a version of this argument on stage at devWorld 2026, and it has only gotten truer since.

The install command told a human what to type. The skill tells an agent how to win. Within a couple of years, agent-readiness will be a line item in every serious dev tool launch, and the teams that treated their skill as a real product, versioned, tested, and honest, will quietly own the funnel that everyone else cannot even see.

Ship the skill.

FAQ

What is a skill, or SKILL.md, for an AI agent?

A skill is a folder with a single SKILL.md file: machine-readable metadata plus plain-language instructions that teach an AI agent how to use a specific tool or complete a specific job. Anthropic formalized the format as Agent Skills, and by 2026 more than a dozen agents read it, including Claude Code, Cursor, Codex, Gemini CLI, and GitHub Copilot.

How is a skill different from documentation?

Documentation is a library a human browses. A skill is a playbook an agent opens only when it has a matching job. Skills use progressive disclosure: the agent loads the name and description at startup, the full file only when a task matches, and deeper reference files only when a step needs them, which keeps the agent’s context small.

Why does agent onboarding matter for developer tools now?

Because the first user of your tool is increasingly an agent acting for a human, not the human directly. The agent reads your skill, decides in a few hundred tokens whether you can do the job, and either wires you in or moves on. If your tool is not legible to the agent, it loses to one that is, regardless of brand.

How do you keep a skill from going stale?

Treat it like code, not content. Keep one source of truth, version it, give it an owner, and write evals that run the skill end to end in CI so a renamed flag or changed command breaks your build instead of your users’ agents. A stale skill actively misleads every agent that reads it.

Anil Kumar Krishnashetty is a Senior Technical Product Marketing Manager at Bright Data in Berlin. Previously frontend engineer at SAP and One.com, technical product manager at Contentful and commercetools, and PMM at Lokalise and Parallels. He speaks about developer experience, the agent-era web, and technical product marketing, 25+ talks and counting.