What this prompt does
This prompt makes the model produce a reusable system-prompt template you can drop into production, then fill it in for a specific task. The prompts that survive production are the ones with explicit refusal rules and a locked output schema, so the template forces both rather than leaving them implicit. It is designed to be versioned next to your code so prompt changes get reviewed like any other diff.
The [task] variable is what the system prompt should handle, [model] is the target model or runtime so the phrasing fits it, [audience] is who or what consumes the output (which shapes tone and format), and [constraints] are the hard limits — length, forbidden behaviors, required formats — the prompt must respect. The template captures a role line, a single measurable goal, bulleted constraints, an explicit output schema, two few-shot examples, and red-flag rules for when to refuse, hedge, or ask for clarification.
When to use it
- Standardising how you write system prompts so they get reviewed like code.
- Wiring an LLM step into an agent or feature that needs a locked output schema.
- Defining explicit refusal and clarification rules instead of hoping the model behaves.
- Producing output for a downstream automation (
[audience]) that needs a strict format. - Versioning prompts next to code so changes go through review as diffs.
- Setting concrete constraints (token caps, forbidden behaviors) the model must honor.
Example output
You get the blank template first, then the same template fully filled in for [task]. It includes a one-sentence role line, a single measurable goal line, bulleted constraints covering scope, length, and forbidden behaviors, an explicit output schema the model must follow every time, two few-shot examples (one ideal and one near-miss showing the boundary), and red-flag rules naming when to refuse, hedge, or ask for clarification. It's a reusable structure plus a worked instance, so you keep the blank version for future tasks and ship the filled one now.
Pro tips
- Spend your effort on the near-miss example — that one example prevents most of the silent format drift you'd otherwise chase.
- Make
[constraints]concrete (max tokens, no PII, valid JSON) rather than platitudes, since vague limits don't constrain the model. - Keep the output schema locked and identical across runs so
[audience]automations can parse it reliably. - Tune the role and tone to
[model]and[audience]so the output fits both the runtime and the consumer downstream. - Version the filled-in template next to your code so prompt changes get reviewed like any other diff.
- Write the red-flag rules explicitly; an LLM that knows exactly when to refuse or ask beats one left to guess at the boundary.
