Fundamentals prompts

Improve this prompt.

MY PROMPT:
"""
[PASTE]
"""

WHAT I ACTUALLY WANT: [DESCRIBE THE OUTPUT YOU ARE HOPING FOR]
WHAT I AM GETTING: [WHAT IS WRONG WITH THE CURRENT OUTPUT]
WHAT IT IS FOR: [THE PURPOSE]
MODEL: [WHICH ONE]

Produce:

1. WHAT IS MISSING - go through the six things a prompt usually needs and say which mine lacks:
   - THE TASK: what to produce, stated as a verb
   - THE CONTEXT: the situation, the audience, and what the output is for
   - THE INPUT: the material to work from, clearly delimited
   - THE FORMAT: the structure of the output
   - THE CONSTRAINTS: length, tone, what to avoid, what must be included
   - THE SUCCESS CRITERIA: what a good answer contains
   Generic output is almost always missing context and constraints.

2. THE SPECIFICITY AUDIT - quote every vague phrase in my prompt. 'Good', 'professional', 'engaging', 'high quality' and 'comprehensive' carry no information and consume attention. Replace each with something checkable.

3. THE UNSTATED ASSUMPTION - what I know about my situation that the model does not. This is the largest single source of disappointing output: the prompt makes sense to me because I have context the model was never given.

4. THE REWRITTEN PROMPT - with everything above addressed.

5. WHY EACH CHANGE - one line per change, so I can apply the reasoning to future prompts rather than just using this one.

6. THE EXAMPLE QUESTION - would this prompt benefit from an example of good output? Say when examples help and when they narrow the response unhelpfully.

7. THE ROLE QUESTION - whether telling the model to adopt a role helps here. It is useful when the role carries genuine domain conventions and useless as decoration. Say which applies.

8. THE OUTPUT FORMAT - specified precisely if the output feeds into something else.

9. WHAT NOT TO ADD - the things people put in prompts that do nothing: politeness, emphasis like 'very important', threats, offers of payment, and stacking adjectives. Say if my prompt has any.

10. THE TEST - what to check in the output to know whether the prompt worked, and what to change first if it did not.

Help me work out what context this prompt needs.

WHAT I WANT: [THE TASK]
MY CURRENT PROMPT:
"""
[PASTE, or 'none yet']
"""
MY SITUATION: [TELL ME EVERYTHING RELEVANT - who you are, what you are working on, who it is for]
WHAT GENERIC OUTPUT LOOKS LIKE FOR THIS TASK: [WHAT YOU KEEP GETTING]

Produce:

1. THE CONTEXT CHECKLIST - for this specific task, what the model needs to know to produce something useful rather than generic:
   - WHO the output is for, and what they already know
   - WHAT the output will be used for after it is produced
   - WHERE it appears, since that constrains length and format
   - WHAT constraints exist: brand, legal, technical, political
   - WHAT has been tried already and did not work
   - WHAT the current situation is, in the specifics that matter
   - WHAT would make the output wrong
   Say which of these matter most for my task and which are irrelevant.

2. WHAT I HAVE NOT SAID - from my description, the context I am carrying that the model cannot infer. This is the gap between my prompt and my intention.

3. THE MINIMUM CONTEXT - not everything is worth including. Long prompts full of background can bury the task. Say what is essential, what helps, and what to leave out.

4. THE CONTEXT BLOCK - my situation written as a reusable section to put at the top of prompts for this kind of task.

5. THE DELIMITERS - how to separate context from instruction from input material, so the model does not confuse them. Show the structure with clear markers.

6. THE ORDER - where context goes relative to the task. Generally: role and context first, then the task, then the input, then the format and constraints, then any examples. Say why for my case.

7. THE NEGATIVE CONTEXT - what the output should not assume, not include, or not be. Frequently more efficient than positive description.

8. THE REUSABLE TEMPLATE - my prompt with the context in place and placeholders for the parts that change each time.

