Using Claude Skills

You teach Claude once, it remembers every time

Every time you start a new conversation with Claude, you lose context. The workflow you described yesterday is gone today. The format you spent 10 minutes getting right wasn't saved for the next few times you need it. The rules your team follows for customer responses have to be explained over and over again.

Skills fix that. You teach Claude once, it remembers every time.

I've been building skills as part of my work at Plain, and I've been walking support leaders through this in our Claude Code sessions. The reaction is always the same. People go from "this isn't for me" to "wait, I can actually build this?" in about 20 minutes.

Before I get into the how-to, let me clear up the three things people confuse the most: the difference between skills, plugins, and MCPs.

Skills vs Plugins vs MCP vs Agents: What's the Difference?

These four concepts keep getting tangled up. Here's the simplest way I can explain them.

Skills = knowledge. A skill teaches Claude how to do something. It's a folder with a SKILL.md file that contains instructions, best practices, and workflow steps. "When someone uploads ticket data, detect the columns, normalize the dates, analyze trends, and produce a report in this specific format." Skills are the recipe.

Plugins = packaging. A plugin bundles skills (and other things like agents, hooks, and commands) into a distributable package. It's how you install and share skills from GitHub marketplaces. If a skill is a recipe, a plugin is the cookbook you hand to someone. You don't need plugins to use skills — you can just drop a folder into your skills directory — but plugins make distribution and installation clean.

MCP = connectivity. MCP (Model Context Protocol) gives Claude access to external tools and data. Connect to Slack, Notion, Linear, GitHub, a database. MCP is the kitchen: the tools, ingredients, and equipment. Without MCP, Claude can't reach your systems. Without skills, Claude has to guess what to do once it gets there.

Agents = autonomy. An agent is Claude running with a goal, making decisions across multiple steps without you prompting each one. It reads the skill, reaches for the MCP tools it needs, and works through the problem. A skill tells Claude how to triage a bug report. An agent takes an incoming ticket, checks the customer's account, looks up related Linear issues, drafts a response, and escalates if needed — all from a single prompt.

💡 Please note: There are more advanced patterns here: sub-agents, orchestration, multi-agent workflows. We will cover these in a future lesson.

The shortcut:


WHAT IT DOES

ANALOGY

Skills

Teaches Claude how to do something

The recipe

Plugins

Packages and distributes skills

The cookbook

MCP

Connects Claude to external tools

The kitchen

Agents

Runs autonomously, using skills and tools to complete a goal

The chef

They work together. An MCP server gives Claude access to your Linear projects. A skill teaches Claude your sprint planning workflow. A plugin packages that skill so your whole team can install it with one command.

For support leaders: skills are where you'll spend most of your time. They don't require running servers or managing infrastructure. You write instructions in Markdown, and Claude follows them.

Skills are available across Claude Code, Claude.ai (web/desktop), and the API. This guide focuses on Claude Code because that's my daily workflow. I run it inside Cursor, but the skills themselves are portable. Build once, use everywhere.

What's a Skill?

A skill is a folder. Inside the folder is a file called SKILL.md that tells Claude what to do, when to do it, and how to do it well.

You're not coding. You're describing a workflow in plain language with some light structure so Claude knows when to activate it.

A skill can be as simple as "when I ask you to draft a customer response, always use this tone and format" or as complex as "when I upload ticket data, run this analysis, flag the trends, and produce an executive summary with charts."

The rule of thumb: if you find yourself repeating instructions to Claude, that's a skill waiting to happen.

The Anatomy of a Skill

Every skill lives in a folder like this:




The SKILL.md file has two parts:

1. The frontmatter tells Claude when to use this skill.

---
name: ticket-trend-analyzer
description: Analyzes exported support ticket data to identify volume
  trends, top issue categories, and emerging patterns. Use when user
  uploads a CSV of ticket data, mentions "ticket trends", "support
  metrics", or asks to "analyze my tickets".
---
---
name: ticket-trend-analyzer
description: Analyzes exported support ticket data to identify volume
  trends, top issue categories, and emerging patterns. Use when user
  uploads a CSV of ticket data, mentions "ticket trends", "support
  metrics", or asks to "analyze my tickets".
---
---
name: ticket-trend-analyzer
description: Analyzes exported support ticket data to identify volume
  trends, top issue categories, and emerging patterns. Use when user
  uploads a CSV of ticket data, mentions "ticket trends", "support
  metrics", or asks to "analyze my tickets".
---

2. The instructions tell Claude how to do the work. Written in Markdown, below the frontmatter.

That frontmatter block is the most important part. It's what Claude reads constantly to decide whether your skill is relevant. If your description is vague, Claude won't know when to use it. If it's specific — the exact phrases people would say, the file types they'd upload, the tasks they'd request — it activates reliably.

Building Your First Skill 🛠️

Step 1: Pick one workflow you repeat constantly

Some ideas for support leaders:

  • Analyzing a CSV of tickets to surface trends and top issues

  • Turning messy internal notes into a polished exec summary

  • Drafting customer comms in your team's specific voice

  • Building coverage schedules from historical ticket volume

  • Creating onboarding materials from Slack conversations

