Lesson 3.3: System prompts, custom instructions and reusable templates

Learn to write standing instructions that shape every reply, build a tested template library, version it, and share it across a team without drift.

By the end of this lesson you will be able to explain what standing instructions are and where they sit in a prompt, decide what belongs in them and what does not, write a compact set for your own role, turn your best prompts into templates with clear blanks, and keep a small library that a team can trust, test and update. You will see how many words a good set of standing instructions needs, what they cost when sent thousands of times a day, and how a library pays back its setup time. You should have read Lessons 1.3 and 2.3, since standing instructions are largely the style sheet and prompt structure you have already learned, saved once and reused. No technical background is needed.

By now you know how to write a strong single prompt. The next question is practical: do you rewrite your role, your audience, your style rules and your definitions every single time? You should not. Most tools let you store instructions once, so they apply to every conversation. Used well, this removes repetition and raises consistency. Used badly, it fills each prompt with stale, contradictory text that you have forgotten you wrote.

Standing instructions

Standing instructions are text that goes into every prompt automatically, before your own message. Tools give them different names. In some products they are called custom instructions, personas, projects or profiles. In applications built by developers they are called the system prompt, a message that sits first in the conversation and sets the model's role and rules for the whole exchange. The names and the exact places differ, and they change as products evolve. What stays the same is the idea: a block of stable text that precedes the task.

Recall the layers from Lesson 1.1. The standing instructions are the system layer. Your message for the task is the user layer. The model sees both, together with any conversation so far and any attachments.

Predict first: your standing instructions say "Always reply in formal British English". Today you ask for a casual message to a friend in the same chat. Which instruction will the model follow? Decide before reading on.

There is no guaranteed answer. Many models give more weight to the specific, recent request, and so write casually, but some will follow the standing rule and produce something stiff, and others blend the two. When instructions at different levels conflict, behaviour is unpredictable. The remedy is to write standing instructions as defaults, not absolutes: "Unless I ask otherwise, use formal British English." That one clause tells the model that your task prompt wins.

What belongs in standing instructions

The test for any line is whether it is true for most of your tasks and unlikely to change from day to day. That gives a sensible split. Belongs in standing instructions · Belongs in the task promptWho you are and what you do · What you need done now Your usual audience · This task's specific reader Style rules and words to avoid · Facts and attachments for this job Definitions your work depends on · The format for this deliverable Hard rules that always apply · A one-off constraint Default format and length · A different length for today How to handle missing information · The specific question A compact set usually has six parts: a line on role and purpose, the usual audience, the style rules, key definitions, the hard rules and the format defaults. A good length is 200 to 400 words. Here is how a 350-word set might divide.

Length matters for the reasons Lesson 1.4 gave. Every added rule is another chance to be missed, and a long block dilutes the task you actually typed. If your set grows past about 500 words, ask which lines change a reply and cut the rest.

Writing a set that works

A full example for a credit operations analyst shows the shape.

text Role: You help me, a credit operations analyst at a mid-sized Indian lender, to write, check and explain internal reports and customer-facing messages.

Audience: Unless I say otherwise, my readers are branch managers and senior operations staff. They are busy and not technical.

Style: Plain English, short sentences, active verbs, no jargon without a one-line explanation. Use British spelling. Amounts in Indian format, such as Rs 2,40,000 or Rs 4.5 crore. Avoid exclamation marks and the words "leverage", "utilise" and "reach out".

Definitions: "Overdue" means more than 7 days past the due date. "Active customer" means at least one transaction in the last 90 days. "NPA" means 90 or more days past due.

Rules: Never invent numbers, names or policy. If a fact is not in what I have given you, say "not stated". When I give you data, show your calculation. Never give legal or regulatory advice as final; flag it for review.

Defaults: Give the answer first, then the support. Keep replies under 150 words unless I ask for more. Unless I ask otherwise, use plain text with no symbols.

Three features make it work. It is specific: the definitions remove ambiguity from the exact words the analyst uses. It is written as defaults, so a task prompt can override any of them. And it contains a safe exit for missing information, which is the most useful single line in any set.

What to leave out

A few things do not belong in standing instructions, even though they are tempting.

Personal or confidential data. Do not put account numbers, customer details or secrets in a block that is sent with every message. Task facts. If the line is true only today, it goes in today's prompt. Long examples. They bloat every request. Keep examples in your templates and use them where they are needed. Rules about things that never come up. Each one is clutter. Contradictions. Read the whole set aloud as a stranger, as in Lesson 1.4, and strike anything that pulls against something else.

