System Prompts prompts

Help me write a system prompt.

WHAT IT DOES: [THE PURPOSE]
WHO USES IT: [you / colleagues / customers / another system]
WHAT THE USER SENDS IN: [THE TYPICAL INPUT]
WHAT IT SHOULD PRODUCE: [THE OUTPUT]
WHAT IT MUST NEVER DO: [HARD LIMITS]
WHAT IT SHOULD DO WHEN IT CANNOT HELP: [FALLBACK]
MODEL: [WHICH]

Produce the system prompt with these sections in order:

1. ROLE AND SCOPE - what this assistant is, and explicitly what is outside its scope. The scope boundary is the most important line and the most often omitted; without it the assistant attempts everything and does several things badly.

2. INPUT HANDLING - what it will receive, and what to do when the input is malformed, incomplete, or outside scope.

3. THE TASK - the procedure, in order. Numbered steps if the task has a sequence.

4. OUTPUT FORMAT - specified precisely, with an example. If the output is consumed by a person, say what structure; if by a system, state the exact format and that nothing may precede or follow it.

5. CONSTRAINTS - the rules, stated positively where possible. Negative-only constraints are weaker: pair each 'do not' with what to do instead.

6. FALLBACK BEHAVIOUR - the literal output for each case where it cannot complete the task: out of scope, insufficient information, and unable to determine an answer. Give the exact wording rather than a description, because undefined fallback behaviour means the model improvises differently every time.

7. EXAMPLES - two or three: a normal case, an edge case, and a case it should decline.

Then, separately from the prompt:

8. WHAT WILL GO WRONG - the three most likely failure modes across many uses.

9. THE SCOPE CREEP RISK - the adjacent requests users will make that this assistant should not handle, and whether the scope statement covers them.

10. THE USER INPUT BOUNDARY - if user content is inserted into this prompt, where the boundary is and how to mark it, with the instruction that content inside is data and not instructions.

11. THE TESTING - the specific inputs to try, including the awkward ones.

12. LENGTH - system prompts that are too long have instructions dropped. Say whether mine is at risk and what to cut.

Help me write custom instructions for my regular use.

WHAT I MOSTLY USE IT FOR: [YOUR TYPICAL TASKS]
MY BACKGROUND: [WHAT YOU DO, YOUR EXPERTISE LEVEL IN THE AREAS YOU ASK ABOUT]
WHAT ANNOYS ME ABOUT THE DEFAULT BEHAVIOUR: [BE SPECIFIC]
HOW I LIKE INFORMATION PRESENTED: [YOUR PREFERENCES]
WHAT I DO NOT WANT: [THINGS TO AVOID]
WHERE THIS GOES: [the settings of a chat tool / the start of every conversation]

Produce:

1. WHAT BELONGS IN CUSTOM INSTRUCTIONS - things that are true for most of my conversations: who I am, my expertise level, format preferences, and behaviours to avoid. Not task-specific instructions, which belong in the individual prompt and will conflict with other tasks if made global.

2. THE CONTEXT ABOUT ME - written concisely. My expertise level is the highest-value item, because it determines how much is explained and at what depth. Say what to include and what is unnecessary detail.

3. THE FORMAT PREFERENCES - specified checkably. 'Be concise' is weak; 'default to under 200 words unless the task requires more; do not use headings for short answers' is followable.

4. THE BEHAVIOURS TO AVOID - I said what annoys me. Each translated into a specific, positive instruction. Common ones and their fixes: restating the question before answering, excessive caveats, summarising at the end, offering to help further, and hedged non-answers to questions that have answers.

5. THE DIRECTNESS INSTRUCTION - if I want straight answers, how to phrase it so it applies to substance rather than just brevity: state the answer first, then the reasoning, and say plainly when something is uncertain rather than hedging throughout.

6. THE DISAGREEMENT INSTRUCTION - asking to be told when I am wrong or when a premise is mistaken. Worth including deliberately, because the default is to be accommodating.

7. WHAT NOT TO PUT IN - instructions that will backfire across varied tasks: rigid length limits that break long tasks, format rules that conflict with code or tables, and anything task-specific.

