--- title: "48 AI Prompt Templates with Variables | Prompt Pebble" description: "Search 48 original AI prompt templates for writing, coding, analysis, learning and business. Fill in their {{variables}}, then copy or download the prompt." url: https://promptpebble.click/prompt-templates/ --- Original · searchable · free to use # Prompt templates 48 practical prompts for everyday work, written for this site. Search or pick a category, open a template, fill in its {{variables}} and copy the finished prompt. ## The templates - Writing ### Blog post outline Plan a post before writing it: working titles, a promise to the reader and the point of every section. - `topic` - `audience` - `reader_goal` - `section_count` **Read the template** ``` You are an experienced editor who plans articles before they are written. Create an outline for a blog post about {{topic}} for {{audience}}. By the end, the reader should be able to {{reader_goal}}. Include: - three working titles, each under 70 characters - a one-sentence promise the introduction will make - {{section_count|five}} sections, each with a heading, the single point it makes and one concrete example or piece of evidence to use - a closing section with one practical next step for the reader Do not write the post itself. Mark any claim that needs a source with [source needed]. ``` - Writing ### Rewrite in plain language Turn dense, formal or technical text into something anyone can follow, without losing a single fact. - `reader` - `text` **Read the template** ``` Rewrite the text below in plain language for {{reader|a general adult reader}}. Rules: - Keep every fact, number, date and obligation. Do not add new information. - Prefer short sentences and common words; explain any technical term you must keep. - Use the active voice and address the reader as "you" where it fits. - Keep headings and lists if the original has them. After the rewrite, list any sentence where you were unsure of the original meaning. {{text}} ``` - Writing ### Change the tone of a draft Make a message warmer, firmer, more formal or more relaxed while keeping its facts and requests intact. - `target_tone` - `current_tone` - `recipient` - `draft` **Read the template** ``` Rewrite the draft below so it sounds {{target_tone}} rather than {{current_tone|the way it sounds now}}. It is going to {{recipient}}. Keep the meaning, the facts and any requests exactly as they are. Keep it about the same length unless the new tone needs it shorter. Do not add apologies or praise that are not in the original. Give me the rewrite first, then three short notes on the main changes you made. {{draft}} ``` - Writing ### Reply to an email Answer every question in an email in order, in your chosen tone, with placeholders where you have not decided yet. - `my_points` - `relationship` - `tone` - `max_words` - `email` **Read the template** ``` Help me reply to the email below. What I want to say: {{my_points}} Who the sender is to me: {{relationship}} Tone: {{tone|friendly and direct}} Write a reply of at most {{max_words|150}} words. Answer every question the sender asked, in the order they asked them. If the email asks for something my points do not cover, put a placeholder in [square brackets] instead of inventing an answer. {{email}} ``` - Writing ### Product description A headline, a short paragraph and benefit-led bullets built only from the facts you supply. - `product_name` - `customer` - `facts` - `spelling` **Read the template** ``` Write a product description for {{product_name}}, aimed at {{customer}}. Facts you may use (use nothing else): {{facts}} Write: 1. A headline of up to 10 words. 2. A paragraph of 40 to 60 words on the problem it solves. 3. Four bullet points, each starting with a benefit and backed by one of the facts. Avoid superlatives you cannot back up, such as "best" or "revolutionary". Use {{spelling|US}} English spelling. ``` - Writing ### Proofread without rewriting Fix spelling, grammar and punctuation only, and get a table of every change so nothing slips through unseen. - `variety` - `text` **Read the template** ``` Proofread the text below. Fix only spelling, grammar, punctuation and obvious typos; do not change word choice, style or structure. Return: 1. The corrected text. 2. A table of every change with the columns: original, correction, reason. If something looks wrong but could be intentional (a name, a brand spelling, a quotation), leave it and list it under "Check these" instead. Language variety: {{variety|US English}} {{text}} ``` - Writing ### Headline options A labelled mix of headline styles under a length limit, with the two strongest picked out and explained. - `count` - `audience` - `channel` - `max_characters` - `summary` **Read the template** ``` Suggest {{count|10}} headlines for the piece summarised below. The audience is {{audience}} and it will appear on {{channel}}. Mix these approaches and label each headline with the one it uses: direct benefit, question, number or list, how-to, surprising fact. Keep each under {{max_characters|65}} characters. No clickbait: every headline must promise only what the piece delivers. Finish by naming your top two and saying why in one sentence each. Summary: {{summary}} ``` - Writing ### Article to social posts Standalone posts that each carry one idea from an article, within the character limit of your platform. - `post_count` - `platform` - `character_limit` - `article` **Read the template** ``` Turn the article below into {{post_count|four}} standalone social media posts for {{platform}}. Each post must: - make one idea from the article clear on its own, without thread numbering - stay under {{character_limit|280}} characters, counting spaces - end with a question or a practical takeaway, not a pile of hashtags Use at most two hashtags across all the posts. Quote any figures exactly as the article gives them.
{{article}}
``` - Writing ### Cover letter draft Match your real experience to a job's requirements, and list the gaps instead of papering over them. - `job_title` - `company` - `requirements` - `experience` **Read the template** ``` Draft a cover letter for the role of {{job_title}} at {{company}}. Key requirements from the job ad: {{requirements}} My relevant experience, in my own words: {{experience}} Write three short paragraphs: why this role, two specific examples that match the requirements, and a polite close. Keep it under 300 words. Use only the experience I have given. Where a requirement is not covered, do not invent anything; list it after the letter under "Gaps to address". ``` - Writing ### Feedback on a draft What works, the three changes that matter most and the unclear sentences, without a full rewrite. - `reviewer` - `purpose` - `audience` - `draft` **Read the template** ``` Give me feedback on the draft below as a careful {{reviewer|editor}} would. The piece is meant to {{purpose}} for {{audience}}. Structure your feedback as: 1. What works: two or three points, with short quotes from the draft. 2. The three changes that would improve it most, most important first, each with a suggested fix. 3. Unclear sentences, quoted, each with a one-line explanation of the problem. Do not rewrite the whole draft. {{draft}} ``` - Coding ### Code review by priority Bugs and security problems first, then reliability, then style, with only the changed lines shown. - `language` - `purpose` - `code` **Read the template** ``` You are a senior {{language}} developer doing a code review. Review the code below. It is meant to {{purpose}}. Report your findings in three groups, most serious first: 1. Bugs and security problems: the line or snippet, why it fails and a fix 2. Performance or reliability risks 3. Readability and style, at most five points If a group has nothing worth mentioning, say so. Do not rewrite the whole file; show only the changed lines for each fix. {{code}} ``` - Coding ### Explain unfamiliar code A summary, a section-by-section walkthrough and the side effects you need to know about. - `language` - `reader_level` - `code` **Read the template** ``` Explain what the {{language}} code below does to someone who {{reader_level|knows programming but not this codebase}}. Start with a two-sentence summary. Then walk through it section by section, naming the inputs, the outputs and any side effects (files, network, database, global state). End with anything surprising or risky you noticed. Do not suggest changes unless something is clearly broken. {{code}} ``` - Coding ### Unit tests for a function Normal, edge and error cases with descriptive names, and assumptions marked where behaviour is unclear. - `test_framework` - `extra_cases` - `code` **Read the template** ``` Write unit tests for the function below using {{test_framework}}. Cover: - the normal case with typical input - edge cases: empty input, very large input and boundary values - invalid input and the errors it should raise - {{extra_cases|any other case the code suggests}} Give each test a descriptive name. If the function's behaviour in some case is ambiguous, write the test for the behaviour you think is intended and add a comment starting with "ASSUMPTION:". {{code}} ``` - Coding ### Debug an error Ranked likely causes, how to confirm each one, and a fix for the most likely, with no guessing about libraries. - `action` - `expected` - `error_message` - `environment` - `code` **Read the template** ``` Help me debug an error. What I was doing: {{action}} What I expected: {{expected}} What happened instead: {{error_message}} Environment: {{environment}} Relevant code: {{code}} First list the most likely causes, ranked, with one sentence on how to confirm or rule out each. Then give the fix for the most likely cause. If you are unsure how a library behaves, tell me what to check instead of guessing. ``` - Coding ### Refactor without changing behaviour Cleaner code with the same public interface and no new dependencies, plus any bugs reported separately. - `language` - `goal` - `extra_constraint` - `code` **Read the template** ``` Refactor the {{language}} code below to make it {{goal|easier to read and test}}, without changing its behaviour. Constraints: - Keep the public function names and signatures the same. - Do not add new dependencies. - {{extra_constraint|Keep it compatible with the language version it uses now}}. Return the refactored code, then a short list of what you changed and why. If you spot a bug, point it out separately rather than fixing it silently. {{code}} ``` - Coding ### Regex from examples A readable pattern that matches your examples and rejects your counter-examples, explained part by part. - `regex_flavor` - `what_to_match` - `should_match` - `should_not_match` **Read the template** ``` Write a regular expression for {{regex_flavor|JavaScript}} that matches {{what_to_match}}. It must match these examples: {{should_match}} It must not match these: {{should_not_match}} Give the pattern, explain each part in a short table, and list any input you think is ambiguous. Prefer a readable pattern to a clever one, and avoid patterns that can backtrack catastrophically. ``` - Coding ### SQL query from a question A query in your dialect from a plain-English question and your table list, with NULL handling explained. - `sql_dialect` - `question` - `schema` **Read the template** ``` Write a {{sql_dialect|PostgreSQL}} query that answers this question: {{question}} Tables (name: columns): {{schema}} Requirements: - Use explicit JOINs and table aliases. - Handle NULLs deliberately and say how. - Return only the columns needed to answer the question. After the query, explain in two or three sentences how it works and name any index that would make it faster. ``` - Coding ### Git commit message An imperative summary line of 50 characters or fewer and a wrapped body that explains what and why. - `footer` - `diff` **Read the template** ``` Write a git commit message for the change described below. Format: - A summary line in the imperative mood, at most 50 characters ("Add", "Fix", "Remove", not "Added"). - A blank line, then a body wrapped at 72 characters that explains what changed and why, not how. - {{footer|No footer}} Change description or diff: {{diff}} ``` - Coding ### Document a function Summary, parameters, return value, errors and a usage example in your language's docstring style. - `language` - `doc_style` - `code` **Read the template** ``` Write documentation for the {{language}} function below in the {{doc_style|usual}} docstring style for that language. Include a one-line summary, a description of each parameter and its type, the return value, the errors it can raise and a short usage example. Describe what the function does, not how it is implemented. If its behaviour is unclear from the code, say so in a note rather than guessing. {{code}} ``` - Coding ### Translate code to another language Idiomatic code in the target language with the same behaviour, and a list of places where the two may differ. - `source_language` - `target_language` - `code` **Read the template** ``` Translate the code below from {{source_language}} to {{target_language}}. - Use the idioms and standard library of {{target_language}} rather than copying line by line. - Keep the same behaviour, including edge cases and error handling. - Name any third-party library you rely on, and prefer the standard library where that is reasonable. After the code, list any behaviour that could differ between the two versions (integer overflow, string encoding, date handling and so on). {{code}} ``` - Coding ### Test plan for a sign-up flow Happy path, email verification, validation, refresh and accessibility cases, with the ones to automate marked. - `app_name` - `flow_steps` **Read the template** ``` Write a test plan for the sign-up flow of {{app_name}}. The flow: {{flow_steps}} Cover: - the happy path from the first screen to a confirmed account - email verification: the message arrives, the link works once, and an expired or reused link fails cleanly - validation errors for every field - what happens on refresh, with the back button and on a second device - accessibility: keyboard only, and screen reader labels Write each case as: ID, steps, expected result. Mark the cases worth automating with [auto]. ``` - Analysis ### Compare options against criteria A criteria-by-option table, a recommendation and what would have to change for another option to win. - `options` - `decision` - `criteria` **Read the template** ``` Help me choose between these options: {{options}}. The decision: {{decision}} What matters most to me, in order: {{criteria}} Build a comparison table with one row per criterion and one column per option, with a short note in each cell. Then say which option fits best and why, and what would have to be true for a different option to win. Make clear which points are facts I gave you and which are your assumptions. ``` - Analysis ### Find themes in feedback Counted themes, exact quotes and sentiment from survey answers, reviews or support tickets. - `feedback_type` - `feedback` **Read the template** ``` Find the main themes in the {{feedback_type|customer feedback}} below. For each theme give: - a short name - how many comments mention it (count them; do not estimate) - two representative quotes, copied exactly - whether the sentiment is mostly positive, negative or mixed List themes from most to least mentioned and put comments that fit no theme under "Other". Do not create a theme from a single comment unless it describes a serious problem, and flag those separately. {{feedback}} ``` - Analysis ### Five whys root cause Step-by-step whys that separate supported answers from guesses, ending in tests and a prevention step. - `problem` - `known_facts` **Read the template** ``` Help me find the root cause of this problem with the "five whys" method. Problem: {{problem}} What we know so far: {{known_facts}} Ask "why" step by step, at least five levels deep, and show each step. At each step, say whether the answer is supported by the facts above or is a guess that needs checking. Finish with the most likely root cause, two ways to test it and one change that would stop the problem coming back. ``` - Analysis ### Pre-mortem of a plan Imagine the plan failed and work back: ranked risks, early warning signs and steps to take now. - `time_horizon` - `plan` - `goal` **Read the template** ``` Run a pre-mortem on this plan. Imagine it is {{time_horizon|six months}} from now and the plan has clearly failed. The plan: {{plan}} The goal: {{goal}} List the ten most plausible reasons it failed, grouped under people, process, technology and outside events. Rate each for likelihood and impact (low, medium or high), and suggest one early warning sign and one step we could take now to reduce the risk. ``` - Analysis ### Check an argument for weak points Hidden assumptions, logical gaps and the strongest fair counterargument, so you can make the case stronger. - `argument` **Read the template** ``` Check the argument below for weak points. I want to make it stronger, not to be told it is good. {{argument}} Identify: 1. The main claim and the reasons given for it, one sentence each. 2. Assumptions that are not stated but must be true. 3. Logical gaps or fallacies, quoting the sentence involved. 4. The strongest counterargument a fair-minded critic would make. 5. The evidence that would make the argument more convincing. ``` - Analysis ### Extract fields to JSON Pull named fields out of messy text as JSON only, with null for anything missing and nothing guessed. - `fields` - `text` **Read the template** ``` Extract the following fields from the text below and return them as JSON only, with no commentary: {{fields}} Rules: - Use null for a field that is not in the text; never guess. - Copy names, numbers and dates as written, and also give dates in ISO 8601 form (YYYY-MM-DD) when the full date is known. - If a field appears more than once, return an array. {{text}} ``` - Analysis ### Meeting notes to decisions and actions Decisions, an owner-and-date action table and open questions, using only what the notes say. - `meeting_name` - `date` - `notes` **Read the template** ``` Turn these notes from {{meeting_name}} on {{date}} into a clear summary. Return: 1. Decisions made, one line each. 2. Action items as a table: task, owner, due date. Write "unassigned" or "no date" when the notes don't say. 3. Open questions that still need an answer. Use only what is in the notes and keep names exactly as written. {{notes}} ``` - Analysis ### Questions to ask a dataset Ten questions from simple to advanced, with the calculation or chart for each and the pitfall to avoid. - `subject` - `columns` - `goal` **Read the template** ``` I have a dataset about {{subject}} with these columns: {{columns}} My goal: {{goal}} Suggest the ten most useful questions to ask of this data, from simple to advanced. For each, give the calculation or chart that answers it and one pitfall to watch for (missing values, outliers, small samples, misleading averages and so on). Point out any column whose meaning is unclear before I rely on it. ``` - Analysis ### Summary for a busy reader The single most important point first, then the details needed to act, with numbers and dates kept exact. - `reader` - `time` - `document` **Read the template** ``` Summarise the document below for {{reader}}, who has {{time|two minutes}} to read it. Start with the single most important point in one sentence. Then give up to five bullet points with the details they need to act, including any numbers, dates and deadlines exactly as written. End with "Questions to ask" if anything in the document is unclear or contradictory. {{document}} ``` - Learning ### Explain a concept at my level A plain definition, an analogy and where it breaks, a worked example and the usual misunderstandings. - `concept` - `background` - `max_words` **Read the template** ``` Explain {{concept}} to me. My background: {{background}}. Start with a one-sentence definition in plain words. Then explain how it works using an everyday analogy, and say where the analogy breaks down. Give one worked example with real numbers or a concrete case. Finish with the two most common misunderstandings about it. Keep it under {{max_words|400}} words, and end with one question that checks my understanding. ``` - Learning ### Quiz me, one question at a time Mixed question types that adapt to your answers, with a summary of what to review at the end. - `topic` - `level` - `question_count` **Read the template** ``` Quiz me on {{topic}} at {{level|beginner}} level. Ask {{question_count|ten}} questions, one at a time, and wait for my answer before asking the next. Mix multiple-choice, short-answer and "explain why" questions. After each answer, tell me whether I'm right, give the correct answer with a one-line explanation, and adjust the difficulty of the next question. At the end, summarise what I know well and what I should review. ``` - Learning ### Week-by-week study plan Weekly focus, practice tasks and self-checks that fit the hours you actually have. - `skill` - `current_level` - `hours_per_week` - `weeks` - `goal` **Read the template** ``` Make a study plan for learning {{skill}}. My starting point: {{current_level}} Time available: {{hours_per_week}} hours a week for {{weeks}} weeks My goal: {{goal}} Give a week-by-week plan with a focus for each week, specific practice tasks and a small checkpoint I can use to test myself. Prefer free resources, and describe the kind of resource to look for rather than inventing titles or links. Include one review week. ``` - Learning ### Flashcards from your notes Question-and-answer cards that test understanding, not just definitions, as a two-column table. - `card_count` - `material` **Read the template** ``` Create {{card_count|20}} flashcards from the material below. Each card has a front (a question or prompt) and a back (a short answer of under 25 words). Test understanding, not just definitions: include some cards that ask "why", "what happens if" or "how is X different from Y". Return them as a two-column table: front, back. Base every card on the material alone. {{material}} ``` - Learning ### Socratic tutor Guiding questions instead of answers, small hints when you are stuck, and a reusable method at the end. - `subject` - `problem` **Read the template** ``` Act as a patient tutor for {{subject}}. I'm working on this problem: {{problem}} Don't give me the answer. Ask me one guiding question at a time, building on what I say. If I'm stuck twice in a row, give a small hint. If I make a mistake, ask a question that helps me spot it rather than correcting it directly. When I reach the answer, sum up the method in three steps so I can reuse it. ``` - Learning ### Language conversation practice A role-play in the language you are learning, pitched at your level, with one gentle correction per turn. - `language` - `level` - `role` - `situation` **Read the template** ``` Let's practise {{language}} conversation. My level is {{level|A2 (elementary)}}. Play {{role|a shopkeeper}} in this situation: {{situation}}. Rules: - Speak only in {{language}}, using vocabulary that suits my level. - Keep each of your turns to one or two sentences. - After each of my replies, add one short line in English starting "Tip:" that corrects my most important mistake, if there is one. Start the conversation. ``` - Learning ### Two concepts side by side Definitions, a table of differences, what they share and a rule of thumb for telling them apart. - `concept_a` - `concept_b` - `field` **Read the template** ``` Compare {{concept_a}} and {{concept_b}} for someone learning {{field}}. Give: 1. A one-sentence definition of each. 2. A table of the key differences: purpose, how it works, when to use it and a typical example. 3. What they have in common. 4. A simple rule of thumb for choosing between them. 5. One question that tests whether I can tell them apart, with the answer at the very end. ``` - Learning ### Step-by-step worked example Each step with its reason, the answer checked a second way, and a fresh practice problem to try. - `subject` - `problem` **Read the template** ``` Show me how to solve this {{subject}} problem step by step: {{problem}} Number each step and give the reason for it, not just the calculation. State any formula before you use it. If possible, check the final answer a second way. Then give me a similar practice problem with different numbers, with its answer at the very end so I can try it first. ``` - Learning ### Reading guide for a long text Questions to keep in mind, key terms and what to watch for, without spoiling the conclusions. - `title` - `text_type` - `subject` **Read the template** ``` I'm about to read {{title}}, a {{text_type|book}} about {{subject}}. Help me read it well. Give me: - five questions to keep in mind while reading - the key terms I should know first, each with a plain definition - what to pay attention to in each part, if you know how it is structured (say so if you don't) Don't summarise its conclusions; I want to reach them myself. ``` - Business ### Meeting agenda with time boxes Time-boxed items with owners, each marked inform, discuss or decide, and the reading to do beforehand. - `length` - `topic` - `attendees` - `outcome` **Read the template** ``` Draft an agenda for a {{length|45-minute}} meeting about {{topic}}. Attendees and their roles: {{attendees}} What we need to leave with: {{outcome}} For each item, give a time box, an owner and whether it is to inform, discuss or decide. Put decisions early, leave five minutes at the end to confirm actions and owners, and list anything people should read or prepare beforehand. ``` - Business ### One-page project brief Goal, scope, success measures, timeline and risks from rough notes, with proposed numbers clearly marked. - `notes` **Read the template** ``` Write a one-page project brief from my notes below. Sections: background, goal, in scope, out of scope, success measures, timeline, risks and open questions. Keep each section short. Make the success measures specific and measurable; where my notes give no number, propose one and mark it [proposed]. Do not add commitments, budgets or dates that are not in the notes. {{notes}} ``` - Business ### Customer support reply Acknowledge the problem, explain what happens next and promise nothing beyond what you can offer. - `company_name` - `resolution` - `policy` - `tone` - `max_words` - `customer_message` **Read the template** ``` Write a reply to the customer message below on behalf of {{company_name}}. What we can offer: {{resolution}} Our policy on this: {{policy}} Tone: {{tone|warm, clear and calm}} Acknowledge the problem in the customer's own terms, explain what happens next and when, and finish with one clear next step for them. Don't blame the customer and don't promise anything beyond what we can offer. Keep it under {{max_words|180}} words. {{customer_message}} ``` - Business ### Inclusive job description Responsibilities, essential skills and the first three months, in plain and inclusive language. - `job_title` - `company_description` - `responsibilities` - `must_have` - `nice_to_have` - `location` **Read the template** ``` Write a job description for a {{job_title}} at {{company_description}}. Responsibilities, from the hiring manager: {{responsibilities}} Must-have skills: {{must_have}} Nice-to-have skills: {{nice_to_have}} Location and working pattern: {{location}} Use plain, inclusive language and keep the must-have list to the essentials. Avoid jargon such as "rockstar" or "ninja" and age-coded phrases such as "digital native". Add a short section on what the first three months in the role look like. ``` - Business ### SWOT analysis with actions Specific strengths, weaknesses, opportunities and threats tied to your situation, then actions that use them. - `business` - `decision` - `context` **Read the template** ``` Do a SWOT analysis for {{business}}, focused on {{decision|its plans for the next year}}. Context: {{context}} For each of strengths, weaknesses, opportunities and threats, give three to five specific points tied to the context rather than generic statements. Then suggest three actions that use a strength to seize an opportunity or reduce a threat. Label anything that is your assumption rather than a fact I gave you. ``` - Business ### Customer interview guide Open, non-leading questions about past behaviour and workarounds, with opening and closing scripts. - `product_idea` - `learning_goal` - `interviewees` **Read the template** ``` Write a customer discovery interview guide for {{product_idea}}. We want to learn: {{learning_goal}} We will interview: {{interviewees}} Include a two-sentence opening script, then 12 open questions about the person's past behaviour and current workarounds, not their opinion of our idea. Avoid leading questions and questions that start with "Would you". Add follow-up prompts such as "Tell me about the last time…" and finish with a closing script that asks whether they know anyone else we should talk to. ``` - Business ### Goals to measurable objectives Objectives with outcome-based key results, baselines and targets, and questions for vague goals. - `team` - `period` - `goals` **Read the template** ``` Turn these goals into objectives and key results for {{team}} for {{period|the next quarter}}. Our goals, in our words: {{goals}} For each objective, give two to four key results that are measurable outcomes rather than tasks, each with a starting value and a target. Where we have no baseline, write "baseline needed". Flag any goal that is too vague to measure and ask a question that would sharpen it. ``` - Business ### Clear announcement Lead with what changes for the reader, who it affects and what to do, without the hype words. - `news` - `audience` - `channel` - `facts` - `max_words` **Read the template** ``` Write an announcement about {{news}} for {{audience}}, to be published on {{channel}}. Key facts: {{facts}} Lead with what changes for the reader and when. Say who it affects, what they need to do (if anything) and where to get help. Keep it under {{max_words|250}} words, with a headline of up to 10 words. Avoid hype words such as "excited", "thrilled" and "game-changing". ``` - Business ### Negotiation preparation Your strongest points, their likely objections with calm replies, low-cost trades and an opening line. - `subject` - `counterpart` - `my_goal` - `walk_away` - `their_position` **Read the template** ``` Help me prepare for a negotiation about {{subject}} with {{counterpart}}. What I want: {{my_goal}} My walk-away point: {{walk_away}} What I know about their position: {{their_position}} Give me my strongest arguments, their likely objections with a calm response to each, two or three things I could offer that cost me little, and an opening line. Keep the advice honest and fair: no pressure tactics. ``` No template matches that search. Try a shorter word, or choose All. ## How to use a template Each card says what the template is for and lists its variables, the gaps written as `{{name}}`. Choose Use template and a box appears for every variable, with the finished prompt updating as you type. A variable with a default, written `{{name|default}}`, uses that text when you leave its box empty; any gap you skip stays in braces so you can spot it before you paste. To run one template over many rows, such as a list of products or customers, choose Fill from a spreadsheet in the template window. It opens in the variable filler, where each CSV row becomes its own prompt. ### Making them your own Treat them as starting points. Add the context only you have, delete rules that don't apply and tighten the output format. The XML-style tags around pasted material, such as ``, keep your instructions apart from the content, so the model is less likely to confuse the two. **Testing an agent that signs up for things?** If your AI agent or automation has to receive verification emails, CleanTempMail's [Temp Mail API](https://cleantempmail.com/api) gives your tests disposable inboxes to read from, paid once per request quota with no subscription. It pairs well with the sign-up flow test plan template. ## Questions **Can I use these templates at work?** Yes. Use them, edit them and share the prompts you make with them, at work or anywhere else. Always check what the assistant writes back before you rely on it. **What do the double braces mean?** `{{topic}}` marks a variable, a gap for you to fill. `{{tone|friendly}}` is a variable with a default that is used when you leave it empty. Names ignore case, so `{{Topic}}` and `{{topic}}` are the same gap. **Which AI assistant are they written for?** None in particular. They are plain instructions that work in ChatGPT, Claude, Gemini, Copilot and other chat assistants, and in API calls. **Are the values I type saved?** No. They stay on the page until you close or reload it, and nothing is sent anywhere. Copy or download the finished prompt to keep it.