I have found that effective custom instructions fall into five categories. Understanding them will help you write your own with precision rather than vagueness, because vague instructions produce vague compliance.
Category one: tone and register defaults
These instructions tell the tool how your output should sound by default. Not the content: the feel. For example: always write in a warm but professional register. Do not be overly formal. Do not be casual. The tone should read as a knowledgeable advisor speaking to a valued client, never as a brand speaking to a consumer.
You might also specify what your tone is not. Do not use exclamation marks in client communications. Do not use the word “delighted” or “thrilled” in correspondence. Do not open emails with “I hope this finds you well.” Negative instructions, what to avoid, are often more effective than positive instructions for tone because they remove the specific defaults that the tool tends to fall back on.
Category two: format preferences
These instructions tell the tool how to structure its output by default. For a travel advisor, this might include: always write client-facing content in prose, never in bullet points. Keep emails under two hundred words unless instructed otherwise. When providing options, present them in narrative paragraphs, not numbered lists. Include a subject line for every email draft. Always provide one version unless I ask for variations.
Format instructions eliminate an entire round of editing. If the tool’s default is to produce bullet-pointed lists and your preference is always prose, setting that once saves you from correcting it in every output.
Category three: standing assumptions
These are the things that are always true about your work that the tool should factor in without being told each time. For example: assume all client communications will be read on a mobile device and format accordingly. Assume the client has already received a detailed itinerary document and does not need destination information repeated in emails. Assume I am working with high-end leisure clients unless I specify otherwise. When I mention a destination in Southern Africa, assume I have first-hand knowledge of it unless I say otherwise.
Standing assumptions reduce the amount of contextual briefing you need to include in every prompt. They are the background conditions of your practice made explicit to the tool.
Category four: avoidance instructions
These are the things the tool must never do in your output. They are the most immediately effective category of custom instruction because they remove the specific habits that AI defaults to and that you find yourself editing out repeatedly.
For travel advisors, common avoidance instructions include: never use the phrase “I hope this email finds you well.” Never describe a destination as a “hidden gem” or a “must-visit.” Never use the word “indulge” or “pamper” in property descriptions. Never include a disclaimer about verifying information at the end of a response, I handle verification myself. Never suggest the client “reach out” to me, I prefer “contact” or “let me know.” Never produce output longer than what was requested.
You will have your own list. Every time you find yourself making the same edit to AI output, that edit should become an avoidance instruction. Over time, your avoidance list becomes the most precisely calibrated part of your custom instructions.
Category five: output behaviour rules
These are instructions that control how the tool handles specific types of request. They are more situational than the other categories but powerful when they apply.
For example: when I ask you to draft a proposal, always include a closing recommendation paragraph. When I ask for destination research, always include a note on what has changed in the last two years. When I upload a document and ask questions about it, tell me if the answer is not in the document rather than guessing. When I ask you to compare options, always structure the comparison around the client criteria I have specified, never around generic categories.
Output behaviour rules are the instructions that make the tool behave more like a trained team member and less like a general-purpose assistant. They take longer to develop because they emerge from repeated use, but they are worth adding as you identify the patterns.
