Managing bots is like managing people laid out the pyramid. This page goes to the bottom of it, where the actual work happens.
Where it sits
| ISO quality management system | Bot system |
|---|---|
| Level 1: Quality manual and quality policy | Principles |
| Level 2: Procedures | Playbooks |
| Level 3: Work instructions | Skills |
| Level 4: Records | Saved files and logs |
A procedure says how a process runs across the company. A work instruction says exactly how to do one task. Step one, step two, step three.
In the bot world, that's a skill: a file the bot loads when it needs to do one specific job.
What makes a good work instruction
Anyone who's written work instructions for a shop floor knows the rules:
- One task per instruction. "Set up the press," not "run the department."
- Steps in order. Numbered.
- Specific. Real names, real places, real values.
- Says what done looks like. How do you know it worked?
- Has a revision number. So everyone knows which version they're using.
Good skills follow the same rules.
Why skills beat one big instruction file
Early bots often had one giant instruction document. Everything in one place. That breaks down:
- It gets long, and long instructions get followed less carefully.
- Rules in different sections start to conflict.
- It's hard to update one task without touching others.
Skills split that up. The bot's core instructions stay short: who it is, its job, its principles. The details for each task live in their own skill, loaded when needed. In our review of 90 marketplace templates, nearly all followed this pattern: short core memory, detail in skills (good-practice.md).
Anatomy of a skill
A good skill has:
- A name and a one-line purpose. "an-office-save: how to save a finished record."
- When to use it. "Every time a record is finished."
- The steps. Numbered, specific.
- The check. How the bot confirms it worked.
- What not to do. The common mistake, named.
- A version. Revision number and date.
A real example
Our AN Creation office uses about forty skills. One handles saving records: where the file goes, the dated History copy, reading it back to confirm. One handles the project manager's job. One holds the shared principles. Each bot loads only the skills its role needs.
When we want to change how records are saved, we change one skill. Every bot that uses it picks up the change.
Skills point to sources
A skill shouldn't copy a price list or a spec into itself. It should point to the file that holds it. That keeps one master. See The current version at the point of use.
Where bots differ
A person reads a work instruction once and then mostly works from experience. A bot reads the skill every time, and follows it more literally. That's good, because it's consistent. It also means a vague step stays vague every single time. Write skills more precisely than you'd write them for an experienced operator.
What this means for you
- Find the tasks your bot does over and over.
- Write each one as a skill: steps, check, version.
- Keep the core instructions short.
- Update the skill, not the chat, when something changes.
If you've written work instructions, you already know how to write skills.