# The Prompt Library (Book 2)

Copy-paste starting points for every stage of building a tool. Edit the **[bracketed]** parts.
Most end with "show me your plan first" — keep that habit. Your screen and Claude's exact wording
may differ slightly; the shape is what matters. Each section has a **shape** you fill in and a
**filled example** using this book's sample files.

---

## SPEC a tool — describe it before building (Ch. 12)
Spec twice, build once. Say what the tool does as an outcome, then what goes in, what comes out,
the rules only you know, and how you'll know it works.

**Shape**
> I want to build a small tool. Here's the spec. **Goal:** [what it should do]. **Inputs:** [what
> I'll feed it]. **Outputs:** [what it should hand back]. **Rules:** [the standards that matter].
> **Done looks like:** [how I'll know it works]. Before you build anything, walk me through your
> plan in plain English and flag anything unclear. Don't create files until I say go.

**Filled example**
> I want to build a small tool. **Goal:** turn a client list plus a letter template into one
> finished letter per client. **Inputs:** `template.md` and `clients-sample.csv`. **Outputs:** one
> Markdown letter per row, saved in an `output/` folder, named by client. **Rules:** use the
> client's preferred name, keep my template's wording exactly, and skip any row missing an email.
> **Done looks like:** I open `output/` and see one correct letter per client. Walk me through your
> plan first and flag anything unclear. Don't create files until I say go.

---

## BUILD it — turn the spec into a rough first version (Ch. 13)
Aim for the simplest thing that works, not the polished one. Save a point before it starts.

**Shape**
> Build a first rough version of the tool from that spec — the simplest thing that could work, not
> the polished one. Make a save point first. Then show me what you built and how to run it, so I
> can try it before we refine.

**Filled example**
> Build a first rough version of the letter generator from that spec — simplest thing that works.
> Make a save point first. Then show me the folder you created and tell me, in one line, how to run
> it so I can try it on `clients-sample.csv` before we refine anything.

---

## TEST it — check it before you trust it (Ch. 15)
Three inputs every time: normal, messy edge case, deliberately bad. Read the output yourself.

**Shape**
> Let's test this tool. Run it on (1) a normal input, (2) a messy edge case [describe one], and
> (3) a deliberately bad input [describe one]. For each, show me what it did and whether the result
> looks right. Don't change the tool yet — I want to see where it holds and where it breaks.

**Filled example**
> Let's test the generator. Run it on (1) `clients-sample.csv` as-is, (2) a copy where one row has
> a blank email and one name has odd capitalization, and (3) a copy with the columns in a different
> order. For each, show me what it produced and whether it looks right. Don't change the tool yet —
> I want to see where it holds and where it breaks.

---

## Make a SAVE POINT — snapshot a version you trust (Ch. 16)
A save point is a labeled snapshot you can always return to. Make one before and after any change
that matters.

**Shape**
> This version works the way I want. Please make a save point labeled "[short description]" so I can
> always return to exactly this, and confirm what you saved.

**Filled example**
> This version of the generator works the way I want. Please make a save point labeled "generator:
> handles blank emails and any column order" so I can always return to exactly this. Confirm what
> you saved.

---

## Make it REUSABLE — inputs and configuration (Ch. 19)
Turn the details that change into inputs and settings, so the same tool does next month's job.

**Shape**
> Right now this tool has [detail] built in. Make [that detail] an input instead, so I can run the
> same tool on different [inputs] without rebuilding it. Keep everything else the same. Save a point
> first, then show me how to run it with a different input.

**Filled example**
> Right now the generator uses one fixed template. Make the template a setting instead, so I can
> point it at either a letter template or an invoice template without rebuilding it. Keep everything
> else the same. Save a point first, then show me how to run it against `template.md` and against a
> second template.

---

## MAINTAIN it — small upgrades and memory (Ch. 20)
Small, saved upgrades — never big rewrites. Keep a `CLAUDE.md` as the toolkit's living memory.

**Shape (write the memory)**
> Please write a `CLAUDE.md` for this toolkit that records: what each tool does, what inputs it
> expects, the rules I care about, and how to run each one. Keep it short and plain so any future
> session starts knowing my standards. Show it to me before you save it.

**Shape (make one upgrade)**
> I want one small upgrade: [describe it]. Save a point first, make just that change, and show me
> what's different so I can test it before we keep it.

**Filled example**
> One small upgrade to the tracker: when I ask for a summary, also show the total value of open
> projects. Save a point first, make just that change, and show me what's different so I can test it
> on `projects-sample.csv` before we keep it. Then update the `CLAUDE.md` to note the new summary.

---

## SHARE it — package a tool for someone else (Ch. 21)
Keep the tool, strip the data and secrets, explain with a five-line how-to. Still no server.

**Shape**
> I want to hand this tool to a colleague. Please make a shareable copy: strip out my real data and
> replace it with a small fake sample, remove anything private or secret, and write a five-line
> how-to that explains what it does and how to run it. Show me the packaged folder before I send it.

**Filled example**
> I want to hand the tracker to a colleague. Make a shareable copy: replace my real clients and
> projects with a small fake sample like `clients-sample.csv` and `projects-sample.csv`, remove any
> notes or files with private details, and write a five-line how-to. Show me the packaged folder
> before I send it — I want to check nothing real is left in it.

---

## FIX it — when a tool misbehaves (Ch. 22)
Ask "what changed?" before "how do I fix it?" Name the symptom precisely. Restore if needed.

**Shape**
> My tool is doing this: [precise symptom]. As far as I know, what changed since it last worked is
> [the input / a setting / nothing I can think of]. Please explain in plain English what's going on
> and propose a fix — but don't change anything until I say go.

**Filled example**
> The generator worked yesterday; today it stops with a wall of red text. What changed is that I
> dropped in a new clients file this morning. Please explain in plain English what's going on and
> propose a fix — but don't change anything until I say go. If it's simpler, take the tool back to
> the last save point and we'll retry.

---

## Everyday habits
> Before you make any changes, always show me your plan and wait for my go-ahead.
> Keep it simple and explain what you're doing as you go, as if I'm new to this.
> Whenever a change matters, make a save point first — and tell me what you labeled it.