← All articles
EN NLFR

Build your own AI skill in 15 minutes

Claude's built-in skills are good. Custom skills that know your business are better. Here's how to create one from scratch — no coding required.

Claude’s built-in skills handle common tasks — Word documents, spreadsheets, presentations. But the real power comes when you build skills that are specific to your work.

A custom skill is just a text file with instructions. There’s no coding, no API, no configuration file syntax to learn. If you can write a clear briefing for a human colleague, you can build a skill for Claude.

This tutorial walks you through creating a custom skill from scratch, testing it, and refining it until it consistently produces the output you want.

What is a skill, technically?

A skill is a markdown file (.md) that Claude reads before performing a task. It contains:

  1. When to activate — what triggers this skill
  2. What to do — step-by-step instructions
  3. Rules and constraints — formatting, tone, dos and don’ts
  4. Examples — what good output looks like

That’s it. No programming language, no JSON schemas, no dependencies. Just clear written instructions.

Step 1: Pick a task you repeat

The best skills automate something you do regularly and always do the same way. Good candidates:

  • Weekly status reports — same structure, same audience, different data each week
  • Client onboarding emails — same flow, personalised per client
  • Invoice processing — extract the same fields from every invoice
  • Meeting agendas — consistent format for recurring meetings
  • Social media posts — your brand voice, your format, different topics

Bad candidates (too open-ended for a skill):

  • “Write something creative”
  • “Analyse this problem” (too vague)
  • One-off tasks you’ll never repeat

For this tutorial, let’s build a skill for generating weekly client status reports.

Step 2: Write the skill file

Create a file called weekly-status-report.md in your project folder. Here’s the structure:

# Skill: Weekly Client Status Report

## When to use
Activate this skill when the user asks for a weekly status report,
client update, or project status email.

## Context
These reports go to external clients. They should be professional
but not stiff — think "trusted advisor", not "corporate bureaucracy".

## Report structure

### Subject line
"[Project Name] — Weekly Status Update [Date Range]"

### Section 1: Summary (2-3 sentences)
What happened this week in plain language. Lead with the most
important news — good or bad. No filler.

### Section 2: Progress
Bullet list of completed items. Each item starts with a verb
(Completed, Delivered, Fixed, Launched). Include links or
references where relevant.

### Section 3: In Progress
What's currently being worked on. For each item, include:
- What it is
- Expected completion
- Any blockers

### Section 4: Next Week
What's planned for the coming week. Keep it to 3-5 items maximum.

### Section 5: Decisions Needed (if any)
Items where the client needs to make a decision or provide input.
Be specific about what you need and by when.

## Formatting rules
- Total length: 300-500 words maximum
- Use bullet points, not paragraphs (easier to scan)
- Dates in European format (24 March 2026, not March 24, 2026)
- No emoji
- No "I hope this email finds you well" or similar filler

## Tone
- Direct and factual
- Honest about problems — don't bury bad news
- Specific — "database migration is 80% complete" not "good progress on backend"
- Action-oriented — what happened, what's next, what's needed

## Example output

Subject: Acme Portal — Weekly Status Update 17-21 March 2026

Hi Sarah,

This week we completed the user authentication module and started
integration testing. We're on track for the March 28 milestone,
though we've flagged a potential delay on the reporting dashboard.

**Completed:**
- Delivered user authentication with SSO integration
- Fixed 3 critical bugs from last week's testing round
- Completed API documentation for the data import module

**In Progress:**
- Integration testing (expected completion: 25 March)
- Reporting dashboard — delayed by 2 days due to a data format
  issue with the legacy system. New estimate: 27 March.

**Next Week:**
- Complete integration testing
- Begin user acceptance testing (UAT) with your team
- Deploy staging environment

**Decision needed:**
- We need access credentials for your legacy reporting system
  by Wednesday 26 March to stay on schedule. Can you arrange this?

Best regards,
[Name]

