Skills to Pay the Bills: What Good Agent Skills Look Like

I often hear, “Kyle, you say you haven’t written a line of code in two years. But whenever I use coding agents, I end up rewriting everything the old-fashioned way. What am I missing?”

And I reply, to the voices in my head: “You can’t just install Claude Code and let it rip. You need to configure it with the right skills and context!”

Discussions about AI-driven software development tend to focus on adoption rather than maturity. DORA’s 2025 report puts adoption at 90%, with users interacting with AI for a median of two hours a day. Yet Sonar’s 2026 State of Code Developer Survey found that only 25% of developers regularly use agentic AI tools. So it seems that AI has reached the everyday developer, but it has yet to reach the SDLC of the everyday software business.

At Hypership, I often get the opportunity to work with other software companies to help their engineers use AI effectively across the SDLC (and that’s my ad out of the way). The setup I encounter most often is VS Code or Cursor, with developers using GitHub Copilot primarily for autocomplete and planning. That is a perfectly valid starting point, but what does progression from there actually look like?

Whenever I speak to an engineering team about getting more from these tools, I boil it down to two things:

• If you understand context engineering principles, it changes how you think about and interact with these tools.
• If you utilise skills, the difference in results can be substantial.

Skills are, in effect, domain knowledge that agents can invoke on demand. It's like if you ask me what the greatest Disney movie of all time is. That question triggers me to recall a bunch of information I don't keep active in memory. Disney World. The theme music for Mickey Mouse Clubhouse (that one's for the parents). And within a second, I'd obviously answer: Mulan.

Now imagine a much more professional situation. I need my coding agent to write some UI for my website, but it keeps making everything in purple gradients (that's a real thing, by the way). With a plugin like Impeccable, it could call upon knowledge from actual designers. Expertise on subjects like spatial design, colour theory, typography, and elevation, all baked in as a set of skills.

You can write skills for anything. Your business strategy. Your customers' pain points. Your internal jargon. Your brand. Your deployment quirks. What your team agree is “clean code”. Anthropic even have a skill for creating skills.

Now here's the thing. You can write skills that cause problems. You can have too many skills. And to make things even more confusing, the exact same skill can perform differently depending on which harness and model is using it. Not in a “smarter model = better results” way, either. More like: smarter models actually prefer simpler instructions.

What follows is my own interpretation of what good looks like, shaped by a chronically online interest in skills created by people and companies smarter than me, and grounded in a couple of years of trial and effort transforming my own SDLC.

But before we examine what makes a good skill, we need to understand the environment it operates in. A skill isn’t magic; it is context, introduced at the moment it becomes useful. And context is finite.

Contextual awareness

Whenever I start up Claude Code, the first exchange typically fills the context window from empty to about 5% capacity, roughly 50,000 tokens loaded right at the start of a session.

One “hello” in, and 5% of the context window is already spent.

So what’s taking up all that space? Here’s what gets injected upfront:

• Anthropic's system context for the harness
• Global and project-level CLAUDE.md files
• Auto memory
• Environment information
• MCP tools
• Skill descriptions

To keep things efficient, skills use progressive disclosure, so in the scenario above, only the name and a one-line description of each installed skill are loaded initially. Therefore your skill's description is arguably the most important “UX” consideration in the sense that a good description is more likely to get invoked organically by the model in the right moments, although it's worth saying you can invoke skills directly in your prompts by using a slash (/) command.

Good looking skills

In one sentence, a good skill description tends to include:

• What it does
• When to use it
• Why to use it

Take for example the most widely installed skill in the Anthropic ecosystem, frontend-design:

name: frontend-design
description: Guidance for distinctive, intentional visual design when building
  new UI or reshaping an existing one. Helps with aesthetic direction,
  typography, and making choices that don't read as templated defaults.

If the model decides to call the skill, the full contents get loaded in. In this case, things like the two-pass process (plan a token system first, critique it against the brief, only then write code), the explicit callout of “AI-looking” design patterns, and the insistence on grounding every choice in the subject's actual world and materials. This skill is giving a model context on how to think like a designer.

So the question you should be exploring while writing your own skills is: where does the instruction need to be prescriptive, and where does it need to leave room for the model's own judgement? Too much specificity and you get rigid outputs that all look the same, which is exactly the disease this skill exists to cure. Too little and the model falls back on its defaults, and you're back to purple gradients.

It's prescriptive about outputs and constraints. The palette must be 4 to 6 named hex values. Typography needs at least two roles, a characterful display face and a complementary body face. It even names the specific hex neighbourhood to avoid (#D97757, Anthropic's own accent colour). These are hard edges.

It's ambiguous about everything else though. It never says “use a 12-column grid” or “put the CTA above the fold”. Instead it says things like “the hero is a thesis” and “structure is information”. Numbered section markers aren't banned; the skill just asks whether the content is actually a sequence before using them.

I'm getting too in the weeds of this specific skill… moving on!

Use official skills before writing your own

Check what's already published for your stack. Because every good tech company now ships skills.

Let's say you're working on some AWS solution. Their Agent Toolkit is an official, AWS-supported collection of MCP servers, skills, and plugins, usable straight from the terminal via the AWS CLI. One install command and your agent has curated knowledge covering service selection, CDK and CloudFormation, serverless, containers, storage, observability, and deployment.

Most importantly, when installed as a plugin, those skills would update automatically as AWS ships new capabilities. Skills aren’t so different from documentation. In many cases, they effectively are documentation, translated into instructions an agent can act on. And like any documentation, they rot: behaviours and best practices change all the time in software. With an official skill, that maintenance burden sits with the people who own the source of truth.

AWS are just one example. Vercel have packaged ten years of React and Next.js optimisation knowledge into a react-best-practices skill. Cloudflare released skills for over forty of their services. Supabase shipped Postgres best practices drawn from their support team and database advisors, the accumulated scar tissue of running Postgres for hundreds of thousands of projects. Generally speaking, if you are a company that sells to developers you would be bonkers to not have an official skills plugin.

This approach alone can significantly improve the quality of your agent’s output for little more than a few install commands. Of course, a mature setup can quickly accumulate a lot of skills, and you don’t need all of them available in every workspace. Scope skills to the projects that actually need them. Don’t install your Azure plugin globally if half your projects run on Google Cloud, for example. Good context engineering is as much about excluding irrelevant information as it is about providing useful context.

Writing your own skills

So if official skills provide the vendor knowledge, your own skills should capture what no vendor can: your architecture, conventions, operational edge cases and accumulated tribal knowledge.

Writing a skill is easy, there's a skill for that… Writing one that deserves to exist, and continues to work over time, requires focus. The pattern I apply to every skill I write is: be exact about the destination, flexible about the route, and always give the model a way to check whether it actually arrived. You want to supply the judgement the agent lacks without taking away the judgement it already has.

PostHog recently published some excellent guidance on this. At the far end of the maturity curve, they've published 226 internal skills and built a “context mill” that generates versioned skills from maintained sources of truth (e.g. documentation). Basically, they treat skills as routers rather than encyclopaedias: lightweight instructions that help the agent recognise what knowledge it needs, where to find it and when to load it, without carrying everything in context all the time.

If you’re not ready to build an automated skill factory, the sensible middle ground is to manage skills like a shared codebase. Keep them version-controlled in a git repository, make them easy to install (use the Agent Skills format), and take ownership for maintaining and improving them.

Make every skill earn its place

Ultimately, a skill is operational knowledge with a trigger. Before writing one, ask two questions: have you done this task three times, and are you likely to do it three more? Then ask the agent to perform it cold. If it handles the work perfectly well without additional guidance, you don’t need a skill. If it struggles in consistent, repeatable ways, you probably have a good candidate.

Once the skill exists, treat its first run as a test. Ask the agent where it fell short: which tools it reached for, where the instructions were unclear and what it had to infer. Update the skill and run it again. Repeat that loop every now and then, and it will teach you more about writing good skills than any article, including this one. And that is how you make skills to pay the bills.