Keep them alive

Standing instructions go stale quietly. A definition changes, a style preference shifts, a rule no longer applies, and the block keeps shaping every reply. Put a date and a version at the top, review it every quarter and whenever you notice the assistant doing something odd. A useful symptom of a stale set is a reply that follows a rule you have forgotten you wrote: if the model does something strange, read the standing instructions first.

What they cost

For personal chat, the cost of a few hundred words is nothing. For a team that sends many requests through an application, every request carries the standing instructions, and they add up. A 350-word set is roughly 350 ÷ 0.75 = 467 tokens. If an application sends it with 2,000 requests a day, that is 933,000 tokens a day. At an example price of ₹200 per million input tokens, that is about ₹187 a day, or about ₹5,600 a month, and the set occupies about 6 per cent of an 8,000-token window before the user has typed anything.

The point of the arithmetic is proportion, not thrift. A set that is clear and short earns its cost many times over by saving corrections. A set that is padded costs money and quality both.

From prompt to template

A standing set holds what is stable. A template holds a task you repeat, with blanks for what changes. Lesson 1.3 introduced the idea. Here we make it systematic.

A good template has these parts. Part · What it holdsName · A plain description of the job, such as "Customer reply: billing complaint" Purpose · One line on when to use it and when not to Blanks · Clearly marked inputs, such as [CUSTOMER NAME] and [FACTS] Prompt text · The full prompt, with the blanks in place Example · One filled-in input and a good output Owner and version · Who maintains it, the version number and the date Change note · What changed in the latest version and why Mark blanks in a way that cannot be mistaken for text, such as square brackets in capitals, and keep the same convention throughout your library. Put the instructions that never change at the top and the blanks that do at the bottom, so that filling a template is a matter of pasting into one clear place.

text TEMPLATE: Customer reply, billing complaint (v3, 12 Oct 2026, owner: Meena) Purpose: first reply to a customer who reports a wrong or double charge. Do not use for fraud claims.

Task: Write a reply to the customer message below in our house voice.

Customer message: """ [PASTE MESSAGE] """

Facts you may use (only these): [FACTS FROM OUR RECORDS]

Rules: apologise once, say what we will do and by when, do not promise a refund unless the facts state one, under 100 words, plain text, sign off as [AGENT NAME]. If the facts do not cover the question, write "FACTS NEEDED" and list what is missing.

Everything above the blanks is fixed. A new agent fills in three blanks in under a minute and gets a draft in the house voice, with a built-in exit if the facts are missing.

Test before you share

A template is a small piece of software, and untested software surprises people. Before you add one to a shared library, run it on at least five real or realistic cases, including an awkward one, such as a message with two issues or a missing fact. Score each output against a short rubric: right tone, right length, no invented facts, uses only the facts provided. If it fails on one case, fix the template and rerun all five, because a fix for one case can break another. Five cases is only a start, as the sampling arithmetic of Lesson 2.1 showed, but it catches the common failures cheaply, and Module 5 shows how to test properly.

Building a library

A prompt library is simply the collection of your tested templates, kept somewhere people can find them. It can be a shared document, a spreadsheet or a folder. What makes it useful is not the tool but the discipline.

Organise by job, not by author. "Customer replies", "Weekly reports", "Meeting notes" are better headings than people's names. Keep one source of truth. If three copies exist, three versions will drift. Version everything. A change log of one line per change lets you roll back when an edit makes things worse. Name an owner for each template, the person who answers for it and approves changes. Add examples, so a newcomer sees what good output looks like. Review and retire. Every quarter, remove templates nobody uses and update those whose policies have changed. Link to the standing instructions, so templates do not repeat the style rules and fall out of step.

A library also needs a way to take suggestions. Make it easy for colleagues to propose a change, such as a comment field, and have the owner review them. The best improvements usually come from the people who use a template every day.

The payoff

Setting up a library costs time, and it is fair to ask when it pays back. Suppose ten colleagues each use a template eight times a week, and the template saves six minutes each time compared with writing the prompt and fixing the result from scratch. The saving is 10 × 8 × 6 = 480 minutes, or 8 hours a week. If building and testing the library took 6 hours, it pays for itself in 0.75 of a week, and over about 46 working weeks it returns roughly 368 hours. The numbers are examples, and the pattern is robust: libraries pay when many people repeat the same tasks.

Worked examples

