# The Prompt Library (Book 4)

Copy-paste starting points for every stage of designing and running a system. Edit the **[bracketed]**
parts. Most end with "show me the plan first" or "don't build/run anything until I say go" — keep that
habit; it's what keeps you the architect. Your screen and Claude's exact wording may differ (subagents
and orchestration are the fastest-changing corner of the software); the **shape** is what matters. Each
section has a **shape** you fill in and a **filled example** using this pack's practice files.

Three rules run through all of these:
1. **Decompose before you delegate.** Name each part's job, inputs, output, and handoff before anything
   is built. The plan is the work.
2. **Least privilege, per specialist.** Give each specialist the smallest set of tools it needs —
   read-only where you can. There's a dedicated prompt for that below.
3. **Verify before you trust; keep a human at the risky joints.** Nothing acts on the world without a
   checkpoint, and nothing is "done" until it's been checked.

---

## DECOMPOSE — break a big goal into delegable parts (Ch. 13)
The core architect skill. Turn one goal too big for a single tool into a short plan of specialists.

**Shape**
> Here's a goal that feels too big for one tool: **[describe the goal]**. Before we build anything, help
> me break it into a few parts I could hand to specialists. For each part, name its **job**, what it
> needs as **input**, what it **produces**, and how it **hands off** to the next. Keep it the smallest
> number of parts that does the job — don't over-build. Show me the plan first; don't build yet.

**Filled example**
> Here's a goal that feels too big for one tool: turn my raw account list in `sample-data.csv` into a
> reviewed weekly account brief. Before we build anything, help me break it into a few parts I could
> hand to specialists — for each, name its job, its input, what it produces, and the handoff to the
> next. Keep it to the fewest parts that do the job. Show me the plan first; don't build anything yet.

---

## DELEGATE — hand one slice to a built-in specialist (Ch. 12)
A subagent works in its own context and reports a summary back, keeping its detailed work out of your
main view. It runs in the background — start it, keep working, results come back.

**Shape**
> Delegate this one part to a specialist: **[the part]**. Have it work on its own and report a **summary**
> back, so its detailed work stays out of our main view. Show me what it reports **before** we use the
> result downstream.

**Filled example**
> Delegate this one part to a specialist: read every row in `sample-data.csv` and pull out the accounts
> whose next step is overdue. Have it work on its own and report a summary back. Show me what it reports
> before we use the result for anything downstream.

---

## MAKE A SPECIALIST — create a reusable custom subagent by describing it (Ch. 15)
You don't write the definition — you *describe* the specialist and Claude writes it. Keep its tools
minimal. (See `sample-specialist-definition-EXAMPLE.md` for the *shape* of what Claude produces.)

**Shape**
> Create a reusable specialist for me by describing it back to me first: a **"[role]"** that does this
> specific job: **[the job]**. Give it the **smallest set of tools** it needs — read-only where possible
> — and keep its scope narrow. Show me the definition in plain English, and exactly what it's allowed to
> do, **before** you save it. Tell me how I'll call on it next time.

**Filled example**
> Create a reusable specialist for me by describing it back to me first: an "account-summarizer" that
> reads a folder of account notes and drafts a one-page plain-English summary. Give it the smallest set
> of tools it needs — reading files only, no sending or editing — and keep its scope narrow. Show me the
> definition and exactly what it's allowed to do before you save it, and tell me how I'll call on it next
> time.

---

## SCOPE READ-ONLY — lock a specialist to least-privilege tools (Ch. 15, 19)
Use this whenever a specialist only needs to *look*, not change or send. The scope you grant is the
blast radius you accept.

**Shape**
> When you define **[this specialist]**, scope it to **least privilege**: give it only the tools it
> genuinely needs, and make it **read-only** — it can read and analyze, but it cannot edit files, run
> commands, send, or reach the network. List for me exactly which tools it will and won't have, and
> confirm it can't act on the world before you save it.

**Filled example**
> When you define the account-summarizer, scope it to least privilege: give it only file-reading tools,
> and make it read-only — it can read and analyze the notes, but it cannot edit files, run commands,
> send anything, or reach the network. List exactly which tools it will and won't have, and confirm it
> can't act on the world before you save it.

---

