A/B test your prompting techniques.

What the AI will do

• Find current guidance for the model you use and write meaningful variations of your original prompt.
• Run or guide actual comparisons, repeat the promising pair and deliver the best usable prompt with the results behind it.

What you can provide

• An actual prompt you wrote, its source material and the model or app where you run it.
• What a good result looks like; previous outputs are helpful but not required.

Where you'll take part

• Agree a few judging criteria and evaluate qualities that depend on your needs.
• If the AI cannot call your target model, run the exact prepared packets in fresh chats and return their outputs for comparison.

What you'll get

A prompt tested on your task and model, actual comparison outputs and a concise explanation of what helped, including a tie if no version reliably wins.

Activity context

Take a prompt you actually use and try asking several different ways. Make it more specific, less prescriptive, longer and more detailed, or shorter and simpler. Then compare the work the same model actually produces. The winner is the prompt that helps with your task—not the one that sounds most sophisticated.

For the user

Bring your original prompt and the material it works on. The AI will identify the actual model, look up its current prompting guidance and prepare several versions of the same task. You will help judge the results. If it cannot run that model itself, it will give you exact packets to run and carry the comparison forward when you return the outputs. The accompanying prompting research is a dated starting point, not a permanent set of rules.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Help me A/B test prompting techniques using an actual prompt I wrote, the task I want done and the model I use. Do the comparison on actual outputs from that model. The aim is a more useful prompt for this work, not a universal recipe.

Establish the task, model and judging criteria

Start with my original prompt and source material in whatever form I have them. Inspect relevant accessible prior prompts, outputs, project instructions, emails or chats about the assignment and audience, and the document or data the prompt works on. Use those sources to establish the intended result, necessary facts, who will use it and what earlier outputs missed. Keep this search narrow; a self-contained task needs no wider company investigation.

Inspect the actual model selection or available configuration in the app or API. Record the model identifier or displayed selection, environment, date, available tools and supported settings. Ask me to confirm what you cannot see. Do not trust your unsupported self-description as proof of which model you are or silently substitute the model answering this conversation for the one I want to test. If the app exposes only a product label or automatic routing, record that limitation and keep the available selection constant.

Ask what I liked or disliked about the previous result. Agree two or three concrete criteria before running trials, including any unacceptable error. For example: uses the supplied evidence accurately, answers the decision question, and needs little editing for the intended reader. Where the audience matters, use its expressed requirements or feedback if available; label inferred preferences. Make the criteria usable against completed work, with a short description of what meeting each would look like. Preserve the same criteria for every version.

If required source material is inaccessible, investigate connection or export options and help me supply it. Do not start a comparison whose versions silently receive different essential information.

Turn current guidance into hypotheses

Search and open the latest official prompting instructions for the particular model and environment we will test, usually from the company that makes it. Check model applicability, dates and linked model-specific guidance. Search relevant original experiments or firsthand reports by others when they add a useful idea. Distinguish provider guidance, measured comparisons and practitioner suggestions. Do not transfer an old model's advice to the current model without checking it.

The accompanying prompting research can supply starting sources. If it cannot be opened, request pasted text only if needed; you can also inspect the relevant provider's current guidance directly. Starting points include OpenAI model guidance, Anthropic prompting guidance and Google prompt design strategies. Follow the applicable model-specific pages rather than treating those links as permanent defaults. If browsing is unavailable, ask for the relevant official page text and distinguish the dated advice you can use from current guidance you have not verified.

Explain a few testable ideas in plain language. Examples include clearer success criteria, one relevant example, stronger separation between instructions and source material, a different order, or more freedom for the model to choose its method. Treat the guidance as a reason to run a comparison, not proof of a winner.

Create different ways of asking for the same work

Save my original prompt unchanged as the baseline. Create a manageable initial set, normally the baseline plus four alternatives:

• More specific: resolve ambiguous terms and make the desired result and important constraints more explicit.
• Longer and more detailed: add relevant context, an example or an edge case while preserving the task.
• Shorter and less detailed: remove repetition and unnecessary procedure while retaining essential requirements and facts.
• Less prescriptive: give the model more freedom about approach or presentation while preserving the problem and a recognizable completion point.

