Skills as operational playbooks

Every week you re-explain the same workflows: how you like the follow-up email structured, what goes in the weekly recap, which sections the summary needs. Each re-explanation is a paragraph you have typed before and will type again.

A skill is that paragraph, written down once, triggered by a phrase. Linda’s Hub has 40 of them. /blog drafts a blog post the way she wants it written. /ship wraps up a working session: updates the log, commits, pushes. Every one of them replaced instructions she was tired of typing.

The test is mechanical, not aspirational: if you have explained a workflow to the AI twice, the third time should be a trigger word. One-off prompts are conversations. Skills are infrastructure. Infrastructure compounds.

What a skill is, materially

A skill is one markdown file at a known address in your Hub: .claude/commands/<name>/SKILL.md. Two parts:

• Frontmatter: name and description. That is the complete list. The description does double duty: it says what the skill does and names the trigger phrases (“Use when I say ‘draft a follow-up’…”).
• The instructions: the playbook itself. Inputs, procedure, rules, output format. Written like an SOP you would hand a competent new teammate.

When you type /bluerock:meeting-recap in Claude Code, the skill file loads into your current chat and the instructions take over. (Type it in the Claude Code chat panel, the same place you ask questions; just start with the slash.) That is the whole mechanism. No magic, one file.

The slash is the explicit path. There is also an implicit one, and it is the real power of the description you just read about: you do not have to remember the slash at all. Say a trigger phrase in plain language (“draft a follow-up from this call”) and Claude Code finds the skill and loads it itself, because the description told it when this skill applies. That is why trigger phrases live in the description: not documentation, routing. Your words run your playbooks. (One distinction while we are in the input box: commands like /help and /clear ship with Claude Code; everything under .claude/commands/ is yours.)

Skill or agent? The decision rule, now load-bearing

In Module 1 the rule was vocabulary. Today it decides what you build:

• If you can finish the job in your current chat, it is a skill. The skill borrows your context: your CLAUDE.md, your open conversation, your files. It has no Identity of its own, because the identity in the room is yours.
• If you would rather hand it off and check back, it is an agent. An agent gets the five-part anatomy because it works alone in its own context window.

Notice what a skill does not need from the M1 anatomy: no Identity, no separate Context. It is Job and Output, running in your chat, under your eyes. That is why skills come before agents in this curriculum: the same craft, fewer moving parts.

When to pause, regardless of the rule: two kinds of work earn a stop-and-check no matter how good the skill gets. Anything that makes an external commitment (a client email, a quote, a promise) gets read by you before it sends. Anything that will run unattended gets tested on sample data first. The skill does the drafting; you keep the judgment.

Meta-prompting: design the skill, don’t write it

The mistake everyone makes with their first skill: open the file and start typing instructions cold. You will write down what you think the workflow is, and discover at first use that you skipped the decisions that matter. Instead, use the agent to design the skill. Three patterns, in sequence:

This skill ships in the BlueRock plugin you installed in get-started: /bluerock:meeting-recap, the one that drafts the email you send after a call. Read the plugin’s version below and ask of each piece: why is it shaped this way? This is the pattern; at the end of the module you’ll build your own skill in .claude/commands/.

One thing to notice first: this skill composes with M2. Its default input is notes/<today>.md, the file scribe has been filing all week. If you did the M2 take-home, the skill already has real material to work from. Capture, then process, then produce: the loop grows a third stage.

---
name: meeting-recap
description: >-
  Drafts a follow-up email from call notes, in my
  voice. Use when I say "draft a follow-up",
  "follow-up email from this call", or paste meeting
  notes or a transcript and ask for a recap email.
  Reads today's notes file (or the file I name) if I
  don't paste anything.
---

## Inputs, in priority order

1. Notes or a transcript pasted into the chat.
2. A notes file I name (e.g., "from Tuesday's
   notes" → notes/<that-date>.md).
3. Today's notes file, notes/<today>.md: use the
   most recent meeting under the Meetings section.

If none of these exist, say so and ask which call
I mean. Do not invent a meeting.

## Structure (every time, same shape)

1. Subject line: the topic plus the next step,
   under 9 words. Not "Great meeting you!"
2. One-line opener: reference something specific
   that was said or decided.
3. What we agreed: 2-4 bullets max. Each bullet is
   a commitment with an owner: theirs or mine.
4. The ask: exactly one next step, with a proposed
   date or time window. One ask per email, never two.
5. Sign-off: plain. "Thanks," plus my name.

## Voice rules

- My voice, not vendor voice: direct, warm,
  zero filler.
- No emojis. No exclamation points unless I used
  one in the notes.
- Numbers stay exact. If the notes say $90K,
  write $90K.
- If a commitment in the notes has no owner or
  date, flag it to me in a note BELOW the draft,
  outside the email body. Never guess inside
  the email.

## Output

- The draft email in a single fenced block,
  paste-ready: subject line first, then the body.
  Nothing else inside the fence.
- Below the fence: anything I should double-check
  before sending (missing dates, ambiguous owners,
  a commitment I may not want to make in writing).
  Two bullets max. Skip entirely if there's nothing.

The takeaway, same as M1 and M2: nothing in this file is clever. Five sections of patient, specific decisions, written once. That is the craft, and today you do it for a workflow of your own.

Patterns from How I work with AI that show up in M3: