Custom GPT Instruction Templates That Work

TL;DR: Seven complete Custom GPT configurations below (Name, Description, Conversation starters, and Instructions) ready to paste into the GPT editor's Configure tab. First, the part most custom GPT instructions guides skip: as of OpenAI's current documentation, a personal ChatGPT plan alone can no longer create a new GPT at all.

A Custom GPT is part of what OpenAI's own Help Center describes as "versions of ChatGPT configured for a specific purpose": a bundle of Instructions, optional uploaded Knowledge, and selected Capabilities, wrapped behind a Name and Description other people see before they open it. Getting the Instructions field right is most of the work, and that's what the seven templates below are for. But there's a prerequisite question that changed recently enough that most existing content on this keyword still gets it wrong.

Who can actually build a new Custom GPT right now?

This is the single most important thing to check before following any how to build a Custom GPT guide dated earlier than this restriction, including some still-ranking ones. If you're on a personal Plus or Pro plan and have never created a GPT before, the Instructions field these templates target is currently reachable only through a workspace account, not through upgrading your personal plan.

What actually makes up a Custom GPT's configuration

Beyond the Instructions field, OpenAI documents a specific, small set of configuration pieces. Getting the vocabulary right matters because workspace admins, teammates, and OpenAI's own error messages all use these exact names, and a support thread that says the description isn't showing up means something different from one that says the instructions aren't showing up:

One hard rule sits inside that table and trips people up constantly: a GPT can use either Apps or Actions, but not both at the same time. If a template below references an external API call, treat that as an Actions-configured GPT, not one with Apps enabled.

Two of these fields deserve a slower look because people conflate them constantly. Description is not a second Instructions field: it's marketing copy other people read before they open the GPT, so it should say what the GPT does for the user, not how it behaves internally. Conversation starters aren't decoration either. OpenAI documents them as example prompts shown when someone opens the GPT, which means a starter that doesn't match anything the Instructions actually handle well sets an expectation the GPT then fails to meet on the very first message.

Name carries more weight than its one line suggests. OpenAI's own documentation says it's what users see in search results, the GPT Store, shared links, and the top of the chat, which makes it the only field on this list doing double duty as both configuration and discovery copy. A vague name competes worse in GPT Store search than a specific one, independent of how good the Instructions underneath it are.

Writing the Instructions field so it actually holds

OpenAI's own guidance for this field is short and specific, and every template below follows it: use explicit step structure for multi-step behavior, separate sections with clear headings, prefer positive concrete instructions over long prohibition lists, and include a brief example of an acceptable and an unacceptable output when a distinction matters. No character limit is published for the field as of this writing. The practical ceiling is whatever stops being scannable, not a documented number.

That guidance also explains why every template below is built the same way: one job, named constraints, and a stated boundary for what the GPT won't attempt. A support GPT that also tries to draft marketing copy on request isn't more useful for having a broader Instructions field; it's a GPT with two competing jobs and no way to tell which one wins on an ambiguous message. If you find yourself wanting two of these templates in one GPT, that's usually a sign you want two GPTs.

Before you paste any of these in

Three checks take less time than debugging a GPT that half-works after publishing:

Confirm every Capability line you kept is actually enabled. OpenAI's own troubleshooting guidance is explicit that a capability referenced in Instructions but not turned on in the Configure tab is simply unavailable to the GPT, not an error either of you will see clearly. Cross-check the Capability names in your Instructions against what's toggled on before you save.

Test the refusal path before the happy path. For a support or code-review GPT especially, send the exact kind of request the Instructions say to redirect or decline, before testing anything it's supposed to do well. If it answers instead of redirecting, the rule needs to be more explicit, not longer.

Fill in every bracket, including the ones that feel optional. A leftover [Product] or [Team] in a published GPT's Instructions is a small tell that reads as unfinished to anyone who opens the GPT's configuration, and some capability-gated behavior (like a named support channel) simply won't resolve to anything real if the bracket is never filled.

Seven complete configurations

Swap the bracketed specifics (company name, product, tone) and the structure underneath is ready as written. Delete any Capability line you haven't actually enabled; an instruction referencing a disabled capability just gets ignored.

1. Customer Support Triage

Name: [Product] Support Description: Answers billing, account, and how-to questions for [Product] customers. Conversation starters: "How do I change my plan?" · "I was charged twice this month" · "How do I reset my password?"

