Table of Contents
A reusable prompt template gives a recurring task a consistent starting point. Replace the bracketed fields with your own input, specify what a good result looks like, and check the answer before using it. Templates can reduce ambiguity; they do not guarantee accurate output.
1. Extract information into a fixed format
Use this for contact details, document fields, or other information that must be easy to compare.
Extract [information] from the source below.
Return these fields: [field names and definitions].
Use "Not specified" for missing values. Do not infer them.
Source:
[paste source]Example: extract name, role, company, and email from a signature. Provide one completed example if the field format is unusual. If another program will consume the result, request JSON or CSV and validate its syntax separately.
2. Set a role and working approach
A role can help specify the viewpoint and tone. Describe the behavior you want rather than inventing credentials for the assistant.
Review this as a product manager for [audience].
Focus on the user problem, implementation effort, and missing evidence.
Use concise bullets and label assumptions.
Task: [request]
Context: [relevant details]For a dashboard proposal, ask who needs it, what decision it supports, and which existing reports fail to meet that need. A role prompt does not give the model verified expertise; see how roles and personalities affect prompting.
3. Analyze a decision using defined criteria
Use this when a broad request such as “What should we do?” produces an unfocused answer.
Analyze [situation] using these criteria:
1. [criterion and relevant question]
2. [criterion and relevant question]
3. [criterion and relevant question]
For each, state the evidence, assumptions, and uncertainties.
Recommend a next step based on [priority].For a build-versus-buy decision, criteria might include the required features, maintenance effort, integration needs, and available budget. Supply the actual constraints rather than asking the model to assume them.
4. Test a plan with a critique
Critique this plan: [plan].
Identify its weakest assumptions, likely failure points, and missing information.
Separate evidence-backed concerns from speculation.
For each major concern, suggest a question or test that could resolve it.This is useful before starting a project or changing a workflow. Review whether the objections fit your circumstances; a forceful critique can still be wrong.
5. Improve a draft in rounds
Review this draft for [audience and purpose].
Identify what to keep and the three most important problems.
Explain a concrete fix for each, then provide a revised draft.
Preserve names, dates, and factual claims. Flag unsupported claims.
Draft: [text]For a product-launch email, include the reader’s problem and the real benefit of the feature. Check that the revision does not invent capabilities or change commitments. Ask for a second pass on one remaining issue rather than repeatedly requesting “make it better.”
6. Convert content without losing meaning
Convert [source format] into [target format].
Preserve: [facts, decisions, owners, deadlines].
Change: [organization, length, tone].
Mark missing information explicitly; do not invent it.
Source: [content]Example: turn meeting notes into a checklist with an owner and deadline for each action. Keep “next week” as written unless the meeting date makes an exact date unambiguous. Compare the checklist with the notes to catch omitted commitments.
7. Compare options for a particular use case
Compare [option A] and [option B] for [use case].
Criteria: [list].
Priorities: [ranked priorities].
Use a table with the evidence, tradeoffs, and unknowns for each criterion.
Recommend an option only if the available information supports it.For PostgreSQL versus MongoDB, include the data model, query needs, operational constraints, and the team’s experience. If versions, prices, or features matter, supply current documentation or ask for verifiable sources.
8. Generate ideas within explicit constraints
Create [number] ideas for [purpose and audience].
Hard requirements: [requirements].
Preferences: [preferences].
Avoid: [words, styles, or approaches].
Check each idea against the hard requirements before returning it.For a coffee-brand slogan, you might require eight words or fewer and forbid exclamation marks. Do not imply a sustainability certification or product quality claim unless the brand can support it.
Keep a small, tested template library
Save the prompt, one representative input, and an example of an acceptable result. Test missing fields and unusual inputs as well as the easy cases. Record which model or tool you used and update the template when its behavior changes.
For more examples of task context and success criteria, see writing better business prompts. Keep the library focused on tasks you actually repeat.
Reader Comments 0
Sign in with email or Google to join the discussion.