Skip to content

Character card design: structure, fields, and what “good” means

Character card design here means designing the card’s content and information architecture—how you split voice, scenario, and lore so a model (and a human rereading the file in six months) can follow it. It is not the same as “cover art design,” though cover images matter for discovery.

This complements How to write a more usable character card and the field-by-field series.

What you are designing

A Silly Tavern character card is mostly JSON inside a PNG (V2/V3). Good character card design answers:

  1. Who speaks — stable voice constraints (personality, examples).
  2. Where the scene startsfirst_mes, scenario, optional alternate_greetings.
  3. What facts can surface latercharacter_book / lorebook entries instead of dumping everything into one paragraph.
  4. What the client must not ignoresystem / extensions only when you understand your ST build (see part 5 of the fields series).

Design principles that survive real chats

  • Short beats long in the main fields: put detail into lorebook triggers, not a 4k-word scenario nobody reads at once.
  • Examples teach format: mes_example is how you show “stage directions vs dialogue” if your RP style needs it.
  • One source of truth: if a rule appears in three places, it will eventually contradict itself.
  • Revision order: lock voice first, then opening, then world facts—see the writing-better article for a practical sequence.

Common design mistakes

  • Novelizing the personality field so the model roleplays about the character instead of as them.
  • Lorebook sprawl: hundreds of untested triggers; start with a small set and add when chats prove you need them.
  • Ignoring V2/V3: editors and ST versions differ; V2/V3 compatibility matters when sharing cards.

See also


Browse, preview, and edit embedded JSON in PNGs locally on Mac with Sillycard.

Sillycard — a simple Silly Tavern character card manager, native macOS app. © 2026 Sillycard