The Specialist

In Lesson 1 you hired a helper for one job, one time — fresh eyes, dispatched with a sentence, gone when done. That's day labor. Kitchens run on something better: the specialist. The saucier doesn't get re-explained what sauces are every shift; they have a role — standing instructions, a station, a way they report. You describe the dish, they bring the expertise.

Today your crew gets its first named specialist, and here's the demystification the whole lesson rests on: a specialist is a job description in a file. Plain words, like your CLAUDE.md, like your skills. When you call the specialist, your agent hands the job to a fresh cook who reads that description first and becomes it for the shift. No code. You've been one prompt away from this the entire course.

What you'll plate today

The Inspector: a standing fresh-eyes specialist with its own rubric, tested against the generic helper it replaces — plus the judgment for what deserves a role versus a one-off order.

Ingredients

• Your kitchen-brigade project, chart and pantry ready
• A piece of real work worth inspecting (a report draft, a lesson-2 handbook, a Prep Station output)
• About 30 minutes

Cook

1. Write the job description together

The role should encode what you learned about good fresh-eyes review — not just "review this" but how you want reviewing done here:

We're hiring our first standing specialist: The Inspector — the
fresh-eyes reviewer from Lesson 1, made permanent. Draft its job
description as a subagent role for this project. It should cover:

1. WHO IT IS: a skeptical outside reviewer; it never saw the work
   being made and doesn't know what the author meant.
2. ITS RUBRIC — how it inspects, in order: claims without support
   first, then unclear-to-a-stranger, then inconsistencies, then
   style ONLY if it changes meaning.
3. HOW IT REPORTS: numbered, harshest first, each finding quoting
   the exact line — and a verdict: ship / fix-first / rethink.
4. WHAT IT NEVER DOES: fix things, soften findings, or review its
   own output.

Show me the file before you install it — I want to read my first
job description.

Read it like an employer. The rubric order is your editorial taste becoming policy; adjust it. ("Style only if it changes meaning" is a gift to your future self — inspectors without that rule drown you in comma opinions.)

2. Install and make the first inspection

Install The Inspector as a subagent for this project. Then send it
[your real piece of work] — cold, per its job description. Show me
the report unedited.

Read the report next to what Lesson 1's generic helper gave you. Same fresh eyes — but now the findings arrive in your priority order, quoting lines, with a verdict you can act on. That difference is the role file working. Generic help finds things; a specialist finds things the way your kitchen needs them found.

3. Calibrate — the employer's loop

First reports always need calibration, and calibrating a specialist is wonderfully concrete — you edit the job description:

Two calibrations: [e.g. "verdicts are too timid — if two findings
are load-bearing, that's fix-first, not ship-with-notes" / "it
flagged our kitchen jargon as unclear — add: house terms in
CLAUDE.md are known-good"]. Update the role file, re-run the same
inspection, show me what changed.

Feel what you're doing: managing. Not prompting harder — refining a standing role that gets better every time it runs. This loop (report → calibrate the file → re-run) is the entire craft of running specialists, and it never stops being this simple.

4. Put it on the chart — and learn the hiring bar

Add The Inspector to STATIONS.md: its station, when to send work
there (anything shipping under my name: reports, handbooks,
lessons, decks), and the one-line rule for calling it.

And write the hiring bar into CLAUDE.md: a job becomes a ROLE
when it recurs, needs the same standards every time, and benefits
from cold eyes. Otherwise it stays a one-off order. One cook by
default — specialists must earn their station.

That hiring bar is the lesson's real deliverable. The failure mode ahead of you isn't too few specialists — it's a staff directory of clever roles that never get called. Recurring + standards + cold eyes, or it's not a hire.

When it burns

• The Inspector's output looks like the generic helper's — the role file may be platitudes ("be thorough") instead of process (rubric order, quote lines, verdict). Specialists are made of specifics; sharpen the file, not the summon.
• It started fixing things — job description violation, handle it like one: "Inspectors report; they never touch the dish. Re-read your role, re-issue findings only." If it recurs, make the never-fixes line the file's first sentence.
• You want it to inspect something mid-conversation, with context — then you don't want The Inspector; cold eyes are its whole value. Context-aware review is just… asking your main agent. Both are useful; don't blur the stations.
• Naming feels silly — the name is doing real work: "send it to The Inspector" is a one-line order that loads an entire calibrated process. Silly-sounding and load-bearing, like most good kitchen rituals. (You've been benefiting from this pattern all course — every skill you own is a named ritual.)
• You already have five role ideas — the hiring bar exists precisely for this energy. Write the ideas down, hire when one recurs. Lessons 5–7 add two more crew patterns; let real work fill the chart.

Order up

□ A job description you read and calibrated — rubric in YOUR order
□ The Inspector inspected real work, cold, verdict included
□ One calibration loop: edit the file, re-run, see the difference
□ STATIONS.md lists the hire; CLAUDE.md holds the hiring bar
□ Save point "the specialist"

Next up — Lesson 05: Parallel Plates. One specialist works while you wait. Next lesson three cooks work at once — real parallelism, its honest coordination costs, and the kinds of jobs where it actually pays.

Stuck on a step? Question box below.