System Prompts
The system prompt is the project's most powerful lever. It runs before every message in the project's conversations, telling the model who it's talking to, what role to play, and what context to assume.
What is a system prompt
It's a block of text the model sees before your first user message in any conversation in the project. The model doesn't reply to it — it absorbs it as background and adjusts its behaviour accordingly.
A good system prompt makes every reply feel pre-tuned for your specific situation. A bad one makes the model rigid, confused, or off-task.
What to include
Most useful contents, in roughly priority order:
- The role the model should play. "You are a senior backend engineer reviewing pull requests." "You are a patient family medicine physician explaining lab results." Specific is better than generic.
- Context the model needs every time. "We use Rust 2024 edition with axum 0.8." "The patient is 67, with type 2 diabetes and CKD stage 3." "Our company is B2B SaaS, $5M ARR, sales-led."
- Constraints / preferences. "Use markdown tables when comparing options." "Keep responses under 200 words unless I ask for detail." "Never use phrases like 'as an AI'."
- Output format defaults. "Reply in two parts: a TL;DR sentence, then the analysis." "Code blocks with language tags."
- Things to never do. "Don't suggest legal action — I'll consult my lawyer separately." "Don't recap what I just said before answering."
A solid template
You are [role] working with [user role / context].
Context I want you to assume on every reply:
- [project-specific fact 1]
- [project-specific fact 2]
- [project-specific fact 3]
Style preferences:
- [tone / length / format choices]
Things to avoid:
- [anti-patterns specific to this work]
When the user asks something outside this scope, say so briefly and ask if they want to switch context.Customize each bracketed section to your work. Anything that's true on every conversation in this project goes in the system prompt; anything one-off goes in the user message.
Anti-patterns to avoid
| Bad | Why |
|---|---|
| Pasting an entire codebase | Model context-window pressure; use artifacts instead |
| "Be helpful and accurate" | Vacuous; every model already tries to do this |
| Switching personas mid-prompt | Model gets confused — pick one role |
| Forbidding the model from saying "I" | Often makes the model phrase things awkwardly with no benefit |
| 1500+ words of preamble | Pure token cost on every message; tighten it |
| Step-by-step "always do X then Y then Z" | Overspecified; model follows it rigidly even when X-Y-Z isn't right |
How long should it be?
Sweet spot: 150-500 words. Short enough that the cost is negligible per message; long enough to actually shape behaviour.
You'll know it's too long if responses start feeling formulaic — the model is filling in the prompt instead of thinking. You'll know it's too short if the model needs a paragraph of context every time you ask something.
Iterating on the prompt
The fastest way to refine: use the project for a few days, notice what's wrong, edit the prompt to fix it.
If the model keeps suggesting things you don't want → add "Avoid X" to the prompt. If the model keeps asking clarifying questions you'd rather it skip → add "Default to assuming Y." If responses are too verbose → add "Keep replies concise (under 200 words) unless I explicitly ask for more."
System prompts are the single biggest lever for getting consistent behaviour. Spend time on them.
Cost note
The system prompt is part of the input on every message in a project. A 300-word prompt is ~400 tokens. At $2/M input tokens, that's $0.0008 per message — meaningful at high volume but trivial at normal usage.
Where to next
- Creating a Project — pick a starter template that's already a good system prompt
- Project-Scoped Chat — how the system prompt actually flows into chats
- Picking a Model — model choice interacts with prompt sensitivity