Prompting fundamentals

<materials>
[optional: pasted documents, data, drafts;
 long material always goes first]
</materials>
 
<context>
[your situation: who you are, the project,
 what exists, what you tried]
</context>
 
<examples>
[optional: 1–3 samples you like and 1 you don't,
 each with why]
</examples>
 
<task>
[the deliverable by its professional name,
 and the decision or action it feeds]
</task>
 
<requirements>
- [musts and must-nots: length, scope, constraints,
  named standards]
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- [3–5 checks an expert in this field would apply]
</quality_bar>
 
<output_format>
[the exact shape: sections, table columns,
 file type, length]
</output_format>
 
<process>
[optional: how to work, e.g. give 3 options
 and stop before drafting]
Ask me up to 3 questions first if anything missing
would change your answer; otherwise go on.
End with a list of the assumptions you made.
</process>

Before:
Write a [tone] email to [audience] about [topic].
 
After:
Write a [tone: plain | warm | formal | playful] email to
[audience, e.g. customers who canceled in the last 90 days]
about [topic, e.g. our new $4/month plan].

Prompt 1: From the notes in <materials>,
list every claim and the evidence for it.
Mark claims with no evidence [NEEDS SOURCE].
 
Prompt 2: Using only the supported claims from the previous
answer, propose a 5-section outline for [audience, e.g. the
board, who read only headings and the summary].
 
Prompt 3: Write section 2 of the outline, 300 words.
 
Prompt 4 (fresh chat): Here are a section and the
evidence list. Quote every sentence the evidence
doesn't support, and say why. Don't rewrite anything.

Write a marketing email for my app.

<materials>
Exit-survey answers from users
who canceled in the last 90 days:
- "too expensive": 62%
- "too much manual entry": 21%
- other reasons: 17%
</materials>
 
<context>
Our product: a budgeting app for US freelancers. Since these
users left we added automatic invoice reminders, quarterly
tax estimates (US only) and a cheaper $4/month plan.
The readers: US freelancers, 25–45, who canceled in the last
90 days. They know the app; they don't know what changed.
</context>
 
<task>
A win-back email that gets them
to restart a free 14-day trial.
</task>
 
<requirements>
- Under 150 words; friendly, not pushy; one call to action.
- No fake urgency and no invented discounts
  or features: only the facts above.
- Answer the top two exit reasons, in that order.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- It names the reason they left in the first two sentences.
- It gives one concrete reason to
  return, tied to that reason.
- It has a single clear call to action.
- Every product claim appears in <context>.
</quality_bar>
 
<output_format>
3 subject lines (under 45 characters), preview
text (under 90 characters), then the body.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

Subject lines:
1. You told us why you left. We listened.
2. Less typing, and now $4/month
3. Your invoices can chase themselves now
 
Preview: Automatic invoice reminders and a cheaper plan.
 
Hi {first_name},
 
When people canceled, most told us two things: it cost too
much, and it meant too much typing. We've fixed both.
 
There's now a $4/month plan, and for $4/month you get
automatic invoice reminders, so clients get nudged without
you writing a single email. Quarterly tax estimates (US)
are built in too.
 
Restart your free 14-day trial and see the difference.
 
[Restart my trial]
 
Assumptions:
1. The $4/month plan includes invoice reminders and tax
   estimates.
2. Emails support a first-name merge field.

Assumption 1 is wrong: the $4/month plan does not
include invoice reminders; they are on the $9/month
plan. Tax estimates are on both. Rewrite only the second
paragraph so each feature is tied to the right plan,
keep everything else word for word, then check the draft
against the quality bar again, one line per check.

<materials>
<documents>
<document index="1">
<source>Q3 customer interviews, notes.txt</source>
[paste the interview notes]
</document>
<document index="2">
<source>Support tickets, September.csv</source>
[paste the ticket export]
</document>
</documents>
</materials>
 
<context>
We are a 5-person product team choosing which onboarding
problem to fix next quarter. The founders will read this.
</context>
 
<task>
The top 3 onboarding problems, with the evidence
for each, so we can choose next quarter's fix.
</task>
 
<requirements>
- Use only the documents above, not general knowledge.
- First quote the 10 passages most relevant to onboarding
  problems, with the document index for each; then group
  them into themes ranked by how often they appear.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every theme cites at least 2 quoted passages.
