The specifics — a sharper system prompt.
A briefing only helps if it is specific. Vague instructions give vague, unpredictable answers.
On the last page, swapping the briefing changed the umpire's manner. But a briefing only works as well as it is clear. Tell the umpire merely to “help with the cricket” and you have said almost nothing — so you get a different, often unhelpful answer each time.
The fix is to be specific. A sharp briefing pins down a handful of things: the role the model should play, the rules it should follow, the format its answer should take, the tone to use, and what to do when it is unsure. Each piece you pin down is one less thing left to chance.
It is the difference between telling an umpire “do your best” and handing them the match's playing conditions — exactly what to watch for, how to signal, how to handle a close call.
And consistency is the real prize. A vague briefing might give a fine answer once and a poor one the next time; a specific one makes the good answer the reliable one.
Sharpest of all is the piece that says what to do when the model cannot tell. Without it, an unclear appeal still draws a confident verdict; with it, the umpire is free to admit the doubt.
Start from a vague briefing and add one specific piece at a time. Watch the umpire go from a confident guess to an honest one.
The same one argument — just sharper.
Nothing new in the code: it is still one system string. Being specific is not a feature you switch on — it is just a clearer briefing.
Vague in, vague out.
A briefing that just says “help with the cricket” leaves the model to guess — so it rambles, hedges, and answers differently every time. Each specific piece you add — a role, the rules to apply, the format to use, what to do when unsure, the tone — removes a guess and makes the next answer more predictable.
A good system prompt is not longer for its own sake; it is specific. Say who the model is, what to do, how to answer, and what to do when it is not sure.