← The Health AI Toolkit

The prompt library

You don’t need to start with a blank box. Pick a prompt, fill in the marked fields and adapt it to your work. Read the answer before you use it.

Showing 16 of 16 prompts.

Plain-language handout

Patient comms

You are writing for someone with {{condition}} who reads at a 6th-grade level.Read full prompt
You are writing for someone with {{condition}} who reads at a 6th-grade level.

Write a one-page handout covering:
- what this is, in plain words
- what happens next
- what to watch for
- when to get in touch

Rules: no diagnosis, no dosing, no reassurance you cannot support.
Short sentences. Include no identifying detail about the person.

Uses a condition category, without identifying patient information. Review the wording and clinical accuracy before sharing.

Note template for a visit type

Documentation

Draft a blank note template for a {{visit_type}} visit in {{specialty}}.Read full prompt
Draft a blank note template for a {{visit_type}} visit in {{specialty}}.

Give me headings and field names only. Cover:
- what the visit was for
- what was assessed
- what was discussed
- what happens next, and by when

Leave every field empty. Do not write example content, and do not
suggest what a clinical field should say.

At the end, list the fields you were unsure whether to include.

Takes a visit type and a specialty. No patient goes into it — what comes back is an empty form you fill in wherever the record already lives. It will not tell you what to assess, and it does not know what your EHR or your payers require.

Skeleton for a letter you write often

Documentation

Write a reusable skeleton for a {{letter_type}} letter — for example aRead full prompt
Write a reusable skeleton for a {{letter_type}} letter — for example a
referral, a prior authorisation, or a return-to-work note.

Write the fixed language in full. Use [SQUARE BRACKETS] for everything
that changes between letters, and leave every clinical statement as a
bracket for me to complete.

Then state the tone, length, and reader you assumed, so I can correct you.

Takes a letter type. Nothing about the person the letter is for — the brackets get filled in later, in whatever system already holds the record. The reusable wording is the useful part; the clinical sentences stay yours to write.

Reply you send every week

Patient comms

Patients ask this constantly: {{question}}Read full prompt
Patients ask this constantly: {{question}}

Write a draft reply for our review. Constraints:
- {{reading_level}} reading level
- {{tone}} tone
- no diagnosis, no dosing, no promise about outcome
- say clearly when the real answer is "ask us directly"

Then list what a worried reader could misread, and how to reword it.

Takes the question, not the person asking it. The point is to answer a category of question once so the reply can be reused. If the honest answer depends on the individual, the draft should say so — check that it does before anything gets sent.

First read of a paper

Research

Here is a published paper: {{title_or_doi}}Read full prompt
Here is a published paper: {{title_or_doi}}

First state whether you accessed full text or only an abstract.
Say which details you cannot verify. Do not invent access or citations.

Give me, in this order:
- the question it asked
- who was studied, and who was not
- what it found, with the actual numbers
- the three weaknesses a careful reader would raise
- what it does not support, however it is being quoted

Say where you are unsure. Do not fill a gap you cannot source.

Takes a citation. No patient data, and nothing about applying it to anyone in particular. A model can misread a paper as confidently as it reads one correctly, so treat every number it gives you as something to check against the source.

Write down a process nobody has written down

Practice ops

We do this constantly and it exists only in people's heads: {{task}}Read full prompt
We do this constantly and it exists only in people's heads: {{task}}

Interview me. Ask one question at a time until you could write the steps
without guessing. Then produce:
- the steps in order
- who does each one
- what goes wrong most often, and what to do when it does

Use the words we actually use, not generic operations language.

Takes a task, and then your answers. Keep names, patients, and account details out of what you type back — what is being written down is the process, not any one run of it.

Argue against your own plan

Assistants

Here is a plan: {{plan}}Read full prompt
Here is a plan: {{plan}}

Argue against it. Give me:
- the three strongest objections, best first
- what would have to be true for each one to matter
- what evidence would settle it
- the cheapest thing to test first

No hedging. Do not summarise my plan back at me, and assume I have
already heard the obvious objections.

Takes a plan you wrote — a launch, a hire, a price change, a new workflow. It is a business aid, not a clinical one: never point it at a decision about a specific person, and remember the model has no stake in whether it is right.

Question for a spreadsheet

Build & automate

A spreadsheet is attached. Before you answer anything:Read full prompt
A spreadsheet is attached. Before you answer anything:
- tell me what each column appears to be
- tell me which rows are blank, duplicated, or inconsistent
- tell me what cannot be determined from this file alone

Then answer this: {{question}}

Show the steps you took to get there. If the file cannot answer it,
say so instead of estimating.

Use fictional, public or properly de-identified data. Removing a few identifiers is insufficient. Real patient data requires an approved workflow covering the actual account, services and agreements; a directory label alone is not approval. Check the column interpretation against the file.

