You've been re-explaining your format, your tone and your rules in every chat. A skill is where you write them once, so the assistant applies them itself. What goes in one, what doesn't, and how each assistant calls it.
Lesson 6 left you with a workflow: four steps, a format, run every week. You may have noticed that step 3, "write it in our format", means pasting the format every time. Ten lines of rules, every Friday, forever. This lesson removes that.
What a skill is
A skill is a saved instruction that tells the assistant how to do a particular kind of task your way, and when to apply it. You write it once. From then on, when the task comes up, the assistant follows it without being reminded.
The names differ by product. Claude calls them skills, and also has project instructions. ChatGPT has custom instructions, project instructions and custom GPTs. Gemini has Gems. Copilot has agents you can configure. Underneath, they're the same idea: text that gets put into the window automatically when it's relevant, so you don't have to paste it. Remember lesson 1: the model only sees the window. A skill is a way of making sure the right things are always in it.
The anatomy
A good skill is short. Most are under a page. The example at the bottom does more work than everything above it.
Name. Plain, so you find it later. "Weekly status report", "Reply to a supplier query", "Summarise a contract for the ops team".
When to use it. The trigger, in your own words. This matters most in assistants that pick the skill for you based on what you ask. "When I paste meeting notes and ask for a status" is a trigger. "For reports" is too vague to fire reliably.
Rules. Short, concrete, checkable. "Under 200 words" is a rule. "Keep it concise" is a wish. "Numbers only from my notes; if missing, write [?]" is a rule that also builds lesson 3's checking into the output: a bracketed question mark is easier to spot than a plausible guess.
One example. A short, real example of the output done right. Models imitate examples far better than they follow descriptions. One good example beats three paragraphs of adjectives. If the format is a table, show the table with two rows filled in.
What belongs in a skill, and what doesn't
Put in: the format, the tone rules, the structure, the things you always correct, the things you never want ("no intro, no sign-off", "never use the word 'leverage'"), and who the usual reader is.
Leave out: this week's content, anything that changes often, and long reference documents. Reference material belongs attached to the project, not written into the skill, so you can replace it without rewriting the instructions. And keep it short: a skill that tries to cover everything gets partly ignored, the same way early instructions fade in a crowded window.
Build it from your corrections
The fastest way to write a good skill is not to sit down and imagine rules. It's to look at what you corrected in the last three outputs. Every edit you made is a rule the assistant didn't know. "Too long" becomes a word limit. "Wrong order" becomes a fixed section list. "Made up a number" becomes the [?] rule. Three runs of a workflow usually produce enough corrections to write the whole skill.
Then test it: run the workflow with the skill in place and no pasted format. If the output needs the same correction again, the rule isn't concrete enough. Rewrite that one line. Don't add three more.
Where to save it
Claude: a skill (a short file the assistant loads when the trigger matches) or, simpler, the instructions field of a project. Projects are enough for most people.
ChatGPT: a project with instructions for one recurring task, or a custom GPT if you want to share it with colleagues.
Gemini: a Gem with the instructions pasted in.
Anything else: a text file you paste at the start of the chat. Not elegant, but every rule above still applies.
If your company runs one of these for the whole team, ask whoever administers it. Shared skills are how a team gets consistent output, and they're often sitting unused.
Skills for a team
Once one works for you, it's worth sharing. A shared "reply to a customer complaint" skill means every reply from the team follows the same rules, and the rules live in one place you can change. This is where the specialised-tool question from lesson 5 often resolves itself: a shared skill in the assistant you already pay for does what the "AI for customer service" product was selling, minus the subscription.
The habit
For each workflow: one skill, built from your corrections, under a page, with one example. Revisit it when you notice yourself making the same edit twice.
Try this today
Take the workflow from lesson 6. Open the last two outputs and list every edit you made. Turn each into one rule. Add one example of the output done right. Save it as a project instruction, skill or Gem. Run the workflow once with no pasted format and see what still needs correcting. Fix that one rule.
Check yourself
5 questions. Everything is in the lesson above. Get them all right and the lesson counts as done.
1. What problem does a skill solve?
A skill is saved instruction that enters the window automatically when relevant, so you write your rules once.
2. Which of these is a usable rule in a skill?
Rules need to be concrete enough to check. Adjectives are wishes.
3. What is usually the most effective single component of a skill?
Models imitate examples better than they follow descriptions.
4. Where should a 40-page reference document live?
Long content in the skill crowds the window and fades. Reference material belongs beside the skill, not inside it.
5. The best source for the rules in your first skill is:
Every correction you made is a rule the assistant didn't know. Three runs usually produce the whole skill.