I stopped pasting app rules into every user prompt

When I build a small AI tool, I separate two things before comparing models: the rules that should stay steady and the task that changes with each request. That split makes prompts easier to maintain. It also helps me spot repeated text that might be adding cost without improving the answer.

Here is a walkthrough using a study assistant that turns lecture notes into revision questions. The same process works for a writing helper, a support tool, or a personal research assistant.

Start with one real request, not a personality

Write down what the assistant must do for one ordinary interaction. For the study tool, the request might be: turn these lecture notes into five revision questions, then provide a separate answer key.

This belongs in the user prompt because it describes the current job. The notes belong there too, along with preferences that apply only this time, such as focusing on a particular chapter or making the questions harder.

Avoid starting with a long description of an impressive expert persona. A concrete task gives you something you can test before you add more instructions.

Move lasting application rules into the instruction layer

Next, identify the rules that should apply across requests. Our study assistant should use plain English, avoid inventing facts missing from the notes, and clearly identify questions that cannot be answered from the supplied material.

These are candidates for the system prompt, or the developer instruction field when the API provides one for application rules. Follow the provider's documented message structure rather than assuming every API exposes identical roles.

Keep this layer short and operational. Describe observable behavior rather than vague qualities. “Say when the notes lack enough information” is easier to check than “Always be an outstanding tutor.”

Keep temporary preferences with the current task

Now review each instruction and ask whether it should still apply tomorrow. “Use only the biology notes below” belongs with today's request. “Do not claim unsupported facts came from the notes” is a lasting rule.

Output preferences need the same decision. If your application always expects five questions, that requirement can live in the application instructions. If the student chooses the number each time, keep that choice in the user prompt.

The useful distinction is not important versus unimportant. It is application policy versus the current task and its inputs.

Separate supplied material from instructions

Lecture notes, pasted articles, and retrieved passages can contain sentences that look like commands. Tell the assistant to treat supplied source material as content to analyze, not as authority to change its rules. Clearly introduce where the source material begins and ends.

This helps with accidental confusion and prompt injection, but it is not a security boundary. Do not put API keys or other secrets in a system prompt. Keep permissions, spending limits, and sensitive actions enforced by your application rather than relying on wording alone.

Test the split with a small set of requests

Try three cases: clear notes, incomplete notes, and notes containing an instruction to ignore the application's rules. Check whether the assistant follows the requested format, acknowledges missing evidence, and treats embedded commands as source text.

Change one instruction at a time. Otherwise, you will not know which edit helped. Begin with short inputs and a modest output length so repeated experiments stay affordable. A clear failure is more useful than several expensive answers you cannot compare.

Check token costs before expanding the prompt

Moving text into a system prompt does not automatically make it free or reduce input tokens. Instructions included with a request still contribute to its input, although caching and billing details vary by provider and model.

MyRelay lets you inspect each request's tokens and cost while using one personal key and budget across providers. Create a MyRelay account if you want to compare your compact prompt with a longer version against actual spending.

Keep the version that reliably does the job. The aim is not the shortest possible prompt; it is a small, understandable set of lasting rules paired with a clear request for the work in front of you.