The third time you explain the same procedure to an agent, you are doing the agent's job. Skills fix that: a skill is a named, packaged procedure (the steps, rules, output format, and judgment calls) that an agent loads when a task calls for it, and a shared library makes one agent's hard-won lesson every agent's capability.
90% at 50x
is how Tibo Louis-Lucas, running always-on squads, describes agent output on well-defined procedures: 90% of human quality at 50 times the speed. The skill is what makes the procedure well-defined.
Source: Tibo Louis-Lucas on XiShort answer
Skills are procedures written once and invoked by name, instead of re-explained in every prompt. They load on demand (so agent context stays light), live in a shared library (so the whole squad inherits every lesson), and carry tags (so the library stays browsable as it grows). In MissionControlHQ, the skill library is squad-wide: write the escalation procedure after one incident, and every agent runs it forever after. The signal to write one: you are about to explain the same thing a third time.
Key takeaways
| Principle | What it means in practice |
|---|---|
| Repetition is the signal | Explained twice = write the skill before the third |
| On-demand beats always-loaded | Skills load per task; system prompts stay light |
| The library is squad-wide | One agent's lesson becomes every agent's capability |
| One edit updates everyone | Procedures change in one place, not nine prompts |
| Tags keep it browsable | A growing library needs grouping, not memory |
The lifecycle of a squad skill.
Notice the repetition
The same procedure explained twice is a skill waiting to be written.
Write it once, completely
Steps, rules, output format, edge cases, and the judgment calls.
Shelve it in the library
Named, tagged, visible to the whole squad, invoked when tasks call for it.
Improve it in place
Every lesson learned becomes an edit; every agent inherits it instantly.
The repetition tax
Every squad pays it at first. The support agent needs the escalation rules explained. Next week, the email agent needs the same rules, phrased slightly differently. The week after, a new task needs them again, and the version it gets has drifted: a threshold misremembered, an exception dropped. Now the squad has three almost-identical procedures producing three subtly different behaviors, and the human is the only synchronization mechanism.
The tax has two parts. The visible part is your time: re-explaining is unpaid prompt engineering, performed on demand, forever. The invisible part is the drift: procedures that live in scattered prompts diverge, and divergence in a squad reads as unreliability ("why did the email agent escalate this but the support agent didn't?"). Both parts are paid per-repetition, which is why the fix is to make the procedure a thing that exists once.
What a skill actually contains
A skill is not a prompt snippet; it is the complete answer to "how do we do this here." A good one contains:
- The trigger: when this skill applies, and when it deliberately does not.
- The steps: the actual procedure, in order, with the tools each step uses.
- The rules: thresholds, formats, brand voice, hard limits ("never promise a refund without a ticket").
- The judgment calls: the edge cases you would have answered by Slack message, written down instead.
- The output shape: what done looks like, so quality is checkable rather than vibes.
The judgment calls are the part most people skip and the part that matters most: a procedure without its edge cases is exactly as reliable as the agent's guess on the day the edge case arrives.
Why on-demand beats the giant system prompt
The naive alternative is to stuff every procedure into each agent's standing instructions. It fails predictably: the system prompt bloats until every task carries every procedure whether relevant or not, context gets crowded, and the truly load-bearing rules dilute in a sea of sometimes-relevant ones. It also multiplies maintenance: nine agents with inlined procedures means nine places to edit when one threshold changes.
Skills invert the shape. Each agent carries a light identity (who it is, what lanes it owns) plus access to the library; when a task calls for a procedure, the matching skill loads for that task and unloads after. Context stays small, procedures stay complete, and each skill exists in exactly one place. When the escalation threshold changes, one edit updates the entire squad's behavior from the next task onward: no hunting through prompts, no version skew.
The library effect: one lesson, nine agents
The compounding shows up when the library is shared. Squads without one learn in silos: the support agent painfully works out the escalation rules over a week of corrections, and none of that transfers; the email agent starts from zero on the same problem. A shared library changes the topology: the lesson gets written once, as a skill, and every agent (current and future) inherits it immediately. Onboarding a tenth agent stops meaning re-teaching nine agents' worth of accumulated procedure; the new agent gets the library on day one.
Tags are what keep this usable at scale. A dozen skills need no organization; forty do. Grouping by function (reporting, outreach, QA, research) keeps the library browsable for the humans curating it and scannable for agents choosing what to load. In MissionControlHQ, the skill library is a first-class part of the workspace: skills are named, tagged, editable from the dashboard, and available across the squad, so the "teach once" property holds by construction rather than by discipline.
Writing your first skill
Do not survey your operations looking for skill candidates; let repetition choose. The procedure you have now explained twice is the one to write, because the third explanation was already scheduled. Write it as if for a competent new hire who cannot ask follow-ups: trigger, steps, rules, edge cases, output shape. Then hand the next real task to the agent with the skill and read the output against what you would have produced: the gaps you find are missing edge cases, and they go back into the skill, not into a one-off correction that evaporates.
Expect the first draft to be 80% right and the next three tasks to surface the remaining 20%. That is the point: corrections that used to be repeated conversation become permanent edits.
A skill in practice: the weekly report
Take the most common first skill: the weekly report. Before, the founder explained it fresh most Fridays: pull the numbers from these three places, compare to last week, flag anything that moved more than 10%, keep it under a page, lead with the one thing that needs a decision. Some weeks the report came back in the wrong shape; some weeks the 10% rule got forgotten; every week cost the same five minutes of re-explaining.
As a skill, all of it is written once: the three sources (each an integration the agent queries directly), the comparison logic, the 10% flag threshold, the one-page format, the lead-with-the-decision rule, and the edge cases ("if a source is unreachable, say so explicitly rather than omitting the section"). The Friday lane invokes the skill on schedule. When the founder later wants margins added, that is one edit to the skill, and every future report has margins. The report stopped being a weekly conversation and became infrastructure.
This is the mechanism behind the 90%-at-50x observation: the quality ceiling of agent output on a procedure is set by how well-defined the procedure is, and a skill is the act of defining it.
Keeping the library healthy
Three habits keep a library from decaying. Route corrections into skills: when an agent gets a procedure wrong, fix the skill, not just the instance; a correction that lives only in one task's thread will be needed again. Retire aggressively: when a procedure dies, archive its skill; a library where a third of the skills are stale teaches agents (and humans) to distrust all of it. Keep one skill per procedure: two overlapping skills for the same job is prompt drift reborn with extra steps; merge them the day you notice.
What to turn into a skill first
| Scenario | Best pick | Why |
|---|---|---|
| Weekly/monthly report you keep re-specifying | First skill | Highest repetition, clearest output shape. |
| Brand voice and formatting rules | Skill, tagged 'writing' | Every content lane loads the same voice. |
| Escalation and refund rules | Skill, tagged 'support' | Divergence here reads as unreliability to customers. |
| QA checklist before anything ships | Skill, tagged 'qa' | Checkable output beats vibes. |
| A procedure used exactly once ever | Just a task instruction | Skills are for repetition; don't shelve one-offs. |
| Credentials a procedure needs | Secrets store, referenced by the skill | Skills describe; they never contain keys. |
How often does this procedure run?
- If recurring, or explained twice already→write the skill now
- If genuinely one-off→task instruction; no skill
Who needs it?
- If one agent, one lane→skill, tagged to the lane
- If multiple agents or lanes→skill in the shared library: the whole point
The procedure changed: where do you edit?
- If it's a skill→one edit; the squad updates from the next task
- If it's inlined in prompts→hunt every copy; this is why you migrate it
Frequently asked questions
The concept
What is an AI agent skill? A packaged, named procedure an agent loads when a task calls for it: the steps, the rules, the output format, and the judgment calls written down once. Instead of re-explaining how to write a weekly report in every prompt, the agent invokes the weekly-report skill.
How is a skill different from a system prompt? A system prompt is always loaded and quickly bloats as procedures accumulate. Skills load on demand: the agent carries a light identity plus a library it pulls from per task, so context stays small and each procedure stays complete.
Do skills really change output quality? Practitioners report large gains. Tibo Louis-Lucas, who runs squads on MissionControlHQ, describes agent output on well-defined procedures reaching 90% of human quality at 50x the speed; the skill is what makes the procedure well-defined.
The practice
What makes a good first skill to write? The procedure you have explained to an agent more than twice. Repetition is the signal: if the third explanation is coming, write it as a skill instead. Weekly reports, brand-voice rules, and QA checklists are typical first skills.
How does a skill library help a multi-agent squad? One agent's lesson becomes every agent's capability. A skill written after the support agent learns escalation rules is immediately available to the ops and email agents; tags keep the library browsable as it grows past a dozen skills.
How do skills stay current as procedures change? Edit the skill, and every future invocation uses the new version: one edit updates the whole squad. This beats prompt-repetition, where a changed procedure has to be hunted down in every agent's instructions separately.
Sources
- Tibo Louis-Lucas: on agent output quality
- MissionControlHQ: homepage, early access
- Related on this site: Why MissionControlHQ, Mission Control for OpenClaw
Last updated: July 2026. Product capabilities verified against the live dashboard as of July 2026.