- Counts come from the documents, not estimates.
- Where the documents don't support a claim, you say so.
</quality_bar>
 
<output_format>
The quotes (index | passage), a theme table (theme |
count | example quote), then the top 3 in one line each.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

<materials>
[paste this release's raw notes]
</materials>
 
<examples>
<example>
Before: Fixed bug where export failed for large files.
After: Exports over 2 GB now finish
instead of stopping halfway.
</example>
<example>
Before: Added dark mode.
After: Dark mode is here: Settings > Appearance.
</example>
<example>
Before: Performance improvements to search.
After: Search results now appear about
twice as fast on large workspaces.
</example>
</examples>
 
<task>
Release notes in our house style for the raw notes above.
</task>
 
<requirements>
- Match the tone and structure of
  the examples, not their content.
- Lead with what the user can now do; one line per change.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every line names a change the user
  can see, not an internal one.
- No number appears that isn't in the raw notes.
</quality_bar>
 
<output_format>
A bullet list, one change per bullet, each under 20 words.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

<materials>
<notes>
[paste the meeting notes]
</notes>
</materials>
 
<task>
Every action item in the notes, as
JSON to import into our task tracker.
</task>
 
<requirements>
- Never invent owners, dates or tasks:
  use null where the notes don't say.
- Do not infer dates from words like "soon".
</requirements>
 
<quality_bar>
Before answering, check your output against:
- Every item's quote appears word for word in the notes.
- The output parses as JSON, with
  nothing before or after it.
</quality_bar>
 
<output_format>
Only JSON, matching:
{"items": [{"owner": "string or null",
            "task": "string, imperative, under 15 words",
            "due": "YYYY-MM-DD or null",
            "quote": "the sentence it came from"}],
 "assumptions": ["string"]}
</output_format>
 
<process>
Put any assumption you made in "assumptions", not in prose.
</process>

[medium: photo | oil painting | watercolor | 3D render] of
[subject, e.g. two elderly fishermen mending a red net],
[action or pose, e.g. laughing mid-conversation], in
[setting, e.g. a small harbor at dawn], [composition, e.g.
wide shot, subjects in the lower third], [camera and lens,
e.g. 35mm, eye level],
[lighting: window light | golden hour | overcast | flash],
[palette, e.g. muted teal and orange], [style or era, e.g.
1970s documentary photo], [mood, e.g. quiet and warm].
Aspect ratio [ratio: 1:1 | 4:5 | 16:9 | 9:16 | 2:3].
Exclude: [nouns to avoid, e.g. text, watermark, frame].

Product photo of a matte black ceramic coffee mug with a
thin gold rim, steam rising, on a pale oak table by a
window. Close-up, mug slightly left of center with empty
space on the right for text. 50mm lens, shallow depth of
field. Soft morning window light from the left. Warm
neutral palette, cream and walnut tones. Calm, minimal
mood. Aspect ratio 4:5.
Exclude: text, logos, hands, clutter.

[shot: wide | medium | close-up | over the shoulder] of
[subject with fixed details, e.g. a woman in a yellow
raincoat with short black hair], [one action with its
pace, e.g. turns and walks slowly toward the camera],
in [setting, e.g. a rain-soaked night market at night].
Camera:
[move: static | pan | dolly in | tracking | handheld].
Lens: [focus, e.g. shallow depth
of field, rack focus to the sign].
Style: [look, e.g. 35mm film grain, warm grade]. Lighting:
[light, e.g. neon reflections, teal and magenta].
Duration: [seconds, e.g. 5] seconds. Audio: [sounds,
one per sentence, e.g. Rain patters on canvas.]

About me: I run a small product studio.
I'm expert in visual design, a beginner in
finance, law, marketing and engineering.
 
How to answer: lead with the answer, then
reasons. Use tables for comparisons. Define
technical terms the first time. Use US spelling.
 
Standing rules: Never invent numbers, names, quotes or
sources: write [NEEDS SOURCE] where support is missing.
Ask me up to 3 questions first if anything missing would
change your answer; otherwise go on. When an answer rests
on guesses, end with a list of the assumptions you made.

Rewrite this prompt in the skeleton (materials, context,
examples, task, requirements, quality_bar, output_format,
process): [paste your prompt]. Where it needs facts only
I have, write [NEEDS SOURCE: what's missing] instead of
inventing them. Then list the 3 changes that matter most.

<materials>
<draft_prompt>
[paste your prompt]
</draft_prompt>
</materials>
 
<context>
I'll use it in [tool, e.g. a chat assistant with web
search on], [use: once | as a template I reuse]. I
know [my level: nothing | the basics | a lot] about
[field, e.g. email marketing].
</context>
 
<task>
My draft rebuilt as a strong prompt in this
skeleton: materials, context, examples, task,
requirements, quality_bar, output_format, process.
</task>
 
<requirements>
- The task names the deliverable by its
  professional name, and the decision it feeds.
- Replace any "act as" or "you are" line with
  the standards, frameworks or methods the
  field uses, and say who the output is for.
- Turn vague words into placeholders in one of
  two forms: [label: option | option] using the
  field's own terms, or [label, e.g. example].
- Keep the three standard lines: no invention with [NEEDS
  SOURCE], up to 3 questions first, assumptions at the end.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your rewrite against:
- Everything in my draft survives, or is
  cut on purpose with the reason given.
- The quality bar holds 3–5 checks a professional
  in the field would actually apply.
- Every placeholder is something only I can fill.
</quality_bar>
 
<output_format>
The rewritten prompt in one text block; the 3 changes
that matter most, and why; the placeholders I must fill.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

I want [rough goal, e.g. a pricing page for my app].
I'm new to [field, e.g. conversion copywriting]. Before
producing anything, ask me the questions a professional
would ask a client first: at most 10, grouped, each
with why it matters and 2–3 typical answers. Then stop.

<context>
I want [rough goal, e.g. a pricing page for my budgeting
app]. I'm
[my level: new to | familiar with | experienced in] [field,
e.g. conversion copywriting]. What exists: [current state,
e.g. a draft page and last month's analytics].
</context>
 
<task>
Interview me before you produce anything. The
end result will be [deliverable, e.g.
landing-page copy with layout notes]; first you
need the brief a professional would collect.
</task>
 
<requirements>
- At most 10 questions, grouped by topic, in
  the order a professional would ask them.
- For each: one line on how the answer changes
  the deliverable, and 2–3 typical answers I
  can pick from, in the field's own terms.
- No deliverable, outline or options yet.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your questions against:
- Each answer would change the deliverable;
  drop any question that wouldn't.
- Nothing I already told you is asked again.
- The typical answers teach me the
  vocabulary I'll need to judge the result.
</quality_bar>
 
<output_format>
Numbered questions under group headings, and nothing else.
</output_format>
 
<process>
Ask all the questions in one message, then stop. When I
answer, write the brief back as a bullet list for me to
confirm, and end with a list of the assumptions you made.
</process>

I'm about to work on [task, e.g. choosing a database]
in [field, e.g. backend engineering] and know nothing
about it. Teach me the 12 terms I'll hear most, the 3
named standards or frameworks professionals use, and
the 5 beginner mistakes, applied to my case, in under
600 words. Check every framework is a real, named one.

<context>
I'm about to work on [task, e.g. choosing a database
for an app with 10,000 users] in [field, e.g. backend
engineering]. My background: [background, e.g. product
designer who can read code]. I'll use this to [use,
e.g. brief a contractor and judge their proposal].
</context>
 