Pick the one that saves you the most time this week.

Step 2: Write the frontmatter

Two fields. A name and a description.

The name is lowercase with hyphens. No spaces, no capitals.

ticket-trend-analyzer
Ticket Trend Analyzer
ticket_trend_analyzer

The description answers two questions: what does this skill do, and when should Claude use it?

This is where most skills fail. People write a description that sounds nice but doesn't contain the actual trigger words someone would say out loud.

✅ Good:

description: Creates executive-ready support reports from raw ticket
  data. Use when user says "exec report", "leadership update", "support
  health metrics", uploads a CSV of ticket data, or asks to summarize

description: Creates executive-ready support reports from raw ticket
  data. Use when user says "exec report", "leadership update", "support
  health metrics", uploads a CSV of ticket data, or asks to summarize

description: Creates executive-ready support reports from raw ticket
  data. Use when user says "exec report", "leadership update", "support
  health metrics", uploads a CSV of ticket data, or asks to summarize

❌ Bad:

description
description
description

Claude wouldn't know when to activate that, or what kind of report you want.

Step 3: Write the instructions

Below the frontmatter, write your instructions in Markdown. Be specific. Be actionable. Write it like you're onboarding someone who's smart but has zero context on your team.

Here's a template I use:

# [Skill Name]

## What This Does
[One paragraph explaining the outcome]

## Steps

### Step 1: [First thing Claude should do]
[Clear, specific instructions]
Expected output: [what success looks like]

### Step 2: [Next step]
[Instructions with examples]

## Examples

**Example 1: [Common scenario]**
User says: "Analyze last month's tickets"
What to do:
1. Look for a CSV with ticket data
2. Identify the date range
3. [etc.]

Result: [What the user gets]

## Things to Watch For
- [Common edge case and how to handle it]
# [Skill Name]

## What This Does
[One paragraph explaining the outcome]

## Steps

### Step 1: [First thing Claude should do]
[Clear, specific instructions]
Expected output: [what success looks like]

### Step 2: [Next step]
[Instructions with examples]

## Examples

**Example 1: [Common scenario]**
User says: "Analyze last month's tickets"
What to do:
1. Look for a CSV with ticket data
2. Identify the date range
3. [etc.]

Result: [What the user gets]

## Things to Watch For
- [Common edge case and how to handle it]
# [Skill Name]

## What This Does
[One paragraph explaining the outcome]

## Steps

### Step 1: [First thing Claude should do]
[Clear, specific instructions]
Expected output: [what success looks like]

### Step 2: [Next step]
[Instructions with examples]

## Examples

**Example 1: [Common scenario]**
User says: "Analyze last month's tickets"
What to do:
1. Look for a CSV with ticket data
2. Identify the date range
3. [etc.]

Result: [What the user gets]

## Things to Watch For
- [Common edge case and how to handle it]

One thing I learned the hard way: "Validate the data before proceeding" means nothing.

Instead, be clear with your instructions: "Before creating the report, verify that the CSV contains columns for ticket_id, created_date, category, and status. If any are missing, ask the user which columns map to those fields." That works.

Step 4: Install and test it

There are a few ways to add skills to Claude. Here's the simplest path for each setup:

If you use Claude Code (in your terminal or inside Cursor):

Just ask Claude to do it for you. Seriously. Type something like:

"Create a new skill called ticket-analyzer in my personal skills directory"

Claude will create the folder, the SKILL.md file, and put it in the right place. You can also paste your SKILL.md content and ask Claude to save it as a skill. No file paths to memorize.

If you want to install a skill someone else already built, you can grab it from a marketplace. Type this inside Claude Code:

/plugin

Then browse what's available and install what you need. Claude walks you through it.

If you use Claude.ai (web or desktop app):

Go to Settings → Capabilities → Skills → Upload skill, and upload your skill folder as a ZIP file. That's it.

Once it's installed, test three things:

  1. Does it trigger? Ask Claude something your skill should handle

  2. Does it trigger on paraphrased requests? Don't just use the exact words from your description

  3. Does it stay quiet when it should? Ask something unrelated. Your skill shouldn't fire

If it's not triggering → your description needs more specific phrases.
If it's triggering on everything → your description is too broad.

You can also invoke a skill directly by typing /ticket-analyzer (the name from your frontmatter becomes a command). Useful when you want to force it rather than wait for auto-triggering.

Quick debugging trick: ask Claude "When would you use the [skill-name] skill?" It'll quote your description back and you can see what's missing.

Step 5: Iterate

Your first version won't be perfect. That's fine. You'll use it, notice it missed something, go back and add better instructions. The bar isn't perfection. It's "better than explaining the whole thing from scratch every time."

Patterns I Keep Seeing Work 🔍

After building skills myself and watching leaders build theirs in our sessions, a few patterns keep coming up:

📊 The data analyzer. Upload a CSV of tickets, get back a structured analysis. Top issue categories, volume trends, emerging patterns, time-to-resolution breakdowns. This one gets the biggest reaction in workshops because it replaces hours of spreadsheet work with a two-minute conversation.

⚙️ The workflow orchestrator. Multi-step processes that need to happen in a specific order. Onboarding a new customer. Escalating a bug to engineering. Preparing for a QBR. The skill encodes the sequence so nothing gets skipped.

📄 The report generator. Takes messy operational data and produces something you'd actually show to your VP. Narrative summaries, not just charts. Context, not just numbers.

Real Example: Plain Support Skill

Our team has been using this skill internally for a while to perform actions like:

  • Debugging user issues: the AI agent looks up the customer, reads their thread timeline, and summarizes the conversation. Then it can use that context to investigate the bug in the codebase and put up a fix.

  • Researching customer history before a call: "Show me everything about customer john@acme.com". The agent will pull their profile and recent conversations for full context.

  • Drafting help center content: the agent can crete new help center articles based on patterns it sees in support threads.

In February, we shared this skill with the world and this lesson is the perfect place to showcase how it works.

Once you have the skill installed and the API setup, you can chat with your workspace data.

💡 Please Note: I'm using a demo workspace with fake data for this example. All the customer and thread info is generated with AI.

For example, you can ask Claude Code (or another AI tool) to give you a breakdown of your threads.

In my demo workspace, I have a mix of threads from various customers about a variety of different topics. You can ask Claude Code to give you information about their status and what they are about.

But this is only surface level information. We can use this skill to really understand what's going on with a customer account before jumping on a call with them:

You can draft responses based on existing help center articles:

If you give your Plain Support Skill the ability to send the message on your behalf, it can also do that:

And if the help center doesn't yet have an article that addresses the issue, we can identify that:

Now that we know Two-Factor Authentication is a source of confusion for our customers, let's draft that article and get it published.

First, Claude Code read the 7 threads to fully understand the issue. Then it created a draft (in HTML) based on 3 distinct issue patterns that it uncovered.

I was happy with the result so I asked Claude to publish the new article. Using the API write access to "Create/update articles and groups", Claude went ahead and published that new article.

But I personally find that without specific guidance, AI results tend to feel generic so I built a Help Center writer skill to create articles that are scannable and task-oriented (which is my preference).

Here's the results after I asked Claude Code to rewrite the article using the new skill:

Now let's look at some data. We can ask Claude Code to help us create some reporting and figure out some trends. But we can also install other skills that were built specifically for support data. In this case, I installed my Exec Report Builder skill and asked Claude Code to run it on the workspace data. Here's the result:

A nice .md file with key metrics, top issue themes, product signal, documentation gaps, etc... You can then turn this into a PDF, a Slack message, or anything else that fits your workflow. You can even automate this so it runs once a week and publishes automatically.

Pretty cool :)

Things I Learned the Hard Way

Keep SKILL.md focused. If your instructions are getting long, move reference material into a references/ folder and scripts into scripts/. Claude uses progressive disclosure. It reads the frontmatter first, loads the main instructions when relevant, and only digs into reference files and scripts when needed. My ticket analyzer has industry benchmarks in references/benchmarks.md rather than inlining them. Keeps the core instructions clean.

Scripts are worth the effort. My first version of the ticket analyzer had Claude generating chart code from scratch every time. Sometimes it worked, sometimes the charts looked rough. Now there's a generate_charts.py script that produces consistent, clean visuals every run. If you need repeatable output, put it in a script.

Test with real data. Don't test with clean sample files. Use the messy export from your actual ticketing system. That's where you discover that half your category values have trailing whitespace, or that three agents are listed under slightly different name spellings. Those edge cases are the whole reason the skill exists.

Start with one, then compose. Build the ticket analyzer first. Then the CSAT analyzer. Then the business review generator. Then realize they chain beautifully. Claude can load multiple skills simultaneously and pass findings between them.

Put skills in version control. If you add skills to your project's .claude/skills/ directory and commit them, anyone who clones the repo gets the same workflows. This is how you standardize how your team works with Claude without writing documentation nobody reads.

How to Install and Share

For yourself: Ask Claude Code to save it to your personal skills directory. Or in Claude.ai, upload the folder as a ZIP via Settings → Capabilities → Skills.

From a marketplace: In Claude Code, type /plugin marketplace add anthropics/skills to register Anthropic's official marketplace, then browse and install what you need.

For your team: If your team uses Claude Code, you can add skills to your shared project so everyone gets them automatically. In Claude.ai, admins on team or enterprise plans can deploy skills to the whole organization through Settings.

For the community: Host your skill on GitHub with a clear README and examples. People can install it with one command or download it and add it themselves.

Go Build Something

Pick one workflow you'll repeat this week. Spend 15 minutes turning it into a skill. See what happens.

If you build something cool, or get stuck, send me a message. I'm collecting examples from support leaders and I'd love to feature what you're creating.

WHere next?

Choose your own adventure

Join the teams who rely on Plain to provide world-class support