How to Create Reusable Custom Modes in ChatGPT
A useful mode is not just a role such as ‘act as an expert.’ It is a compact behavior specification: when it activates, what it prioritizes, how it answers, and what it must not do.
The short version
Define a custom mode as an observable operating contract. Give it an activation rule, purpose, required questions, decision priorities, answer format, boundaries, examples, and regression tests. Keep the mode narrow enough that users can predict when it should and should not be active.
Key takeaways
- Describe observable behavior instead of relying on vague expert personas.
- Separate activation, intake, reasoning priorities, output format, and boundaries.
- Use contrasting examples to show what a good response looks like.
- Test missing context, conflicting requests, and out-of-scope tasks before reuse.
Define the behavioral change
Start by describing what should be observably different when the mode is active. ‘Be strategic’ is vague. ‘Identify the three highest-impact problems, explain the evidence, then provide a revised version’ can be tested.
A mode should solve a recurring interaction problem. If the behavior is only needed once, a normal prompt may be enough.
Write the purpose as a transformation: what information enters, what decisions the mode makes, and what useful artifact leaves. This prevents the mode from becoming a collection of personality adjectives without a stable job.
Replace a vague role with testable behavior
- 1Weak: Act as a world-class conversion expert and improve my page.
- 2Stronger: Identify the primary conversion obstacle, cite the page evidence, rank three changes by expected impact, and rewrite only the affected sections.
- 3Test: The response must distinguish observed evidence from assumptions.
Specify the operating contract
The operating contract should be short enough to follow consistently and concrete enough to distinguish the mode from normal conversation.
Order matters. Put activation and scope first, intake questions next, decision rules after the required context, and the output format near the end. When instructions conflict, state which rule wins instead of expecting the model to infer your priority.
- Activation and deactivation phrase
- Primary objective and priorities
- Required questions before answering
- Fixed answer structure
- Boundaries and prohibited behavior
- Examples of good and bad responses
Control intake before generation
A reusable mode should know when it lacks enough information. Define the minimum inputs required to begin and the questions it should ask when those inputs are missing. This is especially important for audits, proposals, planning, and recommendations where assumptions can change the result.
Avoid interrogating the user with every possible question. Ask only for information that changes a decision or the final deliverable. Group questions into one concise intake when possible, then confirm the interpreted goal before doing expensive work.
- Required: information without which the task would be misleading.
- Optional: details that improve tailoring but do not block useful progress.
- Inferable: context the mode may infer if it labels the assumption.
- Out of scope: information the mode should not request or retain.
Design an output contract people can use
Specify the deliverable in terms of sections and decision value, not cosmetic formatting alone. A report can require an executive summary, evidence, prioritized findings, recommended actions, confidence notes, and unresolved questions. Markdown headings are useful, but the information architecture matters more than decorative formatting.
Include conditions for brevity. A mode that always returns a long framework becomes frustrating for simple tasks. Define when it should provide a concise answer, when it should expand, and when it should ask whether the user wants implementation detail.
Critical reviewer mode
- 1Verdict: one sentence stating whether the draft meets its objective.
- 2Evidence: exact passages supporting the verdict.
- 3Priority fixes: no more than five, ordered by impact.
- 4Revision: a clean version applying only those fixes.
- 5Uncertainty: facts or assumptions that still require verification.
Teach with examples and boundaries
Examples are useful when they demonstrate a decision rule that is hard to express abstractly. Choose examples that contrast acceptable and unacceptable behavior. Explain why the difference matters so the mode learns the principle rather than copying surface wording.
Boundaries should cover both subject matter and behavior. A mode may be allowed to improve copy but prohibited from inventing customer evidence. It may recommend tests but not claim guaranteed conversion increases. Clear limits make the workflow more trustworthy and easier to review.
- Do not invent facts, citations, results, or client constraints.
- Separate observations from recommendations and assumptions.
- State when the request falls outside the mode's purpose.
- Preserve user-approved content unless a requested change requires editing it.
Test failure cases, not only ideal cases
Test ambiguous input, missing context, conflicting instructions, and requests outside the mode’s purpose. A robust mode should ask for what it needs, remain inside its boundaries, and state uncertainty instead of inventing support.
Keep a small regression set of prompts. When you revise the mode, rerun them to see whether the improvement broke another behavior.
Record the expected behavior for each test rather than expecting identical wording. The test should evaluate whether the mode asked the right question, applied the right priority, preserved the required structure, and respected its boundaries.
- Ideal input with all required context.
- Missing information that should trigger questions.
- Conflicting requirements that require prioritization.
- A request outside the mode's scope.
- A user correction that should update the active context.
Choose where the mode should live
The right storage depends on scope. A short personal preference may fit ChatGPT custom instructions. Project-specific behavior may belong in Project instructions or a project document. A portable mode can live in a reusable text template that is pasted only when needed.
Do not place every workflow in global instructions. Rules that are useful for one project can interfere with unrelated conversations. Keep the instruction surface as narrow as the behavior it controls, and maintain a versioned source copy outside the chat when the mode matters to business work.
Review the mode periodically. Models and product features change, and a mode that once needed a workaround may become unnecessarily complicated. Retest core behavior after meaningful changes rather than assuming old instructions still produce the same result.
Sources and current documentation
Product capabilities can change. These official pages are included for current feature details; the practical recommendations above remain intentionally workflow-focused.