9. THE TEST - remove one piece of context at a time and see whether the output degrades. This tells you what is actually doing work, and lets you trim prompts that have grown.

10. WHAT CONTEXT CANNOT FIX - if the task itself is underspecified, no amount of background helps. Say if that is the real problem.

Help me specify the output format for this prompt.

THE TASK: [WHAT THE PROMPT ASKS FOR]
MY CURRENT PROMPT:
"""
[PASTE]
"""
WHAT FORMAT I NEED: [DESCRIBE IT]
WHERE THE OUTPUT GOES: [a document / code / a spreadsheet / a person reads it / another system]
WHAT IS GOING WRONG: [inconsistent structure / too long / wrong sections / extra commentary / wrong format]

Produce:

1. THE FORMAT SPECIFICATION - written precisely. Vague format instructions produce inconsistent output. 'Give me a summary' varies wildly between runs; 'three sections headed X, Y and Z, each under 80 words' does not.

2. THE STRUCTURE - stated as a template with the sections named and their content described. Show the shape rather than describing it.

3. THE LENGTH CONTROL - word counts per section rather than for the whole output, because a single total gets distributed unpredictably. Note that models approximate length rather than counting precisely, and that section-level budgets control it better than a global one.

4. THE PREAMBLE PROBLEM - models frequently add an introduction, a restatement of the task, and a closing summary. If the output feeds into something else, this is noise. The instruction that removes it: state explicitly that the response must begin with the first section and contain nothing else.

5. THE EXAMPLE - a short example of correctly formatted output. For format specifically, one example does more than a paragraph of description. Provide one.

6. IF THE OUTPUT IS MACHINE-READ - the additional requirements: exact field names, no surrounding text, consistent types, and what to output when a value is unavailable. Say whether the model supports a structured output feature, because that is more reliable than any instruction.

7. THE CONSISTENCY PROBLEM - format drifts across long outputs and across runs. What helps: a numbered structure, explicit section markers, and stating the format immediately before the task rather than at the start of a long prompt.

8. THE VARIABLE CONTENT - where the content varies but the structure must not, how to make that explicit.

9. THE REWRITTEN PROMPT - with the format specification in place.

10. THE VALIDATION - what to check in the output, and what to do when it comes back in the wrong shape: whether to retry, to specify more tightly, or to handle the variation downstream.

Help me use examples in this prompt.

THE TASK: [WHAT YOU WANT PRODUCED]
MY CURRENT PROMPT:
"""
[PASTE]
"""
EXAMPLES I HAVE: [PASTE ANY GOOD EXAMPLES OF THE OUTPUT YOU WANT]
WHAT IS WRONG WITH THE CURRENT OUTPUT: [THE PROBLEM]

Produce:

1. WHETHER EXAMPLES WILL HELP HERE - they are powerful for: format, tone, level of detail, and tasks that are easier to demonstrate than to describe. They are less useful for: tasks requiring reasoning, tasks where you want variety, and cases where you only have one example, which the model will copy too closely.

2. HOW MANY - one example fixes format. Two to three establish a pattern. More than about five rarely adds and lengthens the prompt considerably. Say what this task needs.

3. THE EXAMPLE SELECTION - if I provided examples, which to use. Choose typical ones rather than exceptional ones; the model copies what it is shown, and an unusually good example produces attempts to replicate its specific features rather than its qualities.

4. THE DIVERSITY REQUIREMENT - if using several, they should vary in the ways the real inputs will vary. Examples that are all similar teach the model that the input is always like that, and it handles the exceptions badly.

5. THE EDGE CASE EXAMPLE - including one example of a difficult or unusual case is disproportionately valuable, because it shows the model what to do when the input is not typical.

6. THE FORMATTING - examples clearly delimited and consistently structured, with the input and the output both shown. Inconsistent example formatting is itself a signal the model picks up.