Example 1: a manager's personal set. A team manager writes a 250-word set: role as a manager of a fifteen-person operations team, usual readers as her own team and her director, a warm and direct style with two banned phrases, the team's own terms defined, a rule to ask before assuming and a default of answer-first replies under 150 words. She reviews it each quarter and notes the date. Every draft she asks for now starts close to her own voice.

Example 2: a team library for customer replies. A support team of twelve builds six templates: billing complaint, fraud report acknowledgement, account access, product question, complaint escalation and feedback thank-you. Each has an owner, a version, an example and a "FACTS NEEDED" exit. A shared document lists them with a change log. New joiners produce acceptable replies on their first day. When a fee policy changes, the owner updates two templates and the log records the date.

Example 3: a weekly report template. An analyst builds a template with blanks for the period, the five key figures and the three notable events. The fixed part says: "Write a status note for senior managers in four sections: summary, numbers, notable events and next steps. Under 200 words. Use only the figures given. If a figure is missing, write 'figure needed'." The weekly job takes ten minutes, and the output is the same shape each week, which makes trends easy to spot.

Sharing with a team: avoiding drift

A shared library works only if people use the current version. Three habits help. Keep the library in one place with a clear "latest" copy, and avoid pasting templates into private notes that go stale. Make updates visible: when a template changes, post a short note with what changed and why. And agree a rule for local edits: people may adjust a template for a case, but if they find an improvement that works across cases, they send it to the owner so everyone benefits.

Common mistakes

Standing instructions that read as absolutes. Write them as defaults that a task can override. Bloated sets. Past about 500 words, rules dilute and conflict. Cut what does not change a reply. Stale instructions. Date them, version them and review them every quarter. Putting private data in a block that travels with every request. Templates with no blanks marked clearly. Use one visible convention throughout. Sharing untested templates. Run five realistic cases, including an awkward one. Many copies of the same template. Keep one source of truth and a change log. No owner. Without a named person, a library decays.

Key takeaways

Standing instructions, called custom instructions, personas, projects or the system prompt, go into every request. Write them as defaults, so that a task prompt can override them. Include what is stable and true for most tasks: role, usual audience, style, definitions, hard rules and format defaults. Aim for 200 to 400 words and include a safe exit for missing information. Keep out task facts, long examples, confidential data and contradictions. Date, version and review the set. A template holds a repeated task with clear blanks, an example, an owner and a change note. Test it on at least five cases, including an awkward one, before sharing. A library needs one source of truth, versions, owners and a review habit. It pays back when many people repeat the same tasks. A standing set sent with thousands of requests has a cost in tokens, though quality matters more than the bill.

Check yourself

1. Why write standing instructions as "unless I ask otherwise"? Instructions at different levels can conflict unpredictably. Defaults make clear that the task prompt wins. 2. Name three things that belong in standing instructions and two that do not. Belong: role, style rules, definitions, hard rules. Do not belong: task facts, personal or confidential data, long examples. 3. A set of 450 words goes with 4,000 requests a day. About how many tokens a day does it add? 450 ÷ 0.75 = 600 tokens each, so 2.4 million tokens a day. 4. What are the parts of a good template? Name, purpose, blanks, prompt text, an example, owner and version, and a change note. 5. Eight people use a template five times a week and save 10 minutes each time. How many hours a week does it save? 8 × 5 × 10 ÷ 60 = 6.7 hours.

Try this

You need an assistant that supports standing instructions or a way to paste a block at the start of each chat, and about fifty minutes.

1. Write a standing set for your own role in 200 to 400 words, with the six parts: role, audience, style, definitions, hard rules and defaults. Include "unless I ask otherwise" and a safe exit. Add a date and a version. 2. Run three of your usual tasks with and without the set. Compare the outputs against this rubric, one point per yes. Check · Without the set · With the setSounds like you or your organisation? · · Uses your definitions correctly? · · Needs fewer corrections? · · Free of invented facts? · · 3. Choose one task you repeat weekly. Turn your best prompt into a template with named blanks, a purpose line, an example and an owner. 4. Test it on five cases, one of them awkward. Record the failures, fix the template and rerun all five. 5. Write the library entry: name, purpose, version, date and change note. 6. Use the payback simulator with the numbers for your team, and decide which template to build next. 7. Set a reminder to review the set in three months.

A good result is a tested standing set, one tested template with a library entry, and a clear difference on the rubric. In the next lesson, the last of this module, we use the model to critique and improve its own work, and your prompts.

Tags: Prompt Engineering System prompts Custom instructions Templates Prompt library