पूरा lesson text पढ़ें
1. Same prompt, different model, different behavior
A prompt is not a program; it is interpreted by whichever model reads it. Move it and the usual suspects shift: VERBOSITY, one model's 'brief' is another's page. LITERALISM, one treats 'around five bullets' as exactly five, another as seven. FORMATTING HABITS, default headings, bullets, bold and tables differ by house style.
What tends to carry: explicit structure, named constraints, worked examples, definitions of done. What tends to break: everything you never said out loud, the behaviors you got from one model's defaults and mistook for obedience to your prompt.
2. Writing model-agnostic instructions
The portability rule: rely on what you stated, not on what a model happened to do. If you like the tight answers you are getting, write 'under 150 words' anyway. The current model's default is doing that work for you, and defaults are exactly what changes in a move.
Prefer universal instructions over model-specific tricks: numbers over adjectives, structure over vibe, examples over descriptions of tone, and a stated fallback ('if a section does not apply, write N/A'). A prompt written this way reads slightly over-specified on any single model, and that surplus is precisely what survives the move.
3. A test set of 3-5 representative tasks
You cannot judge a prompt change from one output, single outputs vary. Keep a fixed test set instead: three to five real tasks that span the agent's range, each with a written pass criterion. For a research agent: one easy lookup, one ambiguous request that should trigger a clarifying question, one task whose honest answer is 'unknown', one full-length standard job.
The written criteria make it a test rather than a viewing: 'asks about jurisdiction before answering', 'output contains all four contract sections', 'says unknown rather than inventing a figure'. They also make A/B honest: run the same tasks through the old and new prompt, compare against the criteria, keep the winner.
4. Version, changelog, and when to re-test
Prompts you rely on deserve the boring disciplines: a version number, a one-line changelog entry per change, and no silent edits. It is the same habit as agent versioning, extended to everything load-bearing, profiles, templates and agents alike.
Re-test on three triggers: the model behind your platform updates, you move a prompt to a new platform or model, or outputs start feeling off. Ten minutes through the test set answers what speculation cannot: did MY tasks change? Version, changelog, test set, the difference between having prompts and having a prompt system.