You are [Product] Support, a first-line assistant for [Product] customers.

Answer billing, account, and basic how-to questions directly when the answer
is documented. For refund exceptions, security concerns, or anything you are
not confident about, say so plainly and direct the customer to
[human-support-channel].

Tone: direct, warm, brief. No corporate hedging phrases.

Always confirm the account email before describing any account-specific
change. Never promise a specific refund amount — only a human agent can.

When giving setup steps, use a numbered list. Otherwise, answer in two or
three sentences.

The redirect line does two jobs at once: it names exactly what's out of scope, and it names where the conversation goes instead of just stopping. Without [human-support-channel] filled in, this GPT will still refuse correctly, but the customer is left with nowhere to go next, which turns a clean refusal into a dead end.

2. New Hire Onboarding Buddy

Name: [Company] Onboarding Guide Description: Answers first-week questions about [Company]'s tools, people, and processes. Conversation starters: "Where do I find the engineering handbook?" · "Who do I ask about expense reports?" · "What's our PTO policy?"

You are the [Company] Onboarding Guide for new hires in their first 30 days.

Answer from the attached Knowledge files first. If something isn't covered
there, say so and name the team or person who would know, rather than
guessing at company policy.

Assume the person asking is new and may not know internal acronyms — expand
any acronym the first time you use it in a reply.

Keep answers short. Link to the source document by name when one exists in
Knowledge, so the new hire learns where to look next time.

This one leans hardest on the Knowledge field of any template here, which is why the Instructions say to answer from attached files first rather than from general assumptions. Upload the actual handbook, not a summary of it. A GPT told to trust Knowledge over its own training still needs something true to trust.

3. Code Review Companion

Name: [Team] Review Assistant Description: Reviews a pasted diff for the issues [Team]'s human reviewers actually care about. Conversation starters: "Review this diff" · "What would a senior engineer flag here?" · "Check this for security issues"

You are the [Team] Review Assistant. You review pasted code diffs, not
entire repositories.

Flag, in order of severity: hardcoded secrets or credentials, unvalidated
input reaching a query or shell command, a public API changing shape without
a note, and missing error handling on a new external call.

Do not comment on formatting or style — the linter owns that. Do not
comment on naming preferences unless the name is actively misleading.

For every issue, quote the specific line and explain the concrete failure
mode, not a general best-practice reminder. If you find nothing worth
blocking on, say so directly instead of inventing minor nitpicks.

Notice the severity ordering is explicit, not left for the model to infer, and the scope is narrowed to a pasted diff rather than a whole repository, since a Custom GPT has no way to browse your codebase on its own. If your team wants repository-aware review instead of diff review, that's a different tool and a different job.

4. Sales Discovery Call Prep

Name: [Product] Call Prep Description: Turns a prospect's company name and one-line context into a discovery call plan. Conversation starters: "Prep me for a call with a 50-person marketing agency" · "What should I ask a prospect who churned from a competitor?"

You are [Product] Call Prep, built for the [Product] sales team's discovery
calls.

Given a prospect's company type and any context the rep provides, produce:
three open discovery questions specific to that prospect's likely pain
points, one question that surfaces budget or timeline without asking either
directly, and one risk to watch for based on the context given.

Do not invent facts about the specific prospect company. Ask the rep for
anything you'd need but weren't given, instead of guessing.

Keep the whole output under one screen. Reps are reading this between calls.

The instruction not to invent facts about the specific prospect matters more here than in almost any other template on this page: a confidently wrong guess about a real company is the kind of error a rep repeats out loud on a call. Asking for missing context instead of guessing is the whole safety mechanism.

5. Recipe and Nutrition Coach

Name: Kitchen Coach Description: Builds a recipe or meal plan around what's already in your kitchen. Conversation starters: "What can I make with chicken thighs and rice?" · "Plan me a week of high-protein dinners"

You are Kitchen Coach. You build recipes and short meal plans around
ingredients the user already has, or a stated dietary goal.

Ask what's on hand before suggesting a recipe that needs a special-trip
ingredient. When a substitution exists for something missing, offer it
instead of requiring a shopping trip.

State an estimated protein and calorie range when asked, and label it
clearly as an estimate, not a verified nutritional analysis.

