# Prompting in one page The few prompt habits that vendor docs and published tests agree on, the tricks that make no reliable difference, and how to save a prompt you reuse and change it without breaking it. Start here · v1.1 · draft · https://hayzlabs.com/start/prompting-in-one-page/ In short: - Brief it like a new colleague: the task, why, who it is for, what good looks like, and an example if you have one. - Put your question after long documents, and do not spend time on threats, tips or magic phrases. - Test a prompt you reuse on three cases, save it as a file with them, and re-run every case after each small edit. This is step 2 of [Start here](https://hayzlabs.com/start/start-here/). Come back to it any time your prompts feel hit and miss. ## The five-line brief Most of what matters is ordinary briefing. Anthropic's golden rule is: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too." It says to think of the AI as "a brilliant but new employee who lacks context on your norms and workflows". Its example of giving a reason is: "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." It calls examples "one of the most reliable ways to steer Claude's output format, tone, and structure" and suggests 3-5 of them ([Anthropic docs](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices), vendor guidance). 1. **Say the task in a line (1 minute).** One sentence on what you want. 2. **Say why (1 minute).** Give the reason behind any rule, as in the speech example above. 3. **Name who it is for (1 minute).** Reader, tone and language. 4. **Say what good looks like (2 minutes).** Length, shape and one thing it must include. 5. **Paste an example if you have one (2 minutes).** One is a fine start. The docs suggest 3-5, which is Anthropic's number and not ours. ```text title="Five-line brief · v1.0" Task: Why: Audience: Good = Example: ``` Replace the following: - ``: what you want, such as `Write a reply to this customer email declining a refund`. - ``: the reason, such as `They are a long-time customer and we want to keep them; the policy is 30 days and they are at 45`. - ``: who will read it, such as `Non-technical and upset; UK English`. - ``: what good looks like, such as `Under 120 words, a 20% voucher, no legal language, one clear next step`. - ``: a past reply you liked, pasted in, or `none`. When the answer is wrong, say what is wrong. "Too long" is weak. "Cut to 3 sentences, drop the apology in line 2, keep the voucher" is better. Try it on the page's example. Each line you fill removes a question a new colleague would have to ask: ## Put the question after long documents In a peer-reviewed benchmark (a standard set of test questions), models (the AI systems behind assistants) used information at the start or end of a long input best, and the middle worst ([Liu et al., TACL 2024](https://arxiv.org/abs/2307.03172), peer-reviewed benchmark). Anthropic reports that putting the question after long documents improved answers by up to 30% in its tests, and suggests asking for relevant quotes first ([Anthropic docs](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices), vendor report). ## What does not reliably help In Wharton's Prompting Science Report 3 (August 2025), threatening or tipping a model "generally has no significant effect on benchmark performance" (GPQA, MMLU-Pro), though single questions swung unpredictably either way ([Meincke et al.](https://arxiv.org/abs/2508.00614), benchmark preprint). In Report 1 (March 2025), "Sometimes being polite to the LLM helps performance, and sometimes it lowers performance" ([Meincke et al.](https://arxiv.org/abs/2503.04818), benchmark preprint). An LLM, or large language model, is the kind of AI behind chat assistants. Chasing a magic phrase is not a good use of your time. Use the five-line brief, then test the result. ## Check with three cases before you reuse a prompt Decide what a pass is first, then try the prompt on three inputs. ```text title="Three-case check · v1.0" Prompt I want to reuse: Pass means: Case 1, a typical input: Case 2, an awkward input (angry, very long or missing information): Case 3, an input where the right answer is "I need more information": Save it only if all three pass. ``` Replace the following: - ``: a short name for the prompt. - ``: what counts as a pass, in a line. - ``, `` and ``: `pass` or `fail`, and one line on why. ## Save it, then change it safely When a prompt passes, or you notice you have typed the same request three times, save it as a plain file in a folder you control, one file per prompt. Keep the three cases in it. The layout and steps are our suggestion. ```text title="Prompt file · v1.0" name: version: tested_on: PROMPT: GOOD OUTPUT LOOKS LIKE: CASES: CHANGELOG: (): ``` Replace the following: - ``: a short name, such as `weekly-update`. - `` and ``: `1.0` and the day you saved it. Raise the version on each change. - ``: the assistants and models you ran the cases on. Update it only after the cases pass. - ``: the working text, with the parts that change shown as ``. - ``: a real output you were happy with, so the next editor knows the target. - ``: each input and what a good answer looks like. Add real failures as they turn up, up to about ten. - ``: one line. When it fails in use: 1. **Keep the input that caused it** and add it as a new case. Run the current version on it first. If it already passes, the case does not show the problem and any edit is a guess. [Describe the failure](https://hayzlabs.com/guides/describe-the-failure/) helps you put the problem in one line. 2. **Make the smallest edit that could fix it**, and raise the version. 3. **Re-run every case.** If an old case now fails, undo the edit and try a smaller one. 4. **Add a changelog line** and update `tested_on`. Edit the file, not just the chat window, so the two never drift apart. When your assistant switches model, re-run the cases before you trust the prompt. Look for lines that contradict each other, such as "be brief" and "be thorough", and remove emphasis (capital letters, "must") where the cases pass without it. For saving the background you paste into every chat, see [Tell it who you are, once](https://hayzlabs.com/start/tell-it-who-you-are/). > [!LIMIT] > The guidance is one vendor's, and other vendors' docs differ. The tests use benchmark questions, so a result that holds on average can still fail on your task. The five-line brief, the three-case check and the prompt file are ours, and no study tests them. A prompt that passes ten cases can still fail on the eleventh. ## Next [Step 3: What not to paste](https://hayzlabs.com/start/what-not-to-paste/) (10 minutes). ## Sources 1. Anthropic. Claude prompting best practices. Vendor guidance. [Link](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) 2. Anthropic. Claude prompting best practices: long context prompting. Vendor report. [Link](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) 3. Liu et al. Paper in Transactions of the Association for Computational Linguistics, 2024. Peer-reviewed benchmark. [Link](https://arxiv.org/abs/2307.03172) 4. Meincke et al. Wharton Prompting Science Report 3, August 2025. Benchmark preprint (GPQA, MMLU-Pro). [Link](https://arxiv.org/abs/2508.00614) 5. Meincke et al. Wharton Prompting Science Report 1, March 2025. Benchmark preprint. [Link](https://arxiv.org/abs/2503.04818)