8. THE LENGTH - custom instructions compete with every prompt for attention. Keep them short; a long standing instruction set means the later items are ignored. Say what to cut.

9. THE INSTRUCTIONS - written out, ready to paste.

10. THE CONFLICT NOTE - where these might interfere with specific tasks, and that a direct instruction in a prompt overrides a standing preference.

11. THE REVIEW - these should be revised as I notice what still annoys me. Treat them as a working document rather than a one-off setup.

Help me define the scope of this assistant.

WHAT IT IS FOR: [THE INTENDED PURPOSE]
CURRENT SYSTEM PROMPT:
"""
[PASTE]
"""
WHAT IT IS DOING THAT IT SHOULD NOT: [THE PROBLEM]
WHO USES IT: [AUDIENCE]
WHAT HAPPENS IF IT GOES OUT OF SCOPE: [mildly unhelpful / confusing / a real problem]

Produce:

1. THE SCOPE STATEMENT - what this assistant handles, stated positively and specifically. Vague scope is the root cause: 'helps with customer queries' includes everything.

2. THE OUT-OF-SCOPE LIST - explicitly named. This is more effective than a general scope statement, because it removes ambiguity about the specific cases that arise. From my description, the adjacent things users will ask for.

3. THE BOUNDARY CASES - the requests that sit near the edge. For each, a decision: handle it, partially handle it with a caveat, or decline. Making these decisions in advance is what produces consistent behaviour.

4. THE DECLINE BEHAVIOUR - the literal wording when a request is out of scope. It should: say plainly that it is not something this assistant handles, not attempt a partial answer, and point somewhere useful if there is somewhere. Write it.

5. THE PARTIAL ANSWER PROBLEM - the most common scope failure. Asked something adjacent, an assistant gives a hedged, unreliable answer rather than declining. This is worse than declining because the user acts on it. State the instruction that prevents it.

6. THE AUTHORITY QUESTION - the things this assistant should never be treated as authoritative on, given my stated audience and consequences. Particularly: anything with legal, financial, medical or safety implications where a wrong answer causes harm.

7. THE ESCALATION - where users should go instead, named specifically.

8. THE PROBLEM I DESCRIBED - addressed directly. Say why the current prompt allows it and the specific change.

9. THE REVISED SYSTEM PROMPT - with scope properly defined.

10. THE TESTS - the specific inputs to try, including: clearly in scope, clearly out, adjacent, a request to ignore the scope, and an in-scope request phrased to look out of scope.

11. THE MONITORING - how to find out what users are actually asking that falls outside scope, since the scope will need adjusting based on real use rather than guesses.

Help me define the voice for this assistant.

WHAT IT IS FOR: [PURPOSE]
WHO IT TALKS TO: [USERS AND THE CONTEXT THEY ARE IN]
HOW IT SHOULD SOUND: [YOUR DESCRIPTION]
HOW IT SOUNDS NOW: [THE CURRENT PROBLEM]
OUR BRAND VOICE IF THERE IS ONE: [PASTE OR DESCRIBE]
EXAMPLES OF THE RIGHT TONE: [PASTE, if you have any]

Produce:

1. THE VOICE, SPECIFIED CHECKABLY - my description translated into instructions that can be followed and verified. 'Friendly but professional' is not an instruction; 'use contractions, address the user as you, keep sentences under 20 words, do not use exclamation marks' is.

2. THE SPECIFIC ELEMENTS - decide each explicitly:
   - Formality level
   - Contractions or not
   - Sentence length
   - How it addresses the user
   - Whether it uses humour, and how much
   - How it opens and closes responses
   - Whether it uses emphasis, lists, or headings
   - Response length by default

3. THE CONTEXT VARIATION - tone should shift with the situation. An assistant that is cheerful while delivering bad news is jarring. Specify how the voice changes for: an error, a decline, a complaint, and a routine query. This is the element most often missed.

4. THE THINGS TO AVOID - the specific phrases and patterns. Usually: excessive enthusiasm, apologising repeatedly, 'I'd be happy to help with that', restating the question, and offering further help at the end of every message.

