The Skills System
Skill files are specialized instruction sets that turn Claude into an expert at specific tasks in your workflow — UI design, database patterns, testing, error handling, and more.
CLAUDE.md gives Claude the context of your project. Skill files give Claude the expertise for specific types of tasks. Together, they are the system that produces consistently high-quality output across every kind of work you do.
What a Skill File Is
A skill file is a Markdown file that contains:
- The best approach for a specific type of task
- The patterns and conventions to follow
- The anti-patterns to avoid
- Reusable code snippets for common scenarios
- Checklists for quality assurance
When you tell Claude to use a skill — or when CLAUDE.md instructs Claude to check for a matching skill — Claude reads that file and applies everything in it to the current task.
The Excel analogy: Imagine you have saved report templates for every common report type — balance sheet template, cash flow template, aging report template. When someone asks for a cash flow report, you open the template and fill in the specific numbers. The template carries all the formatting, the column structure, the formulas, the style — you just provide the data.
A skill file is that template, but for coding tasks.
Global Skills vs Project Skills
Skills live in two locations:
Global skills (~/.claude/skills/): Available in every project on your machine. These contain your universal patterns — UI design principles that apply to all your apps, testing approaches you use everywhere, error handling patterns that are project-agnostic.
Project skills (.claude/skills/ in your project root): Available only in this project. These contain project-specific patterns that do not apply elsewhere.
In practice: Most skills start global and stay global. The patterns for writing a good RLS policy, a well-structured React component, or a proper edge function are the same regardless of the project.
The Skill Library (Built Into Your Global Profile)
As part of this training, you have access to a library of production-tested skill files built from real projects. These cover:
| Skill File | Use When |
|---|---|
ui-design.md | Building any UI component, page, or layout |
supabase-patterns.md | Any DB schema, RLS, query, migration, or edge function |
testing-patterns.md | Writing or reviewing any test |
error-handling.md | Adding error handling, toasts, boundaries |
data-modeling.md | Designing or modifying any DB schema |
api-patterns.md | Building any edge function or API endpoint |
performance.md | Optimizing queries, bundles, or render performance |
react-patterns.md | Complex hooks, context, or performance patterns |
cache-strategy.md | React Query staleTime, invalidation, optimistic updates |
state-management.md | Zustand store structure, selectors, persist |
new-project.md | Starting any new project from scratch |
deployment-runbook.md | Any production deploy or migration push |
Each of these represents hours of accumulated knowledge from real production systems. When Claude uses them, it applies patterns that have been tested and refined across multiple projects.
How Claude Uses Skills
When you start a task, Claude checks your CLAUDE.md for instructions on which skill to use. In the Udyogaseva project, the CLAUDE.md contains a skill protocol table:
When Claude starts a task, its first line is: "Using [skill] for this task."
This is your signal that Claude has read the relevant expertise file and will apply its patterns throughout the task. If you ever see Claude not announcing a skill for a significant task, you can prompt it: "Read the relevant skill file before starting."
What a Skill File Looks Like — A Real Example
Here is what a button-styles.md skill contains: the exact component structure, prop names, loading state pattern, and variant options your project uses. When Claude reads this skill file before writing a button, every button it produces follows these patterns. No variation. No guessing. No inconsistency across components.
How to Write Your Own Skill File
You do not need to write skill files from scratch at the start of training — the global library covers the common cases. But as you build more, you will develop patterns specific to your workflow. Here is how to document them:
When to create a new skill:
- You catch yourself explaining the same pattern to Claude across multiple sessions
- You write a pattern you are proud of and want to use in future projects
- You make a mistake and want to encode the lesson so it never happens again
How to structure it:
- Start with what the skill covers (one sentence)
- List the patterns to follow (the how)
- List the anti-patterns to avoid (the what NOT to do)
- Add any reusable code patterns relevant to this skill type
Keep skills focused. A skill that covers one topic well is better than a skill that covers five topics superficially. If a skill is growing too large, split it.
components.md. Write three things: how you structured the component, one pattern you liked, one thing you want to do differently. That is a skill file. It does not need to be long — it needs to be useful.The Compound Effect
Here is the most powerful aspect of the skills system: it compounds.
In your first project, you might have 3–5 skill files. In your second project, you add 3 more from patterns you learned. By your fifth project, you have 15–20 skill files covering nearly every situation you encounter. By the time you are running Batch 2 of this training, you have a library of refined skills that makes your Claude Code sessions dramatically more consistent than Batch 1.
Every time you write a skill:
- Every future session benefits from it automatically
- Every project that matches the trigger uses the better approach
- Every mistake you encode as an anti-pattern never happens again
- Future trainees who use your skill library inherit your accumulated knowledge
This is the system that a solo developer uses to punch far above their weight. Not because they work faster at any individual task — but because every task makes all future tasks better.
Using Skills in Practice — The Workflow
When you start a significant task:
CLAUDE.md for the matching skillIf Claude does not announce a skill on a significant task, say: "Before starting, check for a matching skill file."
After the task is complete:
- Did you use a better approach than what is in the skill? Update the skill.
- Did you encounter an anti-pattern the skill did not warn about? Add it.
- Did you invent a new pattern from scratch? Write a new skill.
The skill files are not read-only documents. They are living code that you and Claude maintain together.
Why Most Developers Do Not Do This
Writing skill files feels like extra work when you are in the middle of a task. The code is working, the feature is done, why document it now?
The answer is: because the next session starts fresh. Whatever you figured out today, Claude will not know tomorrow unless you write it down.
Developers who skip this documentation step stay at the same skill level indefinitely. Developers who maintain their skill library compound — each session is more capable than the last, each project is more consistent than the previous one.
The investment is 5–10 minutes per skill file. The return is every session for every project that follows.