Claude Code

Skills

Teach AI how you work.
Modular knowledge that compounds over time.

The problem

AI knows a lot.
But not your processes.

Claude can write code, review contracts, and build applications. But it doesn't know:

  • How your ClickUp boards are structured
  • Your definition of done for a feature
  • Your company's scoping workflow
  • Which fields are required when creating a build
  • How you write proposals or run workshops

The gap

Every time you start a new conversation, you lose all that context. You re-explain the same processes. You correct the same mistakes. Over and over.

Skills close that gap — permanently.

Definition

What is a Skill?

A skill is a modular, self-contained package of knowledge and workflows. Think of it as an onboarding guide — it transforms Claude from a generalist into a specialist for your domain.

Knowledge, not actions

A skill describes how things work — your processes, schemas, conventions, and rules. It doesn't execute workflows; it provides the expertise to do them right.

Progressive disclosure

AI only loads what it needs. The skill description is always visible. The body loads on trigger. References load on demand. No context waste.

Shareable across teams

Put a skill in a plugin marketplace and everyone on your team gets the same consistent knowledge base. One source of truth.

Evolves over time

Start rough, iterate based on feedback. The best skills aren't written in one go — they're refined through real usage and real corrections.

Structure

Anatomy of a Skill

clickup-delivery/
├── SKILL.md ← always required
│   ├── YAML frontmatter (name + description)
│   └── Markdown body (compact, <2000 words)
└── references/ ← loaded on demand
    ├── build-creation.md
    ├── sprint-cycle.md
    └── definition-of-done.md

Optional: scripts/ for executable code, assets/ for templates and images.

SKILL.md

The core file. Contains the name and description in YAML frontmatter (determines when AI triggers the skill), plus a compact body with essential knowledge.

References

Detailed docs that AI reads only when needed. Process guides, schemas, examples, field requirements. This is where depth lives — without polluting the context window.

Core concept

Progressive Disclosure

The model always knows the skill exists. It reads only what it needs. A massive, complex knowledge base feels lightweight because only relevant parts enter the context window.

Level 1
~100 words
Metadata
Name + description
Always loaded
Level 2
<5k words
SKILL.md body
Core knowledge
On trigger
Level 3
Unlimited
References
Deep detail
As needed
Key distinction

Skills vs Commands

Skill

Knowledge. Describes how things work, what fields exist, how processes are structured. Matter-of-fact documentation.

"A build has these required fields:
 client, type, milestone...
 Statuses: scoping → active → done"
  • AI auto-discovers when relevant
  • Multiple commands can reference it
  • Domain owner maintains it

Command

Action. A workflow prompt that guides the user through a process. Asks questions, calls tools, produces output.

"/new-build
 Ask user for client name, type...
 Create build in ClickUp using skill"
  • Only runs when explicitly called (/slash)
  • References skills for knowledge
  • Simple markdown file

Rule of thumb: If you update the skill, commands don't need to change — they point to the same source of truth.

Architecture

The Plugin Bundle

Skills don't live alone. A plugin bundles related skills, commands, agents, and MCP servers into one installable package.

Marketplace

Org-wide catalog

Plugin

Themed bundle

Skills

Knowledge

Commands

Workflows

MCPs

Tool access

Sales Plugin

Fireflies MCP + meeting prep skill + proposal command

Developer Plugin

Code review agent + tool design skill + cleanup command

Hackathon Plugin

Recap skill + prep skill + communication commands

Install a plugin → get skills, commands, and MCPs in one click. No setup.

Process

Building a Skill

1

Understand the domain

What does the user actually need? Which processes are repeated? What context gets lost between sessions?

2

Plan the resources

Which parts need scripts? Which need reference docs? What's core enough for SKILL.md vs a reference file?

3

Write SKILL.md

Strong trigger description. Compact body in imperative form. Point to references. Stay under 2000 words.

4

Use it. Break it. Improve it.

The best skills come from iterating on real feedback — not from writing the perfect document upfront.

We'd much rather you start with a mediocre skill and fill it in over time with your learnings — collecting feedback and knowing what's missing. That's how you get a really good skill. — From team sessions on skill development

The Skill Creator shortcut

Use the /skill-creator skill to generate a first draft from a conversation. It structures your existing knowledge into the right format — then you iterate.

Critical detail

The Description Makes or Breaks It

The description field in frontmatter determines when AI triggers your skill. Vague descriptions mean your skill never gets used.

BAD — won't trigger

description: Provides guidance
  for working with ClickUp.
  • No trigger phrases
  • Too vague — when exactly?
  • Wrong person (not third-person)

GOOD — triggers reliably

description: This skill should
  be used when the user asks to
  "create a build", "add a feature",
  "check delivery status"...
  • Specific trigger phrases
  • Third-person format
  • Matches real user language
In practice

How It All Connects

When someone types /new-build, here's what happens:

Command triggers

The /new-build command prompt loads and starts the workflow.

Skill provides knowledge

Command references the ClickUp Delivery skill → AI reads which fields are required, what statuses exist, how builds are structured.

MCP executes

With the right knowledge, AI calls the ClickUp MCP to actually create the build with correct fields.

Skill updates separately

When the process changes, only the skill gets updated. All commands still work — they reference the same source.

Single source of truth

If you have 5 different commands that need to know how builds work, they all point to one skill. Update once, everything stays consistent.

Ownership matters

Each skill has a domain owner:

  • ClickUp delivery → Leonie
  • Salesforce workflows → Wouter
  • Developer tooling → Sjoerd / Lex
  • Sales processes → Thomas

Nobody blindly edits someone else's skill. Feedback goes to the owner.

Best practices

Rules of Thumb

Keep SKILL.md lean

1500–2000 words max. Move detailed process docs, schemas, and examples to references/. The body is for essential knowledge only.

Split, don't grow

When a skill gets too large, break it into multiple focused skills within the same plugin. Finance has audit + close management as separate skills.

Watch for prompt injection

External skills from community sources can contain hidden instructions. Always review imported skills before trusting them with sensitive workflows.

Commands stay invisible

Unlike skills, commands are never auto-discovered. They only activate on explicit /slash invocation. Perfect for setup flows and onboarding.

Reference, don't repeat

If the same knowledge appears in multiple skills, extract it into one skill and have others reference it. Avoid duplication across your plugin.

Collect feedback

Build a feedback loop — a simple MCP or ClickUp integration where users can report what went wrong. Rich feedback makes skills better fast.

A skill is essentially just a prompt. But it's structured, it's progressive, and it's shareable. And that makes it something completely different — it makes it a reusable piece of expertise that compounds every time someone uses it and makes it better. — From internal skills workshop
Next step

Start Building

1

Pick one process
you keep re-explaining

2

Use the skill creator
to draft a SKILL.md

3

Test, iterate,
share with your team

Every skill you build is knowledge your team never has to re-explain. The investment compounds.