# The Prompt Library *Tech Stack → Playbook. Copy, paste, replace the bracketed parts, go.* Every prompt below is copy-ready. The square-bracketed placeholders — `[YOUR TEXT]`, `[PASTE CODE]` — are the only parts you edit. Each entry tells you what the prompt actually does and gives one pro variation for when the basic version stops being enough. These work in any capable chat model — Claude `[AFFILIATE]`, ChatGPT `[AFFILIATE]`, Gemini `[AFFILIATE]`, or a local model via Ollama. The stronger the model, the more the multi-step prompts pay off. --- ## 1. Writing & Editing ### 1.1 Rewrite for clarity ``` Rewrite the following text so a busy reader gets the point in one pass. Rules: - Keep every fact and claim. Change nothing substantive. - Cut filler words, hedges, and throat-clearing. - One idea per sentence. Short sentences preferred. - Put the main point in the first sentence. - Target length: [60-80]% of the original. After the rewrite, list the three biggest changes you made and why. TEXT: [PASTE YOUR TEXT] ``` **What it does:** Forces a tightening pass instead of a paraphrase. The "keep every fact" rule stops the model from quietly dropping content, and the change log lets you audit what it did instead of re-reading everything. **Pro variation:** Add `"Preserve my voice — do not make it sound corporate. Flag any sentence where you were unsure whether something was filler or intentional style."` This is the difference between an editor and a sander. ### 1.2 Tone shift ``` Rewrite this text in a different tone. Same facts, same structure, different register. Current tone: [e.g., casual Slack message] Target tone: [e.g., formal note to a board member] Audience: [who reads this and what they care about] Keep: [anything that must survive verbatim — names, numbers, a specific phrase] Give me two versions: one conservative shift, one full shift. Label them. TEXT: [PASTE YOUR TEXT] ``` **What it does:** Tone requests fail when the model has to guess how far to go. Asking for two calibrated versions turns a guessing game into a choice. **Pro variation:** Paste a sample of the target voice: `"Here is an example of the tone I want: [PASTE SAMPLE]. Match its sentence length, formality, and directness."` Models imitate examples far better than they follow adjectives. ### 1.3 Executive summary ``` Write an executive summary of the document below. Format: - One-sentence bottom line at the top, bolded. - 3-5 bullet points: key findings or decisions, each with the supporting number or fact. - One "what happens next" line. - Maximum 150 words total. Rules: - No adjectives that aren't in the source. - If the document recommends something, the summary must say so explicitly. - If a number matters, include the number, not "significant growth." DOCUMENT: [PASTE DOCUMENT] ``` **What it does:** The word cap and the "numbers, not adjectives" rule produce a summary someone can act on, rather than a shorter version of the fog. **Pro variation:** Add `"Then write a second summary for a different audience: [e.g., the engineering team]. Same facts, different emphasis."` One document, two summaries, two audiences — this is where the tool starts saving real time. ### 1.4 Critique-then-improve ``` You will improve this text in two separate passes. Do not skip pass one. PASS 1 — CRITIQUE ONLY: Read the text as a skeptical, intelligent reader. List: - The 3 weakest arguments or passages, quoted, with why they fail. - Any claim that needs evidence it doesn't have. - Where a reader would stop reading, and why. PASS 2 — REWRITE: Rewrite the text fixing exactly the problems from Pass 1. Nothing else changes. TEXT: [PASTE YOUR TEXT] ``` **What it does:** Asking a model to "improve this" gets you cosmetic edits. Forcing a written critique first makes the rewrite address actual weaknesses, and gives you a review you can disagree with before anything changes. **Pro variation:** Run Pass 1 only, disagree with half of it in a follow-up message, then ask for the rewrite. The critique-negotiate-rewrite loop is how professionals use these tools; the one-shot version is the training wheels. ### 1.5 First draft from a mess ``` Below are my raw notes. Turn them into a first draft. Output: [format — memo / blog post / proposal / speech] Audience: [who] Length: [roughly how long] The point I'm trying to make: [one sentence — if you can't write this, that's the real problem] Rules: - Use only what's in the notes. Where the draft needs something the notes don't have, insert [NEEDED: description] instead of inventing it. - Order for the reader's logic, not the order of my notes. NOTES: [PASTE RAW NOTES] ``` **What it does:** The `[NEEDED: ...]` rule is the whole trick. It converts hallucination — the failure mode of every "write this for me" prompt — into a visible to-do list. **Pro variation:** Before the draft, add: `"First, list three different ways this could be structured, one line each. Wait for me to pick one."` Structure is the highest-leverage decision in any document; don't let the model make it silently. --- ## 2. Coding ### 2.1 Explain this codebase ``` I'm new to this codebase. Explain it to me in layers. Layer 1: What does this code do, in one paragraph a non-engineer could follow? Layer 2: Walk through the architecture — main components, how data flows between them, and where execution starts. Layer 3: The three things most likely to confuse a new developer here, and the one file I should read first. Do not summarize file-by-file. Explain how it works as a system. CODE: [PASTE CODE OR FILE LISTING] ``` **What it does:** File-by-file summaries are what you get by default, and they're nearly useless. The layered structure forces a system-level explanation, and "what will confuse me" surfaces the tribal knowledge. **Pro variation:** In an agentic tool like Claude Code `[AFFILIATE]` or Cursor `[AFFILIATE]` that can read files itself, replace the paste with: `"Explore this repository, then give me the three layers. Cite specific file paths for every claim."` The citations keep the tour honest. ### 2.2 Refactor with constraints ``` Refactor the code below. Goal: [e.g., extract the validation logic so it can be tested in isolation] Hard constraints — violating any of these means the refactor failed: 1. The public interface does not change. Callers compile without edits. 2. Behavior is identical, including error cases and edge cases. 3. No new dependencies. 4. [Your own constraint, e.g., "stay under 50 lines per function"] Output: - The refactored code. - A list of every behavioral risk you noticed — places where you had to make a judgment call about what the original code intended. CODE: [PASTE CODE] ``` **What it does:** Unconstrained refactoring requests get you a rewrite in the model's preferred style, which is a diff nobody asked for. Hard constraints keep the blast radius small; the risk list tells you where to look during review. **Pro variation:** Add `"Do it in the smallest possible steps. Show each step as a separate diff I could commit independently."` Reviewable steps beat one heroic diff, for AI exactly as for humans. ### 2.3 Write the tests first ``` I'm about to implement this. Write the tests BEFORE any implementation exists. What I'm building: [describe the function/module and its contract] Test framework: [pytest / jest / go test / etc.] Requirements: - Cover the happy path, each documented error case, and the edge cases YOU think I haven't considered — label those clearly. - Each test name states the behavior it proves, not the method it calls. - Tests must fail meaningfully against an empty implementation. - After the tests, list any ambiguity in my spec that the tests forced you to resolve, and how you resolved it. ``` **What it does:** Writing tests first exposes vague specs before code exists. The final instruction is the valuable part — the ambiguity list is your spec review, done by the entity that just tried to pin your spec down. **Pro variation:** Follow with: `"Now implement the minimum code that passes these tests. Do not add anything the tests don't demand."` You have just made a language model do disciplined TDD, which is more than most of us manage unsupervised. ### 2.4 Debug systematically ``` Help me debug this. Do NOT guess at a fix yet. Symptom: [what happens] Expected: [what should happen] When it started: [if known — what changed around then] What I've tried: [attempts and results] Step 1: List the 4-5 most plausible root causes, ranked by likelihood, each with a one-line reason. Step 2: For the top 2, give me a specific check to run — a command, a log to look at, a print statement to add — that would confirm or eliminate it. Step 3: Stop. Wait for my results before proposing any fix. CODE / ERROR: [PASTE RELEVANT CODE AND FULL ERROR OUTPUT] ``` **What it does:** The default failure mode of AI debugging is a confident fix for the wrong cause. This prompt forces differential diagnosis — hypotheses, then evidence, then treatment — and the hard stop keeps the model from sprinting past the actual bug. **Pro variation:** When you report results back, add: `"Update your ranking based on this evidence. Say explicitly which hypotheses are now dead."` Making the model track eliminated causes stops it from circling back to them, which is otherwise a genuine and maddening failure mode. ### 2.5 Code review ``` Review this code as a senior engineer who has to maintain it after I leave. Order findings by severity: 1. Bugs — things that are wrong now, with the failing input if you can construct one. 2. Traps — things that will break under load, concurrency, bad input, or the next person's edit. 3. Design — structural choices that make change expensive. 4. Nits — style. One line each, no lectures. Rules: - Quote the exact line for every finding. - If something is good, say so once at the end, briefly. - If you're unsure whether something is a bug, say "unsure" — do not bluff. CODE: [PASTE CODE OR DIFF] ``` **What it does:** Severity ordering stops the review from leading with formatting nits. The "unsure" rule is important: models bluff confidence by default, and giving explicit permission to hedge produces measurably more honest reviews. **Pro variation:** Run the same diff past two different models and diff the reviews. Where they agree, act. Where they disagree, that's exactly where a human should look. This costs two prompts and routinely catches what one reviewer misses. --- ## 3. Analysis & Research ### 3.1 Steelman both sides ``` Question: [STATE THE DECISION OR CONTROVERSY] Argue both sides at full strength. Round 1: The strongest honest case FOR. Best evidence, best logic — as made by its smartest advocate, not a strawman. Round 2: The strongest honest case AGAINST, same standard. Round 3: The crux — the smallest set of factual questions that, if answered, would settle this. For each: what evidence exists, and what's still unknown. Do not tell me which side you find more convincing unless I ask. ``` **What it does:** Models default to balanced-sounding mush or to whichever side your phrasing leaned toward. Structured steelmanning gets you the real shape of a disagreement, and Round 3 — the cruxes — is usually worth more than both arguments. **Pro variation:** Add Round 4: `"What would each side predict happens in the next 12 months? Give me predictions that differ, so time can referee."` If both sides predict the same observable future, the dispute is about words, not facts — also worth knowing. ### 3.2 Extract structured data ``` Extract structured data from the text below. Schema — one JSON object per record: { "name": string, "date": "YYYY-MM-DD or null", "amount": number or null, "category": one of ["A", "B", "C"], "source_quote": "the exact text this record came from" } Rules: - Output a JSON array only. No commentary, no markdown fences. - Missing field → null. Never invent a value. - Ambiguous record → include it, set "category" to "UNCLEAR", and put your reasoning in "source_quote". TEXT: [PASTE UNSTRUCTURED TEXT] ``` **What it does:** Turns emails, PDFs-turned-text, and meeting transcripts into data you can actually load into a spreadsheet or script. The `source_quote` field is your audit trail — every extracted value points back to the text that produced it. **Pro variation:** For batches, do a two-pass run: extract, then in a fresh conversation paste the JSON and the source and ask the model to `"verify each record against the source and flag mismatches."` Extraction and verification in one pass lets errors grade their own homework. ### 3.3 Compare options with a decision matrix ``` Help me choose between: [OPTION A], [OPTION B], [OPTION C] Context: [what this is for, constraints, budget, timeline] What matters to me, in order: [e.g., 1. reliability 2. cost 3. speed of setup] Build a decision matrix: - Rows: my criteria plus any criterion you think I've wrongly ignored (flag yours). - Score each option 1-5 per criterion, with a one-line justification per cell. No score without a reason. - Weight by my priority order and show the weighted totals. Then, separately: what's the strongest argument that the losing option is actually the right choice? What would have to be true for the winner to be a mistake? ``` **What it does:** The matrix disciplines the comparison; the last paragraph is the safeguard. A clean weighted total feels authoritative, and the "what would make this wrong" question is what keeps it from becoming a rationalization engine. **Pro variation:** Add: `"Mark every cell where your score is based on general knowledge rather than something I told you, with a ⚠. Those are the cells I need to verify."` Models fill matrices confidently from stale or generic knowledge; make the confidence visible. ### 3.4 Literature summary with flagged citations ``` Summarize what is known about: [TOPIC] Structure: 1. Consensus — what most credible sources agree on. 2. Contested — where credible sources disagree, and the actual axis of disagreement. 3. Unknown — what nobody has good data on yet. Citation rules — these are strict: - Attach a source to every substantive claim. - Rate each source reference: [SOLID] you're confident it exists and says this; [CHECK] it likely exists but verify before citing; [PATTERN] this reflects your general knowledge, no specific source. - Never present a [PATTERN] claim in the voice of a cited fact. ``` **What it does:** The three-tier flag is the honest version of AI-assisted research. Models fabricate plausible citations under pressure to cite `[VERIFY — well-documented failure mode, worth an anchor link to a source]`; this prompt gives fabrication nowhere to hide by making "I don't have a source" a legal answer. **Pro variation:** In a tool with real web search (Claude or ChatGPT with search enabled, or Perplexity `[AFFILIATE]`), follow with: `"Now verify every [CHECK] item with a live search and upgrade or kill each one."` Generation and verification as separate steps, always. ### 3.5 Assumption audit ``` Here is a plan/analysis/forecast. Do not evaluate its conclusion. Instead, surface its assumptions. List every assumption it rests on — stated or unstated — sorted into: 1. LOAD-BEARING: if this is wrong, the conclusion collapses. 2. SENSITIVE: if this is wrong, the numbers move materially. 3. COSMETIC: wrong doesn't matter much. For each load-bearing assumption: how would I actually check it, and what's the cheapest test? TEXT: [PASTE THE PLAN OR ANALYSIS] ``` **What it does:** Most bad plans fail at an unstated assumption, not in the visible reasoning. This inverts the review: instead of arguing with the conclusion, you get a ranked list of the places the ground could give way. **Pro variation:** Run it on your own work before someone else does. Then: `"Write the one-paragraph memo I'd be embarrassed to receive from a critic who found the weakest assumption."` Cheap immunization. --- ## 4. Business ### 4.1 Meeting notes → actions ``` Turn these meeting notes into a follow-up record. Output three sections: ACTIONS — table: task | owner | deadline | source line from the notes. If owner or deadline is missing, write "UNASSIGNED" or "NO DATE" — do not guess. DECISIONS — what was actually decided, one line each, with who decided. A decision someone merely proposed is not a decision; leave it out. OPEN QUESTIONS — raised but not resolved. Then flag: any action with no owner, any decision that reverses a previous decision in these notes, and anything discussed for a long time that produced no action or decision. NOTES: [PASTE MEETING NOTES OR TRANSCRIPT] ``` **What it does:** The proposed-vs-decided distinction and the UNASSIGNED flags are what separate this from a summary. The final flags surface the meeting's real dysfunction: ownerless work and expensive conversations that produced nothing. **Pro variation:** If you have transcripts (from Zoom, Granola `[AFFILIATE]`, or Otter `[AFFILIATE]`), run the same prompt on the last four meetings of a recurring series and add: `"Which actions from earlier meetings appear again later, unfinished?"` Recurring-meeting archaeology; results are often uncomfortable. ### 4.2 Email drafts by scenario ``` Draft this email. Scenario: [e.g., declining a vendor renewal / chasing an overdue deliverable a second time / delivering mixed results to a client] To: [role and what they care about] Relationship: [warm / neutral / strained] What I need to happen: [the single action or understanding this email exists for] Constraints: [anything that must or must not be said] Rules: - Subject line that states the point, not "Following up." - The ask appears in the first three lines and once more at the end. - Length: as short as the scenario allows. - No "I hope this email finds you well." Give me two versions: direct, and diplomatic. Label them. ``` **What it does:** "What I need to happen" is the field that fixes AI email drafts — without a defined outcome you get well-formatted words with no vector. Two calibrated versions beat one guess at your preferred register. **Pro variation:** For a genuinely delicate email, add: `"Before drafting, tell me the three ways this email could be misread by someone having a bad day, and draft to survive all three."` ### 4.3 Project plan generator ``` Build a first-draft project plan. Project: [what's being delivered] Deadline: [date] · Team: [people/roles available] · Budget/constraints: [limits] Definition of done: [the sentence that will be true when this is finished] Output: 1. Phases with rough durations — and mark the critical path. 2. Per phase: deliverables, owner role, entry/exit criteria. 3. Dependencies — what blocks what, explicitly. 4. Top 5 risks: trigger, impact, cheapest mitigation. 5. Ask me the 5 questions whose answers would most change this plan. Do not pad. If the deadline looks unrealistic for the scope, say so in the first line, before the plan. ``` **What it does:** A usable straw-man plan in one prompt. The "say so first" rule matters: models will politely build you a beautiful plan for an impossible deadline unless told that honesty outranks compliance. Question 5 turns the draft into a dialogue instead of a fait accompli. **Pro variation:** Feed the draft back a week later with reality: `"Here's the plan and here's what actually happened in week one. Replan the remainder and tell me what week one implies about the original estimates."` ### 4.4 Risk pre-mortem ``` Run a pre-mortem. The plan: [PASTE OR DESCRIBE THE PLAN] It is [6 months] from now. The project failed — visibly, embarrassingly. Write the honest internal post-mortem of that failure: 1. The headline account of what went wrong. 2. The 3 root causes, and for each: the early warning sign that was visible at the START — i.e., visible today — and ignored. 3. The uncomfortable thing everyone on the team already suspects but hasn't said. Then break character and give me: the 3 cheapest actions to take this week that most reduce the probability of this exact post-mortem being written. ``` **What it does:** Asking "what are the risks?" gets a generic list. Narrating the failure retrospectively — a technique with real research behind it `[VERIFY — Gary Klein's pre-mortem method; cite properly]` — produces specific, plausible failure paths, and item 3 gives the model social permission to say the impolite thing. **Pro variation:** Run it twice with different failure modes: `"once where we failed by moving too slowly, once where we failed by moving too fast."` The two post-mortems bracket your real risk landscape. ### 4.5 Proposal / one-pager compressor ``` Turn this into a one-page decision document for [DECISION MAKER / ROLE]. Fixed structure: - THE ASK: one sentence. What you want them to approve. - WHY NOW: 2-3 lines. Cost of waiting. - THE PLAN: 4-6 bullets, each with a number (time, money, or headcount). - RISKS: the 2 real ones, with mitigation. Not the cosmetic ones. - WHAT APPROVAL COSTS THEM: money, people, political capital. Be exact. Hard cap: 350 words. If material won't fit, list what you cut at the bottom so I can veto the cuts. SOURCE MATERIAL: [PASTE THE LONG VERSION] ``` **What it does:** Executives decide from one-pagers; teams write ten-pagers. This does the compression with an explicit ask, real costs, and — critically — a visible list of what got cut, so the compression is reviewable instead of silent. **Pro variation:** Add: `"Then write the three questions [DECISION MAKER] is most likely to ask after reading it, with the answers. I'll bring those to the meeting."` --- ## 5. Learning ### 5.1 Feynman explainer ``` Explain [TOPIC] using the Feynman technique. Round 1: Explain it as if I'm a smart 12-year-old. Everyday analogies only, no jargon. Round 2: Same explanation, one level up — introduce the 5 most important technical terms, each defined in one plain sentence at first use. Round 3: Tell me where Round 1's analogies break down — what they get subtly wrong that would confuse me later. Round 3 is mandatory. Every analogy lies a little; I want to know how mine lie. ``` **What it does:** Rounds 1 and 2 are standard tiered explanation. Round 3 is the upgrade: analogy-driven learning fails precisely where the analogy stops matching reality, and almost nobody asks where that is. **Pro variation:** Reverse it: `"I'll explain [TOPIC] back to you in my own words. Grade my explanation — what did I get wrong, what did I leave out, and what did I say correctly but for the wrong reason?"` Explaining back is the actual Feynman technique; the prompt above is just the warm-up. ### 5.2 Quiz me with escalating difficulty ``` Quiz me on [TOPIC]. Run it like this: - One question at a time. Wait for my answer before continuing. Never dump a full quiz. - Start at level 1 (recall). Two consecutive right answers → move up a level: 2 = application, 3 = analysis, 4 = edge cases and "it depends" territory. - A wrong answer: tell me what's wrong with MY answer specifically — not just the correct answer — then re-ask the same concept differently later. - Every 5 questions: one-line status. Level, what's solid, what's shaky. Stop after [15] questions with a summary: what to review, and the three questions I should get right next week to prove it stuck. ``` **What it does:** Retrieval practice with adaptive difficulty — the study method with the strongest evidence base `[VERIFY — testing-effect literature; link a real citation]` — in a chat window. The wait-for-my-answer rule is essential; without it every model dumps twenty questions and the exercise dies. **Pro variation:** Paste your own materials first: `"Quiz me only on the document below. If I've missed something the document emphasizes, weight your questions toward it."` Now it's an exam for the meeting, the cert, or the codebase you're about to touch. ### 5.3 Learning-path builder ``` Build me a learning path. Goal: [what I want to be able to DO — a verb, not a vibe] Current level: [honest description of where I am] Time: [hours per week] for [duration] How I learn best: [building things / reading / video / mix] Output: 1. Milestones — each one a thing I can DO, checkable by me, not "understand X." 2. Per milestone: the ONE primary resource (not a list of ten), the exercise that proves it, and the trap most learners hit at this stage. 3. What to deliberately skip at my level, and when it becomes worth learning. 4. The milestone where most people quit, and what to do the week I hit it. No "it depends." Pick things. I'd rather revise a real plan than navigate a hedge. ``` **What it does:** "One primary resource" and "checkable milestones" fight the two curriculum failure modes: resource overload and vague progress. Item 3 — permission to skip — is where an adapted plan beats a generic syllabus. **Pro variation:** Return every two weeks with the same conversation: `"Milestone 2 done, here's what was harder than expected. Revise the path."` A learning path that never updates is a syllabus. One that updates is a tutor. ### 5.4 Concept X-ray ``` I keep almost-understanding [CONCEPT]. X-ray it for me. 1. The one-sentence core — what this concept is REALLY about under the notation. 2. The prerequisite chain: what 2-3 ideas must be solid first? For each, a one-line self-test so I can check whether mine actually are. 3. The standard misconception — the wrong version most learners carry, and the example that breaks it. 4. Three worked examples: trivial, typical, and one where naive application gives the wrong answer. I suspect my gap is at the prerequisites. Check there first. ``` **What it does:** "Almost understanding" is nearly always a prerequisite gap, not a difficulty gap. The self-tests in step 2 locate the actual hole instead of re-explaining the top layer for the fifth time. **Pro variation:** After the X-ray: `"Now give me the example from step 4c as a problem WITHOUT the solution. I'll attempt it; diagnose my attempt."` Diagnosis of a real attempt beats explanation, every time. --- ## 6. Meta-Prompts ### 6.1 Prompt improver ``` Improve this prompt before I run it. MY DRAFT PROMPT: [PASTE YOUR PROMPT] What I actually want out of it: [describe the ideal output] Do: 1. Diagnose — where is it ambiguous, underspecified, or asking two things at once? 2. Rewrite it. Add explicit output format, constraints, and quality bar. Keep my intent. 3. List what you had to ASSUME about my intent — each assumption is a question I should answer to make the prompt better still. Do not run the improved prompt. Just hand it to me. ``` **What it does:** The cheapest upgrade in this library: spend one prompt improving a prompt you'll use fifty times. Step 3 matters most — the model's assumptions reveal exactly what your draft failed to say. **Pro variation:** Ask for calibrated variants: `"Give me a strict version (locked format, for repeated automated use) and a loose version (room for the model to surprise me, for exploration)."` Different jobs need different tightness, and knowing which you need is most of prompt literacy. ### 6.2 Custom-instructions builder ``` Interview me, then write my custom instructions / system prompt. Ask me, in batches of 3-4 questions: - What I do and what I use AI for most. - Output preferences: length, format, code style, language. - Pet peeves: what AI responses do that wastes my time. - What I want it to push back on vs. just execute. - Expertise level per domain, so it can stop over-explaining. After the interview, write the instructions: - Under 250 words. Every line earns its place. - Behavior rules, not identity fluff. "Lead with the answer" beats "You are a helpful expert." - Ordered by how often each rule matters. ``` **What it does:** Produces the block you paste into ChatGPT custom instructions, Claude Projects/styles, or a CLAUDE.md `[AFFILIATE — links to Claude and ChatGPT setup]`. The interview format extracts preferences you didn't know you had; the 250-word cap forces rules over decoration. **Pro variation:** After a week of use: `"Here are three responses that annoyed me this week [PASTE]. Update my instructions to prevent each, without breaking anything else."` Custom instructions are a living document; most people write them once and wonder why they stop working. ### 6.3 Persona designer ``` Design a reusable persona for [JOB — e.g., reviewing my landing-page copy]. Define: 1. Role and seniority — specific enough to constrain behavior. "VP of Sales who has seen 1,000 landing pages and buys nothing easily," not "marketing expert." 2. What they systematically notice, in priority order. What they don't care about. 3. Their bar: what makes them say "good," and how rarely they say it. 4. Voice: blunt/diplomatic, terse/thorough, question-first or verdict-first. 5. Three sample responses in-persona to a mediocre input, so I can check the calibration before using it. Then output the whole persona as a single system-prompt block I can paste at the top of any future conversation. ``` **What it does:** A named, calibrated persona produces sharper and more consistent critique than "act as an expert," mostly because step 3 pins the praise threshold. The sample responses let you tune the persona before trusting it. **Pro variation:** Build a small panel — the skeptical buyer, the confused newcomer, the compliance reviewer — and run important work past all three in separate conversations. Disagreement between personas maps your revision priorities. ### 6.4 Output rubric writer ``` I'm about to ask an AI to produce: [THE DELIVERABLE]. Before I ask, write the grading rubric: 1. 5-7 criteria a demanding expert would grade this deliverable on, each with a one-line description of what "excellent" looks like. 2. The 3 most common ways AI-generated versions of this deliverable fail. 3. A one-paragraph "definition of done." Output the rubric as a block I can append to my generation prompt with the instruction: "Grade your own output against this rubric before showing it to me, and revise once if any criterion scores below excellent." ``` **What it does:** Self-grading against an explicit rubric measurably improves output quality, and writing the rubric *before* generating keeps the standard independent of whatever the model happens to produce. This is the poor man's eval harness, and it's shockingly effective for repeated tasks. **Pro variation:** Keep the rubric and reuse it as an actual review tool: paste any draft — AI-written or human-written — with `"Grade this against the rubric. Scores plus one line of evidence per criterion."` One artifact, two uses. --- ## How to use this library Three habits make everything above work better. **Replace the brackets with real specifics.** Every placeholder you fill vaguely costs you output quality. "Audience: stakeholders" gets generic output; "Audience: a CFO who was burned by the last data project" gets the real thing. **Separate generation from verification.** The strongest pattern in this library appears over and over: make the model produce, then make it (or a second model, or a fresh conversation) check. Never let one pass do both jobs. **Steal the structure, not the words.** Every prompt here is a pattern: constrain the format, demand reasons for claims, force the uncomfortable list, make uncertainty legal. Once you see the patterns, you'll write better prompts than these for your own work — which is the point. *Part of Tech Stack → Playbook. See also: the How-To Guides for building things, and the Application layer dossier for what these tools are underneath.*