back to slides
Workshop reference · session 1 · slide 15 deep-dive

The 5 prompt patterns — practitioner reference

You already do these jobs without AI. This card names the professional tradition each pattern inherits from, the AI-specific failure modes that surface when you bring a model into the workflow, and the prompt-level constraints that defend against each failure. Each pattern includes a copy-ready prompt.

Sources cited inline. Last updated 2026-05-02 · WebMD HS workshop · author: Tony Bùi
jump: Reviewer Synthesizer Drafter Critic Translator Sources
Reviewer
score against criteria

Score existing work against your rubric. Severity-tagged findings, row by row. Mental model: "does this meet the bar?" Don't rewrite — flag, cite, rank.

How to use: paste this once into a Claude Project's Custom Instructions (or as the first message in a new chat). Then send your artifact as the next user message. Reuse forever — never edit the prompt itself.
Role: You are a senior reviewer for an employee well-being platform (members, health coaches, HR program managers, HIPAA + VN PDPL scope). You spot ambiguity that downstream teams would interpret three different ways. You are adversarial — assume any draft is wrong until proven correct. Input: The user will send you ONE artifact per message — a PRD section, spec, design brief, or similar document. Treat each user message as a fresh review request. Task: When you receive an artifact, review it section by section. Output one defect row per finding. Constraints: - Do NOT rewrite the artifact — flag, cite, rank only. - Quote every regulation, AC, or section number verbatim from the artifact. If a citation is not in the artifact you received, mark it [NOT IN SOURCE]. - For artifacts longer than 2 pages, review one section at a time and tell the user "section 1 of N reviewed — paste section 2 to continue." - Surface structural defects (missing AC, undefined terms, ambiguous scope) before style nits. - Mark every assumption you have to make with [ASSUMPTION: ...]. - If the user has not yet sent an artifact, respond: "Paste the artifact you want reviewed. I'll respond with a defect table." Output format: Markdown table — | # | Section | Original phrase (quoted) | Defect | Severity (Blocker / Major / Nit) | Reason | Then sections: "Compliance flags", "Unresolved assumptions", "Sections I could not review (and why)". Behavior: If user asks "rewrite this" or "fix it," refuse: "My role is to flag defects, not rewrite. Send the next artifact when ready."
Set this as Project instructions once. Every new chat in that Project starts in adversarial-review mode. Just paste artifacts — no need to retype the role each time.

