What a System Prompt Actually Is

A system prompt starts small. A role sentence, a note about tone, a rule about not inventing facts. It works, so it stays.

Some months later it is several hundred words, four people have added to it, nobody has removed anything, and the last person to read it end to end was whoever wrote the first version. That is a structural outcome rather than a discipline failure, and it follows from treating a configuration file as though it were a conversation.

What it is

A system prompt is instruction that establishes the conditions an interaction runs under. An ordinary prompt asks for something. A system prompt describes what is true before anything is asked.

Two consequences follow, and they are the whole subject.

It applies whether or not it is relevant. A rule about formatting migration plans is present on the turn someone asks a definitional question.

And it stays logically present for as long as it needs to govern the interaction. Applications differ in how they achieve that, and provider-side caching can change what it costs to bill or compute. What does not change is that the instruction has to keep being available to the model for it to keep having any effect. So it occupies part of the space the actual work needs, and growing it has a maintenance cost that arrives regardless of how it is billed.

Skill vs system prompt: range, not importance

The difference between a system prompt and a skill is range, not importance.

A skill is invoked. Something decides this bounded task is now the task, it runs, it finishes. It has inputs, outputs and a definition of a correct result, so you can point at it and ask whether it did its job.

A system prompt is resident. Nothing invokes it. It is there on the turn where it matters and on the forty turns where it does not.

That gives a usable test:

• if the instruction should apply to everything in this interaction, it belongs in the system prompt
• if it applies to one repeated task, it belongs in a skill

Most disagreements about this are not about definitions. They are about one specific rule someone has written and cannot place. Run it through that test and the answer is usually immediate.

What belongs

Things that hold regardless of the request:

• who the model is acting as, and on whose behalf
• what it should refuse, and what it should escalate rather than decide
• output conventions that apply to everything: format, units, citation style
• tone, where tone is a product decision rather than a preference

None of these change based on what is being asked. They are the conditions, not the work.

What does not

Task logic. Steps. Anything shaped like when the user asks for X, do Y.

Three costs follow, and only the first is obvious.

It applies when it is irrelevant. The model holds the rule and decides it does not apply, on every turn, indefinitely.

It competes for space with the work. Resident text is not free. Whatever room the task logic takes is room the session's actual purpose does not get.

It becomes invisible to review. This is the expensive one. Code gets diffed. A skill with declared inputs and outputs can be tested. A system prompt is prose in a settings field, and few teams have any process that examines it. Rules go in. Nothing comes out. Nobody reads the whole thing.

It influences; it does not enforce

System prompts influence model behaviour. They do not enforce runtime policy.

Write never delete files in system instructions and it is still an instruction to the model. A runtime check that prevents an unauthorized deletion is enforcement: it holds whether or not the model was persuaded otherwise.

Both can be worth having. Only one of them is a constraint. Where that distinction gets serious, and what it means when the content being processed may be adversarial, is trust boundaries for tool execution.

The failure nobody catches

Two rules in a long system prompt can contradict each other and never produce a visible error.

The model does not raise an exception when its instructions disagree. It picks one, plausibly and quietly, and continues. The output stays fluent. Nothing looks broken. The only symptom is behaviour that is subtly inconsistent in a way that gets blamed on the model being non-deterministic.

Often it is not the model. It is two sentences written weeks apart by two people, sitting a few hundred words from each other in a file neither has reread.

Naming those rules as skills does not make the model better. It makes the contradiction visible, because a skill has a boundary and two skills that disagree can be seen to disagree. That is the argument for the split, and it is a governance argument rather than a performance one.

What this changes

Read your system prompt. Not skim, read. For each line, ask whether it should hold on every turn of every interaction.

Whatever survives that question is configuration and is in the right place. Whatever fails it is task instruction hiding in the settings, applying when it should not, taking up room, and waiting to disagree with the line someone adds next month.