Module 02 · Lesson 06
Building Your Personal Prompt Library
Reading time: 18 minutes Track: Prompt Mastery · Module 02 Capstone Prerequisites: Module 02 · Lessons 01–05
What this lesson does
This is the capstone of Module 02. You've learned the six-element framework, role and audience targeting, constraint stacks, iteration patterns, and failure recognition. Now we operationalize all of it into something you'll actually use every day: your personal prompt library.
By the end of this lesson, you'll have:
- The structure of a personal prompt library that fits how you work
- Three working prompts saved and ready to use for your most common tasks
- A versioning and improvement system that gets better over time
- A clear handoff to Module 03 (Governance) and your role-specific module
This lesson is hands-on. By the time you finish, you should have actual prompts written and saved, not just an understanding of how libraries work.
01 · Why a personal prompt library matters
Most people use AI in a rediscovery loop. Every task, they think about the prompt fresh. They write something, iterate, eventually get usable output, and then close the conversation. The next time they need to do that same task, they start over.
This is the most expensive way to use AI.
A personal prompt library inverts the model. You write each prompt template once, refine it through real use, and save the refined version. The next time you need that task, you load the template, swap in case-specific details, and you're done in 2 minutes instead of 20.
The compounding effect
A senior medical writer who builds a library of 15 high-quality prompt templates across their recurring tasks (CSR sections, ISS narratives, manuscript drafts, response letters, etc.) saves an estimated 40-60% of their drafting time after the library is mature.
A senior clinical operations lead with 10 templates (PD memos, monitoring reports, query letters, site communications, etc.) reports similar gains.
The library is the difference between AI as a one-off tool and AI as infrastructure.
02 · What goes in a prompt library
Three categories of content:
1. Task templates
The core of the library. Each template covers one recurring task type and includes:
- Role assignment
- Standard context structure (slots for case-specific details)
- Goal specification
- Format/template
- Hard constraints
- Soft constraints
- Reference example placeholder (or actual reference if non-confidential)
2. Constraint snippets
Reusable constraint blocks for biotech work. The hard constraint library from Lesson 03 is a starting point. You'll add your own as you encounter new requirements.
3. Failure recovery prompts
The eight precise correction patterns from Lesson 04, saved as ready-to-paste snippets. When you hit a Confident Hallucination, you don't reinvent the recovery prompt — you grab the saved version.
03 · Library structure
You can build your library in any tool that works for you. Notion, a Word doc, a folder of markdown files, a private GitHub repo, a notes app. The structure matters more than the tool.
Recommended folder structure
📁 My AI Prompt Library
│
├── 📁 01_Templates_by_Task
│ ├── PD_Memo_template.md
│ ├── ISS_Section_template.md
│ ├── Investigator_Brochure_Update_template.md
│ ├── Standard_Response_Letter_template.md
│ └── ... (one file per recurring task)
│
├── 📁 02_Constraint_Snippets
│ ├── biotech_hard_constraints.md
│ ├── regulatory_terminology.md
│ ├── format_specifications.md
│ └── ...
│
├── 📁 03_Recovery_Patterns
│ ├── confident_hallucination_fix.md
│ ├── generic_drift_fix.md
│ ├── constraint_violation_fix.md
│ └── ...
│
├── 📁 04_Reference_Examples
│ ├── [Stored examples of previously approved outputs]
│ └── ...
│
└── 📁 05_Sandbox
└── [Where you draft and test new templates]
Naming conventions
- One file per template, named for the task it handles
- Date-stamp major revisions in the filename:
PD_Memo_template_v3_2026-02.md - Keep old versions until you're confident in the new one
Versioning
Every template improves with use. Mark versions:
- v1 — first draft, untested
- v2 — refined after 5+ real uses
- v3 — mature, tested across multiple cases
- v4+ — additional refinements, new constraints added, edge cases handled
A template at v3 or higher is in production. v1-v2 are still being tested.
04 · Building your first template
Let's build one together. Pick your single most frequent recurring task — the one you do at least once a week.
Step 1 — Define the task
In one sentence, what is this task?
Example: "Drafting protocol deviation memos for visit window deviations classified as Minor."
Be specific. "Drafting memos" is too broad. "Drafting protocol deviation memos for visit window deviations classified as Minor" is operational.
Step 2 — Identify what changes per case vs. what stays the same
For your task, list:
Static elements (same every time):
- Role assignment
- Document structure / template
- Hard constraints
- Reference example
- Stylistic preferences
Variable elements (change per case):
- Subject ID
- Specific deviation details
- Root cause
- Timeline
- Corrective action taken
This separation is the key insight that makes templates work. The static elements become the template; the variable elements are slots to fill.
Step 3 — Write the template
Using the six-element framework:
# Protocol Deviation Memo — Minor Visit Window Deviation
## v1 · created [date]
## 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: [TRIAL_ID]
Subject: [SUBJECT_ID, de-identified]
Visit affected: [DAY_X visit]
Protocol-defined window: [Day X ± N days]
Actual visit date: [Day Z]
Variance from window: [N days outside window]
Reason for deviation: [BRIEF_DESCRIPTION]
Subject safety status: [STATUS]
Assessments completed at rescheduled visit: [STATUS]
PI notification status: [STATUS]
PI concurrence with classification: [YES/NO]
## GOAL
Draft a Protocol Deviation memo classifying this deviation as Minor
(visit-window-only, no impact on subject safety or data integrity per
SOP-CO-007). The memo will be reviewed by the Director of Clinical
Operations and filed in the TMF. Length: 300-400 words.
## FORMAT
Standard memo with sections:
1. Header (date, study, subject, 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)
Third-person, formal regulatory tone. No first-person language.
## CRITICAL CONSTRAINTS — MUST NOT VIOLATE
- Classify as Minor only (visit-window deviation within tolerable
variance per SOP-CO-007)
- Use only the information provided above — do not introduce facts
not stated
- Do not generate citations or references; use [CITE] placeholders
- Do not state or imply causality for the deviation reason
- No subject-identifiable info beyond the de-identified ID
- Do not recommend protocol amendments unless explicitly stated
- All AE language must use MedDRA preferred terms
## STYLISTIC GUIDANCE
- Lead the Description with the deviation event, not the consequence
- Root Cause section should be neutral and factual
- Corrective Action should describe what's already been done plus
what will prevent recurrence
## REFERENCE EXAMPLE
[Paste a previously approved Minor PD memo here]
Step 4 — Test the template
Use it for an actual PD memo. Note what didn't work, what was unclear, what the model missed despite the template.
Step 5 — Refine
Based on the test:
- Tighten constraints that the model violated
- Add format specifications you didn't realize you needed
- Clarify role or context elements that produced unexpected output
Promote to v2.
Step 6 — Save and use
Save to your library. Use it for the next 5-10 cases. Refine to v3 when stable.
05 · The hard part — confidential reference examples
The most powerful element of a template is a reference example showing what good output looks like. The challenge in biotech: most "good examples" are confidential.
Approaches that work
Approach 1 — Anonymize a real example Take a real previously approved document. Remove or replace:
- Subject identifiers
- Sponsor names
- Investigator names and sites
- Specific dose values that could fingerprint the program
- Trial identifiers
Save the anonymized version as your reference example. This keeps the structure and language without the confidential specifics.
Approach 2 — Synthetic but realistic Construct a fictional but plausible example based on the structure of real approved documents. This takes more effort but produces a reusable, sharable reference.
Approach 3 — Use public examples For some document types, public examples exist:
- Published clinical study reports (some are publicly released)
- FDA approval review documents
- Investigator brochure templates from public protocols
- IRB-approved protocols from clinicaltrials.gov
These are less perfect for your specific work, but they're shareable and don't carry confidentiality concerns.
Approach 4 — Don't include the example in the prompt itself Some teams instead provide the example to the model at the start of a conversation, then run the template prompt afterward. This keeps the confidential content out of saved prompt files but uses it in the actual workflow.
What not to do
Do not paste real confidential examples into AI tools without appropriate data governance approval. Module 03 covers this in depth, but the short version: confidential reference materials need to go through your team's AI governance review before being used as prompt examples.
06 · Building a constraint snippet library
Beyond task templates, a library of reusable constraint snippets accelerates new template creation. Save these as separate files you can paste into any new template.
Example snippets to build
# Snippet — Biotech Hard Constraints (Scientific Content)
CRITICAL — MUST NOT VIOLATE:
- Use only information provided in this prompt. Do not introduce
data, results, or claims from training data.
- Do not generate citations. Use [CITE] placeholders.
- Do not state or imply causality unless explicitly told.
- Do not make comparative claims against marketed therapies.
- Do not include any patient-identifiable information.
- Reproduce numerical values exactly. No rounding or approximation.
- Preserve all caveats and limitations from source materials.
# Snippet — Regulatory Tone
STYLISTIC:
- Third-person voice; no first-person language
- Past tense for completed activities, present tense for ongoing
- Prose paragraphs; minimal bullet points
- Sentence-case section headings
- MedDRA preferred terms for AEs; CTCAE v5.0 for grading
- ICH-E3 terminology where applicable
# Snippet — Executive Summary Output Format
FORMAT:
- Length: [X] words ± 10%
- Lead with the conclusion
- One sentence summarizing what we're saying
- 2-3 sentences of supporting evidence
- 1 sentence on implications or next steps
- No headings within the summary
- Plain language; minimize jargon
Build 10-15 of these snippets covering your common needs. Paste relevant snippets into each new template you create.
07 · Sharing vs. private
A decision point: is your prompt library personal or shared with your team?
Personal
Pros: builds your specific voice and preferences, no coordination overhead, you control versions
Cons: doesn't scale your work, doesn't help colleagues, your knowledge stays in your head
Shared with team
Pros: leverages collective experience, faster onboarding for new team members, more standardized output
Cons: coordination overhead, version management, requires governance review of templates
Recommended progression
Start personal. After 30-60 days of personal use, evaluate which templates are stable enough to share with your team. Move those to a shared library. Keep newer or more individualized templates personal.
Some templates should never be shared (your specific style preferences). Most should eventually graduate to team libraries.
This is also the foundation of Module 07 (Skills and Customization) and Module 08 (AI Operating Model), where we cover how to operationalize libraries at team and organizational scale.
08 · Capstone deliverable for Module 02
To complete Module 02, produce the following:
-
At least three working task templates for your most frequent recurring tasks. Each should:
- Use the six-element framework
- Have hard constraints separated from soft
- Include a reference example (anonymized if needed)
- Be at v2 or higher (tested on real cases)
-
At least five constraint snippets covering common requirements in your work
-
A library structure organized in your tool of choice, with versioning
-
A short reflection (one page) on:
- Which template produced the biggest gain
- Where you still see failure patterns
- What you'll build next
This isn't graded; it's a portfolio piece for your Module 10 capstone and an actual operational asset.
09 · A common trap
A pattern we see: learners build elaborate libraries early, before they've used templates enough to know what works.
The better progression:
- Build one template (your most common task)
- Use it 5-10 times in real work
- Refine based on what you learned
- Build a second template
- Use it 5-10 times
- Refine
- Build a third
After three templates at v3+, you'll have learned enough about how templates work for your specific role to build the rest faster and better.
The worse progression:
- Build 15 templates in one sitting
- None of them tested
- Most get abandoned or never used
- The 2-3 you actually try need heavy revision
Build slowly. Refine through real use. The library grows organically into something you trust.
10 · Knowledge check
Three questions.
Q1. Why does the lesson recommend building only one template at a time and refining it through 5-10 real uses before building the next?
a) Building multiple templates simultaneously is technically difficult b) Templates built without real testing tend to be poorly calibrated, often get abandoned, and don't reflect what actually works for the specific user's tasks — iterative refinement through use is what produces production-quality templates c) AI tools limit how many templates you can build d) Templates require senior approval
Q2. A learner wants to include a real previously approved CSR section as a reference example in their template, but the document is confidential. What's the recommended approach?
a) Skip the reference example b) Use the document anyway since it's just being used as a template c) Anonymize the document by removing identifiers, sponsor names, investigator names, and specific values; or use a synthetic but realistic example; or use a public example from a comparable source d) Wait until the document is publicly released
Q3. A template is considered "production-ready" at approximately what version level?
a) v1 — initial draft is sufficient b) v3 or higher — after refinement based on real use across multiple cases c) v10 — extensive iteration is required d) Version doesn't matter
Answers: Q1: b · Q2: c · Q3: b
11 · End of Module 02
You've completed Module 02. You should now have:
- An accurate framework for building high-performance prompts
- An understanding of role and audience targeting
- Hard and soft constraint libraries
- Iteration and debugging patterns
- Recognition of the seven common failure modes
- The beginning of a personal prompt library
Next: Module 03 · Governance & Compliance
Module 03 is the required gate before role specialization. It covers the bright lines you must internalize before using AI in biotech work — what data never goes in, how to document AI use, decision frameworks for the gray zones, and how to engage your compliance team productively.
You cannot proceed to your role-specific module without completing Module 03. This is intentional. Governance fluency is the only capability where weakness is dangerous in addition to suboptimal.
Take a break if you need one. Module 03 is important.
End of Lesson 06. End of Module 02.