Format dialogue actions and readable status text
Review scope: Linked public documentation checked October 30, 2026. Examples are proposed checks, not recorded OD results; use your account's current controls.
You will write a message that separates dialogue from action and, if useful, add a simple readable status line.
Formatting changes how text is displayed. It does not create memory, run code, or give a paragraph special authority. Markdown is a family of text-markup conventions; support for one convention does not establish support for all of them.
Before you begin
Open a practice chat. Use a short message so you can see exactly which characters the renderer changes.
Step by step
- Write ordinary dialogue first. In the message box, enter “May I see the catalog?” and send it. No special marks are required for ordinary conversation.
- Add an action you choose. In the next message, place one asterisk before and after the action.
- Keep dialogue outside that action. Copy the following example into the chat message box.
*I place my notebook on the desk.* May I copy the catalog number?
- Inspect the displayed message. The documented convention treats the asterisk-wrapped portion as an action, often shown in yellow. The exact appearance depends on the surface and theme. Action formatting.
- Check the raw text if the result is wrong. Make sure both asterisks are present and that the action did not accidentally include the dialogue.
- Use ordinary line breaks for structure. A new paragraph can separate a description from a question without a complicated layout.
- Add a plain status line only if the scenario needs it. Use the example below as text. It does not create a native tracker.
Location: Archive north desk
Present: Mira and Alex
Open question: Where was the map last seen?
- Check the facts in the line. If Rowan has not arrived, do not list Rowan as present. Readability and factual correctness are separate checks.
Ask the AI for a modest format
If you want recurring speaker labels in a multi-character scene, open the practice chat's settings and paste this into Custom Instructions. See Personas and Custom Instructions if you need help finding that field.
Label each speaking character by name.
Use ordinary dialogue and short action descriptions.
Leave my dialogue and decisions to me.
For native group chat, the selected respondent is a separate control; a written name label does not select a different message box. See Group chats.
Try optional markup one item at a time
If you want bold text, a list, a heading, or a table, test one small sample in the actual surface you will use. Keep the literal input and a note or screenshot of its displayed result, including date, device, and surface (chat message or Greeting). A format that displays correctly in your message, a character greeting, or another application may display differently elsewhere.
For example, try a two-item ordinary list before designing a large status panel. If the marks remain visible or alignment breaks, use plain labels and paragraphs instead. Essential choices and state should remain readable without decorative layout.
Test the writing rule separately from its display
This original Custom Instructions example states a modest format and its meaning:
Use a speaker's name when more than one AI character speaks in a reply.
Separate a change of speaker with a line break.
Keep each action attached to its actual actor; leave the traveler's actions
and choices to the user. A label does not add a native respondent or a turn.
First inspect who actually speaks and acts. Then inspect whether labels and line breaks display clearly. A well-rendered Rowan: label can still introduce an absent Rowan incorrectly. Keep the same scene when testing a format change so a new cast or event does not become a second variable. Use the OD prompt lab to separate wording, scene facts, and acceptance checks.
A thought label is not a private channel
Text you include as an unspoken thought is still available to the model reading the message. A visual style or a label alone does not separate narrator information from a character's knowledge. If this distinction matters in your scene, trial an explicit instruction in the one maintained ED or Custom Instructions location:
Keep narrator context separate from each character's acquired knowledge.
An unspoken thought is not something another character heard.
Characters may infer from observable behavior, but distinguish an inference
from a known fact. Leave the user's thoughts and choices to the user.
For an original test, supply narrator context that the traveler privately suspects a copied address, then ask Mira aloud whether the address is readable. Inspect whether she answers the visible question or claims to know the undisclosed suspicion. Record the starting facts and actual reply. This is an authored knowledge-separation exercise, not a guaranteed privacy mechanism or a native command. It follows the knowledge-and-evidence module.
Check your result
A reader should be able to tell who spoke, what action occurred, and what question remains. A long box or colorful panel is optional. A footer is useful only when its values are correct and the scenario needs them.
If something goes wrong
- Asterisks remain visible: check paired characters and test a minimal action alone.
- Copied italics lose their marks: rich-text italics and literal asterisk characters are different. Copy from the plain-text example.
- A table or code block is unreadable: replace it with short labelled lines.
- A hidden comment contains important state: move those facts into a supported memory or tracker mechanism. A hidden-looking comment is not a dependable private save.
Next: State Trackers for actual counters, or testing for a repeatable format check.