Chapter 21: Skills: Use, Fork, Build#

Where the system becomes yours#

Everyone’s Claude Code can write an email. Only yours can write the specific weekly update you send, pulling from the specific folders you keep, in the specific voice you use — because you taught it that once, as a skill, and now it is a command.

Chapter 13 introduced skills as a concept and Chapter 16 gave you eleven ready-made ones. This chapter is the full craft: how skills actually work, when to build one, how to write your first, and — the quietly powerful part — how to reshape the ready-made ones so the plugin becomes raw material instead of a cage.

What a skill really is#

A skill is a folder with one file in it: SKILL.md. That file says, in plain language, what the skill does, when it should fire, and where its output goes. No code. If you can explain a process to a new hire, you can write a skill.

A few settings at the top of the file (the “frontmatter”) tell Claude Code how to treat it. Only three matter to you:

• description — the single most important line. This is what Claude reads to decide whether the skill matches what you just asked for. Write it packed with the phrases you would actually say. A vague description means the skill never fires; a sharp one means it fires exactly when you need it.
• allowed-tools — what the skill may do: read files, write files, run commands. Listing them keeps the skill scoped to what it actually needs.
• Who can call it — by default, you can type it as a command and Claude can reach for it on its own when your request matches. Both are useful; both can be switched off per skill when you want one and not the other.

(There is also a setting that runs a skill in its own separate side-conversation so a long messy job does not clutter your main one — context: fork. I do not use it, and nothing in this part needs it. Filed under “exists.”)

Should this even be a skill?#

Before you build anything, one test: do it often, same steps every time → make it a skill. Do it rarely, with real judgment each time → keep doing it by hand.

A skill hides its steps behind one command, which is exactly right for your Monday status report and exactly wrong for a quarterly decision where the thinking is the work. Automating a judgment-heavy process just hides the only part that mattered. One more honesty check: if a task is frequent but still changing shape every time you do it, it is not ready either — wait until it settles. Building the skill is easy; knowing whether you should is the actual skill.

Your first custom skill, in four steps#

Step 1 — pick the candidate. The best first skill is something you have done at least twice, by hand, the same way both times. A repeated request you phrase the same way. A document you always shape identically. Your second-time-done workflows are your skill backlog.

Step 2 — sketch it in plain English. Before touching any file, write the procedure the way you would say it out loud: “Read each active project’s latest log entries and most recent meeting. For each, write three lines: what moved, what’s blocked, what’s next. Sort by nearest deadline. Save to Drafts with today’s date.” That sketch is 80% of the skill.

Step 3 — put it in the project. Skills tied to your work belong inside the Command Centre folder, at .claude/skills/<name>/ — not in your global user-level skills. This matters more than it looks: a project skill travels with the folder, gets versioned with the folder, and is right there to open and edit when you want to change it. Global skills are only for habits you genuinely want in every folder you ever open. When in doubt, project.

Step 4 — write the file. Ask Claude to do it from your sketch, or write it yourself:

Example file: .claude/skills/weekly-status/SKILL.md:

---
name: weekly-status
description: >
  Compile a one-page weekly status across all active projects. Triggers include
  "weekly status", "project status", "compile my Monday status".
allowed-tools:
  - Read
  - Write
  - Glob
---

# Weekly Status

Read the latest Daily Log entries and the most recent Meeting Transcripts
file for each project named in CLAUDE.md's Active Workstreams.

For each one, write three lines: **Moved**, **Blocked**, **Next**.
Order by nearest deadline.

Save to Drafts/YYYY-MM-DD-weekly-status.md and print the path.

That is a real, working skill. Save it, and /weekly-status exists.

Run it, then let use finish it#

Your first run will be 80% right. The missing 20% only shows up in use: it skipped a project, the order was wrong, you wanted a fourth line. Each time, add one line to the SKILL.md. Within a month the skill encodes more care than you could muster by hand on a busy Monday — because it remembers every Monday’s lesson, and you do not have to.

Make the plugin’s skills yours#

The same mechanic works on the eleven skills the Command Centre shipped with — and this is the move that makes the whole system feel owned rather than rented. Say /daily-log sorts your day into four sections but your work needs six. Do not fight it, and do not work around it. Copy it and edit it:

Inside Claude Code:

Copy the daily-log skill from the Command Centre plugin into this project's
.claude/skills folder, then change it to route entries into six sections:
Decisions, To-dos, Ideas, Blockers, People, and Money.

Your copy now takes precedence over the plugin’s version, and a plugin update will never overwrite your changes. The scaffolding is universal; the parts are swappable. Every skill in the system is meant to be opened, read, and reshaped — that is why they are plain-language files and not black boxes.

Borrow before you build#

One last discipline before you go skill-happy: before building anything, check whether a plugin or existing tool already does it (Appendix A and B are your catalogs). Most capability already exists; rebuilding it is pure cost. Build only the piece that is genuinely specific to your work — and build it small. The signal to build is an existing tool failing on your real input, not a vague feeling that custom would be nicer.

Pro tips#

1. Write the description like a trigger, not a title. It is the whole difference between a skill that fires and one that gathers dust.
2. Prefer small skills that combine over one big skill that does everything. Small ones are easier to get right and easier to reuse.
3. Copy before you fight. When a ready-made skill is almost right, make it yours and edit — never contort your workflow around someone else’s default.