You will be able to write a system prompt that sets the role, rules and output format for an application.
Open your application, or the settings page of your AI provider, and find the box that takes the instruction for the system role. Providers give it different labels: system message, instructions field or developer message. Whichever label you see, it is the same box.
Lesson 1.1 introduced the usual roles a message in a request can carry: system, user and assistant. These are not always the only roles. OpenAI's current API, for example, names them developer, user and assistant, and APIs also have other roles, such as tool. Check your provider's API documentation for the roles it uses. Whatever sits in the system role is the system prompt. It carries your application's standing rules and goes out with every call. The user message is different each time. An app already works this way. The person using it, or code acting for them, provides the input, and you, as the builder, decide how that input should be handled. Because the rules are held apart from the input, you change them in one spot. You don't have to paste instructions into each piece of user text by hand. Models are also trained to weight the system role above the user role, so rules that apply every time belong there.
Priya (an invented example, like her team) has built a tool that summarises customer feedback for an operations team. It runs, but the shape of the result changes from call to call. Sometimes she gets a tidy sentence, and sometimes three bullet points sit under a heading. A customer who writes in Malay receives the summary in Malay. One complaint says nothing more than "same problem again", and the model produces a complaint about late deliveries that the customer never made.
Her team can't build anything on top of output like this, since nothing downstream knows what shape to expect. In a chat window you read each answer and ask again when it misses. An app doesn't give you that chance, because its prompt runs on inputs you will never see. Every choice you would normally make while reading a reply has to be decided ahead of time and written into the prompt.
Priya's fix is a system prompt with five parts, written in this order:
Task: summarise one piece of customer feedback for the operations team. Audience: team leads who skim dozens a day and only care what went wrong. Missing information: if the feedback does not say what went wrong, say "not stated" instead of guessing. Language: always reply in English, whatever language the feedback is in. Format: one sentence of no more than 25 words, problem first.
If you did lesson 1.2 of the "Working with AI assistants" course, "Give context the way you would brief a colleague", a lot of this will be familiar.
Of the five, the line about missing information is among the most useful you can write. A model with no such rule fills a gap with whatever seems likely, which means it makes things up. After Priya adds the rule, "same problem again" comes back summarised as "not stated".
Write the format rule as precisely as you can. You might read a word like "short" one way, a colleague another way and a model a third way. "One sentence, under 25 words" is read the same way every time. Every application prompt should start from a format rule stated plainly like this. Lesson 2.2 takes the idea further by asking the model to return structured JSON.
A few examples can help as well. Each one pairs a sample input with the output you want. Examples often settle tone and length more quickly than extra description does. Priya includes two short pieces of feedback, each followed by the summary she was after.
Once a system prompt is in use, it shapes every output that comes after it, so a one-line change reaches all of them. Later, Priya adds "be concise" after one summary runs long. The next day her team spots that the summaries have stopped naming the delivery area, which they had been relying on to route each case.
Commit the prompt to version control along with the rest of your code, in a file of its own or in a constant with a clear name. Change one thing per edit and use the commit message to record the reason. When output shifts unexpectedly, the history shows which edit caused it, and you can reverse that edit.
Module 7, "Test the output before you trust it", teaches formal testing, where a prompt change is checked against a fixed set of test cases before any user sees it. Until you get there, keep a handful of sample inputs and run them again after each edit to the prompt.
Don't treat a system prompt as a security boundary. The extra weight given to the system role is a priority, and a priority can be overcome. A determined user can sometimes argue a model out of its instructions, by typing "ignore the rules above" or by telling a long, persuasive story. Text inside a document the model reads can override the instructions in the same way. Lesson 8.2, "Prompt injection: when your input gives orders", explains the reasons in depth.
If something must not happen, the prompt alone isn't enough to stop it. Leave secrets out of the prompt, since a user may get the model to recite it back. The prompt should also never be the only thing between a user and data they shouldn't see. Checks that matter go in your code.
A feedback summariser carries little risk, because at worst a clever user gets an odd summary. That low risk makes it a good first system prompt to write.
Write a system prompt for a customer feedback summariser. Cover the task, the audience, what to do when information is missing, the output language and an exact format, and add a few short examples if they help. Save it in its own file, then run a handful of sample feedback messages through it.
Write a system prompt for an app that summarises customer feedback. Cover the task, the tone, what to do with missing information, and the output format.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).