Brief for a small internal tool

Build & automate

Build a small tool that does this: {{what_it_does}}Read full prompt
Build a small tool that does this: {{what_it_does}}

Before writing any code:
- restate what you think I asked for, in one paragraph
- list the decisions you are about to make on my behalf
- ask me about anything you would otherwise guess

Then build it to run on my own machine, with no database and no accounts.
Use made-up sample data. Show me how to run it and how to stop it.

Build with fictional rows in a dedicated workspace. Inspect actual file, network and connector permissions: an empty starting folder does not confine an agent. Separately approve the data path and code before real clinical use.

Script for a task you repeat

Build & automate

I do this by hand every week: {{task}}Read full prompt
I do this by hand every week: {{task}}

Ask me what the input looks like and what the output has to look like.
Then write a script that does it, and make it:
- refuse to run if the input is not what it expects
- write to a new file, never over the original
- print exactly what it changed

Finish by telling me what to check the first few times before I trust it.

Takes a description of the work, not the files themselves. Run it on copies until you trust it. If the real files hold patient information, then the machine you run it on and the tool you built it with both need to be ones allowed to see that.

Evidence conversation

Research

Research this question: {{population_and_question}}.Read full prompt
Research this question: {{population_and_question}}.
Use human studies and relevant guidelines from {{allowed_public_sources}}.
For each item, give a direct source link, design, population, comparator,
measured outcome, main finding and limitations. Separate association from causation.
State what you actually accessed: full text, abstract or other material.
If access is limited, say what cannot be checked. Do not invent citations.
Finish with one useful follow-up question and the claim I should verify first.

Use a population-level question and public sources. Open the source and check the claim before applying the answer to clinical care.

Check a claim against its source

Research

Check this sentence: {{draft_claim}}.Read full prompt
Check this sentence: {{draft_claim}}.
Against this source that I am allowed to share: {{source_link_or_text}}.
Identify the exact population, comparator and measured outcome.
Show the passage or table that supports or contradicts the sentence.
Label the claim supported, overstated or unverified, and explain why.
Suggest the narrowest accurate revision. Distinguish surrogate outcomes
from clinical outcomes. If you cannot access the relevant material, stop and say so.

The assistant’s check is another draft to verify. A real citation can still accompany an inaccurate statement.

Maya’s fictional living care map

Build & automate

Use only the fictional Maya S1–S8 teaching packet.Read full prompt
Use only the fictional Maya S1–S8 teaching packet.
Create one HTML file I can open in a browser. Put her goals first.
Include a dated source timeline, context, uncertainties and a follow-through table.
Attach a source ID to every factual statement; label inference separately.
Keep the medication discrepancy, unconfirmed sensor lows and missing wearable nights open.
Do not diagnose, choose treatment or invent a clinician-approved plan.
Leave next-step decisions for clinician review, with owner and review-date fields.
After I review the file, I may provide S9. Show what S9 changes and what it does not resolve.

Use the entirely fictional packet linked from the workflows page. This exercise creates a teaching file; it does not connect to a clinical record.

Proposed update from a fictional message

Documentation

Use this fictional message: {{fictional_message}}.Read full prompt
Use this fictional message: {{fictional_message}}.
Compare it with this fictional record excerpt: {{fictional_record}}.
Return the source/date, patient-reported summary, conflicts, missing information
and proposed record change beside the original text. Preserve uncertainty.
Do not overwrite the record, approve a medication change or send a reply.
Finish with the questions a clinician must confirm before approving an update.

Practice with fictional inputs. Real messages need an approved data path and clinician review; connecting an EHR requires separate testing and authorization.

Weekly public research brief

Research

Find up to three new human studies or relevant guidelines on {{topic_and_population}}Read full prompt
Find up to three new human studies or relevant guidelines on {{topic_and_population}}
published during {{review_window}}, using {{allowed_public_sources}}.
For each: direct link, publication date, design, population, main finding and limitations.
Distinguish new publications from older papers resurfacing. Flag duplicates
when previous results are available. Say if there is no relevant new evidence.
State access limitations. Do not include patient information or treatment advice.
Produce a private draft for review; do not send or publish it elsewhere.

Run once and open a source before scheduling. Configure the cadence, timezone, destination and failure reporting separately; this prompt does not schedule itself.

Compare business records before acting

Practice ops

Compare these fictional business records: {{fictional_records}}.Read full prompt
Compare these fictional business records: {{fictional_records}}.
Build a dated table of completed transactions, unpaid checkouts, active products
and renewal notices. State the source for each entry and any conflict.
Do not treat an unpaid checkout as a purchase or an old notice as current status.
Propose the smallest action and list the facts I must verify first.
Do not cancel, purchase, refund, send or change anything.

The talk’s membership example illustrates checking status before a consequential action. Use fictional records to practice and confirm permissions before connecting real accounts.