D3 TS 3.2 · supports 3.1 · ~5 hrs · Skip to quiz →
▶ Watch: how a skill loads · 2 min
The context chapter was about what Claude knows. This module is about what Claude can do, and where those abilities live. Claude Code has a small set of extension types, and people mix their names up constantly, so let's define all five in plain terms before building anything.
A skill is a folder containing instructions for one kind of job. Prepping a meeting brief. Formatting a client deck. Filing a weekly log. Claude picks a skill on its own when your request matches the skill's description, the way a good assistant hears "get me ready for Thursday" and reaches for the briefing checklist without being told which checklist.
A slash command is a saved prompt you fire by name. You type /weekly-log and a prompt you wrote earlier runs. Claude never triggers a command on its own. You do, deliberately, like a speed dial button.
A subagent is a separate worker with its own context window, defined in a markdown file. It gets a full chapter of its own later in the course.
A hook is a script that fires automatically at fixed moments, such as "before every shell command." Hooks are the enforcement layer, and they get the next chapter to themselves.
A plugin is a box that holds any combination of the above, packaged so someone else can install the whole set in one step. Skills and commands are the tools; a plugin is the toolbox with a handle on it.
A skill is a folder inside .claude/skills/, and the folder contains one required file named SKILL.md. Here is a complete, real one, the same skill built step by step in this module's closing demo. This is the entire thing, no parts hidden:
.claude/skills/meeting-brief/
├── SKILL.md
└── template.md---
name: meeting-brief
description: Build a one page brief for an upcoming client meeting. Use when
the user asks to prep, brief, or get ready for a named meeting or stakeholder call.
---
# Meeting brief
1. Find the meeting. Look in meetings/ for a file matching the name or date given.
2. Read STAKEHOLDERS.md and pull the role, history, and open items for each attendee.
3. Fill out template.md: purpose of the meeting, who is in the room, open questions,
decisions we need from them.
4. Save the result to deliverables/briefs/YYYY-MM-DD-<meeting>.md and show it.Walk through the parts. The block between the --- lines is called frontmatter, and it is the skill's ID card: a name and a description. Everything below the frontmatter is the body: the actual procedure, as long as it needs to be. And template.md is a supporting file, extra material the body refers to. A skill folder can carry as many supporting files as it wants: templates, examples, reference tables, even scripts.
Now the part that makes skills special, which you watched in the walkthrough. When a session starts, Claude reads only the description. One sentence in the briefcase. The body and the supporting files stay on disk until the moment the skill is actually used. That is progressive disclosure working as a feature: you could build thirty skills like this one, six thousand lines of accumulated procedure, and a session would carry thirty sentences.
Which means the description is the most important two lines you write. Claude uses it, and nothing else, to decide when the skill applies. Look at the example again: it says what the skill makes ("a one page brief") and when to reach for it ("when the user asks to prep, brief, or get ready for a named meeting"). Now compare a description like "helper for documents." What request would match that? None, reliably. A skill with a vague description sits in the menu forever, never chosen. Write the description like a menu entry: the dish, and when you would order it.
Skills can also live at the user level, in ~/.claude/skills/, where they follow you into every project. Same format, different scope, exactly like the CLAUDE.md levels.
A command is simpler than a skill, and knowing when the simpler tool is enough is the actual lesson of this section.
A command is one markdown file in .claude/commands/. The file name becomes the command name. Here is a complete one, also from the closing demo:
# .claude/commands/weekly-log.md
---
description: File the weekly activity log
---
Summarize what changed in this repo over the last 7 days. Check git log and the
modified dates in deliverables/. Write the summary to logs/week-of-$ARGUMENTS.md
using the section headers from logs/TEMPLATE.md. Keep it under a page.Type /weekly-log 2026-08-21 in any session and this prompt runs, with $ARGUMENTS replaced by whatever you typed after the command name, so the log lands in logs/week-of-2026-08-21.md. That is the whole mechanism: a saved prompt, a name, an optional argument slot.
So when is a command the right choice over a skill? Ask one question: who should decide when this runs? If the answer is "Claude, whenever my request calls for it," you want a skill with a good description. If the answer is "me, on Friday afternoons, by typing a thing," you want a command. The weekly log is a perfect command because nobody wants Claude filing logs on its own initiative. The meeting brief is a perfect skill because you want "get me ready for the steerco" to just work, phrased however it comes out.
Everything you have built so far lives in one repo, and git shares it with everyone who clones that repo. A plugin is the step beyond: the way capabilities travel to people outside your repo.
What a plugin is. A named, versioned package that can carry skills, commands, agents, hooks, and MCP server configuration, bundled so someone installs the whole set in one step. Install the plugin and everything inside arrives already wired up: the skills appear in the menu, the commands answer to their names, the hooks start enforcing.
How a plugin comes to be. The story usually runs like this. You build the meeting-brief skill for yourself. Over a few weeks you refine it: the description gets sharper, the template improves, a deck-design skill joins it, then a guardrail hook. Your teammates use all of it daily, because it is committed to the shared repo and git delivers it to them. Then a consultant on a different engagement sees one of your briefs and asks how to get the same setup. Their team has a different repo. Copying folders across repos works exactly once, and then it rots: no version numbers, no updates, five diverging copies within a month. That moment, when good capabilities want to travel beyond the repo they grew up in, is what plugins are for.
A worked example. Picture a healthcare consulting practice that has refined its toolkit across two engagements: three skills (meeting-brief, deck-design, weekly-log), a command, and three guardrail hooks (a command blocker, a credential scanner, and an audit log). They package it as consulting-toolkit, version 1.0. A new engagement team spins up, installs the plugin on day one, and every consultant immediately has the same skills, the same commands, and the same protections, before their repo has a single deliverable in it. Two months later the deck skill gains a better layout system; the practice ships version 1.1, and every team updates with one command instead of hand copying folders. Recipes that get emailed around versus a cookbook with numbered editions.
A plugin is not an MCP server, and the two get confused constantly, so here is the clean split. An MCP server is a live, running connection to an outside system: a database, a document store, a ticketing tool. It gives Claude reach: new places to read from and act on. A plugin is a package of files that installs capabilities into Claude Code itself. It gives Claude know-how: procedures, shortcuts, guardrails. The overlap that causes the confusion: a plugin can carry the configuration that tells Claude Code which MCP servers to connect to. So the plugin is the box, and an MCP connection can be one of the things listed in the box. MCP servers get a full chapter of their own later in the course.
| MCP server | Plugin | |
|---|---|---|
| What it is | A running service Claude talks to | A package of files you install |
| What it adds | Reach: live access to outside systems | Know-how: skills, commands, hooks, agents |
| How it lives | Runs alongside your sessions | Installed once, then part of your setup |
| Example | A server exposing the firm's document store | consulting-toolkit v1.1 |
When to package. Keep building skills and commands freely in the shared repo; git already shares them with your team, versioned and reviewed. Reach for plugin packaging at the moment your capabilities are stable and another team wants them. The plugin is the retail edition of what your repo already proved out.
You now know several tools: skills and commands from this module, plugins for sharing them, and hooks and subagents on their way in the next two chapters. All that variety creates the one question you will actually face at work, over and over: "I want Claude to handle something for me. Which of these do I build?"
Ask yourself these five questions, in order. The first yes wins:
Now watch the questions sort five real requests, the kind that come up in an ordinary week:
| The request | Which question catches it | Build | Why |
|---|---|---|---|
| "Every client deck must use the brand colors and our layouts" | Q2 · knowledge applied when relevant | Skill | A wrong color is fixable, so no hook. The 300 lines of design system load only on deck days. |
| "I run the same repo summary every Friday afternoon" | Q3 · you are the trigger | Command | /weekly-log runs when you type it and never otherwise. Nobody wants reports filed uninvited. |
| "Claude must never commit directly to main" | Q1 · the word "never" | Hook | CLAUDE.md prose works most of the time, and most of the time fails a never rule. |
| "Summarize these forty files without wrecking my session" | Q4 · heavy reading | Subagent | Forty files fill its window; one page comes back to yours. |
| "Another team wants our whole setup" | Q5 · wanted beyond the repo | Plugin | Stable capabilities, versioned, installable in any repo. |
One tool is deliberately missing from the list: CLAUDE.md. After the context chapter, that should feel right. The root file is for identity and the conventions most sessions need. Almost everything operational belongs in one of the five tools above, where it loads on demand or enforces by mechanism.
Back to the team: five consultants running an AI governance engagement at a regional health plan, sharing one repo as their second brain. Over six months, that repo quietly accumulated 23 skills. Meeting prep. Deck formatting in the client's brand. Document transcription. Weekly data syncs. Voice guides for writing in the practice's registers. Real capabilities, built one at a time as needs came up, by whoever hit the need first.
In month seven, a new consultant joined the team. Day one, she cloned the repo, opened a session, and asked the obvious question: "what skills do you have here?" The answer came back: none. Twenty three skills on disk, zero visible. The cause was the address bug you already met: skills are discovered only inside the .claude skills folder, and the fix was one ask to move them. But moving the folder only made the skills discoverable. Whether the collection actually worked was a separate question, and answering it meant auditing all 23 against what this module teaches. Here is what the audit found.
The majority held up. Each of these is procedural, needed sometimes rather than always, and reachable by a natural request:
prep-for-meeting, the flagship. A consultant says "get me ready for the sponsor call," and the skill finds the meeting file, reads the stakeholder roster, and drafts the brief. Nobody types a skill name. The request itself is the trigger.deck-design: 300 lines of the client's visual system, loading only on the days someone builds slides.pptx, docx, xlsx), each holding the production steps for one deliverable type.persuasion-voice, which reshape drafts into the practice's writing registers on request.The audit's second finding: five of the 23 were never really skills. The test that exposed them is a single question: would you ever want Claude doing this uninvited?
open-gov-hub opens the governance hub site in a browser. One action, no procedure, always a human choosing the moment. That wants to be /open-gov-hub, a command.sync-ecosystem-data, sync-curated-content) pull fresh content on a rhythm a person kicks off every Monday morning. Command shaped today; later in the course they become scheduled automations that need no human at all.Nothing was wrong with the content of these five. They were mislabeled, and the label matters: a skill invites Claude to act on its own judgment, and every one of these is an action where a person should hold the trigger.
The sharpest finding. Three skills (clipping-linker, pocket-automation, partner-voice) had empty or missing descriptions in their frontmatter. Spell out what that means:
The repair, per skill, cost two sentences: what it makes, and when to use it.
After the folder move, five renames, and three written descriptions, the new joiner's day one question got a different answer: fifteen skills listed with descriptions, plus five commands she could see by name. Her first stakeholder brief happened that same afternoon, produced by asking for it in plain words, through a skill written by a colleague she had not met yet. That is what a working capability layer feels like: the team's accumulated craft, available to its newest member on her first day.
To run this audit on any repo, three checks:
▶ Watch the demo: building your first skills · 4 min
The prompt pack: every demo prompt, cleaned and explained
The demo applies this whole chapter, prompt by prompt, in the practice repo the course has been building. You watch five instructions build the capability layer: the meeting-brief skill described in one plain prompt (and the SKILL.md Claude writes from it), the supporting files it reads, the /weekly-log command with its $ARGUMENTS date slot, and a deliberately vague doc-helper skill built to fail. Then the tests run in a fresh session: discovery, matching, the command by name, the vague skill missing on cue, and the two sentence description rewrite that brings it to life.
Then run the pack in your own repo. The prompt pack linked above holds every prompt from the demo, cleaned up and explained. Copied as is or rephrased in your own words; describing what a skill makes and when it is used is the actual craft, and the demo proves that a plain description is all Claude needs. As you go, check what the demo checked:
/weekly-log with a date writes the log to the templated path. The command and its $ARGUMENTS slot work.Claude Code docs on Skills and Slash commands (code.claude.com/docs), and the Agent Skills documentation for the standard behind SKILL.md.
Take the Module 02 quiz → then hit the Study App for Domain 3, lesson 3.2.