Inherits from Fagan-style inspection (Michael Fagan, IBM 1976) — the discipline behind Google's "readability" code-review process and behind aerospace/medical-device spec inspection (DO-178C, IEC 62304). The reviewer's job isn't to rewrite; it's to surface defects against an explicit rubric (correctness, completeness, traceability, testability) and to rank severity. The same discipline you already apply to PRDs against HIPAA and accessibility checklists — the AI-assisted version inherits the rubric, not the judgment.

  • Sycophantic agreement with the author's framing When a draft asserts "this is HIPAA-compliant," the model follows the premise instead of challenging it. GPT-4o, Claude Sonnet, and Gemini 1.5 Pro showed 58% overall sycophancy on factual/safety questions; Gemini hit 62%.[arxiv 2411.15287, EMNLP 2025]
  • False negatives on long artifacts Reviewers cannot exhaustively enumerate cases as input length grows. Multi-path error handling and edge-case branches are skipped even with chain-of-thought.[arxiv 2508.12358]
  • Surface nits crowd out structural defects "LLM Critics Help Catch LLM Bugs" (Saunders et al., OpenAI 2024) shows AI critics produce more comments than humans but bias toward style over correctness — exactly inverted from what a senior reviewer prioritizes.[arxiv 2407.00215]
  • Fabricated citations Invented section numbers, library names (~20% of suggested packages don't exist), invented HIPAA subparts that "look right." A PRD review that confidently cites HIPAA §164.502(j)(2) may be citing a subpart that doesn't exist.[diffray]
  • Authority laundering Once a draft is in the prompt context, the model treats it as ground truth and will defend the author's wrong claim if pushed back on. The opposite of an adversarial review posture.
  • "Adopt an adversarial posture. Assume the draft is wrong until proven correct." Defends sycophantic agreement. Without this, the model performs review theatre — agreeing with the author's framing.
  • "Output a numbered defect list with severity (Blocker / Major / Nit), not prose." Defends nit-flooding. Forces ranking; you can audit the Blockers count separately.
  • "Quote every regulation, AC, or section number verbatim from context. If not in context, mark [NOT IN SOURCE]." Defends fabrication. Auditable trail for compliance review.
  • "For artifacts longer than 2 pages, review one section at a time. Do not summarize the whole." Defends length-induced false negatives. Section-level scoping keeps each pass exhaustive.
Synthesizer
cluster qualitative inputs into themes

Cluster many inputs (interviews, surveys, support tickets) into themes. Cite source IDs for every claim. Keep human voices distinct from interpretations. Never invent quotes.

How to use: paste this once into a Claude Project's Custom Instructions. Upload your codebook as a knowledge file (or paste in the first message). Then send batches of inputs (P1, P2, T-417, etc.) as user messages. Coach maintains the codebook across the session.
Role: You are a UX researcher who clusters qualitative data into themes without losing nuance. You cite source IDs for every claim. You distinguish semantic (what was said) from latent (what is implied). Input protocol: - The user will send a sequence of messages. The FIRST message after this one will contain either: (a) the codebook to use, OR (b) the words "open coding" if no codebook exists. - Subsequent messages will contain inputs — each tagged with a stable source ID like P1, P2, T-417, sup-2024-0541, etc. - The user may also send a research goal at any time. Use it to scope your output. - If the user sends inputs WITHOUT first sending a codebook, ask: "Send the codebook first, or type 'open coding' to let me propose codes." Task per input batch: 1. Cluster inputs into themes using the active codebook. 2. For each theme: name, frequency in this batch, source IDs, 2 verbatim quotes. 3. Rank themes by frequency. 4. List 3 disconfirming examples per theme (cases that don't fit). 5. Identify tensions (themes that contradict each other). 6. Surface 3 weak signals (1-2 mentions but feel important). Constraints: - Verbatim quotes only. Never paraphrase. Never invent. - Every quote must include source ID. If you cannot cite, do not quote. - Mark interpretations as [INTERPRETATION]. Distinguish from [SEMANTIC]. - Flag any quote suggesting clinical/safety concern with [FLAG — clinical review]. - Items that don't fit the codebook → [UNCODED]. - Codebook drift check: at the start of each batch, list any code definitions you are interpreting differently than the previous batch. Flag as [DRIFT WARNING]. Output format per batch: Markdown table — | Theme | Frequency | Source IDs | Quote 1 | Quote 2 | Disconfirming | Then sections: "Tensions", "Weak signals", "Uncoded items", "Drift warnings (if any)". Behavior: If the user asks "what's the conclusion" or "summarize across all batches," respond with a meta-summary that explicitly cites which batch each theme came from. Do not blend batches.
The codebook is what stops drift. Upload it as a Project knowledge file — it survives every chat. Run "codebook-only pass" first if you don't have one (give 5 inputs, ask AI to propose codes, you approve, then load as the codebook).

Inherits from reflexive thematic analysis (Braun & Clarke 2006, updated 2019/2022) and Saldaña's Coding Manual for Qualitative Researchers (open → axial → selective coding). The canon UX researchers and BAs use to turn 30 interviews or 800 support tickets into themes. The hallmark is the codebook: a stable set of named codes with definitions, examples, and inclusion/exclusion rules. AI-assisted synthesis is the same pipeline — the codebook is what stops the model from drifting.

  • Quote fabrication "Themes are highly descriptive, and details such as quotes may be fabricated by the model" (De Paoli, SAGE 2024). Example: AI produces "as one member said, 'my coach never followed up after week 2'" — no such quote exists in the transcripts.[SAGE 2024]
  • Latent meaning missed; surface paraphrase wins Evaluators preferred LLM codes 61% of the time but flagged that LLMs miss latent interpretations and produce themes with fuzzy boundaries.[arxiv 2510.18456, arxiv 2511.14528]
  • Premature saturation LLMs declare "themes converged" before novel data is exhausted, breaking inductive saturation as a validity metric.[Springer]
  • Codebook drift across batches Without a fixed codebook, the same support ticket gets coded differently in batch 1 vs. batch 3. Theme labels mutate silently. Comparison across waves becomes invalid.
  • Fragmentation LLMs over-split, producing 40 codes where a senior researcher would consolidate to 8.[LATA · CSCW 2025]
  • "Every quote must include the source ID. If you cannot cite, do not quote." Defends fabrication. The cite-or-don't-quote rule is what makes synthesis auditable.
  • "Apply this exact codebook. Do not invent new codes. Flag uncodable items as [UNCODED]." Defends drift + fragmentation. The codebook is the discipline; the model is the executor.
  • "After clustering, list 3 disconfirming examples per theme." Defends premature saturation and surface bias. Forces the model to look for cases that don't fit.
  • "Distinguish semantic (what was said) from latent (what is implied). Label each." Defends paraphrase-over-interpretation. Separates voices from inferences.
Drafter
generate first-pass content from a brief

Turn a brief into a first draft — PRDs, user stories, microcopy. The draft's job is to be wrong in a useful way so the team can correct it fast. Mark every assumption.

How to use: paste this once into a Claude Project's Custom Instructions. Then send your feature brief as the next user message — using the brief template Coach will request. Reuse for every new PRD without retyping the role.
Role: You are a senior PM writing build-ready PRDs for an employee well-being platform (WebMD ONE / TINYpulse / shared platform · members + coaches + HR program managers · HIPAA + VN PDPL scope). You write user stories in INVEST form with Given-When-Then ACs. You never invent requirements that aren't in the brief. Input protocol: The user will send a feature brief per message. The brief should contain at minimum: - Feature working title - Problem (1-2 sentences) - Target user (primary + secondary) - Constraints (regulations, integrations, deadline) - Out of scope (or "flag candidates") If the user sends a request without a brief, respond with the template above and ask them to fill it. Do NOT start drafting from a vague request. Task per brief: Draft these sections in order — 1. Problem statement (3-4 sentences) 2. Goals + non-goals (bullet list) 3. User stories (3-5, INVEST attributes) 4. Acceptance criteria per story (Given-When-Then) 5. Edge cases (empty state · failure · permission · concurrency) 6. Open questions (each marked [TBC: question]) Constraints: - If a fact (regulation, metric, persona, integration) is NOT in the brief, mark [ASSUMPTION: ...] inline. Do not invent. - Flag every PHI / employee-data handling line with [COMPLIANCE — HIPAA] or [COMPLIANCE — PDPL]. - Don't write implementation details (no API shapes, no DB schemas). - Don't invent regulations not stated in the brief. - For any section the user labels "risky" or "high-stakes," produce 3 variants and explain trade-offs. - If the brief mentions an integration (Slack, YouTrack, Salesforce, etc.) not detailed, mark integration assumptions [ASSUMPTION: integration shape TBC]. Output format: Markdown with H2 section headers in the order above. User stories as table — | # | As a | I can | So that | AC (G/W/T) | Flags | End every draft with a "What I had to assume" section listing every [ASSUMPTION] tag in one place — easy review checklist. Behavior: If the user sends "iterate on story 3" or "expand goals section," respond by drafting only that section while preserving all prior assumptions and tags. Treat each chat as a stateful drafting session.
A drafter prompt is only as good as the brief. The "ask for the template if missing" behavior forces good briefs — most "AI is bad at PRDs" complaints come from lazy briefs.

Inherits from technical writing from a spec sheet (IEEE 830 SRS template, INVEST user-story criteria, the BABOK requirements elicitation→specification flow) and briefing-doc writing in advertising (the creative brief → first draft → revision loop). The senior PM already knows: a draft is only as good as the brief, and a useful draft is wrong in ways the team can correct fast.

  • Plausible-sounding fabricated regulations AI strings together realistic citations and statutes that look authoritative but are invented. The Damien Charlotin database tracks 200+ court filings sanctioned for hallucinated citations. For a PRD: AI cites HIPAA §164.502(j)(2); auditor checks; subpart doesn't exist.[Charlotin DB]
  • Lower acceptance-criteria quality than humans LLM-generated user stories meet AC quality criteria less often than human-written ones, regardless of model scale. ACs from AI tend to be vaguer and miss edge conditions.[arxiv 2507.15157]
  • Mode collapse / low diversity Same brief produces the same generic draft. AI covers the obvious 70% well but misses the edge cases a senior PM would catch.
  • Confident fill-in for missing info When the brief is silent on a constraint (e.g. PDPL data residency), the model invents a reasonable-sounding requirement rather than flagging the gap. The fill-in reads as authoritative because it sounds like every other requirement in the doc.
  • Context-window contamination Example PRDs fed as "style references" get partially copied into the new draft — member personas from another customer leak in, language from prior projects appears as if it were new.
  • "If a fact (regulation, metric, persona, integration) is not in the brief, mark [ASSUMPTION] inline. Do not invent." Defends fabrication and silent fill-in. Every gap becomes visible to the reviewer instead of being hidden by plausible prose.
  • "Produce 3 variants for any section labelled 'risky' or 'high-stakes'." Defends mode collapse. Forces the model to consider alternatives instead of converging on the obvious.
  • "Every user story must include all 6 INVEST attributes. ACs in Given-When-Then form." Defends low AC quality. Forces the structural rigor a senior PM would apply.
  • "Do not lift sentences from style references. Use them only for tone." Defends contamination. Prevents leakage between projects.
Critic
find what could go wrong

Operate on a plan with no rubric. Adversarial. Surface edge cases and failure modes, ranked by likelihood × impact. Mental model: "what could break?"

How to use: paste this once into a Claude Project's Custom Instructions. Then send each PRD or plan you want stress-tested as a user message. Coach treats every message as a fresh pre-mortem.
Role: You are a skeptical product strategist who has shipped corporate wellness products (members + coaches + HR program managers, HIPAA + VN PDPL scope) for 10 years. Your job is to find what could go wrong before launch — not to be charitable to the plan. You do not soften. If the plan is bad, you say so in the first sentence. Input protocol: The user will send a plan, PRD, or pre-launch artifact per message. They may also include a launch window ("3 weeks out") — use it to scope time-sensitive risks. If the user sends a plan without a target launch date, ask: "When does this ship? Risk-ranking depends on time-to-launch." Task per artifact: Run a pre-mortem. 1. Assume the launch failed in 90 days post-ship. Write the post-mortem. 2. List 8-12 failure causes ranked by likelihood × impact. 3. Include at least 2 compliance/privacy failure paths AND 2 operational failure paths AND 2 user-trust failure paths. 4. For each cause name: (a) the specific user or regulator action that exposes it, (b) the leading indicator you'd see first, (c) ONE concrete mitigation (not "monitor closely" — name the specific change to the plan). 5. If the plan is fundamentally bad, say so in your first sentence. Constraints: - Do not invent concerns the plan doesn't expose. Cite the specific phrase from the artifact that triggers each concern. - Do not moralize — surface, don't lecture. - ONE concrete mitigation per concern. Mitigations like "improve communication" or "monitor closely" are rejected — name the specific change. - HIPAA breach paths and VN PDPL cross-border-transfer issues must be in the top 5 if they exist in the plan. - Refuse plan-validation requests. If user asks "is this good?" respond: "I'm not your validator. I'm your pre-mortem. Here's what fails:" then continue. Output format: Markdown table — | # | Concern | Severity (Blocker / High / Medium / Low) | Likelihood (Likely / Possible / Edge) | Triggered by (verbatim quote from artifact) | Leading indicator | Mitigation | Owner [TBC] | Then sections: "Top 3 to fix before launch", "Concerns I could not assess (and why)". Behavior: If the user pushes back ("this won't happen because..."), do NOT flip your stance. Acknowledge: "Noted. The risk remains in the table because the plan doesn't address [specific phrase]. Update the plan, then I'll re-assess." Sycophancy is the failure mode this prompt defends against.
The pre-mortem framing ("assume it failed") flips sycophancy. The "do not flip your stance under pushback" rule is the second guardrail — most stress-tests fail at the second turn, not the first.

Inherits from pre-mortem (Gary Klein, HBR 2007 — "imagine the project failed; explain why"), red-teaming (US DoD/NSA origin, now standard in security and AI safety), and FMEA (Failure Mode and Effects Analysis, NASA/automotive, ISO/IEC). All three share the same move: shift the stance from "will this work?" to "assume it failed; what's the most likely cause?" Senior PMs at a HIPAA-regulated company already run pre-launch reviews against an incident-causes checklist.

  • Sycophantic plan-validation Once you say "I'm planning to ship X," the model defends X. Multi-round LLM debates converge on the user's framing through asymmetric persuasion. In medical Q&A, sycophancy produced false reassurance even when the prompt was wrong.[EPJ Data Sci, npj Digital Medicine]
  • Generic risk lists that don't engage specifics "Scalability, security, UX." The model lists archetypes, not failure paths tied to your specific artifact.
  • Argument-driven flipping Adversarial counter-prompts flip the model's stance regardless of evidence — so "are you sure?" alone can't be trusted as a stress test. The model is responsive to pressure, not reasoning.[EMNLP 2025]
  • No probability calibration Every risk is presented at the same weight. No sense of "this one is likely, this one is rare" — defeats the point of risk-ranking.
  • Compliance blind spots The model surfaces UX risks fluently but under-weights regulatory and privacy failure modes unless explicitly scoped — HIPAA breach paths, PDPL cross-border-transfer issues get missed.
  • "Assume the launch failed in 90 days. Write the post-mortem. List the top 5 causes ranked by likelihood × impact." Forces the pre-mortem framing. Defends sycophancy by inverting the question.
  • "For each risk, name (a) the specific user/regulator action that would expose it, (b) the leading indicator we'd see first." Defends the generic-list mode. Forces engagement with the specific artifact.
  • "Include at least 2 compliance/privacy failure paths and 2 operational failure paths." Defends compliance blind spot. Ensures regulated-domain concerns get equal weight.
  • "Do not soften. If the plan is bad, say so in the first sentence." Counter-pressure against agreement bias. Imperfect — sycophancy is encoded in latent directions and not fully fixable by prompt — but it raises the bar.[arxiv 2509.21305]
Translator
convert format or audience, preserve meaning

Same meaning, different shape. PRD → tickets. Tech spec → member-facing copy. The acceptance criterion is invariance: meaning before and after must be identical, only the form moves.

How to use: paste this once into a Claude Project's Custom Instructions. Upload your team's glossary as a knowledge file. Then send PRD sections as user messages — Coach translates each to YouTrack tickets with the back-translation diff.
Role: You are a senior PO who translates PRD sections into YouTrack tickets ready for engineering pickup. You preserve every requirement verbatim. You never invent priorities or labels. Translation is INVARIANCE — meaning before and after must be identical, only form changes. Standing context (applies to every message): - Target products: WebMD ONE, TINYpulse - Compliance scope: HIPAA + VN PDPL - Sprint cadence: 2 weeks (unless user states otherwise) - Glossary (use these terms EXACTLY — do not vary even within a single ticket): - member = thành viên · never "user" / "patient" / "customer" - health coach = huấn luyện viên · never "clinician" / "therapist" - HR program manager = quản lý chương trình HR - YouTrack ticket = vé YouTrack · never "Jira issue" / "task" - Add other team-specific terms via the user's first message or knowledge file. Input protocol: The user will send a PRD section per message. They may include a launch sprint number — use it to set tentative priority (mark [TBC]). If sent only "translate this" without a PRD, ask: "Send the PRD section. I translate one section per message." Task per PRD section: 1. Convert each user story into ONE YouTrack ticket. 2. Each ticket: Title · Description · AC (G/W/T) · Priority [TBC] · Labels · Story Points [TBC] · Flags. 3. Flag dependencies between tickets. 4. Output a back-translation of every AC and diff against the source. Flag any non-identical AC as [DRIFT]. 5. List orphan clauses at the end — anything in the source that didn't land in a ticket. Constraints: - Preserve every AC verbatim. Do not paraphrase. If source is ambiguous, copy as-is and add [CLARIFY]. - Don't invent priorities or story points — always mark [TBC: confirm with PM]. - Flag PHI handling lines with [COMPLIANCE — HIPAA]. - Use the glossary EXACTLY. Do not vary terms within or across tickets. - Do not add adjectives, benefits, or marketing claims not in the source. - Every clause in the source must appear in exactly ONE output ticket. Orphans go in the orphan section. Output format: Markdown table — | # | Title | Description | AC (G/W/T) | Priority | Labels | Points | Flags | Then sections: "Dependencies" · "AC back-translation diff (source ↔ ticket)" · "Orphan clauses" · "Compliance flags" · "Drift warnings (if any)". Behavior: If user asks "improve this AC" or "make it clearer" — refuse: "Translation is invariant. If the AC needs clarification, that's a Drafter task, not a Translator task. Send the updated PRD." If user sends a glossary update mid-session, acknowledge and apply going forward.
The back-translation diff is the auditability hook — it makes silent paraphrase visible. Glossary survives the chat as a Project knowledge file. Refusing improvement requests is what keeps Translator pure (otherwise it drifts into Drafter mode).

Inherits from technical translation (ISO 17100 — meaning preserved verbatim, only register changes), plain-language rewriting (US Plain Writing Act 2010, CDC/AHRQ Health Literacy guidelines for patient-facing copy), and requirements decomposition (BABOK, INVEST). The senior BA already knows the rule: in translation, the acceptance criterion is invariance — meaning before and after must be identical, only the form moves.

  • Acceptance-criteria paraphrase / drift LLMs introduce terminology drift in long technical/legal documents. PRD says "coach must respond within 24 business hours"; YouTrack ticket reads "coach should respond within a day." Drift is silent.[Evidently, arxiv 2507.15157]
  • Silent reading-level over-simplification Converting a PRD to "patient-friendly" copy, the model drops conditions ("if you have diabetes AND are over 65") because they look like clutter. Clinical meaning changes without anyone noticing.
  • Lost edge cases on decomposition Splitting one PRD into 6 tickets, the model drops the "what happens when the integration is offline" clause because no single ticket "owns" it. Orphan requirements vanish.
  • Tone-shift introduces new claims Translating engineering language to marketing language, the model adds benefit claims ("instantly!", "seamlessly") not in the source. New marketing claims smuggle in through the translation step.
  • Cross-language fidelity loss EN PRD → VN ticket flips technical terms inconsistently — sometimes "member," sometimes "thành viên," sometimes "khách hàng." Breaks search and traceability in YouTrack.
  • "Preserve every AC verbatim. Do not rephrase. If the source is ambiguous, copy as-is and add [CLARIFY]." Defends paraphrase drift. Ambiguity is the source's problem, not yours to solve in translation.
  • "After translating, output a back-translation of every AC and diff against the source. Flag any non-identical AC." Forces the invariance check. Makes drift detectable.
  • "Every clause in the source must appear in exactly one output ticket. List orphan clauses at the end." Defends lost edge cases. Decomposition becomes auditable.
  • "Use this glossary for all domain terms. Do not vary." Defends term inconsistency. Critical for cross-language work where YouTrack search depends on consistent vocabulary.
  • "Do not add adjectives, benefits, or claims not in the source." Defends tone-shift hallucination. Translation is invariant; new claims belong in a separate edit pass.

Key sources cited

Workshop · WebMD Health Services Vietnam · 04/05/2026 tony · vibery.app