Lesson 2: Packaging Your Expertise
Course: Monetizing AI Skills
Estimated time: 25 minutes
Difficulty: Advanced Builder
You know how to do something well. The problem is that what's in your head doesn't translate automatically into something an agent can follow reliably. Expert knowledge is full of implicit context, judgment calls, and "just know when" decisions that feel obvious to you and are completely opaque to anyone else.
Packaging expertise is the process of making that implicit knowledge explicit. It's harder than it sounds. Experts are notoriously bad at explaining what they do, not because they can't communicate, but because they've internalized so much that they can't see it anymore.
This lesson gives you the structure to make your expertise teachable to an agent.
The Anatomy of a Great Skill
A skill package has six components. Not all are required for every skill, but knowing all of them helps you design a complete one.
SKILL.md - The front door. This is what loads when an agent discovers your skill. It needs to answer four questions immediately: What does this skill do? When should I use it? What do I need to provide? What will I get back?
Keep SKILL.md short. An agent reading it should understand the skill's purpose and interface in under a minute. Save the detailed instructions for the instructions file.
Example SKILL.md opening:
# Cold Email Writer
**Purpose:** Writes personalized cold outreach emails that get responses.
**Use when:** You have a prospect's name, company, and a specific reason to reach out.
**Inputs:**
- Prospect name and company
- Your product or service (1-2 sentences)
- The specific reason you're reaching out (pain point, trigger event, or mutual connection)
**Output:** A cold email under 150 words with a clear subject line and a single call to action.
**Note:** This skill works best when you've done 5+ minutes of prospect research. Generic inputs produce generic emails.
Instructions.md - The expertise itself. This is where you write out exactly how to do the thing, in enough detail that an agent without your background can do it at 80% of your quality level.
The structure that works: start with the goal state (what does good look like?), walk through the steps in order, include decision criteria at each step ("if X, do Y; if not, do Z"), specify quality checks before the final output.
Tools directory - Any external functions the skill needs. If your skill requires calling an API, fetching web content, or reading files, define the tools here. Use the same format as the agent tool definitions from Course 3. Each tool should have a clear name, description, and input schema.
Resources directory - Reference material. Templates, examples, checklists, style guides. Anything the agent can use while executing the skill. These don't execute code - they're readable context.
Examples directory - Input/output pairs. At least 3 examples per skill. These calibrate quality better than instructions alone. "Here's what a good output looks like" is often more useful than "here's how to produce a good output."
tests/ - A set of test inputs with expected outputs or quality criteria. Not required for a first release, but essential for maintaining a skill over time. If you update the instructions, run the tests to verify you didn't break anything.
Writing Instructions That Agents Can Follow
This is the hardest part of packaging expertise. Most first attempts at instructions are too vague, too high-level, or too full of "use your judgment" placeholders.
The test for an instruction: could a junior person with no context follow this step and produce acceptable output? If yes, the instruction is specific enough. If no, make it more specific.
Three failure modes to avoid:
Too vague: "Write an engaging email." - What makes it engaging? What's the structure? What's the length? What tone? Engaging to a Fortune 500 CMO is different from engaging to a startup founder. None of this is specified.
Expert shorthand: "Apply the AIDA framework." - An agent trained on internet text probably knows what AIDA means. But you'd write better instructions by spelling out: "Start with something that immediately captures attention (1-2 sentences). Then create desire by connecting your product's benefit to their specific situation. End with one clear action they should take."
Too many options: "Depending on the context, you might want to try X, or possibly Y, or in some cases Z." - Options that require judgment to choose are instructions the agent can't reliably follow. Make the choice for them, or give explicit criteria for choosing.
The structure that works:
## Instructions
### Step 1: Research the Prospect (5 minutes of reading)
Before writing, gather:
- Their job title and tenure at the company (LinkedIn)
- A recent company news item (funding, product launch, expansion)
- One sign that your product would address something they care about
This is non-optional. If you don't have these three things, ask the user to provide them before proceeding.
### Step 2: Write the Subject Line
The subject line must be:
- Under 7 words
- Specific to them (include their company name or the news item)
- A question or a specific claim - not vague ("Idea for Stripe" not "A quick thought")
Write 3 options and select the strongest one.
### Step 3: Write the Opening Line
The first sentence is the most important. It must:
- Reference something specific and real about them or their company
- Not be a compliment ("I loved your recent tweet" is generic - everyone says this)
- Sound like something a real person would write, not a template
Good: "Saw that Stripe just expanded into 15 new markets - congrats."
Bad: "I've been following your company's impressive growth."
### Step 4: Write the Value Statement (1-2 sentences)
Connect what you noticed in Step 3 to the specific pain your product solves.
Pattern: "[Thing you noticed] usually means [specific challenge]. We help companies like yours [specific outcome]."
### Step 5: The Call to Action
One action only. Options in order of conversion rate:
1. Ask for a 15-minute call with a specific suggested time slot
2. Ask a yes/no qualifying question
3. Ask if they're the right person to talk to
Do not: ask them to "learn more," "check out our website," or "let me know if you're interested." These are non-committal and get ignored.
### Quality Check Before Sending
- Is the email under 150 words?
- Does it contain the prospect's name and company?
- Is there exactly one call to action?
- Does it read like it was written for this specific person, not for a template?
If any answer is no, revise before outputting.
That's what actionable instructions look like. Every step is specific. Every decision criterion is explicit. The quality check at the end catches the most common failures before they reach the user.
The Examples That Make or Break a Skill
Instructions tell an agent what to do. Examples show it what good looks like. Both are necessary.
For most skills, 3-5 input/output example pairs is the minimum. Each example should illustrate a different variation: a different industry, a different tone, a different level of input quality.
Structure your examples as real scenarios:
## Example 1: SaaS to E-commerce Brand
**Input:**
- Prospect: Sarah Chen, VP of Marketing, Shopify store (fashion brand, 200 employees)
- Your product: A customer segmentation tool that personalizes email campaigns
- Reason to reach out: Their recent funding announcement ($15M Series B)
**Output:**
Subject: Congrats on the Series B - quick question
Hi Sarah,
Just saw the Series B news - exciting time for the team. Brands at that growth stage usually hit a wall with personalization: the volume grows faster than the marketing team can manage.
We help e-commerce brands segment their customer base automatically and run personalized email sequences without manual work. Our customers see an average 23% lift in repeat purchase rate.
Would you be open to a 15-minute call next Tuesday or Wednesday to see if it's relevant?
[Name]
---
Why this works:
- Subject is specific to their news
- Opening acknowledges the milestone, pivots to a real challenge it creates
- Value statement is specific (23% lift, repeat purchase rate) not vague ("drives growth")
- CTA is specific (day of week, duration)
The "why this works" section after each example is optional but useful. It tells the agent (and the user reading the skill) what principles the example is demonstrating. It makes examples teachable, not just illustrative.
Testing Your Skill Across Platforms
Before you sell a skill, test it. A skill that works on one agent runtime but breaks on another isn't ready for distribution.
The things that vary across platforms:
- How SKILL.md is loaded and referenced
- Whether tools are called in the format you defined
- How the platform handles multi-step instructions (does it follow them all, or stop after the first completion signal?)
- How errors from tools are surfaced (some platforms catch exceptions, others bubble them up)
The minimum test suite: run your skill on 3 different inputs with 3 different agents or platforms. At minimum: Claude with direct API access, and one hosted platform (OpenClaw or another runtime).
For each test, verify:
- Does the agent read all of SKILL.md before starting?
- Does the agent follow the instruction steps in order?
- Does the agent use the tools when instructed?
- Does the quality check step catch obvious problems?
- Does the output match the expected format?
Document any platform-specific quirks in your SKILL.md under a "Platform Notes" section. Users will appreciate knowing that the skill behaves slightly differently on Platform X and what to do about it.
Version Control and Maintenance
A skill you publish is a commitment to the people using it. When the underlying model updates, when an API you depend on changes, when you learn something that improves the instructions, you need to update the skill.
Use version numbers in your SKILL.md:
Version: 1.2.0
Last updated: 2026-02
Changelog: Updated examples with 2026 formatting; fixed issue with tool timeout handling
Semantic versioning (major.minor.patch) works here: major version bumps for breaking changes in inputs or outputs, minor for new capabilities, patch for fixes and improvements.
Keep old versions available (as separate files or tags in your git repo) so users who've integrated a specific version don't break when you update.
Exercise: Package One Workflow as an Agent Skill
Take the workflow you identified in Lesson 1 and package it.
Day 1: Write the instructions.
Open a new markdown file. Work through your workflow step by step. For every step, ask: would someone who's never done this before know exactly what to do here? If not, add specificity until they would. Don't stop until every step has that level of clarity.
Aim for 400-800 words of instructions. Too short means you haven't captured the expertise. Too long means you're padding.
Day 2: Write the SKILL.md.
Write your front door file. Keep it to 200-300 words. Test it by showing it to someone who doesn't know what your skill does and seeing if they can explain it back to you.
Day 3: Write three examples.
Take three real inputs you've worked with (anonymized if necessary). Write the output your skill should produce for each. Add a "why this works" note to each.
Day 4: Test it.
Create a folder with your SKILL.md, instructions, and examples. Tell an agent: "Read the SKILL.md and instructions in this folder, then process this input: [use one of your examples]." Compare the output to your expected output. Note the gaps.
Day 5: Refine based on what you found.
Update the instructions to address the gaps you found in testing. Run the test again. The output should be noticeably better.
At the end of this week, you have a publishable skill. Not a perfect one - there's no such thing. But one that's ready for users to test.
Key Takeaway
Expertise in your head doesn't equal a skill. A skill is expertise written out with enough specificity that an agent can follow it and produce output you'd be proud of. The gap between those two things is the packaging work. It takes longer than you expect and is worth more than you think.
What's Next
You have a packaged skill. Lesson 3 covers getting it in front of people: where to publish, how to use free skills as marketing, and how to set up discovery so the right buyers find you.