5. THE EXAMPLES - if I provided any, what specifically makes them right. If not, write two example exchanges demonstrating the target voice, because examples convey tone far better than description.

6. THE BRAND ALIGNMENT - if I gave a brand voice, whether it translates to conversational use. Brand voices written for marketing copy frequently do not work for support or error messages, and forcing them produces something odd.

7. THE USER STATE - I said what context users are in. If they are likely frustrated, rushed, or confused, the voice should account for it. A user with a problem wants efficiency, not warmth.

8. THE VOICE BLOCK - written as a section for the system prompt, concise enough not to crowd out the functional instructions.

9. THE CURRENT PROBLEM - I said how it sounds now. Diagnose why and give the specific instruction that fixes it.

10. THE TEST - sample exchanges to check: a routine request, a complaint, an out-of-scope request, and a user who is annoyed. The voice is judged on the difficult ones, not the easy ones.

My system prompt is not working properly. Help me fix it.

THE SYSTEM PROMPT:
"""
[PASTE]
"""
WHAT IT SHOULD DO: [INTENDED BEHAVIOUR]
WHAT IT ACTUALLY DOES: [THE PROBLEM]
EXAMPLE OF IT GOING WRONG: [PASTE AN ACTUAL EXCHANGE]
HOW OFTEN: [always / usually / occasionally]
MODEL: [WHICH]

Produce:

1. THE INSTRUCTION AUDIT - go through my system prompt and list every instruction it contains, including the implicit ones. Long system prompts frequently contain more instructions than their author realises, and the count itself is often the problem.

2. THE CONFLICTS - instructions that pull against each other. The model resolves conflicts unpredictably, which produces exactly the kind of inconsistency I described. Quote each conflicting pair.

3. THE POSITION ANALYSIS - where the failing instruction sits. Instructions in the middle of a long prompt are followed less reliably than those at the start or end. Say where mine is and where it should be.

4. THE AMBIGUITY - instructions that could be read more than one way. Quote them and give the unambiguous version.

5. THE NEGATIVE-ONLY INSTRUCTIONS - things stated as prohibitions with no alternative behaviour specified. These are weaker. Rewrite each as a positive instruction.

6. THE EXAMPLE, ANALYSED - I pasted a failing exchange. Work out which instruction was not followed, and which other part of the prompt might have caused it. Frequently the failure is caused by a different instruction than the one that appears to have been broken.

7. THE LENGTH PROBLEM - if the prompt is long, which instructions are most likely being lost. Say what to cut, consolidate, or move.

8. THE OCCASIONAL-FAILURE CASE - if I said it fails only sometimes, that points to underspecification rather than a wrong instruction: the prompt leaves a decision open and the model makes it differently each time. Identify the open decision.

9. THE STRUCTURE FIX - system prompts work better with a clear structure: role, scope, task, format, constraints, fallbacks, examples. Say whether mine has one and restructure it.

10. THE REVISED PROMPT.

11. THE TEST SET - the specific inputs to run against the revised version, including the case that was failing, so I can tell whether it is fixed rather than guessing.

12. WHAT NEEDS A NON-PROMPT FIX - if something must be guaranteed, prompt wording will not guarantee it. Say which of my requirements need validation, a structured output feature, or a check outside the model.

Help me handle user input safely in this prompt.

THE SYSTEM PROMPT:
"""
[PASTE]
"""
WHERE USER CONTENT GOES: [WHAT GETS INSERTED AND FROM WHERE]
WHERE THE CONTENT COMES FROM: [typed by the user / uploaded files / fetched web pages / emails / database records]
WHAT THE ASSISTANT CAN DO: [tools, actions, data access it has]
WHERE THE OUTPUT GOES: [shown to the user / stored / sent onward / acted on]

Produce:

1. THE TRUST BOUNDARY - which parts of the assembled prompt are trusted and which are not. Anything that originated outside my control is untrusted, including content that arrived indirectly: a file someone uploaded, a page that was fetched, a database field another user wrote.

2. THE DELIMITING - how to mark untrusted content clearly, with an explicit statement that anything inside is data to be processed and never instructions to follow. Show the structure.

