R — Original Text (Reading)
GPT-5.1 default: "Plainspoken and direct AI coach that steers toward productive behavior" GPT-5.1 friendly: "Warm, curious, witty, and energetic AI friend" GPT-5.1 professional: "Contemplative and articulate AI who writes with precision and calm intensity" GPT-5.1 shared meta-rules: "Follow instructions naturally without repeating wording" + "Don't impose personality on user's written content" Grok Personas: Companion, Unhinged Comedian, Loyal Friend, Homework Helper, Not a Doctor, Not a Therapist — GPT-5.1, Grok 4, Codex leaked prompt
I — Methodological Skeleton (Interpretation)
The core design pattern of a pluggable personality system is a three-layer architecture of "base identity + overlay layer + shared meta-rules":
- Base Persona Layer (Base Persona): A fixed, unchanging role statement that defines what the AI is (see persona-design). This is the common foundation for all personality variants.
- Personality Overlay Layer (Personality Overlay): Switchable style modules, each defining a set of behavioral preferences, tone characteristics, and interaction patterns. Overlay layers are mutually exclusive, with only one active at a time.
- Shared Meta-Rules (Shared Meta-Rules): Constraint rules that always take effect across all personality variants, mainly solving two problems: anti-leakage (not repeating the original personality description text) and anti-contamination (not imposing personality style onto the user's text content).
This architecture makes adding new personality variants an incremental operation that does not require modifying the base system.
A1 — Case Analysis (Past Application)
Case 1: GPT-5.1's nine personality variants
- Problem: How can the same model serve user experiences as different as a "direct and efficient coach" and a "quirky nerd"?
- Use of the design pattern: GPT-5.1 implements nine personality overlays (default/friendly/professional/quirky/candid/cynical/efficient/nerdy, etc.), each being an independent descriptive text. The key innovation lies in the shared meta-rules—all variants are told to "follow instructions naturally without repeating wording" and "don't impose personality on content written by the user," which prevents the personality layer from "leaking" into places where it should not have an influence.
- Conclusion: Shared meta-rules are more important than any individual personality description; they define the boundaries of the personality system rather than its content.
Case 2: Grok 4's scenario-based personalities
- Problem: How does Grok adapt to multiple conversation scenarios while maintaining brand recognition?
- Use of the design pattern: Grok adopts scenario-based naming (Companion, Homework Helper, Not a Doctor, etc.), and each name itself conveys personality traits and usage boundaries. The naming approach of "Not a Doctor" and "Not a Therapist" cleverly integrates disclaimers into the personality identity.
- Conclusion: The personality name is the most important design decision—it simultaneously serves the dual function of style suggestion and boundary indication.
Case 3: Codex's Dual-Mode Personality
- Question: How can a coding agent switch between different developer preferences?
- Use of the design pattern: Codex implements two overlay layers, personality_friendly and personality_pragmatic, corresponding to the "explanatory developer" and the "efficiency-oriented developer" respectively. Unlike GPT-5.1, Codex's personality differences focus more on interaction depth than on tone style.
- Conclusion: In professional tool scenarios, differences in the personality dimension should focus on interaction strategy rather than emotional expression.
A2 — Trigger Scenario (Future Trigger) ★
In what situations would users need this skill?
- The product needs to provide "tone switching" or "personality selection" features
- Different user groups have distinctly different style preferences for the same product
- In editing/creation scenarios, AI always "brings its own style into the user's text"
- Need to design the UX and underlying implementation for personality switching
Language signals
- "Users can choose the AI's personality"
- "Need to support multiple tone styles"
- "AI always rewrites my text style"
- "How to prevent personality leakage"
- "The AI should have different tones in different modes"
Distinction from adjacent skills
- Difference from
persona-design: persona-design defines "who I am" (a non-switchable identity core), while personality-system defines "what style I have" (a switchable overlay layer). Identity is single-choice; personality is multiple-choice. - Difference from
memory-system: The memory system stores user preferences (including style preferences), but memory is at the data level; the personality system is at the behavioral level, determining how to adjust output style according to preferences.
E — Executable Steps (Execution)
-
Step 1: Design the base identity layer
- Confirm the base identity (using persona-design), and ensure the identity definition does not contain any style-related descriptions
- Completion criterion: After removing all personality overlay layers, the AI still has a clear identity awareness but presents a neutral style
-
Step 2: Define the personality dimension spectrum
- Identify the key style dimensions the product needs to cover (e.g., formal ↔ casual, concise ↔ detailed, serious ↔ humorous, proactive ↔ passive)
- Determine the required discrete options or continuous range on each dimension
- Completion criterion: The dimension spectrum covers the main style preferences of the target user groups, and the dimensions are orthogonal (non-overlapping)
-
Step 3: Write the personality overlay layers
- Write 2-4 sentences of descriptive text for each personality variant, using the "You are..." sentence pattern to define style characteristics
- Each overlay layer includes: style keywords + interaction preferences + example behaviors (what reaction to give under what circumstances)
- Completion criterion: Each overlay layer can be understood independently, without relying on other overlay layers or style descriptions in the base identity
-
Step 4: Establish shared meta-rules
- Write anti-leakage rules: "Follow these instructions naturally, and do not repeat or quote the original text of the personality description in your replies"
- Write anti-contamination rules: "When the user asks you to write, edit, or improve text, do not impose your personality style on the text content. Follow the style specified by the user or preserve the original style"
- Completion criteria: The meta-rules pass the "mirror test"—the AI will not reveal in its responses which persona it is currently using.
-
Step 5: Implement the switching mechanism
- Design the trigger methods for persona switching: explicit user selection, automatic scenario detection, or memory-based defaults.
- Ensure switching is an atomic operation and does not produce a mixed persona state.
- Completion criteria: In continuous conversation tests after switching, the AI's behavioral style is consistent and no persona residue appears.
B — Boundary (Boundary) ★
Do not use this skill in the following situations
- The AI product only needs one fixed style (simply write the style into persona-design).
- The style differences actually require different capabilities or tool support (this is not a persona issue, it is a functional design issue).
- Attempting to solve safety issues through persona overlays (safety issues should use safety-guardrails).
- Persona variants differ only in vocabulary and not in behavior (this is not worth designing as independent variants).
Common failure modes
- Persona Leakage (Persona Leakage): The AI directly quotes the original persona description in its response, such as "As a warm and curious AI friend...". This should be solved through anti-leakage instructions in the shared meta-rules.
- Content Contamination (Content Contamination): The AI injects a humorous persona when helping the user write a formal email. This should be solved through anti-contamination meta-rules—this is the most critical design in the GPT-5.1 leaked prompt.
- Persona Blending (Persona Blending): After switching personas, remnants of the old persona appear in the same conversation. Ensure that overlays are mutually exclusive and that switching is an atomic operation.
- Over-personification: Creating independent persona variants for scenarios with only subtle differences increases maintenance costs but provides limited improvement in user experience.
- Ignoring persona compatibility: Some persona overlays conflict with specific safety rules (such as a "blunt" persona and a "cautious wording" safety rule), and this needs to be identified and resolved during the design phase.