Twenty years I have run operations, and every automation promise arrived wearing the same suit: RPA in 2016, macros in 2004, Zapier chains with forty-seven steps and a password that expired every March. Each one died the identical death: the person who knew how it worked left the building, and the procedure walked out with them.
I am suspicious of AI agents the way a foreman is suspicious of a new power tool, which is to say I assume it will fail exactly when the schedule is tightest. What got my attention about Muse was not the model but the paperwork, because somebody finally wrote the procedure down. About time.
Not in a slide deck but in a file: a markdown file, averaging seventy-eight lines, with a name like flight-booking and a job description attached. I counted sixty-four of them living on a working agent's machine: fifty-five shipped with the system, nine more the agent had written for itself after recurring real work, four thousand two hundred seventy-six lines of filed procedure in total. That is not a prompt. Far from it. It is a small library of operations manuals, and operations manuals are the only automation artifact that has ever survived contact with a real Tuesday.
Anatomy of a filed procedure
Each skill is two things stapled together. A small metadata card carries the name, the description, and the category, which is the routing signal the agent uses to decide when to reach for it, so the procedure gets loaded by relevance rather than by the user remembering to ask for it in the moment. On the grocery skill, the card says, in effect, load me first whenever food shopping comes up. It does not have to remember the procedure exists, because the card remembers for it the way a good dispatcher remembers which crew knows the tricky valve.
But the procedure itself is the interesting part, because the flight-booking skill opens with a decision tree, not a pep talk: establish the route, the dates, the cabin, and how flexible the traveler is. Ask only for the missing detail that would actually change the route or the price, then rank verified total price against total travel time. Never compare a one-way fare to a round-trip total, and never substitute a different flight for the one the traveler named. Book only the offer carrying that exact flight number.
Read that again, because that is seven failure modes pre-answered. A chatbot told to "book a flight" has to rediscover every one of those traps in real time, while spending your money. What the skill holds is what the operation learned the hard way, filed under a name so nobody has to learn it again, which is the entire promise of every operations manual ever written and also the reason most of them end up gathering dust on a shelf. Nineteen of the fifty-five system skills carry subdirectories of reference documents they pull in when the task gets specific, and availability flags on the procedures say which runtime they are allowed to run on. This is not configuration but a job description with a security clearance attached.
Read the playbook before the password
Now for the consequence nobody advertises: a skill file is readable whether or not you have connected the service it drives. You can read exactly what a connector is allowed to read and write before you do the OAuth dance, not after. That reverses the normal order of software, where you sign in first and discover the limits later. One researcher put the division of labor in a sentence worth keeping: the connector is how the agent reaches the tool; the skill is how it knows the procedure for using it.
A tutorial on Muse's connector skills calls the skill file the source of truth: not the marketing page, not the settings screen, the skill file, and the good ones include cost guides. Gmail's skill documents that a send costs one hundred one budget units and a read costs twenty, which is why the agent batches instead of looping. You learn the economics of the tool from its own documentation before you spend a dollar of attention on it, which is more than any permissions screen ever told you.
A prompt dies with the chat
The sharpest definition I found comes from a skill-sharing guide: a prompt works once and is gone, while a skill is saved, named, and reusable in any conversation, and the sharper half of the sentence is what follows, because a skill saves the instructions plus the corrections: what failed, what got changed, what to avoid next time.
That is the difference between tribal knowledge and a filed procedure, and anyone who has run a crew knows it is the entire difference, which is why crews with binders outperform crews with legends every single time. After a task goes well, you tell the agent to make it a skill, and it writes down the recipe it just followed, including the incident report, so next time you ask in one sentence. Second runs inherit the first run's bruises, which is more than I can say for most of the contractors I have hired.
A community catalog now lists two thousand three hundred eighty-four such skills for Muse, in an open format any assistant can read. Everything about the format fits on an index card, a name, a description, and markdown instructions, and yet there is, as of this writing, no official way to install one into Muse. You paste the file into chat and tell it to use the skill for that topic. It works. It is also fragile: no versioning, no updates, no revocation. For now the whole ecosystem runs on copy and paste, which is exactly how every operations manual started before somebody built the filing cabinet.
A binder doesn't do the surgery
Now the objection, stated at full strength, because it deserves it. A skill is a prompt with a filename, and everything it does can be done by pasting the same text into chat, because the execution underneath is identical: a stochastic model reading words and guessing the next step. Writing the procedure down did not make the model reliable. It documented your hope.
Half of that is true, and the true half matters. A hospital checklist works because the humans are trained, supervised, and audited on it, while an LLM following a markdown file is a stochastic process wearing a hi-vis vest. A two-hundred-eighty-five-line shopping procedure goes stale the day a retailer redesigns its checkout, and nobody has published a freshness metric for any community skill. A great playbook does not fix an unreliable agent: if the model misreads step four, the other two hundred eighty-four lines do not save you.
The other half is wrong, and here is why. A binder does not do the surgery, but hospitals with binders kill fewer people. The file does three things a pasted prompt cannot: it persists across sessions, because a prompt dies with the chat; it accumulates corrections, because the second run inherits the first run's incident log; and it loads by routing, not by memory, with the metadata card meaning the agent reaches for it unprompted when the topic comes up instead of waiting for you to remember it exists. That is not ceremony but the difference between hoping the procedure gets followed and having a system that files it.
Who owns the procedure owns the operation
Meta's coding agent now ships with twenty built-in skills, four of which exist for the single purpose of migrating users off competing tools, which tells you skills have become a moat. Research labs are building agents that write their own, turning failures into new entries automatically, which means the library gets smarter every time something breaks, assuming anyone bothers to read the new entries before they rot like the old ones did. By now the industry has figured out what every foreman already knows: the procedure is the asset. The model is interchangeable. The procedure isn't.
Which leaves you with the practical question every time your agent does something well: did you file it, or are you going to teach it again next month?
File the procedure: four moves
- After any agent task that worked, say "make this a skill." You just filed the procedure. Next time, one sentence. The second run inherits the first run's incident log.
- Before connecting a service, read its skill file. It lists exactly what the connector can read and write, so read the limits before the OAuth dance, not after. No surprises is a feature.
- Supervise a new community skill like a new hire. Paste it in, tell the agent when to use it, watch the first three runs, and remember that unreviewed procedures earn trust the same way people do: by surviving supervision.
- When a skill fails, edit the file. Do not re-prompt harder. Fix the procedure, not the pep talk. That is the whole operational insight, and it is the one most people miss.
What this article did not prove
Here is the honest accounting: the library I audited lives on one working agent's machine and uses an internal format: the metadata sits in a separate card file rather than in the markdown header the open standard uses, same mechanism in a different envelope, and it is not Meta's shipping Muse catalog. That community count of two thousand three hundred eighty-four skills is self-reported, and I could not independently verify the catalog's safety-review claim. I did not run a controlled trial of task success with and without the relevant skill loaded, so the reliability argument rests on mechanism and operator reports, not an experiment. Meta's public documentation of Muse skills is thin as of October 2026, and the paste-into-chat status may change if a native install flow ships.
Models are engines and skills are the manuals, so read the manual before you hand over the keys.