The prompt library

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.

Contains no health information by design — the condition is a variable, not a record.

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.

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.

Patients ask this constantly: {{question}}

Write a reply we can send as-is. 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.

Here is a published paper: {{title_or_doi}}

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.

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.

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.

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.

This is the one prompt here where what you attach matters more than what you type. Strip names, dates of birth, and record numbers before you upload, or use a tool the directory records as covered by a BAA. The first half of the prompt exists because the usual failure is not a wrong sum — it is a confident answer over a column the model misread.

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.

Takes a description of the tool, not any of the data it will eventually handle. Build it against invented sample rows and only point it at anything real once you have watched it work. An agent reads whatever folder you start it in, so start it in an empty one.

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.