Welcome to another series on building with AI agents, where I break down the fundamentals of what it takes to build an agent that knows you, understands how you think, and can partner with you to make better decisions—faster and with less effort.
Over the last few months, I’ve written about many topics to help you build more personalized and effective agents, including:
The Better Your AI System Gets, the Less You Have to Explain
💎 The Complete Guide to Building Your First Agentic System (That You Can Actually Trust)
💎 The Complete Guide to the Context Folder That Changed How I Work With AI Agents
I write about these mainly because I still meet many people who feel that AI is not really capable of doing human work, or that it keeps hallucinating. They end up disappointed and conclude that AI is just hype. Those people still don’t realize how much AI’s capabilities have grown over the last three years, and they are still using it like a slightly better Google. They haven’t built an AI system that actually knows who they are and what they are working on.
This reminds me of a realization from Sam Altman on David Senra’s podcast, where he admitted how wrong he was in predicting how quickly people would adapt to using AI, given its capabilities. In reality, adapting to new technology is harder and takes much longer than optimists typically expect.
This is why I’ve become so passionate lately about digging into the mechanics of working with AI. The more I use it, the more I realize it’s no longer about prompting or running one-off chats with an agent, but about building systems that last and actually help you do better work and be more productive.
And today’s topic is Skills.
Garry Tan (CEO of Y Combinator) has a phrase for how he builds AI agents: “thin harness, fat skills.”
In his essay, he describes skills as reusable procedures that carry process, judgment, and domain knowledge. You give the agent a specific request, and the skill supplies a method for working through it.
That connects to something I wrote about in my previous post on agent harnesses. Having better AI models is not the only way to improve your work with AI; building the right AI system is. A system with the right instructions, sources, tools, boundaries, and checks around the work.
In my newsletter setup, that includes files explaining my audience, what I write about, how my free and paid posts differ, and the standards I want the writing to follow. As those files get better, the agent has a better starting point. I spend less time explaining the publication from the beginning.
But knowing about my newsletter still leaves a lot of room for interpretation when I ask the agent to do something specific.
Take research.
The agent can know who I write for and still collect sources that don’t help me decide what to write. It can understand my topics and still suggest an angle I’ve already covered. It can produce a detailed brief without making clear which claims I can actually support.
At that point, I need to explain how I want the research done. Where to begin, what to look for, which sources to trust, what to question, and what I need to see before choosing a direction.
That is where skills shine.
The same applies to proposals, meeting summaries, brainstorming, and action plans. These are tasks we come back to regularly, each with a process shaped by what we care about and what we consider good work. If we keep asking the agent to do them, it makes sense to capture that process in a skill so we don’t have to explain how we want the work done every time.
A skill gives your process a form the agent can use
A skill is a reusable set of instructions for a particular type of work. A simple way to think about it is as a standard operating procedure, or SOP, written for an agent.
It describes how to handle the job: what information to read, which steps to follow, how to make the decisions along the way, and what to check before returning the result. You supply the specific request, such as preparing a proposal for a new client. The skill supplies the process you want the agent to follow for proposals.
If you use Claude and ChatGPT to build a skill, you can trigger it with a custom slash command called /skill-creator.
Once the skill is generated, the main instructions for the skill live in a file called SKILL.md, with supporting references, examples, or scripts alongside it when needed. Anthropic’s explanation shows how a skill can direct the agent to additional material as the task requires it.
That gives every work you want to do with AI a starting point so you no longer need to manually prompt everything from zero.
For example, imagine you work with several clients. Each has a different business, different needs, and a different conversation behind the proposal you’re going to send them. You could build a skill that reads the discovery call transcript, understands what the client needs, compares that with the services you provide, and prepares a proposal.
When another client comes along, you can use the same skill with their information. The agent follows the process you’ve already defined, using the new client’s situation to shape the recommendation. You may still need to clarify missing details or adjust for an unusual request, but much of the work leading up to a proposal you can review can follow that repeatable process.
That process can reach into the apps you already use, too. Once your agent has the right connections and permissions, a skill can guide it to context in Gmail, Google Drive, Google Sheets, or Notion, as well as meeting notes from Granola or transcripts from Fathom/Zoom. You can build a process around information that lives across those apps, beyond the files on your computer.
For the proposal, that might mean reading the discovery call transcript, checking the client’s follow-up email in Gmail, and consulting your service information in Notion and pricing in Google Sheets before preparing a draft for you to review. The connections give the agent access; the skill explains which information to use and how to work with it.
This is how skills tie the harness together. The harness provides access to files and tools, along with instructions and boundaries. A skill is one part of that system, organizing the pieces around a particular job. It gives you a process you can reuse, inspect, and improve as you see the agent work through real requests.
A skill carries your judgment into the work you delegate
Looking back at Garry Tan’s explanation, this is what makes skills valuable to me. A skill is a compact version of my judgment about a particular type of work: how I want it done, what the agent needs to consider, and what would make the result good enough for me to use.
My newsletter context can help with writing, outlining, brainstorming, research, and social posts. But knowing my audience doesn’t tell the agent how I choose an article angle or decide whether a research brief gives me enough evidence to write. Each job needs its own instructions for applying that context and evaluating the work.
The more I use agents, the more of these recurring jobs I see as worth teaching through skills. When I can explain the process, the relevant sources and tools, and the decisions I care about, I give the agent a clearer way to work toward my quality bar. As I build more skills, I can see which parts of the job it can handle and where it still needs me.
I now have many skills, each serving a different type of work. For example, one skill repurposes my newsletter into different types of social posts, another summarizes what’s happening in AI based on the newsletters I subscribe to, and another reviews my writing. These skills help me save a lot of time by avoiding the need to re-explain everything to an agent.
This is why most people should build more skills into their workflow. That’s where you learn to extract your standards and judgment, convert them into text-based markdown files that an agent can follow, and turn them into reusable instructions you can trigger at any time.
But, to get there, you need to make those standards specific enough for the agent to apply.
7 questions to include when you build a skill
When you build a skill, describe the job clearly enough that the agent knows how to begin, how to work through it, and what you expect back.
I’d use these 7 questions to put those instructions together:
When should the skill run? Describe the requests or situations it applies to. “Prepare a proposal after a client discovery call” gives it a clearer purpose than “help with client work.” You can also ask the agent to use the skill by name.
What should it produce? Specify the deliverable, its format, and what it should help you accomplish. For a proposal, that might be a draft you can review with the recommended scope, pricing, timeline, and open questions.
What context does it need? Name the files, examples, previous decisions, and information from connected apps that the agent should consult. Explain what each source is for and which takes priority if they disagree.
What process should it follow? Lay out the sequence, when to use particular tools, and how to make decisions along the way. Understanding the client’s needs comes before choosing deliverables. Include the criteria you use to choose between plausible options.
What does good look like? Describe your quality standards and include an approved example with an explanation of why it works. In a proposal, you might expect every recommendation to address a stated client need and every assumption to be visible.
What should it do when something is missing? Explain when to ask a question, flag uncertainty, or pause. If missing information would change the scope or price, the agent should know to ask before committing to a recommendation.
What should it check before finishing? Define how to evaluate the result and what needs your approval. For a proposal, that could mean checking that scope, price, and timeline agree, then returning the draft for review before anything is sent.
These are the types of questions I keep asking myself to build and evaluate my skills. Every time I find a flaw in the output, I revisit the Skill.md file to understand what the AI actually built for me and correct it again.
A skill is not a one-off activity that you can just build and forget. It takes a refinement process to get to the point where you’re actually satisfied with the result.
That’s why I think it’s important to have a good eval process to check the quality of the outputs the agent generates for you. We’ll go into the eval process in an upcoming post.
How my paid-post evaluator applies my editorial standards
Now, let me walk you through my favorite skill that I used to grow AI Maker Lab, where I write mostly in-depth implementation posts with prompts, templates, skills, and agents that readers can simply copy.
The skill called paid-post-evaluator.
It is designed to help me decide whether a topic deserves a paid AI Maker Lab post. I can give the agent a rough idea, a tool, or a reader question and ask it to evaluate the topic using that skill.
The skill starts with a rule that matters to me: an interesting topic doesn’t automatically deserve a paid post. I want a paid post to give readers a working version they can copy, adapt, or run. That could be a set of files, a template, an automation, or a workflow with the setup and checks needed to use it.
That standard shapes what the agent is instructed to do. Before suggesting angles, it needs to verify what the tool or feature actually does and research what could be built with it. It uses tools like Tavily to run deep research. The skill also points to separate references for the research method, patterns from my paid-post archive, a scoring rubric, and the format of the final brief.
The archive reference gives the agent something specific to look for: a real problem, a setup or connection, something readers can copy, a visible output, and limitations the post needs to explain. It also tells the agent to name the gaps when an idea can’t support those parts.
From there, the process asks for two or three possible angles, followed by one recommendation. The agent then has to develop that recommendation far enough to explain what I would build, what readers would receive, what they could do with it, and what I would need to test first.
The scoring rubric carries more of my judgment. It asks the agent to consider the reader’s problem, the usefulness of the deliverables, the implementation detail, and whether I can show real proof. Novelty alone isn’t enough. An idea should be marked down if it repeats something I’ve already published without adding a useful capability, or if the setup would be too difficult for most readers to adapt.
As a proof of this skill’s output, a while back I was thinking about how to create a video animation using AI, and a tool called HyperFrames by HeyGen came into the picture. I told the agent to use the skill to figure out what I could do with HyperFrames, and here’s the result:
Look, I just gave you a clue for this Thursday post :)
As you can see, the output is a decision brief with research, a proposed build, scores, tradeoffs, and a next step. The skill explicitly allows recommendations such as “better as a free post,” “better as a live demo,” or “do not pursue yet.” It gives the agent permission to reject an idea instead of finding a paid angle for everything.
I still decide whether to pursue the recommendation. Having these instructions doesn’t prove that every evaluation will be useful. But it gives me something concrete to review: did the agent find a build readers could use, support its recommendation, and flag what I still need to prove? If it misses something, I can look at whether the process or the criteria need adjusting.
Turn a task you already do into your first skill
Look back at the work you’ve asked an agent to help with recently: Which tasks will come around again? Which ones took a few corrections before the result felt useful? Those are good places to look for your first skill.
Here are a few possibilities:
Turn discovery call notes into a client proposal based on the services you offer.
Compare tools for a purchase, checking your requirements, budget, and reasons to rule an option out.
Prepare a weekly project update that surfaces changes, blockers, and decisions someone needs to make.
Brainstorm article angles, check what you’ve already covered, and develop the strongest one into an outline.
Turn a newsletter into social posts using examples of how you write for each platform.
Review a draft for the issues you regularly catch before publishing.
Pick one where you can recognize a useful result. You don’t need to have the whole process written down yet. Use this prompt to have the agent interview you and help turn your answers into a skill:
“Help me build a reusable AI skill for a recurring task.
Start by asking what work I want help with and what a useful result would look like. Interview me one question at a time, using my answers to decide what to ask next.
Explore how I currently do the work, what information and tools it needs, how I make decisions, and what I check before accepting the result. Ask for examples or past corrections when they would help clarify my standards.
If I’m unsure, offer a few concrete possibilities for me to react to. Don’t invent preferences or requirements on my behalf.
Once you understand the task, summarize the proposed process and any unresolved questions. Let me confirm or adjust it before drafting the skill.
Then create the skill instructions, separating reusable guidance from details that will change each time. Include a simple test I can run to see whether it works as intended.”
Try the finished skill on a real task and check whether it captured what you meant. If the result falls short, explain what needs to change and use that feedback to refine the instructions before trying again.
Happy experimenting! 🙌🏻
Actionable steps...shifting my current progression from prompt → agent → automation to something more like context → process → skill → automation, but only where warranted. Did I get that right?
Turning complex agent workflows into clear, actionable steps is an art form. Great read!