How to Build Claude Skills: Teach AI Your Way of Working
- stephen03058
- Dec 9, 2025
- 5 min read
Every time I start a new conversation with Claude, I find myself explaining the same things: how I like reports structured, what tone works for our clients, which questions to ask before drafting a proposal. It's like onboarding a new team member from scratch every single conversation.
Sound familiar?
This is the problem Claude Skills solve. Instead of re-explaining your preferences and context every time, you can create a simple document that Claude reads automatically. Your company knowledge, your preferred formats, your communication style—captured once, applied consistently.
What Actually Is a Skill?
Think of a skill as a briefing document for Claude. It contains instructions, context, and examples that shape how Claude responds to certain types of requests.
When you add a skill to a Claude Project, Claude checks whether your question matches that skill's purpose. If it does, Claude follows your documented approach instead of making generic assumptions.
The core of every skill is a single file called SKILL.md. It has two parts:
A header with a name and description (tells Claude when to use this skill)
Instructions explaining what you want Claude to do differently
That's it. No coding required. You're writing instructions in plain English.
Why Would You Want This?
Three situations where skills genuinely help:
Consistent communication. If your business has a particular voice—whether that's formal and precise or conversational and direct—a skill ensures Claude matches it every time. No more editing AI-generated content to sound like your organisation.
Repeatable processes. Meeting summaries, client proposals, status updates. If you follow the same structure repeatedly, a skill captures that structure once. Next time, Claude already knows the format you want.
Institutional knowledge. Claude doesn't know your client history, your service offerings, or your internal terminology. A skill fills those gaps so responses actually fit your context.
Example 1: A Client Communication Style Skill
Let's say your business has a particular way of communicating with clients. You're professional but not stiff, you use plain language, and you always include specific next steps. Here's what that skill might look like:
---
name: client-communications
description: Use when drafting emails, proposals, or any written communication to clients. Ensures consistent tone and format across all client-facing content.
---
# Client Communication Guidelines
## Our Voice
Write like a knowledgeable colleague, not a corporation. Specifically:
- Use "we" and "you", not "the company" or "the client"
- Plain English only—if a simpler word exists, use it
- Be direct about what we can and can't do
- Always include a clear next step
## What to Avoid
- Jargon: "leverage", "synergy", "circle back", "touch base"
- Vague promises: "soon", "as quickly as possible", "in due course"
- Passive voice: "it was decided" should be "we decided"
- Filler phrases: "I just wanted to", "I hope this email finds you well"
## Email Structure
1. **Opening**: State the purpose in the first sentence
2. **Body**: Key information in 2-3 short paragraphs max
3. **Next step**: Specific action with a date ("I'll send the draft by Thursday" not "I'll be in touch")
4. **Sign-off**: Keep it simple—"Thanks" or "Speak soon" is fine
## Proposal Structure
1. **What you're trying to achieve** (their words, not ours)
2. **What we'll do** (specific deliverables)
3. **What it costs** (no hiding fees)
4. **What happens next** (timeline and first step)
## Examples
Instead of: "Please do not hesitate to reach out should you have any questions."
Write: "Let me know if you have questions."
Instead of: "We would like to take this opportunity to thank you for your business."
Write: "Thanks for working with us."
How to Create This
You don't need to write this from scratch. Start a conversation with Claude and say something like:
"I want to create a skill for client communications. Our style is professional but conversational, we avoid corporate jargon, and we always include specific next steps. Can you help me draft a SKILL.md file that captures this?"
Claude will generate a first draft. You review it, adjust the examples to match your actual preferences, and you've got a working skill.
Example 2: A Meeting Summary Skill
If you run regular client meetings or internal sessions, you probably summarise them the same way each time. A skill makes that format automatic.
---
name: meeting-summaries
description: Use when summarising meetings, calls, or workshops. Creates consistent, actionable summaries that can be shared with attendees.
---
# Meeting Summary Format
## Structure
Every summary follows this format:
**Meeting**: [Type and topic]
**Date**: [Date]
**Attendees**: [Names]
**Key Decisions**
- Decision 1
- Decision 2
(Only include actual decisions made, not discussions)
**Action Items**
| Action | Owner | Due Date |
|--------|-------|----------|
| Specific task | Name | Date |
**Discussion Notes**
Brief summary of main topics covered. 2-3 paragraphs maximum.
**Next Meeting**
Date and focus if scheduled.
## Guidelines
- Decisions go first—they're what people check back for
- Action items need three things: what, who, when. If any is missing, flag it.
- Keep discussion notes brief. This isn't a transcript.
- If something was unresolved, note it under a "Parking Lot" section
## Tone
- Neutral and factual
- Use people's names, not "it was agreed"
- Present tense for actions: "John to review" not "John will review"
How to Create This
Again, start with Claude:
"I need a skill for meeting summaries. I want decisions listed first, then action items in a table with owner and due date, then brief discussion notes. Can you create a SKILL.md template for this?"
Refine the output based on what your team actually needs to see in meeting summaries.
Building Your First Skill
Here's the practical process:
Start with repetition. What do you find yourself explaining to Claude over and over? What formatting do you always have to fix? Those are your skill candidates.
Describe what you want in conversation. Don't try to write the skill document yourself. Tell Claude what you're after and let it generate the first draft. You're the editor, not the author.
Be specific with examples. "Professional tone" means different things to different people. Include before/after examples so Claude understands exactly what you mean.
Test it on real work. Add the skill to a Claude Project and try it on actual tasks. Notice where Claude still misses the mark and update your instructions.
Keep it focused. One skill for client emails, another for meeting summaries, another for proposals. Trying to cover everything in one skill makes it too vague to be useful.
What Goes Wrong
Too vague. A description like "helps with writing" triggers on everything and helps with nothing. "Use when drafting client emails or proposals to ensure consistent voice and format" is specific enough to be useful.
Too complicated. If your skill document is three pages long, Claude will struggle to follow it consistently. Aim for one page of clear instructions with a few good examples.
Set and forget. Skills improve through use. When you notice Claude missing something, update the skill. Five minutes of refinement saves hours of repeated corrections.
Getting Started
Pick one type of work where you consistently adjust Claude's output to match your preferences. Maybe it's email tone, report structure, or how you like information summarised.
Start a conversation with Claude:
"I want to create a skill for [type of work]. Here's how I like it done: [your preferences]. Can you help me write a SKILL.md file?"
Review what Claude produces. Adjust the examples to match your actual style. Add it to a Claude Project. Test it on real work.
The first skill takes 20 minutes to create. After that, Claude works the way you work.
Skills are used within Claude Projects. Each project can have multiple skills that Claude applies based on what you're asking for. To add a skill, upload the SKILL.md file (and any supporting documents) to your project's knowledge base.




Comments