Skip to main content
Writing a skill takes about ten minutes and pays back every time the job comes round again.

​
Creating one

1

Open the coworker's Files tab

Skills live with the coworker, alongside its instructions and personality.
2

Add a new skill and name it

Lowercase letters, numbers, dashes and underscores; start with a letter or number; up to 64 characters. competitive-analysis and monthly_report are both fine.
3

Write the description

One line saying when this skill applies. This is the most important field on the page — see below.
4

Write the procedure

The steps, in order, in plain language.
You can also ask for one in the chat with /skill, optionally naming it — useful right after your coworker has done something well, when the method is fresh.

​
The description does the work

Your coworker reads every skill’s name and description to decide which one a task calls for. If the description is vague, the skill sits unused.
Weak: “Research procedure” Better: “Use when asked to compare us against a named competitor — covers pricing, positioning and what to check for.”
Write it as when to use this, not what this is. The difference is whether your coworker recognises the moment.

​
Writing the procedure

Steps in order, one thing each. If two things can happen in either order, say so. Say what “done” looks like. A skill that ends without a finish line leaves your coworker guessing when to stop. Include the judgement calls. The steps are the easy part; what makes a skill valuable is the “if the number is more than 20% off, flag it rather than fixing it silently”. Name the output. “Ends with a one-page brief: recommendation first, then three supporting points, then sources.”
Write it as if for a new starter, not as a specification. If a capable colleague could follow it, so can your coworker.

​
A worked example

Name: competitive-analysis Description: Use when asked to compare us to a named competitor. Procedure:
  1. Find their current pricing page and read it properly. Note the date.
  2. Find their positioning — homepage headline, and how they describe themselves.
  3. Check for anything from the last three months: funding, launches, layoffs.
  4. Compare against ours on price, target customer, and the three features we win on.
  5. If you can’t find current pricing, say so rather than using an old figure.
  6. Finish with: one-line summary, a comparison table, and where we’re vulnerable.
A skill open in the editor, showing its when-to-use description and its numbered procedure

The same skill in the editor. The description is the field that decides whether it ever gets used.

Note step 5. That’s the line that stops a confident, wrong answer, and it’s the kind of thing only you know to include.

​
Good to know

Changes apply to the next task. A task already running keeps the skills it started with.
Start from something your coworker already did well. Ask it to write the skill from what it just did, then edit — faster than starting from a blank page, and it captures details you’d forget.

​
Common questions

As long as the procedure genuinely is. Half a page is common. If it’s running to several pages, it’s probably two skills.
Almost always the description. Rewrite it as “use when…” and be specific about the trigger. You can also call it directly with /skill-name to check the procedure itself works.
Yes, any time. Editing as you notice gaps is the normal way skills get good.
Yes. If you might want it back, your coworker also keeps skills it has retired — see Skills that improve themselves.

​
Next steps

Running a skill

Call it by name.

What skills are

Skills versus instructions versus memory.

Custom helpers

When a skill isn’t enough.

Skills that improve themselves

Let your coworker propose them.