Turning something you repeat into a reusable job
When you do something once, it comes out well, and you can feel you’ll do it again, you turn it into a job I can run on command — so the next run starts where the last one ended.
Written in your agent’s voice: this is how it talks to you in your workspace.
Say "make this a skill I can run"
The moment is right after a good piece of work, while it’s still in the conversation.
You did it once, it came out well, and you’ll do it again next week or for the next client.
Right after the good example is when the work is freshest — the steps are still on screen, and I can build from the real thing instead of a description of it.
Say so right then, before the example scrolls out of the chat:
"This came out great, and I’ll do it every week — make this a skill I can run."
The system calls that saved routine a skill: the steps are kept, you call it by name, and the same input gives back the same shape of output every time.
The morning brief, a call recap, an invoice draft — each was built once this way, and each now runs on a one-line ask.
You don’t have to know the steps yourself, or even whether the work is a skill at all — that judgment comes next, and it isn’t yours to make.
The System Builder builds the skill, and shows you the result
Building a skill is machinery, so I don’t do it from memory — I bring in a specialist.
The system carries a builder called the System Builder, and it owns the machinery: new domains, skills, rules, hooks, and connectors.
It has a skill for building skills, which is the one I summon the moment you say "make this a skill I can run."
You describe the what; the System Builder owns the how — the same split you use on every other piece of work.
First it writes a spec — a short note holding what the skill takes in, what it gives back, and what good looks like.
Then it builds the skill to that spec, tests it on a real example, and shows you the result.
You never write anything technical, and you never pick a technical option.
Describe it the way you’d explain it to a colleague:
"Make me a skill that takes a call transcript and gives back a one-page recap — decisions, action items with owners, follow-ups — formatted like the one we just did."
Then name it, so you’ll reach for it later:
"Call it the call-recap skill."
Before it writes a line, the builder checks what already exists, so you don’t end up with two skills doing the same job.
It narrates each step as it goes — what it’s checking, what it’s writing, where the skill lands — so nothing happens that you didn’t watch.
The builder may ask a question or two where your intent is genuinely unclear.
If a question feels like it’s asking how rather than what, say so, and it gets decided for you.
You judge the result, then it runs by name
The System Builder runs the new skill on a real example, and you judge that result the way you’d judge any first draft.
Read it, correct it plainly, the same as a first pass on anything else.
The spec is your checklist here: every gap between the result and what you described is a bug to close, not a quirk to live with.
Each correction goes back into the spec, so the next run already carries your fix.
Once it’s right, the skill is saved in the right domain, alongside that domain’s other skills, owned by whoever owns that domain.
From then on you call it by name, and you never touch the build again:
"Run the call-recap skill on this transcript."
Same input, same shape of output, every time — a one-line ask, not a rebuild.
What makes a good candidate
A good candidate has three things: a clear input, a clear output, and steps in between that stay the same.
The test is one sentence: did I do this once, and will I do it again?
A call recap passes — a transcript goes in, a one-page summary comes out, and the shape holds every time.
A one-line "thanks for the meeting" note fails — there’s no fixed shape to keep, and writing it fresh is faster than calling a skill.
A piece of judgment that changes with every situation, or a true one-off you’ll never repeat, stays a conversation — forcing it into a routine costs more than it saves.
Ask while the good example is still in front of you, not days later, so the builder works from the real thing instead of your memory of it.
The one thing to remember
If you did it once and you’ll do it again, say "make this a skill I can run" while the good example is fresh.
You describe the outcome and judge the result; the System Builder writes the spec, builds the skill, and keeps the steps — so the next run is a one-line ask.
Next: how your corrections make me better.