Module 02 · Lesson 01

The Anatomy of a High-Performance Prompt

Reading time: 22 minutes Track: Prompt Mastery · Required for all learners Prerequisites: Module 01 complete

What this lesson does

You learned in Module 01 that specification writing is the highest-immediate-ROI capability in AI fluency. This lesson teaches the specification framework.

By the end, you'll be able to:

1. Identify the six components of a high-performance prompt
2. Construct prompts that produce near-final-draft output on first response
3. Diagnose why a weak prompt failed and rebuild it
4. Apply the framework to any task in your real work

This is the most practical lesson in the curriculum so far. Bring a real task with you — by the end of the lesson you'll have constructed a working prompt for it.

01 · The framework in one sentence

A high-performance prompt has six components. They aren't optional. They are the difference between output you ship and output you rewrite:

Role + Context + Goal + Format + Constraints + Examples

You'll see various frameworks online with different names (RTF, CRISPR-prompting, RICE, etc.). They're all approximating the same thing. This particular six-element model is the one I'll use throughout HaiPhai because it's complete, easy to remember, and maps cleanly to how biotech work is actually structured.

Let's go through each.

02 · Element 1 — Role

What it is

Tell the AI who it's being. This isn't a parlor trick. The role you assign meaningfully changes the output by activating different parts of the model's training.

Weak version

"Help me draft a memo about the protocol deviation."

Strong version

"You are a senior clinical operations lead at a mid-size biotech with 15 years of experience drafting protocol deviation memos for Phase 2-3 oncology trials. You write in compliant, audit-ready language consistent with ICH-GCP standards."

Why it works

When you tell the model "you are a senior clinical operations lead," the model generates output that statistically resembles content written by senior clinical operations leads. The vocabulary tightens, the structure conforms to industry conventions, and the tone matches the audience.

The rule

Be specific about three sub-elements:

1. Title/function ("clinical operations lead," "regulatory affairs senior specialist")
2. Seniority level ("senior with 15 years experience" vs "associate")
3. Domain expertise ("Phase 2-3 oncology trials" or "rare disease clinical development")

A common mistake: assigning a role that's too vague. "You are an expert" is almost useless. "You are a senior regulatory affairs specialist with experience in FDA orphan drug submissions" is operationally different.

03 · Element 2 — Context

What it is

The background the model needs to do this task well. The model does not know your company, your project, your conventions, your audience, your previous work, or your standards. You supply this — and supplying it is what separates generic output from output that fits your situation.

Weak version

"Draft a Section 5.2 narrative for our ISS."

Strong version

"Context: We're filing an NDA for HLX-201 (fictional drug name — substitute your own), a small molecule for second-line treatment of refractory multiple myeloma. We have two Phase 2b trials with overlapping populations. The integrated safety summary will pool data from both trials. The Section 5.2 narrative I'm asking you to draft covers Grade 3+ adverse events by system organ class, with subgroup analysis for age (≥65 vs <65) and prior therapy lines."

Why it works

Without context, the model generates an averaged-out generic ISS narrative based on what such narratives typically look like in its training data. With context, it generates one tailored to your specific scenario.

What context to provide

Match context to task. For a drafting task, include:

• What is being drafted (specific document section, specific deliverable)
• What it's for (regulatory submission type, internal review, etc.)
• Who reads it (FDA, internal QC, executive leadership)
• What's already established (previous related work, standing decisions)
• What's specific to this case (this trial, this drug, this scenario)

Common failure pattern

Over-context. Pasting an entire 200-page protocol when only Section 7 is relevant. The model gets distracted by irrelevant context and produces output that wanders. Provide the context that's necessary — no more.

04 · Element 3 — Goal

What it is

What you actually want the model to produce. Stated as a deliverable, not as a question.

Weak version

"Tell me about the dose escalation."

Strong version

"Produce a 250-word executive summary of the dose escalation results from the Phase 1b trial, intended for an investor update slide. Focus on the recommended Phase 2 dose, the safety profile at that dose, and the most clinically meaningful efficacy signal."

Why it works

A "tell me about X" prompt invites the model to choose what to say. A specific deliverable narrows the model's output to exactly what you need.

The rule

State three things explicitly:

1. The output artifact (memo, summary, narrative, slide bullets, draft section)
2. The length/scope (250 words, three paragraphs, one page, full section)
3. The intent (what this output is for — informing, deciding, drafting toward)

Common failure pattern

Asking questions instead of requesting deliverables. "What were the most common AEs?" produces a list. "Draft a 150-word safety overview paragraph for our investor deck, leading with the most clinically meaningful AE pattern from the Phase 2b trial" produces output you can actually use.

Stop writing questions. Start writing specifications.

05 · Element 4 — Format

What it is

The structural form the output should take. Headings, bullet points, tables, narrative paragraphs, specific document conventions.

Weak version

"Give me the summary."

Strong version

