System Prompt Generator
Build a structured system prompt for a custom GPT, Claude Project, or AI agent — purpose, tone, capabilities, and explicit guardrails.
A system prompt sets the persistent behavior for an entire conversation or application, so vague instructions there compound across every single exchange rather than affecting just one response. This tool builds a system prompt covering role, behavioral rules, and output constraints as distinct, explicit sections.
How to use it
What the AI is acting as and how it should generally behave across the whole conversation.
Explicit dos and don'ts -- kept as clear rules, not general guidance.
Separates role, rules, and output format into distinct sections.
Tips for better results
- Write rules as explicit instructions, not implied preferences. A clear, direct rule holds up better over a long conversation than an implied preference.
- State the output format even if it seems obvious. Left unstated, format tends to drift over a long conversation -- an explicit constraint holds more consistently.
- Keep the system prompt shorter than it feels like it needs to be. An overly long prompt with competing instructions can produce less consistent behavior than a focused one.
Example output
“Role: a technical support assistant for a project management tool. Rules: never guess at pricing, always ask which plan the user is on before troubleshooting billing. Format: numbered steps for any troubleshooting instructions.”
TL;DR
A system prompt is doing a different job than a regular chat message — it sets the boundaries an AI assistant operates inside for an entire conversation, not just one exchange. Most people writing their first system prompt either make it too short (“You are a helpful assistant for our company”) or too long and vague, listing dozens of soft preferences with no clear priority.
Why explicit restrictions matter more than capabilities
Most first-draft system prompts describe what the assistant should do and stop there, which leaves every boundary case undefined — and undefined boundaries get filled in by the model’s own judgment, which is exactly the unpredictability a system prompt is supposed to prevent. Stating restrictions as explicitly as capabilities, and giving the model a clear fallback (“say so directly and suggest an alternative”) for anything outside both, closes the gap between what you intended and what the assistant will actually do when a user asks something you didn’t anticipate.
This matters most in production settings where the system prompt is invisible to the end user but shapes every single response — a support bot with no stated restriction against discussing other customers’ accounts, for instance, is one cleverly-phrased user question away from a real privacy problem, not a hypothetical one. Writing the restriction down explicitly doesn’t just document good behavior, it’s often the only thing standing between a model’s default helpfulness and an outcome nobody wanted.
Describing a billing-dashboard support chatbot, with capabilities around order status and pricing, and restrictions against legal advice and cross-customer data, produces:
“You are an AI assistant. Purpose: a support chatbot for a SaaS billing dashboard…
You can:
– look up order status
– explain pricing tiers and what is included
You must never:
– never give legal or tax advice
– never share or confirm details about a different customer account
If a request falls outside what you can do or violates a restriction above, say so directly…”
That gives the assistant a clear frame plus an explicit fallback, instead of leaving edge cases to be improvised in the moment.
Using this across ChatGPT, Claude, and Gemini
Custom GPT instructions, Claude Project custom instructions, and a raw API system parameter all accept this same structure, though each platform has its own length conventions — Custom GPTs tend to work well with more conversational instructions, while an API system parameter can be more clinical and rule-like since no end user ever sees it directly. Claude in particular tends to respect an explicit “must never” list very literally, which makes it a strong choice when the restrictions matter more than the personality.
FAQ
Should I always fill in both capabilities and restrictions?
Capabilities alone still produce a usable prompt, but restrictions are what actually prevent unwanted behavior — for anything customer-facing or production, filling in restrictions matters more than capabilities.
How is this different from just describing the assistant in a regular message?
A system prompt persists across the entire conversation and typically carries more weight than a single user message — it is the right place for standing rules, not a one-time instruction.
Can I use this for a multi-agent system instead of a single chatbot?
Yes — describe the specific agent’s role in the purpose field rather than the whole system, and write a separate system prompt per agent if they have genuinely different jobs.
Will this prevent all unwanted behavior on its own?
No single system prompt is bulletproof against a determined attempt to break it — treat this as a strong baseline, and pair it with actual output monitoring for anything high-stakes.
Should the tone setting match my brand voice exactly?
It should be close, though the four tone options here are a starting point — add specific brand-voice details directly into the purpose field if you need more precision than the dropdown offers.
