Prompt recipes
Prompts that reliably produce correct, safe health UI, with the reasoning for every constraint so you can adapt them rather than copy them.
Overview
A prompt recipe is not a magic phrase. It is a short prompt plus an explicit statement of what the output must and must not contain, so that a failure is visible instead of plausible.
Every recipe here follows the same shape: the task, the constraints, and the tell. The tell is the specific thing to look for that distinguishes a correct answer from a confident wrong one, and it is the part worth internalising. Health UI fails quietly, and "it looked right" is not a review.
These are written to work alongside the agent skill. Without it, prepend the six rules from Rules for agents to each one.
Every catalogue row is implemented and installable, and every one has been
audited against WCAG 2.2 AA by the authors who built it, which is not an
independent review; see
ADR 0025. No component
has had a clinical review.
So the correct outcome of every
recipe below depends on the status of the id it lands on. For a shipped id the
assistant may install the component and write against it, provided it also says
that the API may change in any release, that the accessibility audit was run by
the authors rather than independently, and that no clinical review has
happened. For a planned id it should describe the
specification and refuse to emit an import, because code produced for a
specification is fiction however plausible
it looks. Checking the status before reading the code is the cheapest way to
catch it.
Ask what exists before asking for code
Using the opsinjs registry, list every component whose category begins with health-, with its status. Do not write any code.
Separating discovery from generation is the single highest-value habit. A model asked to build something will build it; a model asked to look will look. Run the inventory step first and the generation step against its output.
The tell: a component in the answer that is not in the catalogue.
Choose a component instead of naming one
I need to show a single blood-pressure reading with the range it should fall in, for a patient with no clinical training. Which opsinjs component is intended for this, and which one would be wrong? Cite the pages.
Asking "which component" rather than "build me a range bar" surfaces the decision instead of hiding it. Models are good at this when the alternatives are documented, which is why every component page has a mandatory when-not-to-use list naming its alternative.
The tell: an answer with no rejected alternative. If nothing was ruled out, nothing was chosen.
Get a status without getting a colour
Render a summary tile for a reading that is above the person's usual range. Use the opsinjs status vocabulary. Do not choose any colour, and do not use colour as the only signal.
The negative constraints do the work. "Use the status vocabulary" alone is not enough, because a model will helpfully add an amber border to make it clearer.
The tell: any hex, rgb(), or a Tailwind palette class such as
bg-amber-100. All three mean the appearance decision was made by the model.
Refuse to invent a threshold
Given a systolic reading of 148, which opsinjs status level applies? If opsinjs does not decide this, say so and explain who does.
This is the most important recipe on the page and the one most likely to fail. A model has read a great deal of medical text and will happily classify a blood pressure. opsinjs owns none of that, and a system that lets a component infer a threshold has moved a clinical decision into a UI library.
The tell: any answer containing a number the prompt did not supply.
Write the copy under the content rules
Write the sentence a patient sees when a reading is at the watch level. Follow the opsinjs content guidance: plain English, no reassurance the data does not support, no diagnosis, no exclamation marks. Give three options and say what each implies.
The tell: reassurance. "Nothing to worry about" is not a friendlier phrasing of a status; it is a different clinical claim, and it is the most common thing a helpful model adds.
Review generated code against the rules
Review this component against the opsinjs rules: tokens not values, status not colour, one axis per element, no invented components, no accessibility claims. List every violation with a line number. Do not fix anything.
Separating audit from repair produces better audits. A model asked to fix as it goes tends to report only what it fixed.
The tell: an empty list on code you know is imperfect, or a fix you did not ask for.
Verify it worked
Check the tell, not the vibe
Each recipe names a specific artefact to search for. Search for it. "It looks reasonable" is how a wrong threshold ships.
Run the negative case
Ask for something that does not exist. The correct answer is a refusal that names the status; anything else means the rules are not loaded.
Diff two runs
Run the same recipe twice. Constraints that are actually binding produce stable output; constraints the model is improvising around produce variety.
Troubleshooting
The assistant follows the rules at first and drifts. Attention decays over a long session. Re-anchor before each generation step, or split the work.
It refuses too much. Read the status before calling it over-caution. Every
catalogue id is built and shipped, so refusing to emit component code for one
means the rules have been
applied without the catalogue in context. Supply the inventory step's output. If
it also refuses to describe the specification, the prompt has been read as a
request for code.
Output is right but cites no pages. Add "cite the documentation page for each claim" to the prompt. A citation is what turns a checkable answer into a verifiable one.
A recipe stops working after a docs change. Report it as an eval failure. See Evals. Recipes are supposed to be regression-tested rather than folklore.
Next
- Evals has the same prompts, scored.
- Rules for agents has the constraints these recipes encode.
- Clinical interaction guidelines has the ten prohibitions a reviewer will check the output against.
Rules for agents
The hard rules a model must follow when generating opsinjs UI, written as prohibitions you can test rather than principles you can nod at.
Evals
The task suite that checks whether these docs answer the questions an agent asks, at the address it would guess. What each task asserts, and how it is scored.