<task>
A one-page primer on this field, applied to my task.
</task>
 
<requirements>
- The 12 terms I'll hear most, one line
  each, with an example from my case.
- The 3 named frameworks, standards or methods
  professionals use to decide here, and what each checks.
- The 5 mistakes beginners make, and 5 questions to
  ask any expert or AI before accepting their answer.
- Sources to read next: official
  docs, standards, well-known books.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every term is one I'll meet on this task
  in the next month, not textbook trivia.
- Each framework is real and named, and
  described the way its authors describe it.
- A professional would agree with
  the list of beginner mistakes.
</quality_bar>
 
<output_format>
Four short sections, with tables where they
help; under 600 words; plain US English.
</output_format>
 
<process>
End with a list of the assumptions you made about my task.
</process>

For [goal, e.g. onboarding emails for a new app],
give me 3 genuinely different approaches a
professional might take, a comparison table (best for
| effort | main risk) and a recommendation for my
situation: [constraints, e.g. one person, two weeks].
Check they differ in method, not wording. Then stop.

<materials>
[paste the brief from the interview, or your notes]
</materials>
 
<context>
Constraints: [constraints, e.g. one person, two
weeks, no budget for paid tools]. What matters most:
[priority: speed | cost | quality | low risk].
</context>
 
<task>
2–4 materially different approaches to
[goal, e.g. onboarding emails for our app],
so I can choose before anything is drafted.
</task>
 
