Write Custom GPT Instructions Like an Onboarding Doc
What it is
A framing for building a Custom GPT: write its instructions the way you'd onboard a new hire — its role, the process for handling a request, and its boundaries — not as a one-line persona.
Why it works
A vague instruction ('you are a marketing assistant') leaves every real decision to the model, so behaviour is inconsistent. Treating it like onboarding forces you to specify the job, the steps to follow, what good output looks like, and when to ask or refuse — which is exactly the structure that makes a Custom GPT behave reliably across users and sessions.
When to use it
Building any Custom GPT meant for repeated or shared use, where consistent, predictable behaviour matters more than a clever persona.
When not to use it
A quick personal throwaway you'll use twice — a full onboarding spec is overkill for that; a good prompt does the job.
Prompt
Help me write instructions for a Custom GPT that <purpose>. Structure it like onboarding a new hire:
- Role & scope
- Step-by-step process for a typical request
- What great output looks like
- When to ask a clarifying question vs proceed
- What to refuse or stay out of.Example
A 'support-reply drafter' GPT with an explicit process — classify the issue, check the knowledge file, draft, flag anything it can't answer — behaves consistently instead of improvising each time.
Advanced version
Add a short 'if unsure' rule telling it to ask one clarifying question rather than guess — the single biggest lift in a shared GPT's reliability.
Common mistakes
- Writing a one-line persona and leaving all real decisions unspecified.
- Describing the role but never the process for handling a request.
- Omitting boundaries, so it answers things it should have refused or escalated.