Phase 3 · Claude
Claude prompt library
Why it matters
Once you know what Claude is good at, the fastest way to get value is to keep a set of proven prompts and adapt them, rather than starting from a blank box each time. These are copy-ready prompts for the workplace jobs Claude does best: working through long documents, writing carefully, analysing data, producing structured output, and helping you learn. Take one, swap in your own material, and iterate.
How to use this library
Every prompt below is a starting point, not a magic word. Copy one, replace the bracketed parts with your own material, and read the reply critically. A good prompt improves the writing and the structure, never the truthfulness, so you still check anything load-bearing before it goes anywhere. Keep to the Phase 0 privacy rules: no confidential or personal data in a personal account. Where you want to practise safely, run any of these against the Fernway sample files instead of live work.
Each card carries a short "why this works" note, because the point isn't to memorise the prompts, it's to see the pattern so you can write your own. The patterns repeat: name the role and audience, give the real material, state the format, and add a guardrail against invention.
Long documents
Claude can hold a lot of text at once, which makes it strong on long reports, contracts, threads and policies. The habit that keeps this reliable: ask pointed questions and make Claude quote the lines it relied on, rather than trusting a blanket summary.
Summarise the document below for a busy manager who won't read the original. Give me: (1) a three-sentence overview, (2) the five points that most affect a decision, and (3) anything that looks risky, unusual or unresolved. For each point, note the section or page it came from so I can verify it. Keep it to plain UK English. Document: [paste].
Why this works: Naming the reader, the length and the three things a decision-maker actually needs turns a wall of text into something usable, and asking for the page or section behind each point makes the summary checkable rather than something you have to take on faith.
In the document below, find whether it covers [the specific thing you need, e.g. a break clause, the core hours, the renewal terms]. Quote the exact lines that answer it and give the section they're in. If the document doesn't cover it, say so plainly rather than inferring an answer. Document: [paste].
Why this works: A pointed question plus 'quote the exact lines' is far more reliable than a vague 'does it mention…?', because for long files Claude may work from retrieved passages, so quoting forces it to show the evidence, and 'say so plainly if it's not there' stops a confident but empty answer.
Compare these two versions of the same document and list what changed. For each change give the old wording and the new wording, and flag any change that alters a meaning, an obligation, a figure or a deadline, as opposed to just wording or formatting. Put the meaning-changing ones first. Version A: [paste]. Version B: [paste].
Why this works: Asking for a change-by-change comparison with the old and new wording side by side surfaces exactly what moved, and flagging changes that alter meaning or obligations focuses your attention on the ones that matter rather than cosmetic edits.
Read the email thread below and list every commitment, decision or promise anyone made. Give me a table with columns: Who, What they committed to, By when (or 'not stated'), and which message it came from. Mark anything ambiguous as AMBIGUOUS rather than resolving it. Thread: [paste].
Why this works: Long email or chat threads bury who agreed to what; asking for a table of commitments with the person, the promise and the source message turns a scroll-back into a checkable list, and 'mark anything ambiguous' stops Claude inventing certainty the thread doesn't have.
Careful writing
Claude writes fluently, which is exactly why the guardrails matter: fluent isn't the same as accurate. These prompts get you a usable draft while keeping it anchored to what you actually gave it.
Draft [the email / note / paragraph] described below. Use only the facts I've given you; don't invent names, dates, figures or events I haven't provided. If something important is missing, leave a clearly marked [GAP] and list what you'd need from me. Audience: [who]. Tone: [e.g. warm but professional]. Length: about [N] words. Details: [paste].
Why this works: The 'don't invent any details I haven't given you' line is the single most useful guardrail in careful writing: it stops Claude filling gaps with plausible-sounding specifics, and asking it to flag what's missing turns those gaps into questions for you rather than fabrications.
Here's a short sample of the writing voice I want you to match: [paste 3 to 5 sentences]. Now write [the thing you need] in that same voice; same warmth, sentence length and level of formality. Briefly tell me the two or three features of the style you deliberately copied, so I can check the match. Content to write: [paste].
Why this works: Models copy patterns brilliantly, so pasting a short sample of the voice you want steers the output far more than describing it, and asking Claude to name what it noticed about the style makes the match repeatable and teaches you what actually carries a voice.
Tighten the draft below to about [N] words. Cut filler and repetition, keep every load-bearing fact and the main ask, and don't make it colder; keep the tone. Afterwards, list anything meaningful you removed so I can confirm I'm happy to lose it. Draft: [paste].
Why this works: Concrete instructions (a target length, a ban on filler, a rule to keep the key point) give Claude a describable target, and asking it to show what it cut lets you catch anything important that went out with the padding.
Help me write a careful reply to a difficult situation. The situation: [describe plainly, no confidential detail]. I want to [apologise sincerely / decline / push back] while staying [warm and professional]. Don't over-promise or admit to anything I haven't told you is true. Give me a draft of about [N] words, and a one-line note on the tone choices you made.
Why this works: A tricky message needs the real situation, the tone you want and the outcome you can offer; supplying all three (plus 'apologise without over-promising') gets a message you could actually send rather than a defensive template, while keeping you from committing to something you can't deliver.
Analysis
For anything with numbers, the rule from Level 2 holds: make sure Claude computes rather than eyeballs, and tell it how to handle messy data. For reasoning, push it to argue against itself.
Analyse the attached data and answer: [your questions, e.g. total and average sales by region, the three biggest month-on-month changes]. Use your analysis tool to compute the figures on the actual data rather than estimating. Before the numbers, tell me how you handled any blanks, duplicates, or text in number columns, and flag any rows you couldn't interpret. Show the key figures in a small table.
Why this works: Asking Claude to use its analysis tool means it writes and runs code on the actual data rather than estimating, and spelling out how to treat blanks, duplicates and stray text stops it deciding silently, the two things that separate a trustworthy number from a plausible one.
I need to choose between these options: [list them, with any constraints]. For each, give the main pros and cons in a short table. Then recommend one, in two sentences, and state the assumptions your recommendation depends on, so I can check whether I agree with them. Be honest if it's a close call.
Why this works: Structuring the reply as options with pros, cons and a single recommendation forces a decision rather than a shrug, and asking for the assumptions behind the recommendation lets you check whether you share them before you act on it.
Here's a plan or argument I'm fairly confident about: [paste]. Argue against it as strongly and fairly as you can; build the best case that I'm wrong, not an easy one to knock down. List the three objections most likely to actually matter, and for each, what evidence would tell me whether it's a real problem. Don't soften it to be polite.
Why this works: Asking Claude to build the strongest case against your plan (a steelman, not a straw man) surfaces the objections you'd rather not think about, and it's most valuable precisely because a fluent tool will otherwise happily agree with you.
Structured output
Half the value of AI at work is getting output in a shape you can use as-is. Name the exact structure and Claude does the reformatting you'd otherwise do by hand.
From the notes below, give me: (1) a three-sentence summary a manager could read at a glance, then (2) a table of every action with columns Action, Owner, Due date. Put the nearest due date first, and mark any action with no clear owner as UNASSIGNED. Add a short 'risks / watch items' list for anything raised that isn't yet an action. Notes: [paste].
Why this works: Splitting the ask into a short manager summary and a table of actions with owners and dates gives you output you can act on immediately, and marking unowned actions as UNASSIGNED turns a vague to-do into something you can chase.
Extract the following fields from the text below into a table, one row per [item]: [list your columns, e.g. Name, Company, Request, Date, Status]. If a field isn't present for a row, put 'not stated' rather than guessing. Don't add rows or fields I didn't ask for. Text: [paste].
Why this works: Defining the exact columns and a fallback value for missing data gives you consistent, table-shaped output every time, and the reliable structure is what lets you paste it straight into a sheet instead of tidying it by hand.
Turn these rough meeting notes into three sections: Decisions made (what was actually agreed), Actions (with owner and due date, or UNASSIGNED), and Risks / open questions (raised but not resolved). Don't turn a discussion point into a decision unless the notes say it was agreed. Keep it to plain UK English. Notes: [paste].
Why this works: Asking for three named sections (decisions, actions, risks) imposes a structure that catches the things rough notes usually lose, and keeping decisions separate from actions stops 'we agreed to think about it' being logged as a task.
Convert the text below into a clear, ordered checklist someone could follow without reading the original. Use short imperative steps. Where the text implies a step but doesn't state it plainly, add it and mark it [IMPLIED] so I can confirm. Don't invent steps that aren't supported by the text. Text: [paste].
Why this works: Converting instructions or a policy into a step-by-step checklist makes it something people can actually follow, and asking Claude to flag any step that's implied but not spelled out surfaces the gaps a reader would otherwise trip over.
Learning
Claude is a patient tutor for anything you want to understand: a concept, a tool, a bit of jargon. The trick is to make it teach, and check you, rather than just hand you an answer.
Explain [the concept or term] to me. I'm [your starting point, e.g. comfortable with spreadsheets but not technical]. Use plain UK English, one everyday analogy, and one concrete worked example. Then tell me the one thing people most commonly get wrong about it. Keep it under [N] words.
Why this works: Naming your starting level and asking for an everyday analogy plus one worked example gets an explanation pitched for you rather than a textbook, and asking what people commonly get wrong pre-empts the misunderstanding you were about to have.
I want to learn [topic] by being quizzed, not lectured. Ask me one question at a time, starting simple and getting harder based on how I answer. Wait for my answer before the next question. When I'm wrong or vague, correct me briefly and clearly, then continue. After about [N] questions, tell me what I've got solid and what to revise.
Why this works: Asking Claude to teach Socratically (one question at a time, waiting for your answer) makes you do the thinking rather than passively reading, which is what actually builds understanding, and correcting you gently as you go turns mistakes into the lesson.
Create a one-page reference I can keep on [topic]. Include: the handful of key terms with one-line plain-English definitions, the main steps or rules that matter in practice, and the three mistakes beginners make. Use short headings and plain UK English, no jargon without a definition. Flag anything that changes often and would need checking against an official source.
Why this works: Asking for a compact, structured reference (key terms, the steps that matter, common pitfalls) gives you something to keep and reuse, and requesting plain definitions over jargon makes it usable rather than a glossary that needs its own glossary.