Skills — teach it once, run forever

Skills are the most important thing in this manual. If you only learn one habit, learn this one.

What a skill actually is

A skill is a standard operating procedure for one specific task — saved, named, and reusable. Under the hood it's just plain English. An instruction file, written like a recipe: here's what this task is, here are the tools, here are the rules, here's how to do it. No code required, no syntax to learn. Skills load on demand. They are not in the agent's head all the time. When you ask for something, the agent looks at a menu of available skills — just the name and a one-line description of each — picks the matching one, and only then loads the full instructions. This is why skills are essentially free until used. It's the difference between memorizing every cookbook in the kitchen and grabbing one off the shelf when you need to cook. Always-loaded context is what you memorize. Skills are the cookbooks.

You don't have to make any skills yourself

This is the part most beginners miss: you never open a skill file. You don't write it. You don't format it. The agent does all of that. Your job is the conversation. The agent's job is the file.

How to make a skill — the canonical pattern

1. Have a real conversation with the agent about the task. Walk it through what you want done. Give feedback as it works. Tweak the output until you're happy with how it handles the job. 2. Once the process is dialed in, say it: "Make a skill for this." The agent creates the skill file for you. From now on, that task is one-word repeatable. If you already did something cool and want to save it after the fact: Make a skill for what you just did. Same result. The agent reaches back through the conversation, extracts the pattern, and saves it.

The exact phrase matters

The agent is supposed to recognize the intent from softer wording, but in practice it sometimes misses. The two reliable triggers are: "Make a skill for this." "Make a skill for what you just did." Say those words. If you describe a workflow without using the trigger phrase, the agent will sometimes save it as a skill and sometimes just execute the task and move on. The literal phrase is the difference.

The feedback loop — how skills get better

Skills are never done. They get better every time you run them. The pattern: 1. The skill runs. Output comes out. 2. You braindump everything you would have done differently — the line you'd cut, the angle you'd add, the tone tweak, the source it missed, the format you actually want. Voice message is fine. The longer and looser, the better. 3. End with: "Update the skill with my feedback." The agent rewrites the skill on the spot. Next time, it does the job the way you want. Three or four iterations and the skill is dialed for you. Skip this habit and your skills stay generic. Do it religiously and your agent becomes custom-built for your business — by you, one feedback loop at a time. Same rule on phrasing: say the literal words "update the skill with my feedback." The agent picks up on softer language most of the time, but the exact phrase never misses.

Examples of useful skills

A handful from the wild: lead-gen — what sources to pull from, how to verify emails, the voice to email in, how to send. youtube-pipeline — how to produce a video from idea to upload, end to end. pre-call-research — how to research a lead before a sales call, with a note that emails the prep brief to the team member running the call. deploy-website — how to deploy websites (handles the steps you'd otherwise google every time). weekly-receipts — drop a folder, the agent categorizes and updates the spending sheet. draft-launch — input the new product info, get a launch announcement in your voice.

summarize-and-extract-action-items — drop in a transcript, get the summary plus a checklist of who owes what. email-signature — always ends emails with the full signature block, not just the first name. Pattern: anything that's a specific recurring task is a skill. Anything that's general behavior across all tasks is always-loaded context (Chapter 6).

Skills beat piling more rules into always-loaded context

A common beginner instinct: "Just put more rules in always-loaded context." Don't. Always-loaded context costs tokens every session. Skills load only when called — free until used. Skills are by far the most important thing. You don't need memory if you're designing good skills. Rules are global. Skills are local. Use rules for things that apply to everything; skills for things that apply to specific recurring jobs.

The full chain: plan, execute, skill, schedule

Once you start chaining, you stop doing recurring work. The chain has four links:

1. Plan. Question the agent before it starts. Shape the approach together (Chapter 4).
2. Execute. Tell it to go. Review the output. Tighten it.
3. Skill. Once you're happy: "make a skill for this." Now the task is one-word repeatable.
4. Schedule. If it recurs on a clock — daily, weekly, on a specific day — say "set a cron job for this every [time]." The agent now does it on its own (Chapter 12). The first time around, the chain takes an hour. From then on, that piece of work runs itself.

Do it once, then skill it

The canonical rule: if you do something more than three times, make it a skill. Every Friday I drop a folder of receipts in here. Categorize them and update my spending sheet. After the agent does it once well, say: "Make a skill for this — call it weekly-receipts." Next Friday, you just say "run weekly-receipts" and drop in the folder. This is the third time I've asked you to draft a launch announcement. Make a skill for this so next time I just say "draft-launch" with the new product info.

Three uses is the cue. Past that and you're paying the conversation tax every time for no reason.

Don't bother with third-party skill libraries

Pre-made third-party skill libraries are not very useful. Every business has its own workflows and style. Generic skills built for everyone end up doing nothing well. Build your own — the agent will write them based on what you actually do.

Listing and auditing your skills

Once you have more than five or six, ask the agent every couple of weeks: List all the skills you currently have. For each, give the name, one-sentence description, and last time it was used. Flag any duplicates, anything unused for over 30 days, and anything that overlaps with another skill.

Then a follow-up: Based on what we do together and the things we talk about, what skills should we have that we don't?

The first prompt cleans up. The second surfaces automation opportunities you would never have noticed.

When a skill should be a script instead

Some work the agent is bad at — specifically, deterministic data fetching from a known source. The agent can do it, but it sometimes guesses field names or skips fields. A script is code that does one function the same way every time. Inside a skill, a script guarantees the agent gets the right data every run, instead of hoping the agent picks the right fields. More consistent, less nuanced. Rule of thumb: Deterministic data pulls → ask the agent to put a script in the skill. Judgment work (writing the report, picking the tone, deciding who to follow up with) → leave it to the agent. If you are not sure: ask the agent which one this task wants. It will tell you.

Realistic effort cost

Building a really good skill takes hours, not minutes. The first version is rough. The second is fine. The fourth is consistently better than what you'd produce by hand. After that, you stop touching it. The compounding is the point. Six months in, you have twenty skills doing twenty jobs you used to do by hand. That's the whole game. How to turn anything you've taught the agent into a one-word reusable skill it never forgets.