Step 3: Place the file

Put your skill file where Claude can find it. You have two options:

Option A: In your project folder

my-project/
├── CLAUDE.md
├── weekly-status-report.md    ← skill lives here
└── ...

Then reference it in your CLAUDE.md:

## Custom skills
- When asked for a weekly status report, read and follow weekly-status-report.md

Option B: In a skills subfolder

my-project/
├── CLAUDE.md
├── skills/
│   ├── weekly-status-report.md
│   ├── client-proposal.md
│   └── invoice-processor.md
└── ...

Reference in CLAUDE.md:

## Custom skills
Load the relevant skill from the skills/ folder when:
- Weekly report → skills/weekly-status-report.md
- Client proposal → skills/client-proposal.md
- Invoice processing → skills/invoice-processor.md

Step 4: Test it

Open Cowork in your project folder and try:

Write a weekly status report for the Acme Portal project.
This week: completed user auth, fixed bugs, started integration testing.
Dashboard is delayed by 2 days. Need access credentials from client by Wednesday.

Claude should read your skill file and produce output that matches the structure, tone, and formatting you defined.

Step 5: Refine based on output

Your first version will be 80% right. The remaining 20% comes from testing and iteration. Common refinements:

Output is too long? Add to your skill: “Maximum 400 words. If content exceeds this, cut the least important items.”

Wrong tone? Add a “Don’t” section: “Don’t use corporate jargon. Don’t use passive voice. Don’t start sentences with ‘Please be advised that’.”

Missing context? Add: “Always ask the user for the project name and date range if not provided.”

Inconsistent formatting? Add more specific examples. Claude follows examples more reliably than abstract rules.

Three more skill ideas to try

Meeting minutes skill

# Skill: Meeting Minutes

## When to use
When the user provides meeting notes, a transcript, or asks for minutes.

## Output structure
1. Meeting header (date, attendees, duration)
2. Key decisions (numbered list)
3. Action items (table: what, who, when)
4. Open questions (for follow-up)

## Rules
- Infer attendees from the notes if not explicitly listed
- Always attribute action items to specific people
- If a deadline isn't mentioned, mark it as "TBD"
- Keep the total output under 1 page

LinkedIn post skill

# Skill: LinkedIn Post

## When to use
When asked to write a LinkedIn post or social media update.

## Structure
- Hook: first line must make people stop scrolling (question, bold statement, or surprising fact)
- Body: 3-5 short paragraphs, max 3 sentences each
- Takeaway: what should the reader do or think differently?
- CTA: end with a question to drive comments

## Rules
- Maximum 1300 characters total
- Maximum 3 hashtags, at the end
- No emoji in the first line
- Write in first person
- Be specific — "we reduced processing time from 3 hours to 12 minutes"
  not "we achieved significant improvements"

Invoice data extractor skill

# Skill: Invoice Data Extraction

## When to use
When the user provides an invoice (PDF, image, or text) and asks to extract data.

## Extract these fields
- Invoice number
- Invoice date
- Due date
- Supplier name
- Supplier VAT number
- Line items (description, quantity, unit price, total)
- Subtotal, VAT amount, Total

## Output format
Return as a structured table. If a field is missing, write "NOT FOUND".
Never guess VAT numbers or amounts — only extract what's clearly visible.

## Rules
- Belgian VAT format: BE 0XXX.XXX.XXX
- Amounts in EUR by default unless another currency is explicit
- If the invoice is in French or Dutch, still output field labels in English

When a CLAUDE.md is enough

Not everything needs a formal skill file. If your instructions are short (under 20 lines), just put them in your CLAUDE.md directly. Skills are worth the separate file when:

  • The instructions are long (50+ lines)
  • You want to reuse them across different projects
  • You want to share them with colleagues
  • The task has a specific output format that needs detailed examples

For simple preferences (“always write in Dutch”, “use formal tone”), CLAUDE.md is the right place.

What’s next?