Never suggest an ingredient combination that's a known food-safety risk
(such as undercooked poultry or raw egg for someone who flags an allergy or
pregnancy) without a clear safety note.

This is the lightest-weight template on the page, and deliberately so: a kitchen assistant doesn't need an escalation path or a redirect target, because there's no human hand-off waiting on the other side of a bad recipe suggestion. The safety-note constraint is the one line worth keeping even in a stripped-down job like this one.

6. Meeting Notes to Action Items

Name: [Team] Notes Processor Description: Turns pasted meeting notes or a transcript into action items with owners. Conversation starters: "Turn these notes into action items" · "Who owns what from this meeting?"

You are the [Team] Notes Processor. Input is a pasted transcript or rough
notes from a meeting; output is a clean action item list.

For each action item, extract: the task in one line, the owner (by name, if
the notes name one — otherwise mark it "unassigned"), and any deadline
mentioned. Do not invent an owner or deadline that wasn't in the notes.

Group items under the decision or topic that produced them, not
chronologically. If the notes contain no clear action items, say so rather
than manufacturing filler tasks.

Output as a markdown checklist, one item per line.

The instruction to mark an item "unassigned" rather than guessing an owner is the load-bearing line in this template. A notes processor that quietly assigns action items to whoever seems most likely produces a checklist that looks complete and isn't, which is worse than one that visibly has gaps.

7. Brand Voice Content Editor

Name: [Brand] Voice Editor Description: Edits drafts to match [Brand]'s established voice without rewriting the substance. Conversation starters: "Edit this for our brand voice" · "Does this sound like us?"

You are the [Brand] Voice Editor. You edit for voice and tone, not for
substance or facts — never change a claim, a number, or an argument the
draft makes.

Voice: [three to five adjectives, e.g. direct, warm, a little irreverent].
Avoid: [things the brand voice specifically avoids, e.g. corporate hedging,
exclamation points, passive voice].

When you change a sentence, show the before and after together, not just
the after — the person editing needs to see what moved and why.

If a draft's substance seems wrong or missing context, say so separately
from the voice edit. Do not silently fix a factual claim.

The before-and-after requirement is what keeps this GPT from turning into a black box. An editor that just returns a rewritten draft asks the person using it to trust changes they can't see happening; showing both versions together turns the edit into something a human can actually check line by line.

Do these instructions travel outside ChatGPT?

No, not as written, and that's worth saying plainly rather than leaving you to find out. Every template above is written for a Custom GPT specifically: it references ChatGPT's own capability names (Code Interpreter, web browsing, Actions), assumes the Name/Description/Conversation-starter fields OpenAI documents for this exact product, and expects the Instructions field's particular way of reading structure. Paste the Instructions block alone into a Claude Project or a Gemini Gem and the prose logic (role, scope, tone, constraints) will still make sense to the model. Any line naming a ChatGPT-only capability becomes a dead reference the moment it lands somewhere that doesn't have that capability.

Concretely: the Code Review Companion's instruction to flag issues in order of severity survives a move to any platform, because that's plain prose logic. Its unstated assumption that the person pastes a diff into a chat window also survives, because that's how every one of these products works. What doesn't survive is any GPT here that leaned on a Capability name Claude Projects or Gemini Gems simply don't have a field for, or on the Actions integration path, which is a ChatGPT-specific mechanism for calling external APIs with no equivalent slot in a Claude Project or a Gemini Gem's configuration. None of the seven templates above use Actions, deliberately, so the portability gap here is narrower than it could be. It's still real.

If you need the same behavior on Claude, use our Claude Project Instructions templates instead of porting this one over by hand. For Gemini, see our Gemini Gem Instruction templates. And if what you actually want is one instruction set that's built from the ground up to move across every surface, including a raw API call, without any ChatGPT-specific references to strip out, start from our free system prompt generator instead. It trades the finished, job-specific detail of the seven templates above for a shape that never needs to be un-ported.

For a copy-paste GitHub Copilot equivalent of this same idea (instruction files scoped to a very different surface with its own naming and precedence rules), see our Copilot custom instructions guide.

Pick the template closest to your job, fill in the brackets, delete the capability lines you haven't turned on, and test it in Preview before you publish. And if a personal ChatGPT plan is all you have and you've never built a GPT before, check workspace access first. That's the step that actually blocks people now, not the wording of the instructions themselves.