The Incuv8or AI Framework - step 4 of 6: Add employees only when they pass the test. Before this: build your COO. Next: hand out the work from your task manager.
I am lazy AF, and that's not a confession - it's the reason I build things the way I do. If I have to explain something twice, I'd rather spend twenty minutes making sure I never explain it again.
Which is how I ended up building employees inside Claude.
The way I set it up now, my COO sits at the top, my business is split into departments, and each department has a small number of AI employees. Every employee is a folder with an agent file - who it is, its job, its model, what it can touch - and an index of the skills it uses. The skills themselves live in one shared library, so a process is written down once and any employee that needs it can use it.
This post is about the skills. Get these right and every employee you build gets better at once. If you want the whole structure first, it's in How I Built an AI Team in Claude.
So what actually is a skill
You know that one prompt you wrote that genuinely works? The really good one that took you a few goes to get right, that now lives in your notes app, and you go and dig out every single time you need it?
That's a skill waiting to happen.
Because here's what happens otherwise. One day you can't be bothered to go and find it, so you wing it. And the output is worse. And you don't quite notice, because it's still fine.
A prompt is something you have to remember to paste. A skill is something Claude reaches for on its own. You describe what you need in your normal words, and it already knows your rules, your format and your preferences - because you told it once, properly, instead of half-telling it forty times.
There are three types of skill, and they're built differently
This is the bit that trips people up. "Skill" gets used for three quite different things, and if you build the third one the way you'd build the first one, it won't work. Strictly, the third one isn't a skill at all - it's the employee that uses your skills - but you build it with the same tools, so it's here too.
| What it is | When you'd build one | |
|---|---|---|
| 1. The repeat prompt | One prompt you use over and over, saved once so you never type it again | You've got a prompt that works and you keep digging it out |
| 2. The process | A series of prompts plus the context behind them - a whole way of doing something, start to finish | You do something the same way every time and it takes several steps |
| 3. The employee's agent file | A role. Who they are, what they know, what they can touch, and the index of skills they use | The work needs its own context, different permissions, a different model, or to run alongside your other employees |
1. The repeat prompt. The simplest one and the best place to start. It's a single job with a single output - a caption, a summary, a client update, a proposal outline. You're not teaching Claude a role, you're teaching it your version of one task.
2. The process. This one is a sequence. Onboarding a client, writing and shipping a blog post, closing off a build. There are steps, they happen in an order, some of them have a decision in the middle, and the context that sits behind them matters as much as the steps do. You're not saving a prompt here - you're saving a way of working.
3. The employee's agent file. This is a role, and it's handled differently to the other two because you're not describing a task, you're describing a person. It needs to know who it is, what it knows and how it works - the same three things you'd put in a job description and an induction - plus which model it runs on, what it's allowed to touch, and which skills from your library it uses.
Don't make every skill an employee. A job only earns its own employee if it needs its own context, different permissions, a different model, or to run at the same time as the others. Otherwise it's a skill, and an employee you already have holds it.
I use all three. My favourite is the third, because once an employee is set up and connected to my task manager, it does the work without me being anywhere near it.
Whichever one you're building, the first two steps are the same. The build prompt is where they split.
You'll get more out of this with your AI brain already set up.
A skill holds your rules. Your knowledge base holds your business. They work together - and a skill that has to keep asking who your clients are isn't saving you much. If you haven't built yours: The Co-Founder Setup.
Step 1 - Find the one worth building
Don't start by deciding what skill you want. Start by finding out what you're already doing over and over.
You are the worst judge of this, by the way. The tasks that eat your week don't feel like tasks - they feel like just how the work goes. So don't guess. Ask.
Look back through my recent chats with you.
I'm looking for the things I ask you to do over & over - the same kind of task,
the same kind of output, where I end up re-explaining my preferences every time.
Give me the top 5 as a table:
What the task is | How often I ask for it | Roughly how long it takes me each
time | What I have to re-explain every single time | Whether it's ONE prompt, a
PROCESS with several steps, or a whole ROLE someone could own.
Then tell me which ONE would save me the most time as a skill, & why.
Don't build anything yet.
Two columns are doing the work there.
What I have to re-explain every time is the one that matters most. That's not a preference. That's a rule you've been carrying around in your head, and it's exactly what belongs in a skill.
One prompt, a process, or a role tells you which of the three you're building, which decides which build prompt you use in Step 3.
When I ran this, mine came back with content scripting. Every single time I asked for a script I was re-explaining my tone, the phrases I hate, the length, the format. So that's the skill I built first, and it now holds all of it permanently.
Step 2 - The template
There's one template for all three types. The difference is which sections you keep.
Everything in brackets is yours to fill in. The arrows tell you which type needs that section - delete the ones that don't apply to you.
---
name: kebab-case-name
description: What this skill does AND when it should be used. Written in the
third person. This is the only part read before deciding whether to load the
skill, so name the actual trigger - the task, the type of document, the words
I'd naturally use when I want this.
---
# [Skill name]
## What this is for
[One short paragraph. The job this does, and who it's being done for.]
## Who you are <-- TYPE 3 ONLY
[The role. What they own, and just as importantly what they don't. One core
task, done well - not five jobs in a trench coat.]
## What you know <-- TYPE 3 ONLY
[Their expertise. The files they read before starting. What they go and check
in my knowledge base, my task manager or my calendar so they're never working
from memory.]
## Before you start
[What you need from me before you can do this properly. If any of it is
missing, ask ONE question and stop - don't guess, and don't produce something
and then ask afterwards.]
## How to do it
[TYPE 1 - the prompt itself, rewritten as instructions.]
[TYPES 2 & 3 - the steps in order, with the decision points marked.]
1. [step]
2. [step - if X then do this, if Y then do that]
3. [step]
## The rules
- [Non-negotiable]
- [Non-negotiable]
- Never [the thing that ruins it]
- Never [the specific phrase or habit you can't stand]
## When to come back to me <-- TYPES 2 & 3
[The decisions this skill does not get to make on its own. Anything involving
money, a client, or something that can't be undone.]
## Output exactly this
[The exact shape you want back. Headings, order, length. Be strict - vague
instructions here are why outputs come back inconsistent.]
## What good looks like
[A real example of a great output.]
## What bad looks like
[A real example of a bad one, and one line on WHY it's bad.]
Four things in this template are doing the heavy lifting, and they're the four things people get wrong.
The description is the trigger
This is the single most important line in the file, and almost everyone writes it lazily.
Claude reads the name and description of every skill you've got, all the time. It reads the rest of the file only once it's decided the skill is relevant. So the description isn't a summary for your benefit - it's the thing that decides whether your skill ever gets used at all.
Write it so it names the situation, not just the subject.
- ❌ "Helps with content." Never fires. Too vague to match anything.
- ✅ "Use when drafting or reviewing a short-form script, reel or caption - writing a new one from a topic, or tightening a draft that's already written."
That second one names the tasks and the words you'd actually use.
One skill, one job
The temptation is to build one giant skill that does everything. Don't. A skill that covers five jobs will get loaded for the wrong one, and then apply the wrong rules.
If your skill needs the word "and" more than twice to describe it, it's two skills. Employees are the opposite: one employee can hold several skills, as long as they belong to the same area of work.
The "never" list is the valuable part
Anyone can write down what they want. The rules that actually improve the output are the ones about what you don't want - the phrases you hate, the structures that don't sound like you, the thing it keeps doing that you keep correcting.
Every time you find yourself typing "no, not like that" - that's a line for the never list. Go and add it.
Good and bad examples beat instructions
One real example of a great output teaches more than five paragraphs describing one. Include a bad one too, with a line explaining why it's bad, because that's what stops the same mistake coming back.
Step 3 - Build it
Claude has a skill for building skills - the Skill Creator. Use it for all three types. It'll walk you through the structure rather than you inventing it.
What changes is what you tell it to ask you. Pick the one that matches what you found in Step 1.
Type 1 - building a repeat prompt
The straightforward one. You already have a prompt that works. You're turning it into something Claude reaches for on its own.
Use the Skill Creator skill to build me a skill for [THE TASK].
Here is the prompt I currently use for this: [PASTE YOUR PROMPT]
Follow the template below.
Before you write anything, interview me. Ask ONE question at a time until you
know:
- exactly what I want it to produce, & in what format
- what I always want it to do
- what I never want it to do
- what good looks like, & what bad looks like
Do not fill in gaps by guessing. If you don't know my preference, ask me for it.
Then give me the finished SKILL.md.
[PASTE THE TEMPLATE HERE - delete the TYPE 3 sections]
"Do not fill in gaps by guessing" is the line that makes this work. Left to its own devices Claude will write you a perfectly reasonable skill full of perfectly reasonable defaults, none of which are yours. The interview is the whole point.
Type 2 - building a process
Same idea, but you're capturing a sequence rather than a single output. The thing you have to get out of your own head here is the order, and the moments where you make a judgement call without noticing you're making one.
Use the Skill Creator skill to build me a skill for my [PROCESS NAME] process.
This isn't one prompt - it's the whole way I do this, start to finish.
Follow the template below.
Before you write anything, interview me. Ask ONE question at a time until you
know:
- every step in order, from what kicks it off to what "done" looks like
- what information you need from me at the start, & what you can go & find
yourself
- the decision points - the places where it depends, & what it depends ON
- what changes every time (the inputs) & what never changes (the rules)
- where you should stop & check with me rather than carrying on
- what good looks like, & what bad looks like
Walk me through my own process one step at a time & write down what I tell you.
Where I skip a step because it's obvious to me, catch it & ask.
Do not fill in gaps by guessing.
Then give me the finished SKILL.md.
[PASTE THE TEMPLATE HERE - delete the TYPE 3 sections, keep "When to come back
to me"]
The step everyone forgets is "where should you stop and check with me". A process skill that ploughs through all nine steps without pausing will confidently do the wrong thing eight times before you see it.
Type 3 - building an employee
This is the one that gets handled differently, because you're not describing a task. You're hiring. If you've built an AI COO, this is its job: it drafts the employee with you, and you test it before it takes any work.
A person joining your business needs three things before they're any use: a job description, an induction, and a way of working. An employee's agent file needs exactly the same three, plus its model, what it can touch and its skills index.
- Who they are. The role, the department it sits in, the work it owns - and what isn't theirs.
- What they know. Their expertise, and where they go to get current. This is the bit people miss. An employee that works from memory makes things up. An employee that opens your knowledge base, your task manager and your calendar before it starts is working from facts.
- How they work. The process they run every single time, in order, the same way, whether you're watching or not.
Use the Skill Creator skill to build me an AI employee.
The role is: [JOB TITLE - e.g. my content editor / my client onboarding
manager / my inbox triage assistant]
This is a ROLE, not a task. Build it as a job description, an induction & a
way of working. First check it needs to be its own employee: its own
context, different permissions, a different model, or running at the same
time as my other employees. If it doesn't, tell me which existing employee
should hold it as a skill instead.
Follow the template below.
Before you write anything, interview me. Ask ONE question at a time until you
know:
WHO THEY ARE
- the work this employee owns, in a single sentence, & which department it
sits in
- which model it runs on, & what it's allowed to touch
- what is explicitly NOT theirs, so they stay in their lane
- who they're doing it for, & what that person cares about
WHAT THEY KNOW
- what they need to be an expert in to do this job well
- which of my files, docs or knowledge base they should read before they start
- what they should go & check every time they run - my task manager, my
calendar, my client notes - so they're never working from memory
- what they should research or look up themselves rather than asking me
HOW THEY WORK
- which skills from my skills library they use (the index)
- the exact steps they run, in order, every single time
- what triggers them to start, & what "finished" looks like
- the decisions they make on their own, & the ones they must bring to me
- my standard - what good looks like, & what bad looks like
Do not fill in gaps by guessing. If you don't know, ask me.
Then give me the finished agent file, & tell me which of my files & skills
it needs access to in order to do the job.
[PASTE THE FULL TEMPLATE HERE]
That last line matters. An employee is only as good as what it can see, so when Claude tells you which files it needs, put them where it can reach them.
An employee does nothing until you give it work. You can hand it tasks in a chat, or through your task manager, and once it does the job well when you hand it over, a routine can wake it up on a schedule - that's the next post.
Step 4 - Upload it
Once you've got your SKILL.md, get it into Claude:
- Go to Customise
- Then Skills
- Then Add Skill
- Upload it
That's it. It's now available in every chat, and you never have to paste that prompt again.
Step 5 - Test it, tweak it, then let it rewrite itself
This is the step that actually makes the skill good, and it's the one everybody skips.
The version you just uploaded is a draft. It's built on what you said you wanted, which is never quite the same as what you want when you see it in front of you.
So:
1. Open a brand new chat - and make sure it's connected to your AI brain, or the output will be generic and you'll blame the skill for it.
2. Ask for the real thing. "Create [whatever it is] using my [skill name] skill." Give it a genuine piece of work, not a test case.
3. Read what comes back, and fix it in that chat. Not in the skill file - in the conversation. "Shorter." "Don't open like that." "Put the numbers at the top." Keep going until the output is genuinely where you want it.
4. Then get Claude to rewrite the skill from the conversation. This is the prompt:
Please review this whole chat.
I've been correcting your output until it's where I actually want it. Now update
my [SKILL NAME] skill so it produces THIS by default, without me having to
correct it every time.
Specifically:
- Turn every correction I made into an explicit rule
- Anything I asked for twice goes into the instructions
- Anything I rejected goes on the never list
- Update the output format so it matches exactly what we've landed on
If any of my corrections contradict something already in the skill, tell me
rather than quietly overwriting it.
Then give me the updated SKILL.md.
5. Re-upload it. Same as Step 4 - Customise, Skills, Add Skill. Replace the old version so you're not running two.
Then do it again next time you use it.
This loop is the whole method. Every rule in my scripting skill came out of an actual correction in a real chat - not from me sitting there in advance trying to imagine what I might one day want. You cannot write a good skill from theory. You can only write a good one from corrections.
Step 6 - The other test: does it fire on its own?
There's a second thing worth checking, and it's a different failure entirely.
Open a fresh chat and ask for the thing in your own normal words, without mentioning the skill at all. Exactly how you'd ask on a Tuesday when you're busy and not thinking about it.
- If it fires - your description is doing its job.
- If it doesn't - the problem is your description, not your skill. Go back to the
descriptionline (see Step 2) and rewrite it so it names the situation the way you'd actually describe it, not the way you'd file it. Then re-upload.
Nearly every "my skill doesn't work" is really "my skill never loaded."
So when is it finished?
It isn't finished when you upload it. It's finished when you stop correcting the output.
Mine has been round the Step 5 loop several times, and it got better every round - because every round came from something that annoyed me in a real piece of work.
Start with one
Run the first prompt today. See what comes back.
You'll probably be surprised at what's on the list - the tasks that are quietly eating your week are rarely the ones you'd have picked.
Then build that one, upload it, and use it for a fortnight before you build another. One skill you actually use beats six sitting in your settings.
And if it turns out the thing you found is a whole role rather than a task, check it against the four questions first: its own context, different permissions, a different model, or running in parallel. If it passes, build the employee. That's where this gets fun.
If you haven't got your AI brain set up yet, that's the foundation for all of this: start here.
And if what you want is the whole system - the pricing, the positioning, and the tech and AI that lets you run a business on three days a week - that's what I teach.
this is the free stuff — imagine what we'd build together
Ready to make your business AI-enabled?
Consulting and one-to-one coaching for founders and freelancers who want AI actually working inside their business — not just talked about.
More guides
Build With AI
I gave myself one weekend to completely reorganise my business (& life) with Claude
Build With AI
The most important thing about AI employees isn't the skill, it's the system underneath
Build With AI
The number one missing piece to AI employees that actually work (and it isn't another skill)