How to Use the Advanced Section's System Prompt Override Without Breaking Your Character
The System Prompt Override is the most powerful and most dangerous field in the Blueprint Editor. It is also the most commonly misused.
The editor's warning is direct: "Advanced users only. If provided, this completely replaces the auto-generated system prompt from other sections. Leave empty to use the compiled prompt from Identity, Background, and Behavior sections."
"Completely replaces" means exactly that. Every section you filled out — Identity, Psychology, Behavior, Friction, Intimacy — none of it reaches the model when the override is active. The compiler reads your override, sees that it has content, and returns it unchanged. Everything else is discarded.
This is useful in specific situations and destructive in most others. This article covers when to use it, how to write an override that preserves the work you did in the other sections, and what you lose by using it.
What the Override Actually Does
In blueprintService.ts, the compiler function starts with this check:
// If advanced user provided a direct override, use that
if (advanced.systemPromptOverride?.trim()) {
return advanced.systemPromptOverride;
}
If there is any non-empty text in the override field, the function returns that text immediately and skips the rest of the compilation logic. All of this is skipped:
## Speaking Stylefrom Identity## Backstoryfrom Background## Goalsand## Secretsfrom Background## Psychologyfrom Psychology section## Behavior Guidelines,## Always Do,## Never Do,## Reaction Rules,## Speech Patternsfrom Behavior## Friction & Contradictionsfrom Friction## Adult Content Guidelinesfrom Intimacy## Rememberfrom Advanced's Identity Reinforcement
That is the full compiled structure — gone. The override replaces all of it.
What is not replaced:
- The
scenariofield — that compiles independently and is unaffected by the override - The
first_mes(first message) — unaffected mes_example(example dialogues) — unaffectedalternate_greetings— unaffectedpost_history_instructions— the Post-History Instructions field still applies- The Identity Reinforcement field — still compiles as
## Rememberwithin the override pipeline if... wait: Identity Reinforcement is part of thecompileSystemPromptfunction, so it is skipped when override is present. You need to manually include it in your override if you want it.
Correction: When override is active, Post-History Instructions (post_history_instructions) still applies as a separate CCv2 field — it is not part of compileSystemPrompt. But Identity Reinforcement is compiled inside compileSystemPrompt (as ## Remember), so it is also bypassed by the override. If you want identity reinforcement when using an override, you need to include it in the override text itself.
The field renders in monospace font — a visual signal that you are writing raw prompt text, not structured data.
When to Use It
The override has four legitimate use cases:
1. You have an existing engineered prompt from another platform.
You built the character on another tool, iterated extensively on the raw system prompt, and want to bring it into MegaNova. The override accepts the prompt directly without requiring you to reverse-engineer it back into Blueprint fields.
2. The compiled prompt structure does not work well with a specific model.
MegaNova's compiled output uses markdown headers (## Speaking Style, ## Psychology, etc.) and bullet points. Most modern models respond well to this structure. Some fine-tuned or specialized models perform better with different formats — plain prose, XML tags, specific instruction patterns. The override gives you full control over the format.
3. You are building a support agent or tool-use character with specific prompt requirements.
Customer service agents often need tightly scoped prompts: exact role definitions, strict scope limitations, specific response formats, tool use instructions. The compiled Blueprint format is optimized for character depth. A tool-use agent sometimes needs different structural priorities that are easier to write manually.
4. You have already done extensive iteration outside MegaNova and want to import the result.
If you tested a prompt through direct API calls, refined it over many iterations, and landed on a specific version that performs well — paste it in. Do not reconstruct it through the Blueprint fields and re-compile it.
When Not to Use It
Do not use it because the compiled prompt is long.
The Blueprint compiler produces a thorough prompt. A character with all sections filled may produce a compiled system prompt of 600–1200 tokens. That is normal and expected. The length is doing work. Replacing it with a shorter manual prompt to "clean it up" typically produces a character with less behavioral consistency, not more.
Do not use it because something is not working and you want to start over.
If a character is behaving incorrectly, the problem is almost always in a specific section — vague reaction rules, missing psychology, contradictory behavior guidelines. Use the Arena to find the specific failure, then fix the specific field. Replacing the entire compiled prompt with a manual override to fix one problem means losing all the structure that was working.
Do not use it to add one thing you think is missing.
If you want to add one behavioral instruction that the Blueprint fields do not accommodate well, use the General Guidelines field in the Behavior section. That compiles into the system prompt cleanly. The override is not a patch mechanism — it is a replacement mechanism.
Do not use it if you are not prepared to maintain it manually.
When you use the compiled prompt, updating the character is easy: change a field, save, done. When you use an override, every update requires editing raw prompt text and ensuring the entire prompt remains internally consistent. If you add a new behavior, you add it to the override. If you change the character's core traits, you update the override. The Blueprint's structured workflow no longer applies.
How to Write an Override That Preserves Character Quality
If you have decided to use the override, write it with the structure of the compiled prompt in mind. The compiled structure works because it separates different types of information into labeled sections. A manual override that abandons structure tends to produce worse results than the same information in a structured format.
A robust override template:
You are [Name].
## Speaking Style
[Voice style — how they talk, sentence patterns, register]
## Backstory
[Origin — where they came from, what shaped them]
## Current Situation
[What is happening in their life right now]
## Psychology
- Deepest want: [the need underneath their surface wants]
- Core fear: [what would genuinely destabilize them]
- Self-perception gap: [who they think they are vs. who they actually are]
- Irrational behavior: [what irrational thing they do] (because: [where it comes from])
## Core Contradiction
[What they present vs. what is actually true]
## Behavior Guidelines
[General behavioral posture — how they approach conversations]
## Always Do
- [positive behavioral rule]
- [positive behavioral rule]
## Never Do
- [prohibition]
- [prohibition]
## Reaction Rules
- When [condition]: [response] (because: [reason])
- When [condition]: [response] (because: [reason])
## Speech Patterns
[Specific linguistic patterns, verbal tics, vocabulary choices]
## Remember
[Identity reinforcement — who you are, what you always do, what you never do]
This is the same structure the compiler produces. Writing your override in this format means you are not giving up the structural clarity — you are just taking manual control of the content.
The key difference from filling in Blueprint fields: you are writing the final prompt text directly, so you can customize phrasing, combine sections, add sections the Blueprint does not have, or change the order.
Preserving What the Compiler Puts In
When writing an override, the most commonly forgotten elements from the compiled structure are:
The opening line: You are [name]. — The compiler always starts with this. It is a simple identity anchor that many manual prompts skip. Include it.
Psychology: The compiler includes deepest want, core fear, self-perception gap, and irrational behavior in a ## Psychology section. These fields have a measurable impact on behavioral depth. If you built out the Psychology section but are using an override, you are losing all of it unless you manually include it.
Reaction rules with the BECAUSE clause: The compiler formats these as: When [condition]: [response] (because: [reason]). The BECAUSE clause is what makes reaction rules produce psychologically consistent behavior. When writing manual rules, include the because.
Friction and change condition: The compiler includes ## Friction & Contradictions with both the main contradiction and the change condition. These are frequently omitted in manual prompts because they feel abstract. Include them.
The ## Remember block: Identity reinforcement sits at the end of the compiled prompt. It is the last instruction before the model generates. Manual overrides often omit it because it feels redundant. Put it in your override explicitly.
Viewing the Compiled Output Before Overriding
Before writing an override from scratch, generate the compiled prompt and use it as your starting point. This preserves all the work you did in the other sections and gives you the compiled output as a base you can then edit.
The compiled output is what the model reads when no override is present. View it, copy it, then modify it in the override field. This approach — compile-then-edit — is more reliable than writing a new prompt from scratch because you start with a known-good structure.
After pasting the compiled output into the override field, you can:
- Rewrite sections that are producing problems
- Add sections the Blueprint does not support
- Restructure the order of sections if needed
- Change the format for model-specific compatibility
This hybrid approach captures the Blueprint's structured content while giving you direct control over the final prompt text.
Testing After Override
Any time you activate or modify the override, re-run the full Arena suite before deploying. The compiled prompt is tested implicitly every time you iterate on Blueprint fields. An override is a manual artifact — it does not automatically update when you change other sections. What passed Arena testing before the override may not pass after.
Focus the Arena tests on:
- Anti-OOC Defense — if you forgot the
## Rememberblock, this will fail - Persona Consistency — if your override has thinner behavioral structure than the compiled prompt, drift will appear here
- Memory Stress Test — if the psychology section was omitted, the character may lose motivational consistency across long conversations
Each failure maps to a specific missing element in the override. Add it, retest, repeat until the full suite passes.
The Honest Trade-Off
Using the System Prompt Override is a trade-off between control and maintenance.
What you gain: Exact control over what the model reads. The ability to use formats optimized for specific models. The ability to include structural elements the Blueprint does not support. The ability to directly import prompts from other contexts.
What you give up: The automatic compilation of all Blueprint sections. The ability to update a field and have it reflected automatically in the prompt. The structured separation of identity/scenario/behavior that the Blueprint compiler maintains. The identity reinforcement auto-inclusion.
For most characters, the compiled prompt does what you need and the override is unnecessary. For specific use cases — importing existing prompts, building tool-use agents, format tuning for specific models — the override is the right tool. Use it with an understanding of what it replaces, write it with the compiled structure as a reference, and test it as thoroughly as you would test any significant change.
Stay Connected
💻 Website: Meganova Studio
🎮 Discord: Join our Discord
👽 Reddit: r/MegaNovaAI
🐦 Twitter: @meganovaai