3. THE POSITION - untrusted content should come after the instructions, not before, and the key instructions should be restated after it. Content placed before the instructions has more influence over the response.

4. THE INDIRECT INJECTION RISK - if content is fetched or uploaded rather than typed, instructions can be hidden inside it, and the person affected may be the user rather than the attacker. Say which of my sources carry this risk.

5. WHAT AN ATTACKER COULD ACHIEVE - be concrete, based on what I said the assistant can do and where the output goes:
   - If it has no tools and the output is shown only to the same user, the risk is low and the realistic outcome is an assistant that misbehaves
   - If it can call tools, access data, or send anything onward, the risk is materially higher
   - If the output is rendered as HTML, stored for others to read, or passed to another system, the output itself becomes an attack vector
   Assess mine honestly rather than overstating it.

6. THE STRUCTURAL DEFENCES - in order of effectiveness:
   - Least privilege: the assistant should not have a capability the task does not require. This is the only defence that genuinely holds.
   - Validating tool arguments against an allowlist rather than trusting model-generated values
   - Confirmation for consequential actions, outside the model's control
   - Treating the output as untrusted: escaping it before rendering, never passing it to a shell, an eval, or a query

7. THE INSTRUCTION-BASED DEFENCE, HONESTLY - telling the model to ignore instructions in user content reduces the rate and does not eliminate it. It is worth including and must never be the only control protecting anything that matters. Write the wording, with that caveat stated.

8. THE REVISED PROMPT - with delimiting and instructions in place.

9. THE TEST CASES - specific strings to try against this assistant.

10. THE PROPORTIONATE CONCLUSION - what actually needs doing here given the real risk, rather than a generic security list.

Help me set up maintenance for this system prompt.

THE SYSTEM PROMPT:
"""
[PASTE]
"""
HOW LONG IT HAS BEEN IN USE: [TIMEFRAME]
HOW IT HAS CHANGED: [WHAT HAS BEEN ADDED OVER TIME]
WHO CHANGES IT: [just me / several people]
HOW I KNOW IF IT IS WORKING: [CURRENT MONITORING, if any]
HOW MANY PEOPLE USE IT: [SCALE]

Produce:

1. THE ACCRETION AUDIT - system prompts grow by accumulation: an instruction added for one bad case, another for a complaint, another for an edge case. The result is long, contradictory, and nobody remembers why each line is there. Go through mine and flag: instructions that may no longer be needed, instructions that duplicate each other, and instructions added for a case that a better-worded rule would cover.

2. THE CONSOLIDATION - the same set of behaviours expressed in fewer, clearer instructions. Shorter prompts have their instructions followed more reliably, so consolidation is a functional improvement rather than tidiness.

3. THE WHY RECORD - each instruction annotated with what it is there for. Without this, nobody can safely remove anything, and the prompt only ever grows. Produce it as a separate document rather than as comments in the prompt itself.

4. THE VERSIONING - keeping previous versions, with what changed and why. Essential when a change makes something worse and needs reverting, which happens regularly.

5. THE CHANGE PROCESS - especially if several people edit it: who changes it, how a change is tested before it goes live, and how a regression is caught. An untested change to a prompt many people use is a live experiment.

6. THE TEST SET - the most valuable maintenance asset. A fixed set of inputs with expected behaviour, run before and after every change. Every bug ever found becomes a permanent test case. Build the starting set from my prompt's requirements.

7. THE MODEL CHANGE PROBLEM - provider models are updated, and a prompt tuned for one version can behave differently on the next. Say what to monitor and how to find out quickly. Running the test set on a schedule catches this.

8. THE DRIFT MONITORING - how to know what users are actually sending and how the assistant is actually responding. Logging inputs and outputs is what makes improvement possible; without it, changes are guesses.

9. THE REVIEW CADENCE - how often to look at the whole prompt rather than patching it, given my scale.

10. THE REVISED PROMPT - consolidated, with the annotation document alongside.

11. THE ONE-INSTRUCTION-AT-A-TIME RULE - changing several things at once means not knowing which change caused an improvement or a regression. Worth stating as a working practice.