I've watched a lot of people use Claude Code, and most of them start every session the same way. Who they are, what the project is, how the team likes things done, what went wrong last time. Then they close the window and explain it all again tomorrow. I kept seeing this with colleagues and friends, smart people getting a fraction of what the tool can do, and it's the part I most wanted to show them: you can write your job down once, as skills Claude reads every time, and stop explaining it from scratch. You'll still check the work, you just won't start from zero every time.
And it goes much further than saving a prompt. A skill can hold what you do, including the steps you take in a browser, a desktop app, or another tool. It can hold what you decided and why, and what you know: where things live, what broke last time, how the last migration went. Claude picks the right skill on its own when a task fits, skills can hand work to each other, and the whole set can live in one shared repository, so when you improve a skill, everyone on your team gets the better version.
By the end of this post you can:
- turn any task you repeat into a skill that Claude runs on request,
- give that skill a notes file, so a correction you make once gets read on every run,
- put a whole job into a skill: the actions, the decisions, and the knowledge behind them,
- borrow ideas from skills that already work in roles like data analyst, lifecycle marketer, support lead, or back-office admin,
- give Claude working rules it follows every session, and let it choose the right skill by itself,
- let one skill use another,
- and share your skills with your team from one repository, updates included.
You don't write code for any of it. You describe what you want, and Claude writes the files. I run my own work and a team's recurring operations this way, weekly reports and store releases among them, and what follows is the setup I'd hand a friend on day one.
This is the last of four posts on getting more out of Claude Code, and you can read it on its own. The others cover making Claude finish what it starts, giving it a team of agents, and setting up work that repeats every week.
Step 1: know what a skill is
A skill is a folder with one file in it, SKILL.md. Put it in ~/.claude/skills/<name>/ and it works in every project on your machine. Put it in .claude/skills/<name>/ inside a project, commit it with the project, and anyone who clones that project gets it too.
The file starts with a short header:
---
name: weekly-update
description: Writes my weekly team update from this week's notes and
tracker. Use when I ask for the weekly update, the Friday summary,
or "what did we ship this week".
---
Below the header go the instructions: what to read, what to do, what the output looks like. Claude Code lists your available skills with their descriptions, and when your request matches one, it loads that skill's instructions and follows them. You can also run it by name, /weekly-update. The instructions only load when the skill is used, so a skill costs almost nothing on the days you don't need it.
The description is how Claude decides when to use the skill, so write it in the words you'd actually type. And if a skill should only ever run when you ask by name, anything that sends or publishes for example, tell Claude: "Add disable-model-invocation: true to this skill's header." From then on it never starts that skill on its own.
Step 2: turn your next repeated task into a skill
Don't start by writing a skill. Start by doing the task once with Claude, the normal way, until the result is right. Then ask it to turn what you just did into a skill. (In every prompt in this post, replace the parts in angle brackets with your own details. For <skill-name>, use the name Claude gave your skill, and paste "we just finished" prompts into the same conversation where you did the work.)
Turn the task we just finished into a skill. Save it as
.claude/skills/<skill-name>/SKILL.md. Include what it's for, the inputs
it needs, the steps we actually took, and the format of the output.
If an input is missing when it runs, it should ask me instead of
guessing. It must never send, publish, or delete anything. Then show
me how to run it.
Pick the task you explain most often. For most people I've shown this to, that's a weekly update, a meeting summary in a fixed format, a report built from the same three sources, or a reply to the same kind of email.
Then test it where it counts: open a fresh session, run /<skill-name> on a new example, and check the output. Anthropic also publishes a skill-creator skill that does the same job and helps sharpen the description; ask Claude whether you have it.
Step 3: give the skill a notes file, so corrections stick
A skill that does the same thing the same way forever is a saved prompt. What makes it get better is a small notes file next to it, one it reads before every run and adds to when you correct it:
Update the <skill-name> skill. Add a file learnings.md next to its
SKILL.md, and make reading it the first step of every run. When I say
"save this" while using the skill, add one dated rule to that file:
what went wrong and what to do instead. If a new rule contradicts an
old one, replace the old line instead of adding a second. Show me the
file after each save.
This file only stays useful if you hold it to two rules. First, it only records things that would have cost you real time or money if they happened again. A report that came out fine goes nowhere; a report that used last month's numbers because the file name changed becomes a rule. My ads skill has more than fifty of these after a few months, and each one is a mistake it now checks for before it starts. Second, when a rule changes, the old line gets replaced. A notes file that holds two versions of the same rule is worse than no file, because the next run can't tell which one is current.
Test it the same way: correct the skill once, say "save this", then run it in a fresh session on an example that would have triggered the same mistake.
Step 4: put everything you do, decide, and know into skills
This is the step most people never take: writing down the decisions and knowledge behind a job, not only its steps. Do it, and a skill works like your team's memory. It can hold three kinds of things.
Actions: the steps of a job, in order, including the ones that don't happen in a chat window. A skill can use every tool your Claude Code session has. Connected tools (MCP connectors) let it read and write in Slack, Gmail, Notion, Linear, your analytics, your ad accounts. The Claude in Chrome extension lets it work in websites that have no connector, inside your own logged-in browser. Computer use lets it operate desktop apps. The terminal covers the rest. So a skill can describe a job end to end, not just the part you'd normally type. Each of these needs setting up once: Chrome needs the Claude extension, and computer use needs Claude's desktop app with it turned on, and isn't included on every plan. If you're not sure what you have, ask Claude: "Which tools does this job need, and which can you use in this session? Walk me through setting up anything that's missing."
Decisions: what you chose and why. Which option you picked, which one you rejected, the threshold you settled on. Without the why, the next person (or the next session) re-argues the same decision from scratch.
Knowledge: the facts the job depends on. Where things live, what the fields are called, which account owns what, what broke last time and how you fixed it.
The steps for a first app release in a store console, including the one non-obvious step that finally unlocks the publish button, are written down where Claude reads them in my setup, so the next release follows them instead of rediscovering them.
Now think about your own work. Say your team moves its customer list to a new CRM. Write the migration into a skill while you do it: every step, every field mapping you decided on, every surprise and how you got around it. The next migration, or the new hire who inherits it, starts from that record instead of from nothing. The same goes for the quarterly board pack, onboarding a new client, closing the month, or the vendor review nobody remembers how to run.
We just finished <the job>. Save all of it as a skill at
.claude/skills/<skill-name>/SKILL.md: the steps we took, in order; the
tool used for each step (browser, desktop app, connected tool, or
terminal); every decision we made and why; the facts we needed (where
things live, names, IDs); and what went wrong and how we fixed it.
Any step that sends, publishes, spends, or deletes must stop and ask
me first. Don't put passwords or keys in the skill; say where they
are kept instead.
Step 5: borrow ideas from skills that already work
Once you've captured one job, the next question is which others to capture. Here are skills I run myself or built for a team, stripped of anything specific to where they run, so you can see how different the jobs can be. Each one does the work, keeps what it learned, and stops at a clear point for a person's yes.
| Role | What it does | Remembers | Asks you first |
|---|---|---|---|
| Data analyst | Answers revenue, retention and funnel questions from the data warehouse and the analytics tool, and states its assumptions | Quirks of the data, what each business term maps to, sanity-check baselines | Any query that would change or delete data |
| Lifecycle marketer | Builds win-back and re-engagement campaigns by push and email | Who to exclude, and which setups failed before | Shows the exact recipient count and waits for your yes |
| Email writer | Writes campaign copy into a reusable template, with an inbox-style preview you can comment on line by line | Which design fits which kind of email, one place for any price or offer | Never sends; hands the send to the lifecycle skill |
| Support lead | Drafts replies from a catalogue of real past replies plus the customer's live account facts | The catalogue, with how often each reply was used | Never answers a billing question before checking the account |
| Customer researcher | Shortlists people worth interviewing cheaply, then builds a full profile only for those who reply | Who has already been contacted | Before writing anything into a shared database |
| Operations calendar | Works out which recurring task is due today and opens a ticket around each run | Nothing of its own: it points at the skill that owns each task | Each task keeps its own approval rules |
| Ads manager | Reads campaign data across ad platforms and proposes bid, budget and keyword changes | Goals, a log of every change, what was already tried | Any change that spends money |
| Social media marketer | Plans and publishes posts, then checks the post is actually live | Everything posted, every community reply | Paid spend and account changes |
| Back-office admin | Fills in a monthly form on a government website through Chrome | Which rule applies to which case, open questions | One step before the final submit |
| Chief of staff | Keeps the project tracker honest by checking what actually shipped | Which folder belongs to which project board | Closes an item only with the evidence attached |
The details inside these files are where most of the value sits. Each of these rules cost a real mistake to learn, and each one now gets read on every run:
- Recalculate the audience right before every send. An audience like "did X in the last 7 days" on a repeating schedule keeps mailing whoever matched weeks ago.
- Leave your own team out of user numbers. Internal accounts use the product heavily and pay nothing, and they quietly inflate every average.
- Treat "zero" as a question. A wrong field name returns an empty result that looks exactly like an empty inbox.
- Prepared, scheduled, published and measured are four different states. A calendar entry isn't a live post, so check the public link.
- Work out "the third Friday of the month" from the calendar every time. A fixed date drifts onto weekends.
- Write the long version first, then shorten it. A summary written short from the start comes out vague.
- Automate everything up to the irreversible click, and never the click itself.
Your role has rules like these too; most people just carry them in their head. This prompt helps you find where to start:
Help me find my first three skills. Ask me what I do in a normal week,
which tasks repeat, which ones I explain to people over and over, and
where a mistake costs the most. Then propose three skills: what each
one does, what it should remember, which tools it needs, and where it
must stop and ask me. Don't create anything until I pick one.
Step 6: let Claude pick the right skill for you
Once you have more than a few skills, you shouldn't have to remember their names. Claude Code already reads every skill's description and picks the one that fits your request. You make that choice reliable with a short instructions file, CLAUDE.md, the file Claude Code reads at the start of every session: ~/.claude/CLAUDE.md for everything you do, CLAUDE.md in a project folder for that project.
Most people treat CLAUDE.md as a notebook and keep adding to it until it's long, contradictory, and mostly ignored. The official guidance is to keep it under 200 lines. Treat it as a map instead: the handful of rules that apply every session, and a table that says which skill or file handles which kind of work. Then you describe the job, and Claude finds its way to the right skill by itself.
People often get this part wrong: if you write @some-file.md in CLAUDE.md, Claude Code loads that whole file at the start of every session. To keep a file out until it's needed, write its plain path and say when to read it.
One more thing the map is good for, beyond picking skills: facts. A fact I look up often once sat in a file nothing pointed to, so every form that needed it turned into a search. The fix was one page that says which file holds which kind of fact, with no values of its own, and a rule to read that page first.
Help me set up this project's CLAUDE.md. If one exists, read it; if
not, ask me which rules should apply every time I work here. Keep the
rules that must apply in every session in CLAUDE.md (under 200 lines),
and move reference material that only matters for certain tasks into
separate files, one topic each. At the bottom, add a table of "when
I'm doing X, use skill or file Y", covering my skills, using plain
file paths rather than @ imports. Show me the proposed split before
changing anything.
Your CLAUDE.md is also where your working rules go: the ones Claude should follow in every session, whatever the task. These are the rules from mine I'd give anyone, rewritten for any job. The first one exists because I once watched a test run report success while it had run zero tests.
Add these working rules to my CLAUDE.md, one short line each:
- Before saying something is done, show the proof: the file, the
count, the output, or a screenshot.
- For anything a person will see, look at it before calling it
finished.
- Before asking me for a fact (an address, an account, an ID), check
the facts file first.
- When I say "save this" or "never again", write the rule where the
next session will read it.
- Never send, publish, spend, or delete anything without my yes in
this session.
- Before using an outside service, check which account this folder
should use, and ask me if unsure.
- Keep passwords and keys out of files; note where they are kept.
- Match the effort to the job: small tasks directly with one check
at the end, bigger plans only for big work.
Step 7: let skills use each other
A skill's instructions can tell Claude to use another skill for part of the job, simply by naming it. Claude loads that skill, follows it, then carries on. The one exception is a skill you've set to run only when you ask by name: Claude can't start that one from inside another skill, so you run it yourself. So your skills don't have to be islands, and none of this needs code.
A weekly report skill can use your data skill to pull the numbers and your email skill to draft the message, instead of repeating how either one works. Say a research skill finds people worth interviewing: it can hand each one who replies to a separate skill that preps the background before the call.
The most useful version is splitting "when" from "how". A small calendar skill knows only what's due today, from a table you give it. For each due item, it hands over to the skill that knows how to do the work. The calendar only tracks timing, and how the work gets done stays with the other skill. When they disagree, the rule is written down: the calendar wins on timing, the working skill wins on method.
Never copy steps from one skill into another. Point at the other skill instead. Copies drift apart, and then nobody can tell which one is right.
Update the <skill-name> skill so that for <this part of the job>, it
uses the <other-skill> skill instead of doing that part itself. Name
the other skill in the instructions and don't copy its steps. Then
run it once on a small example and show me where the handover
happened.
And for recurring work, the calendar:
Create a skill at .claude/skills/calendar/SKILL.md. First ask me for
my timezone and a table of each recurring task, the days it's due, and
the skill that handles it. When I run /calendar, it lists what's due
today and asks which ones to run. For each one I pick, it uses that
skill and follows its own instructions and notes. It never sends,
publishes, spends, or deletes anything. It adds a line to
calendar-log.md on every run, even when nothing is due.
Step 8: keep it lean
Once you start, you'll add skills faster than you remove them. I did. When I finally measured, I had 251 skills and 84% of them had never been used once in the sessions I checked, while by my own count their descriptions added up to about 27,700 tokens (the chunks of text a model reads before it can answer you). Claude Code trims that list when it gets crowded, which can cut exactly the words it needs to pick the right skill. Run /context to see what actually loads.
You don't need a script to check yours. On a recent version of Claude Code, run /skill-doctor and it shows what each skill costs and how often it's been used. Treat "never used" as a candidate, not a verdict, then park the ones you don't need where they stop loading:
Find these skills in this project's .claude/skills/ folder and in my
personal ~/.claude/skills/ folder: <skill names>. If a name is in both,
ask which one I mean. Move each into a skills-archive/ folder next to
where it was, so it stops loading, without deleting anything. Keep a
list of what moved from where, and tell me how to move any back.
Once a month is enough.
Step 9: share it from one repository, for you or your whole team
Everything so far can live in one place and follow you, or your whole team, around.
For yourself: keep your skills in a git repository, so every machine you work on has the same set. Mine live in one folder that syncs to a private repository; improve a skill on one machine and the others get it too.
For your team: commit the skills to your team's project under .claude/skills/. Anyone who pulls the project gets them, and when someone improves a skill, everyone gets the better version with their next pull.
(Optional, once that works: skills you want in every project can be packaged as a plugin in a shared repository, which everyone installs once with /plugin. Teammates pick up new versions through /plugin; automatic updates for your own shared marketplace are off until you turn them on. In a larger organization, an admin can set this up centrally.)
Sharing turns this into memory that outlives any one person. The rules people forget, never contact the same customer twice, anything that spends money needs a yes, always use the approved template, live inside the skill, and Claude reads them on every run instead of whenever someone remembers. I've set this up for a team's support replies: approved templates, and every edit someone makes to a draft saved as a note for improving that template. The team's actions, decisions, and knowledge end up in files anyone can read and fix, not in one person's head. That's also how we once caught a rule that had quietly been doing the wrong thing.
A rule written in a skill is guidance, and Claude follows it well, but it isn't a lock. For the few rules that must never break, like spending money or messaging customers, also block the action itself with a permission rule or a hook in Claude Code, and test that it actually blocks.
Keep personal things out of anything you share: contact histories, account details, anything with a password or key in it. Our team sync refuses to push if it finds anything shaped like a key.
Prepare these skills for sharing with my team: <skill names>. Put
them, with their notes files, in the .claude/skills/ folder of our
shared project. Leave out personal state: contact histories, logs,
account details. Scan everything for anything that looks like a
password, token, or API key and stop if you find one. Then give me
step-by-step instructions for a teammate: how to get the project, open
Claude Code in it, try one skill, and pull the next improvement.
Your setup, ready this week
You don't need all nine steps on day one. Five short days get you from nothing to a shared skill that keeps its corrections:
You're done when a new session picks your skill by itself, reads its notes, and gives you something you can check without re-explaining a thing, and a teammate can do the same. After that, trim your CLAUDE.md with the Step 6 prompts, and run /skill-doctor once a month.
What surprised me most, after building a lot of these, is how little of it is clever automation. Most of the value is what you and your team do, decide, and know, written down somewhere a person can read it, and a tool that reads it every time.
The rest of this series: loop engineering, graph engineering, and loops and graphs.