# The Prompt Library (Book 3)

Copy-paste starting points for every stage of connecting and automating. Edit the **[bracketed]**
parts. Most end with "show me the plan first" or "don't set anything up until I say go" — keep that
habit; it's what keeps you in control. Your screen and Claude's exact wording may differ slightly
(this is 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.

Two rules run through all of these:
1. **Secrets never go in a prompt.** Keys and passwords belong in the connection's config. There's
   a dedicated prompt for that below — use it early.
2. **Read-only first, human gate on anything that acts.** Start where the worst case is smallest.

---

## CONNECT (read-only) — think it through, then make the first safe connection (Ch. 13–14)
Weigh value against blast radius, then connect so Claude can *see* but not change or send.

**Shape**
> I'm considering connecting Claude to **[the service]**. Before setting anything up, help me weigh
> it: what would this typically be able to *see* and *do*, how big is the blast radius if it went
> wrong, can I start **read-only**, and what should I watch given it may hold **[sensitive data, if
> any]**? Don't set anything up yet — just walk me through the trade-offs.

**Filled example**
> I'm considering connecting Claude to my shared documents folder so a report tool can read the
> current files. Before setting anything up, help me weigh it: what would this be able to see and
> do, how big is the blast radius if it went wrong, can I start read-only, and what should I watch
> given the folder has some client material? Don't set anything up yet — just walk me through the
> trade-offs. Then, if it looks sensible, help me connect it **read-only**, keep the access as
> narrow as the job needs, and read one file back so I can confirm it's working.

---

## KEEP SECRETS SAFE — tell Claude to never ask for a pasted secret (Ch. 13)
Use this once, early. It sets the rule for every connection that follows.

**Shape**
> Ground rule for all of our setup work: **any key, password, or credential must go in the
> connection's settings/config, never in our chat.** Never ask me to paste a secret, key, or
> password into a prompt or a message. If a setup step would need one, tell me *where in the config*
> it goes and let me put it there myself. Confirm you understand before we start.

**Filled example**
> Ground rule for all of our setup work: any key, password, or credential goes in the connection's
> config, never in our chat. Never ask me to paste a secret into a prompt. When we set up the
> documents connection, if it needs a key, point me to the exact place in the settings to put it —
> like the `env` section of the `.mcp.json` file — and I'll add it there myself. Confirm you
> understand, then we'll begin.

---

## BRING IN DATA — feed a tool from a live source (Ch. 15)
Pull live data into a tool you already built, and check what's leaving your computer.

**Shape**
> Use the **[connection]** to pull **[the specific data]** into **[my tool]** so it reflects the
> live source instead of a file I update by hand. Show me what you pulled **before** you change
> anything, and tell me **what data is now leaving my computer** so I can check nothing sensitive is
> going where it shouldn't.

**Filled example**
> Use the documents connection to pull the latest figures into my budget dashboard so it reflects
> the live source instead of `sample-data.csv` that I update by hand. Show me what you pulled before
> you change the dashboard, and tell me what data is now leaving my computer so I can check nothing
> sensitive is going out. Don't change the dashboard until I say go.

---

## MAKE A SKILL — save a routine as a re-runnable recipe (Ch. 16)
Turn something you repeat into a saved recipe you invoke by name. (See `sample-skill-recipe.md`.)

**Shape**
> I do this routine often: **[describe it, step by step]**. Turn it into a saved recipe I can re-run
> by name. Show me the recipe in plain English **before** you save it, and tell me exactly how I'll
> run it next time.

**Filled example**
> I do this every Monday: read the latest rows in `sample-data.csv`, summarize what changed since
> last week, and format it as a short bulleted update. Turn it into a saved recipe I can re-run by
> name. Show me the recipe in plain English before you save it, and tell me exactly how I'll run it
> next time.

---

## SCHEDULE (supervised) — set a routine to run on its own (Ch. 16)
Honest about the layers: some cloud, some on your computer, some event-driven. Start small.

**Shape**
> I'd like **[this recipe]** to run on a schedule: **[when]**. First tell me the ways I could
> schedule this and the trade-offs — I know there's no single one-click scheduler. Then set it up so
> it runs **supervised**, do a **dry run first** so I can see the result, and tell me where its log
> is and how I stop it if I need to.

**Filled example**
> I'd like my Monday summary recipe to run early each Monday. First tell me the ways I could schedule
> this and the trade-offs. Then set it up supervised, do a dry run now so I can see the result before
> it's live, and tell me where its log is and how I stop it. Keep it read-only for now — it should
> only *prepare* the summary, not send it anywhere.

---

## SEND-SAFELY (with a human gate) — an automation with an outward effect (Ch. 17)
Prepare by machine; act by hand. Send to yourself first.

**Shape**
> Build this as **prepare-and-send**: do **[the work]**, then **stop and show me the result and
> exactly where it would go**, and only send **after I approve**. For now, send it to **me** first so
> I can see exactly what would go out. Never send anything outward without my explicit go-ahead.

**Filled example**
> Build this as prepare-and-send: draft a short follow-up note for each row in `sample-data.csv`
> using that row's details, then stop and show me all the drafts and where each would go, and only
> send after I approve. For now, send them to me first (use example.com addresses in the practice
> file) so I can see exactly what would go out. Never send anything outward without my go-ahead.

---

## WORKFLOW — chain a few steps into a small pipeline (Ch. 18)
Keep it simple and supervised. Deep orchestration is Book 4.

**Shape**
> Chain these steps into one small workflow: **[step 1]** → **[step 2]** → **[step 3]** →
> **[step 4]**. Keep it simple and supervised — show me the result of **each step**, let me **stop
> the line** at any point, and don't send or change anything outward without my approval.

**Filled example**
> Chain these steps into one small workflow: pull the latest rows from the documents connection →
> summarize what changed → format it as a one-page update → hold it for my approval before anything
> is delivered. Keep it simple and supervised — show me the result of each step, let me stop the
> line at any point, and don't deliver anything without my go-ahead.

---

## DIAGNOSE / RECOVER — when a connection or automation misbehaves (Ch. 20)
Pause first, ask what changed, take the smallest safe next step.

**Shape**
> This automation is doing this: **[precise symptom]**. As far as I know, what changed since it last
> worked is **[the input / a setting / a connection / nothing I can think of]**. **First, pause it.**
> Then 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 setup back to the last save point instead.

**Filled example**
> My Monday summary ran twice this week and sent two updates. As far as I know, nothing changed that
> I can think of. First, pause it. Then check whether the schedule got set up in two places, explain
> what's going on in plain English, and propose a fix — but don't change anything until I say go.
> Once it's fixed, do one supervised run to confirm it fires once before we re-enable it.

---

## REVOKE — cut off a connection you no longer need (Ch. 13, 22)
Old connections are open doors. Close the ones you're done with.

**Shape**
> I want to **revoke** Claude's access to **[the service]** — I don't need that connection anymore
> (or I'm not comfortable with it). Walk me through removing it and signing it out, confirm it can no
> longer reach that service, and tell me if anything I built depended on it so I can adjust.

**Filled example**
> I want to revoke Claude's access to the documents folder I connected for a one-off report — I'm
> done with it. Walk me through removing the connection and signing it out, confirm it can no longer
> reach that folder, and tell me if any tool I built was relying on it so I can adjust before it
> breaks.

---

## Everyday habits
> Before you set up or change any connection or automation, show me the plan and wait for my
> go-ahead. Keep secrets in config — never ask me to paste one. Connect read-only first, grant the
> least access that works, and gate anything that acts on the world. When something's running on a
> schedule, tell me where the log is and how to stop it.