Add or substitute a small model-specific treatment when the current guidance supplies a clear reason. Name what each variation tests and show the meaningful changes. Keep the underlying task, required source facts and intended output equivalent. Do not call a different assignment an improved prompt, or make the shorter version fail by withholding necessary source information.

Separate the shared source packet from each prompt where useful, so every trial gets the same material. Any added worked example or instruction is an explicit treatment, not a hidden source advantage. The first screen can compare bundled rewrites; later paired trials should isolate the promising change before drawing a conclusion about a technique.

Keep the number of trials proportionate to the cost and duration of the task. Explain and resolve any material cost or scope decision before running it.

Run actual comparisons in equivalent contexts

Inspect whether you can actually call the target model with the required source material. If you can, run the baseline and selected alternatives in fresh sessions with the same model selection, tools, source packet and available settings. Do not include other versions' outputs, the writing conversation or your preferred answer in the trial contexts. Record the exact prompt, actual output, model selection, relevant settings and run conditions for each trial. Re-run the original baseline under these conditions; an old response from a different environment is background, not a controlled baseline.

Where retrieval or web access is part of the task, hold the accessible source set and retrieval conditions as constant as practical, or use the same saved source snapshot when that preserves the task. Record changing web results, hidden memory or routing and any other unavoidable difference. Do not claim those conditions were controlled when they were not.

If you cannot call the target model, prepare numbered, self-contained trial packets with the exact prompts, identical source material or attachments, the model/settings to choose, instructions to start a fresh chat for each and a simple way to return each full output. Guide only the steps I need to perform. Wait for actual returned outputs before reporting results. Never simulate the missing runs or use another model without agreement. A trial packet is preparation, not a completed test.

Use agents for bounded trial execution only when their target model and conditions meet the comparison. Otherwise agents can help with independent judging; do not mistake the availability of subagents for access to the model being tested.

Judge the work and repeat the promising pair

Assign neutral labels to the completed outputs and compare them against the agreed criteria. Where supported, give a fresh reviewer the task, source material, criteria and outputs without prompt labels or your preferred verdict. Have it identify factual errors, missing requirements, clarity and the work needed to make each output useful, with concrete examples. Check its findings against the sources. If review shares context, say so rather than claiming blind independent judging.

Ask me to judge qualities only I can decide, such as whether I would use the result or whether its tone fits the audience. Do not replace usefulness with a score based merely on length or polish. Keep every output in the comparison, including failures.

Choose the strongest informative pair, retaining the original as a reference. Run both prompts again with equal trial counts and equivalent conditions. Two or three runs per prompt can provide an initial consistency check; they do not prove a general advantage. Where suitable additional task examples exist, try the pair on more than one representative input, with both versions receiving each same input. Preserve all results rather than selecting each version's best response.

If a promising rewrite bundled several changes and we want to know which technique helped, construct a pair that changes the suspected factor while holding the rest constant, then run and compare both. If the result depends on the input or remains a tie, preserve that conclusion. Do not invent statistical confidence from a small practical test.

Give me the usable prompt and what we learned

Deliver the best usable prompt, or the tied versions with the practical reason to choose between them. Include the original and tested alternatives, actual comparison outputs or accessible files, a compact account of the judging evidence and repeated trials, and the important uncontrolled conditions. Distinguish a promising rewrite from an isolated technique supported by the paired test.

Explain what improved, what did not and how much editing the result still needs. Keep conclusions attached to this task, model selection, environment and date. Say what change would justify retesting, such as a new model, changed source context or different output requirement. If access or returned outputs are still missing, state precisely that the comparison is unfinished and preserve the packets for continuation. Finish only when actual results support the recommendation.

Done when

You have run and compared actual outputs from the chosen model, repeated the promising pair under equivalent conditions and received the best usable prompt with concrete evidence of what improved—or a useful tie. Prepared packets alone do not complete the activity.

Research & resources

Read the supporting research. Download research as Markdown.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.