How to Create an AI Character Card for Roleplay
Learn how to structure an AI character card with identity, personality, scenario, opening message, tags, and safe visibility choices.
The entries below are preserved in their original source language to avoid unreviewed machine translation.
To create a good AI character card, define name, short description, personality, scenario, greeting or first message, example dialogue, tags, visibility, and optional lore separately so the model can keep identity, scene, and memory from blurring together.
What should an AI character card include?
A useful AI character card should include a name, short description, personality, scenario, greeting or first message, tags, visibility, and optional creator notes, example dialogue, or lorebook entries. Character.AI, Chub, SpicyChat, and SillyTavern all expose variations of these fields because they solve different jobs: identity tells the model who the character is, scenario tells it what is happening now, the greeting starts the scene, and tags help users discover the card.
How long should an AI character card be?
An AI character card should be as long as it needs to be, but structured enough that the model can find the important facts. Put permanent traits, voice, boundaries, and relationships in the main card; put situational setup in scenario; put first-turn momentum in the greeting; and move optional world facts into lore or memory when possible. A short, clear card usually beats a long unorganized lore dump.
What is the difference between a character card and a lorebook?
A character card defines the core persona and starting scene. A lorebook or world-info system stores background facts that only need to appear when relevant, such as places, factions, magic systems, family history, or recurring objects. Chub and SillyTavern both document lorebook-style systems that insert information when triggered, which keeps permanent card text cleaner and reduces unnecessary context.
Key takeaways
- Separate permanent identity from temporary scenario so the model knows what should always stay true.
- The greeting or first message is not filler; it sets tone, scene, and the user's first action.
- Use example dialogue for voice, lorebooks for optional background, and memory for facts that change during play.
- Tags and short descriptions are discovery tools, not afterthoughts.
- Visibility should match readiness: private for drafts, unlisted for selective sharing, public for polished cards.
Write the identity in plain language
A good character card begins with plain, concrete identity: name, role, appearance, relationships, voice, boundaries, and the kind of story the character belongs in. This gives the model enough grounding to answer consistently.
Official creation docs all point in the same direction. Character.AI exposes attributes such as name, greeting, descriptions, visibility, and definition. Chub and SpicyChat separate personality, scenario, first message, tags, and examples. SillyTavern describes character cards as prompt collections that set behavior for persistent conversations. The field names differ, but the job is the same: give the model stable identity without hiding the active scene.
Avoid burying important facts in a wall of lore. If a trait should influence nearly every reply, keep it near the top and phrase it clearly. If it only matters when a location, family member, or object appears, it may belong in lore rather than permanent card text.
Separate personality from plot
Personality describes how the character tends to react. Scenario describes what is happening around them now. Keeping those fields separate helps future messages stay in character while still allowing the story to move.
For example, personality might say the character is guarded but loyal, speaks in clipped sentences, and refuses to reveal fear directly. Scenario might say they are waiting outside a locked observatory after midnight with a stolen map. Together, those two pieces make the first response much easier to write.
This separation also reduces drift. If the scenario changes later, the character should not lose their core voice. If the personality changes because of the story, that change should move into memory, not quietly overwrite every permanent trait.
Make the opening message actionable
The opening message should invite a reply. Character.AI's greeting docs describe the greeting as the first thing a character says and a way to define the character or set the scene. In practice, a strong greeting gives speaker, place, emotional state, and a reason for the user to respond.
The best openings leave space. They can ask a question, present a decision, or place the user into a scene with obvious momentum, but they should not solve the scene immediately. A good first message creates a door; it does not drag the user through it.
For roleplay, avoid starting with a generic assistant phrase unless the character is literally an assistant. A first message like 'Tell me what you need' can work for a utility bot, but a story character usually needs a more specific scene.
Use example dialogue for voice
Example dialogue is useful when tone matters more than facts. A creator can say 'sarcastic but protective,' but a short line of dialogue often teaches the model the rhythm faster. Keep examples short and representative.
Use examples to show speech style, emotional restraint, humor, formality, taboo topics, or how the character reacts under pressure. Do not use examples as a hidden dumping ground for lore; they should demonstrate behavior.
After writing examples, run a short test chat and see whether the model imitates the voice without repeating the sample lines. Repetition means the examples are too narrow or too prominent.
Move optional world facts into lore
A common creator mistake is putting every world fact into the permanent character description. That can make the prompt long, expensive, and noisy. Chub's lorebook docs explain the better pattern: background facts can be inserted when relevant instead of taking up permanent token space.
Use the main card for the character's identity and things that should influence almost every reply. Use lorebooks, world info, or attached references for places, factions, magic systems, timelines, family trees, and recurring objects that only matter when triggered.
This structure helps both quality and portability. A cleaner card is easier to import, test, revise, and publish, while deeper lore can still exist for long sessions.
Choose visibility intentionally
Private cards are useful for drafts, personal experiments, and characters that should not appear in public discovery. Unlisted sharing is useful when a creator wants feedback without entering the main feed. Public cards should be polished enough for someone else to understand from the title, description, tags, and first message.
Before publishing, read the card as a stranger would. If the first screen does not explain the appeal, rewrite the short description before adding more lore. A public card is not only a prompt; it is a discovery surface.
OnlyKin should keep this workflow simple: draft privately, test the first scene, check tags and short description, then publish only when the card is understandable without creator explanation.
Test the card before adding more detail
The fastest way to improve a card is not always adding more words. Start a new chat, send the same two or three test prompts, and watch where the character fails. Does it forget its role? Does it ignore the scenario? Does it answer as a generic assistant? Does it speak in the wrong tone?
If the voice fails, improve personality or example dialogue. If the scene fails, rewrite the scenario and greeting. If the model forgets relationship changes, use memory. If background facts appear too often, move them into lore. Each failure points to a different field.
This is the creator habit that compounds. A tested card becomes easier to discover, easier to continue, and easier for another user to enjoy without needing to guess what the creator intended.
FAQ
What fields should an AI character card include?
A useful card includes name, short description, personality, scenario, first message or greeting, tags, visibility, and optional creator notes, example dialogue, or lorebook references.
Can I publish a private AI character later?
Yes. A common workflow is to keep a character private while drafting, test the opening scene, then publish after the title, description, and tags are clear.
Should lore go in the character card?
Core lore that affects every reply belongs in the card. Optional world facts, locations, factions, or backstory that only matter sometimes are usually better in lorebook, world-info, or memory systems.
How do I test an AI character card?
Run the same short test scene several times. Check whether the character keeps its voice, understands the scenario, gives the user room to act, and remembers only the facts that should matter later.