7. THE OVERFITTING WARNING - the most common failure. Models copy surface features of examples: their subject matter, their specific phrasing, their length, and details that were incidental. If my examples all concern one topic, the output will drift toward that topic. Say what in my examples might be copied that I do not intend.

8. THE COUNTER-EXAMPLE QUESTION - showing a bad example labelled as bad sometimes helps and sometimes teaches the model to produce it. Generally: describe what to avoid rather than demonstrating it. Say if there is a case here where a counter-example would help.

9. THE PROMPT WITH EXAMPLES - assembled, with the examples placed where they work best, which is usually after the instructions and before the actual input.

10. THE TEST - run it with and without the examples and compare. Examples lengthen the prompt and cost tokens, so they should be earning their place.

My prompt has instructions the model ignores. Help me fix it.

MY PROMPT:
"""
[PASTE]
"""
THE INSTRUCTIONS BEING IGNORED: [WHICH ONES]
WHAT HAPPENS INSTEAD: [THE ACTUAL BEHAVIOUR]
MODEL: [WHICH]
HOW OFTEN IT HAPPENS: [always / usually / sometimes]

Produce:

1. WHY INSTRUCTIONS GET IGNORED - the usual causes, applied to mine:
   - BURIED: in the middle of a long prompt, where attention is weakest. Instructions at the start and end are followed more reliably.
   - CONTRADICTED: another instruction pulls the other way, and the model resolves the conflict unpredictably
   - NEGATIVE ONLY: 'do not be verbose' gives nothing to do instead. Negative constraints are weaker than positive ones.
   - VAGUE: not checkable, so not followable
   - COMPETING WITH THE TASK: the instruction conflicts with what the content naturally wants to be
   - TOO MANY: a prompt with twenty constraints will have several dropped

2. THE CONFLICT AUDIT - go through my prompt and find instructions that pull against each other. 'Be comprehensive' and 'keep it under 200 words' is a conflict, and the model will pick one.

3. THE POSITIVE REWRITE - every negative constraint restated as a positive instruction. 'Do not use jargon' becomes 'use everyday words a non-specialist would know'. This is more effective and it is the single most useful change here.

4. THE PLACEMENT - where to move the ignored instructions. Critical constraints belong at the end, immediately before the model responds, as well as near the start.

5. THE CHECKABILITY TEST - every constraint should be one where I could look at the output and say definitively whether it was followed. Rewrite any that fail this.

6. THE PRIORITY STATEMENT - when constraints conflict and both matter, say which wins. Models handle explicit priority better than they handle silent contradiction.

7. THE CONSTRAINT COUNT - how many are in my prompt. If it is more than about seven, some will be dropped regardless of wording. Say which to cut or which to enforce another way.

8. THE REPETITION QUESTION - restating a critical constraint at the end does help. Say which of mine warrant it, without turning the prompt into repetition.

9. THE STRUCTURAL ALTERNATIVE - some constraints are better enforced outside the prompt: checking the output, a second pass that fixes the specific issue, or a structured output feature. Say which of mine would be more reliably handled that way.

10. THE REWRITTEN PROMPT.

11. THE REALISTIC EXPECTATION - some instructions are followed most of the time rather than always. If something must be guaranteed, it needs validation rather than a better prompt.

Help me turn this into a reusable template.

MY PROMPT:
"""
[PASTE]
"""
HOW OFTEN I DO THIS TASK: [FREQUENCY]
WHAT CHANGES EACH TIME: [THE VARIABLE PARTS]
WHAT STAYS THE SAME: [THE FIXED PARTS]
WHO ELSE WILL USE IT: [just me / colleagues / anyone]

Produce:

1. THE VARIABLE EXTRACTION - everything in my prompt that changes between uses, pulled out as clearly marked placeholders at the top. A template with variables buried in prose is one people fill in wrongly.