"Format: Three paragraphs. Paragraph 1 — context and trial design (4-5 sentences). Paragraph 2 — primary efficacy result with effect size and confidence interval (4-5 sentences). Paragraph 3 — safety overview with specific Grade 3+ rates and clinically notable patterns (4-5 sentences). Use prose, not bullets. Use FDA preferred terminology. No headings within paragraphs."

Why it works

The model is generative — it'll produce something. The question is whether that something matches the form you actually need. Specifying format upfront is the difference between five minutes of formatting cleanup and zero.

What to specify

Depends on output type. For documents:

• Structure (sections, headings, paragraphs, bullets)
• Length (word count or paragraph count by section)
• Voice (first person, third person, organizational)
• Specific format conventions (citation style, terminology source, document standards)

For analysis output:

• Table structure (columns, rows, what each cell contains)
• Comparison format (side-by-side, before/after, pros/cons)
• Visualization specs (if generating chart-ready data)

Common failure pattern

Specifying form too late. People often realize the format was wrong after seeing the first output, then iterate. You can save the iteration by specifying upfront.

06 · Element 5 — Constraints

What it is

The boundaries — what the output must do, must avoid, must comply with. Constraints are the safety net that keeps output usable.

Weak version

"Make sure it's good."

Strong version

"Constraints:

• Use only data from the two Phase 2b trials I'm providing — do not introduce data from other sources
• All AE classifications must use MedDRA preferred terms
• Do not state or imply causality unless it's supported by the data provided
• Do not make comparative claims against marketed therapies
• Do not generate citations — leave bracketed placeholders [CITE] where citations belong, I will fill them
• Match the tone and structure of the Section 5.2 from our previously approved Phase 2a IND (provided below for reference)"

Why it works

Constraints prevent the most common failure modes (citation fabrication, scope drift, comparative claims, off-label inferences). Constraints are how you encode the regulatory and scientific guardrails that your work requires.

What to constrain (universal)

For any biotech work, consider constraints around:

• Source restriction — only use what's provided; don't introduce outside data
• Terminology — MedDRA, CTCAE, ICH-E3, or your team's standards
• Citation handling — leave placeholders, don't generate citations
• Causality language — don't infer causality; state association if supported
• Comparative claims — typically forbidden in regulatory-adjacent work
• Off-label content — none, regardless of how the data look
• Patient privacy — no identifiable patient information in output

Common failure pattern

No constraints at all, or vague ones ("be careful with claims"). Constraints have to be specific to be useful. The model can comply with "do not state causality" — it cannot comply with "be careful."

07 · Element 6 — Examples

What it is

A reference example showing the model what good output looks like for this specific task. By far the most underused element. Also the most powerful.

Weak version

(No example provided.)

Strong version

"Reference example — this is how Section 5.2 has been written in our previously approved submissions:

[Paste 200-400 words of an actual previously approved Section 5.2, with any identifying details removed if needed]

Match the structure, terminology, and tone of this reference. Adapt the content to the new trial data I'm providing."

Why it works

A reference example provides a high-density specification that words alone can't capture. The model doesn't just learn "use formal language" — it sees what formal looks like for your specific document type. It doesn't just learn "match our style" — it sees your style. This is roughly 10x more efficient than describing the style in prose.

How to use examples

For any recurring task, build a small library of example outputs you've previously approved. Then include the most relevant one in each new prompt.

If you don't have an existing example (you're drafting a new document type for the first time), you can:

• Use a published example from a comparable source (peer-reviewed paper, public FDA review document, etc.)
• Ask the model to draft a candidate, refine it manually, and use the refined version as the example going forward
• Skip the example for first drafts, and add one back once you have approved output

Common failure pattern

People assume the model can "figure out" their style without examples. It usually cannot. The model produces a generic version of "what such documents look like" rather than your version. Including an example moves output from generic to specific.

08 · Putting it all together — a worked example

Let's build a real prompt using all six elements. Scenario: you're a clinical operations lead drafting a protocol deviation memo.

The full prompt

Role: You are a senior clinical operations lead at a mid-size biotech with 15 years of experience drafting protocol deviation memos for Phase 2-3 oncology trials. You write in compliant, audit-ready language aligned with ICH-GCP and our internal SOP-CO-007.

Context: Trial HLX-201-2b enrolled Subject 4012-007 (de-identified ID) on Day 1 with all inclusion criteria met. At Day 15, the subject missed the scheduled visit due to a personal travel emergency. The visit was rescheduled and completed on Day 22, outside the protocol-defined window of Day 15 ± 3 days. All study assessments at the Day 22 visit were completed per protocol. No adverse events were missed. The PI has been notified and concurs with classification.

Goal: Draft a Protocol Deviation memo for this scenario. The memo will be reviewed by our Director of Clinical Operations and filed in the trial master file. It must classify the deviation as Minor (visit window deviation, no impact on subject safety or data integrity per our SOP), document the root cause, document subject safety status, document the corrective action, and confirm reporting status. Length: approximately 300-400 words.

