08 · Turn a routine into a Skill
At a glance
| Solves | The same process every week, explained again every time |
| Needs | A workflow that already runs smoothly (this is the precondition) |
| Takes | 5 minutes to create; half an hour to test and adjust |
| Risk | Medium — the resulting Skill performs actions |
The situation
Every Friday you do the same thing: read this week's commits under the project directory, group them by module, count them, summarise the main changes, produce a weekly report.
The first time you spent twenty minutes tuning the prompt. The second time you dug through your chat history for it. The third time you could not find it and wrote it again.
When is it worth freezing
Three tests, and two out of three is enough:
- You have done it three times or more — a one-off is not worth freezing
- The prompt has stabilised — if you rewrite it every time, the process has not settled
- Someone else needs it too — you want to hand the capability to a colleague or to future you
Get it working, then freeze it
Order matters. Turning an unproven workflow into a Skill just freezes the uncertainty.
Run it manually three times, until your prompt stops changing. Then freeze it.
Creating: just describe it
Describe the capability, the trigger and the output in the conversation.
Create a custom Skill for capturing ideas.
Trigger: when I type something beginning with "note an idea".
It should:
1. Identify the type: product idea, content angle, or hypothesis to test
2. Structure it: title / type / body / related tags / timestamp
3. Save to D:/ideas/YYYY-MM.md, appending to the end of the file, never overwriting
4. Reply with a confirmation naming the file and the entry number
Constraints:
- Generate the title from the content, under 20 characters
- At most 3 tags, chosen from existing tags where possible, new ones only if
nothing fits
- Do not expand or comment on the content — keep my wording as it isOnce it finishes, open the Skills panel and the new Skill is in the Installed list.
Using it
Trigger it in any conversation with plain language:
Note an idea: a tool that turns meeting minutes into knowledge-base entries automatically.It typically does three things: identifies the entry as an idea, structures it, saves it to the right place and reports back.
Why it is written that way
The trigger is very specific. "When I type something beginning with 'note an idea'" is far more precise than "when I want to record an idea". The latter makes the model guess your intent, and when it guesses wrong you have no idea why it did not fire.
The actions are four steps, one line each. That is the Skill's execution flow. The clearer it is, the more stable the behaviour.
"Appending to the end of the file, never overwriting." Details like this must be stated. The default behaviour may be to overwrite, and you find out after losing a month of entries.
"Do not expand or comment." The thing capture tools must never do is editorialise. You want an archive, not a rewrite.
Confirmation output. "Which file, which entry number" lets you verify immediately that it really wrote.
Three design principles
One: your first Skill solves exactly one problem
The official wording: define a single capability first.
One Skill, one job. Wanting "capture + organise + weekly roll-up + push" means four Skills, or one Skill plus an automation — not one big Skill.
Two: state the trigger conditions
When it fires, where it writes, what it outputs. The clearer those three answers, the more reliable the Skill.
Three: start with the highest-frequency action
The more often you repeat something, the more it deserves freezing. A daily job pays back in a month; something you do twice a year is a waste of effort.
Acceptance checklist
- [ ] It appears under Skills → Installed
- [ ] Your designed trigger phrase actually fires it
- [ ] Saying the same thing without the trigger phrase does not fire it
- [ ] The output structure matches your spec
- [ ] It wrote to the right place, appending rather than overwriting
- [ ] Fire it three times in a row and the behaviour is consistent
- [ ] Give it a deliberate edge case (very long, empty, special characters) and see what it does
Test for false triggers
The most-skipped check. A Skill with an over-broad trigger will jump in and start doing work in conversations you never expected.
To test it: say something related that should not fire it — "I have an idea I want to talk through" — and the desired outcome is an ordinary conversation with no file written.
Iterating
Run it a few times, then say what is wrong:
Two problems with the "note an idea" Skill:
1. It always creates new tags instead of reusing existing ones. Change it to
read tags already in the file first, prefer those, and only create a new one
when nothing is close enough
2. Change the timestamp format to YYYY-MM-DD HH:mm
Everything else unchanged.Variations
Freeze a playbook from this book
Any playbook here can be frozen once it runs cleanly. Taking bulk rename:
Create a Skill called "receipt filing".
Trigger: when I say "file receipts" and give a directory.
Flow:
1. Read every file in the directory (PDF / image / Word)
2. Extract issue date, issuer, amount and category from the content
3. Rename as "date_category_party_amount"
4. Produce a comparison table for me to confirm
5. Only execute the rename after I confirm
6. Create index.md in the directory with a table of all file information
Steps 4 and 5 cannot be skipped — always produce the comparison table and wait
for an explicit "execute" before changing any file.That last paragraph freezes a safety habit into the Skill — you no longer have to remember to ask for a preview.
Sharing with a team
Attach the Skill to a project and every member gets it when starting a task there.
Personal and project libraries are separate
Personal Skill libraries do not cross between web and desktop; project-level Skills are managed centrally and are identical on both.
Anything for the team, or needed on both surfaces, belongs at project level.
Let it find an existing one
Ask before you build — it may already exist:
I want WorkBuddy to handle XXX. Find suitable Skills first and explain the
differences between them.Needs find-skills — see Ten free Skills.
Automatic accumulation with self-improvement
With self-improvement installed, it records experience, preferences and corrections and prefers them in similar later tasks.
Versus a hand-built Skill:
| Custom Skill | self-improvement | |
|---|---|---|
| Defined by | You, explicitly | Accumulated automatically |
| Behaviour | Deterministic, predictable | Implicit, less controllable |
| Suits | A fixed process | Soft habits: writing style, terminology |
They work together.
Security
A Skill you built is still executable code
Your own Skills also act as you.
When building Skills that delete, bulk write or send outward, write the safety constraints into the Skill itself — like the "always produce the comparison table first" line in the receipt example above.
A constraint written into the Skill is more reliable than one you have to remember.
Before sharing a Skill, check it contains no hard-coded paths, credentials or personal information.
FAQ
Where does a created Skill live?
In Skills → Installed. The enabled state is recorded in your global user configuration and syncs with your account across devices.
Can I export it to a colleague?
Skills support importing a local package via Upload, so a package can be handed over. For team sharing, project-level Skills are the better route.
Do Skills interfere with each other?
Yes. The more installed, the higher the chance of a wrong call. The official advice is to enable only what the current task needs.
Do Skills cost credits?
Not in themselves, but the model calls and tool executions they trigger do. The official note: complex tasks and complex Skills generally consume more credits.