Claude Code Skills for Client Work: When to Build One and What Goes Inside It
- A Claude Code skill is a folder with a SKILL.md description plus any supporting scripts or templates. Claude reads the description and decides on its own when to use it, so a task gets done the same correct way without you re-explaining it in a fresh session.
- Build a skill the second time you catch yourself giving Claude the same instructions for a second client, not the first. One-off tasks do not earn the setup cost; repeated ones do.
- Skills live in two places that matter for what you can bill: a personal skill under `~/.claude/skills` follows you across every client and is your own reusable process; a project skill inside a client's repo ships with the delivery and is usually the client's to keep.
What a Claude Code Skill Actually Is
A skill is a folder containing a SKILL.md file: a short frontmatter description of what the skill does and when it applies, followed by the actual instructions. Claude reads the descriptions of every skill available to it, and when a request matches one, it loads that skill's instructions automatically without you naming it. A skill can also bundle supporting files inside the same folder: a script Claude runs and reads the output of, a template it fills in, a reference doc it checks against.
That auto-selection is the whole point. A slash command has to be typed. A line in CLAUDE.md gets read every session whether it is relevant or not, which is exactly why [a bloated CLAUDE.md file for client projects](/blog/claude-md-file-for-client-projects) becomes a maintenance problem. A skill sits quietly until its description matches the task in front of Claude, then it fires. You get repeatability without paying an attention tax on every unrelated session.
The Second-Client Rule: When a Task Earns a Skill
Build a skill the second time you catch yourself re-explaining the same task to Claude for a second client, not the first. This is the Second-Client Rule, and it exists because writing a good SKILL.md takes real time: naming the trigger conditions clearly, writing the steps in a way that holds up without you in the room, deciding what supporting files it needs. A one-off task does not earn that time back. A task you will do again for a different client this month does.
The tell is in your own behavior, not in the task's complexity. If you notice yourself typing a near-identical paragraph of instructions into a second client's session that you already typed for the first, stop and turn that paragraph into a skill before you finish the second one. You will use it again before the month is out.
What Goes Inside a Client-Work Skill
Keep the SKILL.md description narrow and specific, since that description is the only thing Claude uses to decide whether the skill applies. A vague description gets skipped when it should fire, or fires on a request it should not touch. Name the exact trigger: the kind of file, the kind of request, the situation.
| Piece | What it is | Why it is in the skill |
|---|---|---|
| SKILL.md description | One or two sentences naming exactly when this applies | The only signal Claude uses to auto-select the skill |
| Instructions body | The actual step-by-step process, written for someone with no memory of past sessions | Makes the output repeatable regardless of who or what runs it |
| Templates | A blank version of the deliverable (a report shell, an email format) | Keeps the output shape consistent across clients |
| Scripts | A small executable Claude can run and read the output of | Handles anything more reliable done in code than described in prose |
| Reference docs | Client-specific facts, house style, or a checklist to verify against | Grounds the skill in real constraints instead of generic best practice |
What a skill folder typically holds, and what each piece does
Write the instructions body assuming Claude has zero memory of any earlier session, because it does. State the full process, not a shorthand that only makes sense if you already know the context. That discipline is what turns a private habit into something a skill can actually reproduce.
Personal Skills vs Project Skills: What You Can Bill For
A personal skill lives under your own `~/.claude/skills` folder and follows you into every client project you open, regardless of which repo you are in. This is your accumulated process: an onboarding checklist you run on every new engagement, a QA pass you do before every delivery, a way you always structure a client-facing update. It is your IP, built once and reused across every client, and it is a real part of what you are pricing when you [estimate a Claude Code build](/blog/estimate-a-claude-code-build) faster than a builder starting from a blank session every time.
A project skill lives inside a specific client's repository, usually under a `.claude/skills` folder that gets committed with the rest of the code. It ships with the delivery, and under most work-for-hire terms it belongs to the client the same way the rest of the codebase does, a distinction worth confirming against [who owns the code you build for a client](/blog/who-owns-the-code-you-build-for-a-client) before you decide what goes where. Put anything genuinely client-specific here: a skill that only makes sense against their data model, their brand voice, their support workflow.
Three Skills Worth Building From Day One
Three tasks show up on nearly every paid engagement and are worth turning into a personal skill before your next client, not after your fifth.
- An intake skill that turns a rough client brief into a structured scope draft in the same format every time, which pairs well with the boundary you set in a [one-page agreement before you build](/blog/one-page-agreement-before-you-build).
- A pre-delivery QA skill that checks a build against a fixed checklist before you call it done, a natural companion to the automatic checks covered in [Claude Code hooks for client work](/blog/claude-code-hooks-for-client-work) - hooks fire automatically on an event, a skill you or Claude invoke when a task matches, and the two work well stacked together.
- A change-summary skill that turns a raw diff into a plain-English client update in your own voice, so [the weekly client update that prevents fires](/blog/weekly-client-update-prevents-fires) takes minutes instead of becoming the thing you skip when you are busy.
Skills vs Subagents vs Hooks: Which One to Reach For
These three overlap in name but not in job. A skill is a reusable instruction package Claude selects when a request matches. A subagent, covered in [Claude Code subagents for client work](/blog/claude-code-subagents-for-client-work), is a scoped role that runs a bounded piece of a build in parallel with other work. A hook is a shell command that fires automatically on a specific event, like a file save, with no judgment involved at all.
| Tool | What triggers it | Best for |
|---|---|---|
| Skill | Claude matches a request to a description and loads it | A repeatable process: intake, QA checklists, client updates |
| Subagent | You dispatch it from a primary session for a bounded task | Parallel work on independent pieces of one build |
| Hook | A fixed event, like a file save or a session end | Automatic, no-judgment checks that must run every time |
Skills, subagents, and hooks side by side
Most client work ends up using all three at once: a hook that blocks a commit with failing tests, a subagent that writes those tests in parallel with the feature code, and a skill that turns the finished diff into a client-facing update. None of them replaces the others.
Common Mistakes When Building Client Skills
- Writing the SKILL.md description too broadly, so it fires on requests it should not touch, or too narrowly, so it never fires on the request it was built for.
- Putting client-specific data or credentials directly inside a personal skill you reuse across clients, instead of a project skill scoped to that one repo.
- Building a skill for a task you have only done once, before you know whether it will recur, which is exactly the setup cost the Second-Client Rule is meant to prevent.
- Letting a skill's instructions assume context from a specific past session instead of writing it to work cold, which quietly breaks the moment you use it with a different client.
Join the Profit Room
Inside the Claude Code Profit Room, builders share the actual skills they run across paying client work, including which ones earned their keep and which ones were setup time that never paid off. Join us at https://www.skool.com/claudecodeprofitroom/about and bring the task you keep re-explaining to Claude every session.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What is a Claude Code skill, in plain terms?
A folder containing a SKILL.md file with a short description of when it applies and the instructions for doing the task, plus any supporting scripts or templates the task needs. Claude reads the descriptions of available skills and loads the matching one automatically when a request fits, so a task gets done the same way every time without you re-typing instructions.
Do I need to build a skill for every task a client asks for?
No. Build one only once a task has recurred, under the Second-Client Rule: the first time you do something, just do it. The second time you catch yourself giving Claude near-identical instructions, turn it into a skill before you finish that second pass.
Where should I put a skill, personal or project?
Personal skills under `~/.claude/skills` are your own reusable process and follow you into every client project. Project skills inside a client's repo are usually client-specific and ship with the delivery as part of the codebase. Put genuinely reusable process in your personal folder and anything tied to one client's data or workflow inside their project.
What is the difference between a skill and a subagent?
A skill is a reusable instruction package Claude selects automatically when a request matches its description. A subagent is a scoped role you dispatch on purpose to run a bounded piece of a build, often in parallel with other work. Skills are about repeating a known task correctly; subagents are about splitting one engagement into parallel pieces.
Can a client keep using a skill after I hand off the project?
Yes, if it is a project skill committed inside their repository, it ships with the codebase the same way any other file does. A personal skill living in your own `~/.claude/skills` folder does not transfer automatically; if you want the client to keep using it, copy the relevant skill into their project before handoff.
Last reviewed August 26, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