Format: Standard memo format with the following sections:

1. Header (date, study, subject, deviation classification)
2. Description of Deviation (1 paragraph)
3. Root Cause (1 paragraph)
4. Subject Safety Impact (1 paragraph)
5. Data Integrity Impact (1 paragraph)
6. Corrective and Preventive Action (1 paragraph)
7. Reporting Status (1 paragraph)

Use third-person, formal regulatory tone. No first-person language.

Constraints:

• Classify as Minor (visit-window only, within tolerable variance per SOP-CO-007)
• Use only the information provided — do not introduce facts not stated above
• Do not generate any citations or references; use placeholders [CITE] where needed
• Do not state causality of the personal travel emergency
• Do not include subject-identifiable information beyond the de-identified subject ID
• Do not recommend protocol amendments unless explicitly stated as needed
• All adverse event language must use MedDRA preferred terms

Reference example: [Paste a previously approved Minor PD memo for a similar visit-window deviation, 300-400 words, redacted as needed]

What you'll get

If you send this prompt to Claude, you'll receive output that requires minor edits and is ready for senior review. Compare that to the typical "help me draft a PD memo" prompt that produces a 150-word generic stub that requires complete rewriting.

Time investment

That prompt looks long. It takes about 10-15 minutes to write the first time. For a recurring task type (PD memos, you'll draft dozens per year), you write the template once and reuse it. Per-task time drops to 2 minutes for context substitution.

The break-even is one PD memo. After that, you save 30-60 minutes every time, forever.

09 · The six-element checklist

For any prompt you're about to send for work that matters, run this mental check:

You don't need all six for low-stakes tasks. For anything that matters, you need most or all. A pattern I've seen: experienced AI users tend to skip Constraints and Examples even when those are the highest-leverage elements. Watch for this in yourself.

10 · The 80/20 of prompt writing

Honest priority ranking for where to invest effort if you're building this skill from scratch:

1. Goal (specificity of deliverable) — 30% of the value. Stop asking, start specifying.
2. Examples — 25% of the value. Reference outputs change everything; almost no one uses them.
3. Context — 20% of the value. The model needs your situation.
4. Constraints — 15% of the value. Especially critical in biotech.
5. Format — 7% of the value. Useful, but easy to fix in iteration.
6. Role — 3% of the value. Helpful but oversold by online prompt guides.

The conventional online "prompt engineering" wisdom over-emphasizes Role and under-emphasizes Examples. The actual leverage is the opposite. If you only do one new thing as a result of this lesson, start including a reference example in every important prompt.

11 · Now do it

Take the real task you brought to this lesson. Spend 10 minutes building a six-element prompt for it. Don't aim for perfection; aim for completeness across the six elements. Send it. Compare the output to what you would have produced with an unstructured prompt.

If you don't have a real task in front of you, this lesson is incomplete. Stop reading. Find a task. Come back.

The skill we're building isn't reading-about-prompts. It's writing-prompts. Five minutes of practice now beats five hours of reading later.

12 · Knowledge check

Three questions.

Q1. Which of the following is the most commonly underused element among the six, despite producing some of the largest improvements when added?

a) Role b) Context c) Goal d) Examples

Q2. A clinical operations lead wants AI help drafting a PD memo. Which prompt opening is strongest?

a) "Help me draft a PD memo." b) "Draft a protocol deviation memo for me." c) "Draft a Minor classification PD memo for a Day 15 visit window deviation on subject 4012-007 in HLX-201-2b, formatted per our SOP-CO-007 template, using the reference memo I'm providing as a structure guide." d) "You are an expert at writing PD memos. Write me one."

Q3. Why does specifying constraints matter especially in biotech?

a) Because biotech work is more difficult than other industries b) Because regulatory and scientific guardrails need to be encoded explicitly — vague constraints produce compliance and accuracy risk, and the AI cannot infer them from a vague request c) Because constraints are required for ICH-GCP d) Because constraints reduce token usage

Answers: Q1: d · Q2: c · Q3: b

13 · What's next

You now have the framework for building high-performance prompts. The next five lessons in Module 02 deepen specific aspects:

• Lesson 02 · Role-based prompting and audience targeting — Going deeper on Role and how it interacts with audience-aware output
• Lesson 03 · Constraints, guardrails, and format control — Building biotech-specific constraint libraries
• Lesson 04 · Iterative refinement and prompt debugging — When the first prompt doesn't work, how to fix it
• Lesson 05 · Common failure modes and recovery patterns — Pattern recognition for prompt failures
• Lesson 06 · Building your personal prompt library (capstone) — Operationalizing prompts into a reusable system

By the end of Module 02, prompt writing should feel like a structured engineering skill rather than a creative one. That shift in feel is the skill.

End of Lesson 01.