From Vague to Specific

Every prompt is some subset of these seven parts.

A part you leave out is a decision you hand over. That is fine when the decision is obvious and cheap to get right, and wrong when it is neither. The cheapest to drop are the example and the return contract. The most expensive is the check, because without it "done" becomes an opinion.

Add a sign-up form to my app.

Task: Add a sign-up screen at /sign-up. A visitor creates an account with an email and password, then lands on /welcome.

Context:
<<<
src/features/auth/SignUpPage.tsx and useSignUp.ts, React 18, TypeScript,
the existing Field and Button, the tokens in src/ui/tokens.css.
POST /api/session/signup { email, password } → 201 { userId } | 409 { problem, message }
>>>

Constraints:
password 12+ characters, message "Use at least 12 characters."
email required, message "Enter an email address."
on 409, show the server's message above the form and keep what was typed.
exclude social login, a confirm-password field and a strength meter.

Return: one patch, no commentary, nothing outside src/features/auth.

Approach: read the two files, plan in three bullets, work one step at a time, ask before naming anything new.

Check:
an empty submit shows both messages; 11 characters sends no request;
one click sends one request; a 409 keeps the email.

What changed Not the length. The facts, and their order. Every block in the second prompt fills a part the first one left to the model, and panel 1 names those parts.

The skeleton is the default: the seven parts in the order below, with the blanks left blank. Pick an example to see the same parts filled for a feature, a fault, a decision or a rename, then replace it with your own. The seven rules under the fields say why the order matters.

Nothing is filled yet. The skeleton shows the seven parts and where each one goes. Pick an example to see one filled.

Task: <what to do, and what is true afterwards>

Context:
<<<
<files, stack, material to read>
>>>

Constraints:
<what must hold>
<what is out of scope>

Return: <format, length, what to leave out>

Approach: <plan first, ask, one step at a time>

Example: <one input and the output you want>

Check: <how the answer will be judged>

The order the parts go in

• 1. Start with the task. The instruction sits above the material, before anything else. A model that reads the ask first has something to hang the context on.
• 2. Fence the context. Triple quotes or tags around pasted material. Unfenced text can be read as an instruction, and formatting alone moves accuracy by large margins.
• 3. Restate the line you cannot lose. In a long prompt the start and the end are read better than the middle, so close with the one requirement that matters.
• 4. Separate the reply from the thinking. Say what to return, not how to reason. Forcing a rigid output schema measurably costs accuracy.
• 5. Say what to do, not only what to avoid. A prohibition leaves the model guessing at the alternative.
• 6. Ask for the plan before the work. A task with steps goes better staged or split than in one instruction.
• 7. Ask for the check. An answer with something runnable beats an answer that sounds right.

Both panels hold the same prompt. The left is what was sent and the right marks the words that contribute nothing to decision making. No two people would build the same thing from them and the model is not going to be the exception. Replace each one with a fact. The table below shows the swap.

The test If two people could build different things from a sentence, it is not a detail. It is a preference. Say the path, the status, the sentence, or the number, and it becomes a requirement.

• The task is one imperative sentence, and it sits above the material.
• Anything pasted is fenced, so it cannot be read as an instruction.
• The reply has a shape: format, length, and what to leave out.
• A job with steps asks for the plan before the work.
• There is something to run at the end. "Looks right" is not a check.
• Every fact has a referent: a path, a status, a sentence, a number.

What does not help

The takeaway Structure is the cheap part. Seven parts, one order and a check you can run is most of what the published comparisons support, and none of it needs a clever sentence.

• Formatting alone moves scores by tens of points. Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design, Sclar, Choi, Tsvetkov and Suhr, ICLR 2024.
• Models read the start and end of a long prompt better than the middle. Lost in the Middle: How Language Models Use Long Contexts, Liu et al., TACL 2023.
• In-context learning, where examples began. Language Models are Few-Shot Learners, Brown et al., NeurIPS 2020.
• Demonstrations teach format more than facts. Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?, Min et al., EMNLP 2022.
• The original reasoning prompt. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, Wei et al., NeurIPS 2022.
• "Think step by step" without any examples. Large Language Models are Zero-Shot Reasoners, Kojima et al., NeurIPS 2022.
• Sample several answers, keep the majority. Self-Consistency Improves Chain of Thought Reasoning in Language Models, Wang et al., ICLR 2023.
• Break a hard task into easier ones, in order. Least-to-Most Prompting Enables Complex Reasoning in Large Language Models, Zhou et al., ICLR 2023.
• Give each sub-task its own prompt. Decomposed Prompting: A Modular Approach for Solving Complex Tasks, Khot et al., ICLR 2023.
• Interleave reasoning with tool calls. ReAct: Synergizing Reasoning and Acting in Language Models, Yao et al., ICLR 2023.
• Answer, critique the answer, revise. Self-Refine: Iterative Refinement with Self-Feedback, Madaan et al., 2023.
• Strict output formats cost accuracy on reasoning. Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of Large Language Models, Tam et al., 2024.
• Real GitHub issues as the test bed for repo-level work. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, Jimenez et al., ICLR 2024.
• A plain localise, repair, validate pipeline beats complex agents. Agentless: Demystifying LLM-based Software Engineering Agents, Xia et al., 2024.
• Expert personas do not improve answers. When "A Helpful Assistant" Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models, Zheng et al., Findings of EMNLP 2024.
• The survey that counts the techniques. The Prompt Report: A Systematic Survey of Prompt Engineering Techniques, Schulhoff et al., 2024.
• OpenAI's prompt guide. Prompt engineering.
• Anthropic's prompt guide. Prompt engineering overview.
• Google's whitepaper on prompting. Prompt Engineering, hosted on Kaggle.
• Microsoft's guide to prompting techniques. Prompt engineering techniques.