A curated set of vetted prompts for tasks that come up over and over. Each prompt is annotated with what it's for, why it's structured the way it is, and where to tweak it. Hover any block for a copy button.
Use when: classifying inbound support messages into a fixed set of categories for routing.
You are an automated triage assistant for a SaaS support inbox.
Classify the user's message into exactly one of the following categories:
- billing — questions about invoices, charges, refunds, or payment methods
- technical — bugs, errors, feature not working as expected
- account — login, password, access, account settings
- feedback — feature requests, complaints, suggestions
- other — anything that doesn't fit above
Rules:
- If the message contains multiple issues, classify by the primary one.
- If you cannot determine the category with reasonable confidence, return "other".
- Never invent a category not in the list.
Examples:
Message: "I was charged twice for May."
Category: billing
Message: "The app crashes whenever I open the settings page."
Category: technical
Message: "{user_message}"
Category:Use when: sentiment classification where "neutral" matters and you don't want false positives in either direction.
Classify the sentiment of the text as "positive", "negative", or "neutral".
Use "neutral" when the text:
- Reports facts without clear emotional valence
- Contains both positive and negative elements that roughly balance
- Is too short or vague to determine
Examples:
Text: "Honestly the best meal I've had this year."
Sentiment: positive
Text: "It was fine. Nothing to write home about."
Sentiment: neutral
Text: "Cold food, rude staff, never coming back."
Sentiment: negative
Text: "{input}"
Sentiment:Use when: extracting fields from unstructured text and you need to know which span each field came from.
Extract the following fields from the document below:
- invoice_number (string)
- total_amount (number, no currency symbol)
- due_date (ISO 8601 date)
- vendor_name (string)
Rules:
- Return a JSON object with each field.
- For each extracted field, include a "_source" version with the
exact substring from the document the value came from.
- If a field is not present, set its value to null and omit "_source".
- Do not infer or compute values not literally stated.
Document:
<document>
{document_text}
</document>
Output (JSON only, no other text):Use when: the entity types are known but the count and exact mentions vary.
Extract all named entities of the following types from the text:
- PERSON (people's names)
- ORG (companies, organizations)
- LOCATION (cities, countries, regions)
- PRODUCT (specific named products)
Output a JSON array of objects: [{"type": "...", "value": "...", "context": "..."}]
where "context" is the sentence the entity appears in.
Deduplicate entities that refer to the same thing (e.g., "Google" and
"Google LLC" → keep one). Use the most complete form available.
If no entities of a type are found, simply omit them from the array.
Text:
<text>
{input}
</text>
JSON:Use when: you need consistent summary structure across documents.
Summarize the document below. Your summary must contain exactly:
1. One sentence stating the main point.
2. Three bullet points listing the most important supporting facts.
3. One sentence on what's notably absent or unanswered.
Constraints:
- Total length: under 120 words.
- Use only information present in the document.
- If a section cannot be filled (e.g., nothing notably absent), say so explicitly.
Document:
<document>
{document}
</document>
Summary:Use when: the document exceeds context window. Run the chunk prompt on each chunk in parallel, then the reduce prompt over the chunk summaries.
// CHUNK PROMPT (run on each chunk)
Summarize the following section of a larger document. Your summary
will later be combined with summaries of other sections to produce
a final summary.
- Capture distinct claims, decisions, or events. Skip throat-clearing.
- If this section continues a thought from elsewhere, note that.
- 80 words maximum.
Section:
<section>
{chunk}
</section>
Summary:
// REDUCE PROMPT (run on combined chunk summaries)
You are given summaries of consecutive sections of one document.
Combine them into a single coherent summary of the whole document.
- Eliminate redundancy across section summaries.
- Preserve the document's structure and progression.
- 200 words maximum.
Section summaries:
{joined_chunk_summaries}
Combined summary:Use when: turning rough notes into a polished email while preserving voice.
Turn the bullet notes below into a complete email.
Voice: direct, professional, no filler. Short sentences. No corporate
hedging ("I just wanted to..."), no apologies for length, no "I hope
this finds you well."
Structure:
- One-line subject (no longer)
- Greeting
- Body that covers each note in order
- Action ask if any note implies one
- Sign-off
Notes:
<notes>
{notes}
</notes>
Recipient context: {recipient_context}
Email:Use when: generating code that needs to integrate with an existing codebase.
Write a {language} function that {functionality}.
Constraints:
- Match the style of this existing code in the codebase:
<existing_code>
{example_function}
</existing_code>
- Use only these imports/dependencies: {allowed_imports}
- Handle these error cases explicitly: {error_cases}
- Include a docstring matching the existing style.
- Do not add explanatory text outside the code.
Output the function only:Use when: answering questions from retrieved context where wrong answers are worse than no answer.
Answer the question using only the documents below.
Rules:
- Cite each factual claim with the document ID in square brackets, e.g. [doc_47].
- If the documents don't contain the answer, respond exactly:
"I don't have information about that in the provided sources."
- Do not use prior knowledge; only the documents.
- If documents disagree, present both with citations.
Documents:
{documents}
Question: {question}
Answer:Use when: the model needs to make a decision and you need to inspect the reasoning.
You are deciding whether to {decision_question}.
Use this structure:
<analysis>
1. What are the relevant facts?
2. What is the strongest argument for YES?
3. What is the strongest argument for NO?
4. What are you uncertain about?
</analysis>
<decision>
YES or NO
</decision>
<confidence>
high | medium | low
</confidence>
<one_sentence_reason>
The single most important factor.
</one_sentence_reason>
Inputs:
{inputs}Use when: iterating on a prompt that fails on a specific case.
I have a prompt that is failing on a specific input. Help me revise it.
Current prompt:
<prompt>
{current_prompt}
</prompt>
Failed input:
<input>
{input}
</input>
Wrong output the prompt produced:
<wrong_output>
{wrong_output}
</wrong_output>
Correct output:
<correct_output>
{correct_output}
</correct_output>
Revise the prompt to handle this failure case while keeping it working
on cases it already handles. Make minimal changes — do not over-fit
to this single example.
Output the revised prompt only, with no commentary.Use when: scoring open-ended outputs at scale.
You are evaluating an AI assistant's response to a user question.
Question:
{question}
Response:
{response}
Score the response on each dimension below using the rubric.
ACCURACY (1-5)
5 = All factual claims are correct and verifiable.
3 = Mostly correct, but contains a minor unverifiable claim.
1 = Contains a clear factual error.
COMPLETENESS (1-5)
5 = Fully answers the question.
3 = Partial answer; key part missing or shallow.
1 = Doesn't answer the question.
CLARITY (1-5)
5 = Easy to read on first pass.
3 = Understandable with effort.
1 = Confusing or contradictory.
Before scoring, write 2-3 sentences of analysis. Then output JSON:
{"accuracy": N, "completeness": N, "clarity": N, "analysis": "..."}These prompts are starting points, not finished products. The right next step for any of them is: drop it into your stack, run it on your real inputs, find where it fails, and revise. Module 5 of the course covers that loop in detail.