2. THE VARIABLE DESIGN - each placeholder with:
   - A clear name in capitals, so it is visibly a slot
   - A note on what to put there, and what a good input looks like
   - Whether it is required or optional, and what happens if it is left out
   Placeholders that just say [TOPIC] produce vague inputs and therefore vague outputs. The guidance in the placeholder does real work.

3. THE STRUCTURE - the template assembled: variables first, then context, then the task, then the format, then the constraints. A consistent structure makes templates easy to modify and easy for others to use.

4. THE INPUT DELIMITING - where pasted content goes, clearly separated from the instructions so the model does not confuse material with instruction.

5. WHAT TO MAKE VARIABLE AND WHAT NOT TO - not everything that could change should be a variable. Too many placeholders makes a template tedious to use and it gets abandoned. Say which of my changing elements are worth parameterising and which should be fixed with a sensible default.

6. THE DEFAULTS - for optional variables, what happens when they are not supplied. A template that breaks when a field is empty is fragile.

7. THE USAGE NOTES - a short header saying what the template is for, what it produces, and anything to know. If others will use it, this is what determines whether it is used correctly.

8. THE TEMPLATE - written out in full.

9. THE WORKED EXAMPLE - the template filled in once, so a new user can see what good inputs look like.

10. THE VERSION NOTE - templates evolve. A line recording what changed and when saves confusion later, particularly if others use it.

11. THE TEST CASES - three different inputs to run it against, including an awkward one, to check the template holds up beyond the case it was built for.

The same prompt gives me different quality results. Help me make it consistent.

MY PROMPT:
"""
[PASTE]
"""
THE VARIATION: [DESCRIBE WHAT DIFFERS BETWEEN RUNS]
HOW OFTEN IT IS GOOD: [ROUGHLY]
MODEL AND SETTINGS: [WHICH MODEL, AND TEMPERATURE IF YOU SET IT]
WHAT I DO WITH THE OUTPUT: [PURPOSE]

Produce:

1. THE EXPECTED VARIATION - language models are probabilistic and will produce different responses to the same prompt. Some variation is inherent. The question is whether mine exceeds that, and whether the variation is in the substance or only in the wording. Assess from what I described.

2. THE TEMPERATURE QUESTION - if the setting is available to me, what it does and what value suits my task. Lower values produce more consistent, more predictable output; higher values produce more variety. For tasks with a correct answer or a required format, lower is usually right. Say what to set and whether it will help here.

3. THE UNDERSPECIFICATION CHECK - the most common cause of quality variation. Where the prompt leaves a decision to the model, it makes that decision differently each time. Go through my prompt and identify every point where the model has to decide something I have not specified: the angle, the depth, the structure, the examples chosen, the emphasis.

4. THE DECISIONS TO REMOVE - for each, whether to specify it or leave it open. Specifying more reduces variation and also reduces the chance of a better answer than you would have specified. Say which is worth pinning down for my purpose.

5. THE STRUCTURE FIX - a specified output structure removes a great deal of variation at a stroke, because the shape is no longer being decided each time.

6. THE EXAMPLE FIX - one example of good output constrains the range considerably. If quality varies rather than content, this is usually the most effective single change.

7. THE CRITERIA STATEMENT - telling the model what a good response contains gives it something to aim at. 'A good answer includes X, addresses Y, and avoids Z' reduces variance more than adding more instructions.

8. THE LENGTH FACTOR - longer outputs vary more, because there are more decisions. If consistency matters more than completeness, shorter helps.

9. THE ACCEPTANCE APPROACH - for some tasks the right answer is to generate several and pick, rather than to eliminate variation. Say whether my purpose suits that, and how many to generate.

10. THE VALIDATION - if the output feeds into something else, checking it rather than trusting consistency. What to check for.

11. WHAT CANNOT BE FIXED - if the task genuinely requires judgement, variation is the model exercising it. Consistency and quality are not the same thing, and forcing consistency can lower the ceiling.