Prompts & Writing
Writing System Prompts for Work You Do Every Week
By Jim Vernon, Editor, AI Intelligence International · Published 14 January 2026 · Reviewed against our editorial standards · About the author
If you write the same kind of thing weekly, retyping instructions is a tax you pay forever. A system prompt is where you pay it once.
The best system prompts are not clever. They are written-down versions of the standards you already apply when you review someone else's work.
Key takeaways
- Start from your review comments: Look at the last ten times you edited someone's draft.
- Structure that holds up: Four blocks: who you are writing for and in what voice; what is always true about the organisation; hard rules that must never be broken; and the default output format.
- Include examples, not adjectives: Two short examples of good output and one of bad output with a note on why teach more than a paragraph of description.
- Version it like code: Keep the prompt in a shared document with a date and a change log.
Start from your review comments
Look at the last ten times you edited someone's draft. The comments repeat: too long, no evidence, wrong audience, buried conclusion, unsupported claim.
Each recurring comment becomes a line in the system prompt. This is faster than inventing rules and it produces rules that reflect your actual standard rather than an idealised one.
It also has a side benefit: the document becomes a training resource for new team members.
Structure that holds up
Four blocks: who you are writing for and in what voice; what is always true about the organisation; hard rules that must never be broken; and the default output format.
Keep hard rules short and testable. 'Never state a statistic without a source in the provided material' is testable. 'Be accurate' is not.
Put anything sensitive — claims you are legally not allowed to make, regulated language — at the top and repeat it at the bottom. Instruction adherence is strongest at the edges.
Include examples, not adjectives
Two short examples of good output and one of bad output with a note on why teach more than a paragraph of description.
Choose examples that differ from each other so the model generalises the standard rather than copying a template.
Refresh the examples when your standard shifts, which is usually once or twice a year.
Version it like code
Keep the prompt in a shared document with a date and a change log. When output quality shifts, the first question is what changed, and undocumented prompt edits make that unanswerable.
Test any change against a fixed set of five real tasks before adopting it. Prompt changes have side effects, and the effect is usually visible on task three rather than task one.
Assign an owner. Shared prompts with no owner rot within a quarter.
Common failure modes
Overstuffing: fifty rules produce inconsistent adherence. Prune to the twenty that matter and enforce the rest in review.
Contradiction: 'be concise' next to 'cover all of the following twelve points' guarantees one instruction is ignored. Read the whole prompt for conflicts after each edit.
Style rules with no examples produce a caricature of the style rather than the style itself.
Where it pays off most
Customer replies, recurring reports, product descriptions, internal summaries, code review comments and anything with a compliance dimension.
The measure of success is the share of outputs you send without material edits. Track it informally for a month; a well-built system prompt usually moves it substantially, and that number is the honest ROI of prompting effort.
A template you can adapt this afternoon
Five blocks in this order: who the assistant is acting as, what the output is for and who reads it, the hard rules it must never break, the format specification, and one worked example of an acceptable answer.
Keep the hard rules to a short numbered list. Five enforced rules outperform fifteen aspirational ones, and every rule you add makes the others slightly less reliable.
End with the escalation instruction: what the assistant should do when it does not have enough information. Without it, the default behaviour is to invent, which is the failure you will spend most of your review time catching.
Version it like code
A system prompt in production is configuration, and undocumented configuration changes cause the same confusion here as anywhere else. Store it in a file with a version number and a changelog line per edit.
When output quality changes suddenly, the first question is what changed in the prompt and the second is what changed in the model. Both need dates to answer, and neither is answerable from a chat window.
Re-run your standard test cases after any edit. A one-word change to a constraint routinely alters behaviour on cases you were not thinking about.
Knowing when a system prompt is the wrong tool
If the assistant needs facts that change — prices, stock, policy details, customer history — those belong in retrieved context supplied at run time, not baked into the prompt where they silently go stale.
If the task needs a guaranteed structure, ask for structured output and validate it in code rather than pleading for correct formatting in prose.
And if the rules run past a page and still are not holding, the honest answer is that the task needs splitting into two narrower assistants rather than one heroic instruction set.
Frequently asked questions
How long should a system prompt be?
Long enough to encode your standards, usually a few hundred words. Beyond roughly a page, adherence degrades and rules start contradicting each other.
Should each task have its own system prompt?
Group by output type rather than task. Three well-maintained prompts beat fifteen neglected ones.
Do system prompts transfer between tools?
Mostly, though formatting conventions and instruction-following strength differ. Re-test your fixed task set after switching.
How do I stop teammates editing it randomly?
Give it an owner, a change log and a test set. The test set is what makes review objective rather than personal.
How often should system prompts be reviewed?
Quarterly, plus after any model version change. Vendors adjust default behaviour, and prompts tuned around old defaults drift without anyone editing them.
Can one system prompt serve several tasks?
Only if the tasks share the same rules and format. Otherwise you get an average of two behaviours and neither task is done well.