## COORDINATE — chain specialists into a supervised pipeline (Ch. 16)
Sequential (each feeds the next) or parallel (several at once, then combined). Parallel is faster but
costs more. Package a system you'll re-run as a Skill.

**Shape**
> Coordinate these parts into one supervised pipeline: **[part 1]** → **[part 2]** → **[part 3]** →
> **[part 4]**. Keep the handoffs clean, run it in order, and **show me the result at each stage** so I
> can review. Don't send or change anything outward without my approval. If you'd suggest running any
> steps **in parallel**, tell me the trade-off (speed vs cost) first. Once it works, help me save it as a
> re-runnable Skill.

**Filled example**
> Coordinate these parts into one supervised pipeline: read `sample-data.csv` → flag the overdue accounts
> → draft a short status note for each → collect them into a one-page brief. Keep the handoffs clean, run
> it in order, and show me the result at each stage. Don't send anything anywhere. If any step could run
> in parallel, tell me the speed-vs-cost trade-off first. Once it works, help me save it as a re-runnable
> Skill I can invoke by name.

---

## VERIFY — add a checking specialist before you trust the output (Ch. 17)
Nothing checks the output automatically. Build a separate specialist that cross-checks the work.

**Shape**
> Add a **verification step**: after the pipeline produces its result, have a **separate specialist**
> cross-check it against **[the source / the requirements]** and flag anything wrong or missing **before
> I see it as finished**. Don't let unverified work be treated as done. Show me what the verifier
> checked and what it found.

**Filled example**
> Add a verification step: after the brief is drafted, have a separate specialist cross-check every
> account's details against the original rows in `sample-data.csv` and flag anything that doesn't match
> or is missing before I see the brief as finished. Don't treat the brief as done until it's been
> checked. Show me what the verifier checked and what it flagged.

---

## OBSERVE — read what a run actually did (Ch. 18)
You can't manage what you can't see. Review each specialist's work and cost.

**Shape**
> Walk me through the run we just did: **what each specialist did, in what order, and what each one
> cost**. Point out anything that went off the plan or cost more than I'd expect. Use `/usage` and
> `/workflows` and the agent view to show me, and tell me where the saved transcript is.

**Filled example**
> Walk me through the run we just did on the account brief: what each specialist did, in what order, and
> what each one cost. Point out anything that went off the plan or cost more than I'd expect — I want to
> know if any stage is heavier than it needs to be before I run this on the real list.

---

## GUARD — put system-wide limits in place (Ch. 19)
Least privilege per specialist, a human checkpoint before anything acts, a cost ceiling, and one clear
kill switch.

**Shape**
> Help me guard this system: give **each specialist the least access** its job needs, put a **human
> checkpoint** before anything acts on the world, set a **cost ceiling** for the whole system, and make
> sure I have **one clear way to stop everything fast**. Show me each guardrail so I can confirm it's in
> place before I run this on anything real.

**Filled example**
> Help me guard the account-brief system: keep the reading specialists read-only, put a checkpoint before
> any note would ever be sent, set a monthly cost ceiling for the whole system, and tell me the one way I
> stop everything fast. Show me each guardrail so I can confirm it before I point this at my real
> accounts.

---

## DIAGNOSE / RECOVER — when a system misbehaves (Ch. 20)
Pause first, find which stage, take the smallest safe next step.

**Shape**
> This system is doing this: **[precise symptom]**, and I think it started after **[the change, or
> "nothing I can think of"]**. **First, pause it.** Then tell me **which stage** the problem is in,
> explain in plain English what's going on, and propose a fix — but don't change anything until I say go.
> If a fix looks tangled, take the system back to my last save point instead.

**Filled example**
> The account-brief system is including accounts that aren't actually overdue. I think it started after I
> widened the flagging step. First, pause it. Then tell me which stage the problem is in, explain in
> plain English what's going on, and propose a fix — but don't change anything until I say go. If it gets
> tangled, restore the system to my last save point and we'll try again.

---

## Everyday habits
> Before you build, change, or run any part of a system, show me the plan and wait for my go-ahead.
> Decompose before you delegate. Give every specialist the least access it needs — read-only where you
> can. Add a verification stage before I trust any output, and keep a checkpoint before anything acts on
> the world. When a run finishes, tell me what each specialist did and what it cost — and always keep the
> system the smallest one that does the job.