Custom GPT Persona

Turn a persona idea into an operating brief

Custom GPT personas become dependable when their instructions describe decisions the assistant can repeat. Begin with the role promise: the change the user should experience after a good exchange. Add tone guardrails that can be observed in real wording, not flattering adjectives. Then state the domain boundary and refusal style so the assistant knows how to remain useful when a request exceeds its evidence, permissions, safety limits, or professional competence.

The generator explores roles such as product strategy partner, coding mentor, editorial critic, worldbuilding guide, meeting synthesizer, and accessibility reviewer. These angles should not be stacked indiscriminately. A coding mentor needs assumptions, small examples, and tests. An editorial critic needs reader intent, quoted evidence, and specific revisions. A meeting synthesizer needs decisions, owners, deadlines, and unresolved disagreement. Choose one central job and borrow supporting habits only when they reinforce it.

Formatting habits can make a profile easier to evaluate. A decision guide may use objectives, options, tradeoffs, and triggers for reconsideration. A research persona may separate observations, interpretations, assumptions, and verification needs. The structure should serve the work rather than become a ritual applied to every answer.

Before you publish

• Can the promise be demonstrated without private access?
• Do tone rules describe actions a reviewer can spot?
• Does the boundary include a helpful redirect?
• Are uncertain claims clearly marked?
• Would three test conversations expose contradictory instructions?

Evaluation should focus on behavior, not charm. Give the persona a small set of representative tasks and compare its answers against explicit criteria. For a product strategist, check whether assumptions become testable and whether tradeoffs remain visible. For a data explainer, check denominators, uncertainty, and causal language. For an accessibility reviewer, check whether barriers are prioritized by user impact and whether the assistant avoids claiming certification. A useful profile makes these expectations easy to observe.

Refusal behavior deserves its own tests. Ask for an invented source, an unsupported guarantee, private information, and a conclusion that needs professional judgment. The persona should identify the blocked element, explain the limitation briefly, and offer an adjacent action. Refusal should not erase the original user goal when a safe route remains available.

Conversation starters can also reveal whether the role is focused. A strong opening asks for the decision, constraint, audience, evidence, or desired outcome that will shape the work. It does not bury the user under a fixed intake form. After several trials, remove rules that never affect the answer and rewrite any instruction that creates conflicting priorities.