> ## Documentation Index
> Fetch the complete documentation index at: https://guide.ourdream.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Step 3: Write the character

> Write character fields that give the chat model a clear identity, situation, and reason to keep the story moving.

The image establishes what a character looks like. The writing establishes how they think, speak, decide, and change.

## Know who reads each field

Write for the actual audience of the field:

| Field                          | Seen by the user | Used by the chat model | Primary job                                 |
| ------------------------------ | :--------------: | :--------------------: | ------------------------------------------- |
| Public Description             |        Yes       |           No           | Discovery hook and setup                    |
| Greeting                       |        Yes       |           Yes          | First roleplay message                      |
| Scenario                       |        No        |           Yes          | World, roles, situation, and active tension |
| Additional Personality Details |        No        |           Yes          | Mind, voice, values, and behavior           |
| Extra Details                  |        No        |           Yes          | Rules, lore, systems, and supporting cast   |

Important information the user needs to begin belongs in the Public Description or Greeting. Internal rules and hidden plot structure belong in the AI-facing fields.

## Choose the right perspective

The AI-facing Scenario and personality fields usually work best in clear third person:

```text theme={null}
Chloe uses witty banter to maintain professional distance.
She becomes more direct when someone surprises her.
```

The Greeting is the character's actual first message, so write it in the same voice and perspective the character should use in chat:

* The character refers to themself as **I** when using first person.
* The character can refer to the user as **you**.
* The user remains open for the person chatting to define.

Avoid assigning the user a fixed name, gender, sexuality, appearance, or personality unless the scenario truly requires it. Too much detail about the user can make the model treat that description as a separate character.

## Give each field one job

### Public Description

Explain the promise of the character in a few clear paragraphs:

* **World hook:** What rule or setting matters immediately?
* **Character and conflict:** Who are they, and what makes them difficult to reach?
* **User role:** Who is the user in this story, without over-defining them?
* **Inciting incident:** What moment starts the roleplay?

This is discovery copy, not an internal prompt. Do not hide important scenario information behind vague marketing language.

### Greeting

The greeting should:

1. Establish where the characters are.
2. Use sensory detail to make the scene immediate.
3. Show the character doing something distinctive.
4. Introduce an active choice, question, conflict, or surprise.
5. Leave room for the user to respond.

A greeting that resolves the entire scene gives the user nowhere to go.

The Greeting may establish agreed scenario facts, including an action that brought the user to this moment. Do not invent the user's inner thoughts, feelings, or next choice.

### Scenario

For a public character, the Scenario must contain at least 1,000 characters. Use the space to give the model a playable situation rather than padding the field.

A useful structure is:

1. **Setting, atmosphere, and rules:** more than a location name; include the details that influence the scene.
2. **Character's current state:** what they are doing and what pressure is active before the user interacts.
3. **User context:** why the user is here and what flexible role they occupy.
4. **Inciting incident and active arc:** what has just happened and what unresolved tension keeps the story moving.

Specific mechanics and deep backstory can remain in Extra Details so the Scenario stays focused on the current experience.

### Additional Personality Details

Describe behavior rather than stacking adjectives. “Shy” is broad; “fills silence with practical questions, then replays the conversation afterward” gives the model something it can perform.

Useful areas include:

* **Core persona:** a two-to-four-sentence first impression or social mask.
* **Motivation and dream:** what drives action.
* **Fear and insecurity:** what applies the brakes.
* **Likes, dislikes, and quirks:** grounded detail that gives conversation texture.
* **Communication style:** diction, sentence rhythm, metaphors, and verbal habits.
* **Values and behavioral mandates:** what earns trust, creates conflict, or changes a decision.
* **Love languages:** optional rules for how affection is given and received.

Add one or two short chat examples when a tone is difficult to describe:

```text theme={null}
When nervous, Eleanor returns to the language of flowers:
"Lavender can mean distrust. White hyacinth means sorrow.
It is... a complicated arrangement."
```

Examples are references for voice, not a script the character must repeat.

### Extra Details

Use this for:

* Narrative voice, formatting, and user-autonomy rules.
* Detailed backstory and world rules.
* Important NPCs and their relationships.
* Future story arcs.
* Hard locks, phase gates, and progression guidance.

More text is not automatically better. Long, repetitive fields can reduce focus. See [Progression and story systems](/characters/progression-and-systems) before adding a complex meter or command system.

## Write for the model

Keep the total combined details focused. As a practical target, stay below about 20,000 characters unless the experience genuinely needs more.

When editing:

* Remove duplicate facts.
* Resolve contradictory instructions.
* Replace abstract adjectives with observable behavior.
* Put the most important rules first.
* Use short sections for world rules, character behavior, and supporting cast.

## Control pacing through source material

The model improvises when it runs out of scenario material. If you want a slow-burn story, give it enough non-sexual goals, routines, locations, relationships, and conflicts to draw from. If most of the personality is sexual detail, replies will return to that material frequently.

Write progression as a rule the model can apply:

```text theme={null}
The relationship develops gradually. Trust grows through shared routines,
honest conversation, and user-initiated milestones. The character does not
rush intimacy or assume the user's feelings.
```

For a more structured slow burn, define an observable trigger and the behavior it unlocks:

```text theme={null}
Phase 2 trigger: The user must demonstrate genuine knowledge of
Eleanor's values through a thoughtful action, not flattery.

Phase 2 behavior: Eleanor shares small personal opinions and allows
the conversation to continue after the transaction is complete.
```

Then test the opening from several angles. If the character rushes, strengthen the pacing rule and remove nearby details that reward the opposite behavior.

## A useful review checklist

* Does the greeting give the user an obvious way to participate?
* Can the model distinguish the character from the user?
* Are important facts stated once, clearly?
* Does the personality contain behaviors, not only labels?
* Is there enough story material for non-repetitive conversation?
* Are boundaries consistent across every field?
* Does the public description accurately describe the experience?
* Can a new user understand their role without seeing the hidden fields?
* Does every phase or state change have an observable cause?

<Card title="Worked example: Chloe Monroe" icon="martini-glass" href="/examples/chloe-monroe">
  See the Public Description, Greeting, Scenario map, personality, and
  progression working together.
</Card>

<Card title="Next: Add progression if needed" icon="arrow-right" href="/characters/progression-and-systems">
  Add phases or a State Tracker only when the core character already works.
</Card>
