Tutorial: your first skill
Ten minutes, using a format your team already argues about.
We will build Meeting Notes, a skill that turns a messy set of notes into the write-up your team expects. Swap in your own repeated format as you go.
Pick the right candidate
Before opening the editor, pick something that is genuinely a procedure. Good candidates share three traits:
- It has a shape somebody could describe: sections, an order, a length.
- It comes up regularly, but not in every conversation.
- People currently get it subtly wrong, or ask how it should look.
If your idea is really "always talk like this", that is an agent, not a skill.
Write the description as a trigger
This is the field that decides whether the skill ever fires. Not:
Our format for meeting notes.
But:
Writing up notes, minutes or a summary from a meeting, call or workshop. Sets the section order, the decisions and actions format, and the tone. Load before drafting any meeting write-up.
Say the situations, include the words people actually type ("notes", "minutes", "call", "workshop", "write-up"), and end with an explicit "load before".
Two hundred characters is the limit, which is enough if you spend it on triggers rather than description.
Leave Auto-load on
You want this firing whenever somebody writes up a meeting, without anyone remembering the skill exists.
Write the instructions
Markdown. Adapt:
Write meeting notes in this exact shape.
## Sections, in order
1. **One-line summary.** What the meeting was for and whether it got there.
2. **Decisions.** Only things actually decided. One line each, in the past
tense: "Agreed to postpone the launch to March."
3. **Actions.** A table: what, who, by when. If the owner or the date was
not stated, write "unassigned" or "no date" rather than guessing.
4. **Open questions.** Things raised and not resolved.
5. **Context.** Everything else worth keeping, briefly. This goes last
because most readers stop after Actions.
## Rules
- Never invent an owner or a deadline. Unassigned actions are the single
most useful thing these notes surface.
- Do not include chat, scheduling talk or small talk.
- Keep the whole thing under one page. If it will not fit, the Context
section is what gets cut.
- Attribute a decision to a person only if the notes make it clear.
## When there is nothing to put in a section
Write the heading and "None." Do not silently drop it. A missing
Decisions section reads as though the notes are incomplete.The two rules that make this useful are "never invent an owner" and "write None rather than dropping the section". Both stop the tidy-looking output that hides a gap.
Test that it fires
Save, start a new chat, and describe the situation without mentioning the skill:
Here are my notes from this morning's planning call, can you write them up? [paste something rough]
If it fires, you will get your shape back. If it does not, go back and add the words you just used to the description.
Test that it is right
Now check the content, ideally with awkward input:
Notes with an unowned action. Does it say "unassigned", or quietly assign it to whoever spoke last?
Notes with no decisions. Does it write "None", or drop the section?
Notes with an argument in them. Does it land in Open questions, or get flattened into a decision that was not made?
Each miss is a line to add or sharpen.
Share it
Once it survives a week of your own use, share it with the people who write up meetings, or publish it to the marketplace. See Sharing your work.
Keeping it good
Check the usage count. The skills page shows how often each is used. Zero after a fortnight means the description is not matching what people type, not that nobody wants it.
Add rules when reality bites. The first time it produces something subtly wrong, add the line that prevents it. Skills improve by accretion of specifics.
Split when it sprawls. If Meeting Notes grows a section about board meetings and another about customer calls, that is three skills with three different triggers, and each will fire more accurately alone.
Next
- Writing a good skill in more depth.
- Agents, for when you want a persona rather than a procedure. An agent can carry skills, so these compose.
- Workflows, for a job that should run on its own.