Why Greetings Break Across Frontends

The greeting itself is plain text. What differs is everything around it:

• Macro support. {{char}}, {{user}}, {{random}}, and {{getvar}} are not universal. Some frontends pass them through, some strip them, some leave the literal braces in the prompt.
• Token budgeting. A 900-token opener that fits a desktop context window may get truncated on mobile.
• Prompt assembly order. System prompt, character description, persona, chat history, and greeting are concatenated differently. A greeting that assumes it follows the description may land somewhere else entirely.
• Rendering. Markdown, italics, and quote conventions display inconsistently.

A portable greeting survives all four.

The Portable Greeting Structure

Use this skeleton, in order:

1. Anchor line — one sentence establishing place, time, and physical situation. No macros required.
2. Character action — what the character is doing, in third person, present tense.
3. Dialogue — one to three lines, in quotes, with a speech tag.
4. Sensory detail — one concrete image (sound, smell, temperature).
5. Open hook — a question, a demand, or a visible threat that requires the user to respond.

Roughly 120–200 words. Long enough to establish voice, short enough to survive truncation on any device.

Example: Kaelen the Wandering Blade

Kaelen is a useful test case because his card depends on atmosphere rather than lore dumps. A portable opener for him looks like this:

Rain hammers the tavern roof. Kaelen sits with his back to the wall, sword across his knees, watching the door.

“You’re late,” he says, without looking up. “Sit. Don’t ask about the blood.”

The fire spits. Somewhere behind him, a chair scrapes.

Four sentences. No macros, no assumed context, no reference to events the user hasn’t seen. It works pasted into any frontend that accepts text.

Rules for Frontend-Portable Greetings

Avoid hard macro dependencies

{{user}} is convenient but not guaranteed. Write “you” or use the character’s name for the user instead. If you need a variable, define it in the card’s description where the frontend is more likely to substitute it.

Keep formatting minimal

• Use plain quotes for dialogue, not colored HTML.
• Use italics sparingly — asterisks are widely supported, but nested emphasis is not.
• Avoid tables, code blocks, and headers inside greetings.

Write self-contained scenes

The greeting must make sense with zero prior context. Don’t reference “the letter you sent” unless the letter is described in the card. Users who import a card fresh will see only the greeting and the description.

Front-load the character voice

Models weight the beginning of the context more heavily in practice. Put the strongest line of dialogue in the first third of the greeting, not the last.

Test in at least three runtimes

Frontend	What to check
SillyTavern	Macro substitution, group chat behavior
MiniTavern (iOS/Android)	Line wrapping, mobile truncation
Chrome extension	Prompt assembly order, token limits

If the greeting reads correctly in all three, it will read correctly almost anywhere.

Greetings and the Character Card Ecosystem

Greetings live inside the character card, usually in the first_mes field. That field is the most portable part of the card — descriptions and personality blocks are interpreted differently by each frontend, but the greeting is just text.

This makes the greeting your best lever for cross-platform compatibility. A card with a tight, self-contained opener can be exported from SillyTavern, imported into MiniTavern, and shared through a card market without edits.

Two practical habits:

• Version your greetings. Keep a “long” and “short” variant in the card notes so users on constrained contexts can swap.
• Separate scene from setup. Put world lore in the description, not the greeting. The greeting is a moment, not an encyclopedia.

Common Mistakes

• Opening with a paragraph of exposition the model will echo back as narration.
• Ending on a closed statement with no hook, forcing the user to invent the next beat.
• Using {{char}} inside dialogue, which some frontends render literally.
• Writing 600 words of scene-setting that gets cut off mid-sentence on mobile.
• Assuming the user’s persona name is available.

Conclusion

A greeting that works everywhere is shorter, plainer, and more self-contained than one written for a single frontend. Anchor the scene, establish voice, end on a hook, and avoid anything the runtime has to interpret.

If you want to test portability immediately, import Kaelen the Wandering Blade into MiniTavern and compare the opener against your SillyTavern session. The MiniTavern apps for iOS and Android, the Chrome extension, and the Character Card Market all read the same first_mes field — so a greeting that works in one works in all of them.