<requirements>
- Approaches that differ in method or
  structure, not just in wording or tone.
- For each: a one-paragraph summary, what it's best for,
  effort, main risk, and what it looks like done well.
- Name the standard, framework or method
  each approach follows, if it has one.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- A professional would see each option
  as a real choice, not a straw man.
- The trade-offs say what each approach makes worse.
- The recommendation follows from my constraints
  and priority, and says what would change it.
</quality_bar>
 
<output_format>
One short section per approach; a comparison
table (approach | best for | effort | main
risk); a recommendation in under 80 words.
</output_format>
 
<process>
End with a list of the assumptions you made. Then
stop and wait for my choice; don't draft anything.
</process>

This is a fresh chat. Review this draft for [audience, e.g.
a CFO deciding on next year's budget]: [paste draft]. Write
the 5–7 criteria a professional would judge it on, score it
1–5 on each with evidence, then list the 5 worst problems
with fixes. Do not rewrite it and do not praise it.

<materials>
<draft>
[paste the draft]
</draft>
<brief>
[paste the brief or prompt the draft was written from]
</brief>
</materials>
 
<context>
This is a fresh chat: you did not write this
draft. It is for [audience, e.g. a CFO who reads
only the first paragraph], who will use it to
[decision, e.g. approve or cut the budget].
</context>
 
<task>
A critique of the draft against the
brief and the standards of its field.
</task>
 
<requirements>
- First the rubric a professional would use: 5–7
  criteria, naming any standard the field uses.
- Score the draft 1–5 on each, with
  one line of evidence quoted from it.
- The 5 most important problems, worst
  first, each with a concrete fix.
- Do not rewrite the draft. Do not praise it.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your critique against:
- Every problem points at a specific passage.
- The ranking follows the reader's decision, not your taste.
- If there are fewer than 5 real problems,
  you say so instead of padding the list.
</quality_bar>
 
<output_format>
The rubric; a score table (criterion | score |
evidence); the ranked problems (problem | where | fix).
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

List every factual claim, number and citation in this
answer as a table (claim | confidence high/medium/low
| how to verify | primary source to check): [paste
answer]. Redo any arithmetic step by step, and check
for anything that looks invented or out of date.

<materials>
<answer>
[paste the answer]
</answer>
</materials>
 
<context>
I plan to use this in [use, e.g. a board update
next week]; a wrong number would [consequence,
e.g. undermine the whole update].
</context>
 
<task>
A fact-check of the answer before I rely on it.
</task>
 
<requirements>
- Every factual claim, number,
  date, name and citation in it.
- For each: confidence (high, medium or low), how
  to verify it, and the primary source to check.
- Redo every calculation step by step, or
  with your code tool if you have one.
- Flag anything that may be out of date given your knowledge
  cutoff, and any citation you can't confirm exists.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your table against:
- No claim from the answer is missing.
- "High" means you could say where it is documented.
- Corrected numbers show the working.
</quality_bar>
 
<output_format>
A table: claim | confidence | how to verify
| primary source | corrected value (if
any). Then the 3 claims to check first.
</output_format>
 
<process>
If web search is on, check the 5 riskiest
claims and cite the pages you read. End
with a list of the assumptions you made.
</process>

Write 4 prompts for [tool, e.g. Midjourney] for [use,
e.g. a blog header, 16:9] showing [idea, e.g. a calm desk
at dawn]: subject, medium, composition, lighting, color,
mood, aspect ratio; vary one element per prompt. Check
any in-image text is under 25 characters, in quotes.

<materials>
[paste brand guidelines, or describe 1–3 reference images]
</materials>
 
<context>
The image is for [use, e.g. a blog header, 16:9, with
the title overlaid on the right]. The message: [idea,
e.g. freelancing doesn't have to be chaotic]. The
audience: [audience, e.g. freelancers aged 25–45]. The
brand feels [adjectives, e.g. calm, warm, competent].
</context>
 
<examples>
Like: [paste a prompt, or describe
an image you like, and why]
Not like: [paste or describe one you don't, and why]
</examples>
 
<task>
4 image prompts for
[tool: Midjourney | Flux | Ideogram | Adobe Firefly],
ready to paste.
</task>
 
<requirements>
- Each prompt is one descriptive paragraph: subject,
  [medium: photo | 3D render | illustration | watercolor],
  composition and framing, camera and lens for photographic
  looks, lighting, color palette, mood, aspect ratio.
- Each varies one element from the first:
  lighting, viewpoint, palette or style.
- Describe style traits rather than naming living artists.
- A negative list of nouns to exclude.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your prompts against:
- They describe what a camera or painter would
  see, with no instructions or arguments.
- Space is left where the title goes.
- Any in-image text is under 25 characters and in quotes.
</quality_bar>
 
<output_format>
4 numbered prompts, each followed by one line on
what it changes; the negative list; then any tool
syntax (aspect ratio, exclusions) separately.
</output_format>
 
<process>
End with a list of the assumptions you made about the brief.
</process>

Write a shot list for a [length, e.g. 20]-second
video about [idea, e.g. our app's launch] for
[platform, e.g. Instagram Reels, 9:16]. Per shot:
type, subject, one action, setting, one camera move,
duration, style, lighting, audio. Check recurring
characters have the same description, word for word.

<materials>
[paste the script, storyboard
notes or reference images, if any]
</materials>
 
<context>
The video: [idea, e.g. a 20-second teaser for our
budgeting app's launch] for [platform, e.g. Instagram
Reels, 9:16]. Tool: [tool: Runway | Veo | Sora | Kling];
each generation is a few seconds long. Look:
[look: live action | 3D | stop-motion | hand-drawn].
Audience: [audience, e.g. freelancers who hate admin].
</context>
 
<task>
A shot list, then one standalone generator
prompt per shot, so the clips cut together.
</task>
 
<requirements>
- [number of shots, e.g. 5] shots; for each: shot type,
  subject, one action with its pace, setting, one primary
  camera move, duration, style, lighting and color, audio.
- Recurring characters and props get one fixed
  description, repeated word for word in every shot.
- Describe what you want, not what you don't:
  "smooth, stable camera", not "no shake".
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your shot list against:
- The durations add up to the total length.
- Each prompt stands alone: pasted by itself, it
  gets the right character, setting and look.
- Each shot has exactly one action and one camera move.
</quality_bar>
 
<output_format>
A shot table (shot | type | action | camera | duration
| audio), then each shot's prompt as its own paragraph.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

/goal [end state, e.g. npm test exits 0], shown by [printed check, e.g.
its summary line]; without [constraint, e.g. changing test files]; or
stop after [turns: 10 | 20 | 30] turns.

<materials>
[paste the task, its quality bar, and how the work is checked: test
commands, validators, templates]
</materials>
 
<context>
I'll run this as a goal in [agent: Claude Code | another agent that
re-checks a condition after every turn]. The checker reads only the
conversation: it can't run commands or open files.
</context>
 
<task>
Write a completion condition for this task, under 4,000 characters.
</task>
 
<requirements>
- One measurable end state, and the exact check whose printed output
  proves it.
- The constraints that must still hold: files not to touch, behavior
  to keep.
- A bound: [bound: a turn limit | no progress in two rounds | both].
- Never invent commands or file names: write [NEEDS SOURCE] where you
  don't know them.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Could someone reading only the conversation decide met or not met?
- Is "done" one state, not a list of hopes ("better", "clean")?
- Does it stop in a bounded number of turns even if the task turns out
  to be impossible?
</quality_bar>
 
<output_format>
The condition as one paragraph, then the /goal line to paste, then one
line saying what Claude must print each turn.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change the
condition. End with a list of the assumptions you made.
</process>