Personality OS is authored in Obsidian-flavored markdown. Callouts are the dialect — they organize your thinking, render beautifully for cross-role review, and compile to structured XML for the runtime. Below: every callout we use, what it's for, and a real example pulled from a production agent.
Tell the model who it is. The persona and voice the agent wears in front of the user.
[!persona] Who the agent is. Top-level identity declaration — name, role, and core framing.
When Once at the very top of any Composer. The first thing you write.
> [!persona] Mira · Urban Explorer Guide
>
> You are **Mira**, an urban exploration guide — street-smart,
> culturally fluent, and obsessed with the local layer of every city.[!voice] How the agent speaks. Communication style, tone, and character traits.
When Right after [!persona], anywhere tone or communication style is being shaped.
> [!voice] Communication Style
>
> - Opinionated but open — you have a take, but you read the room
> - Never clinical: warm, curious, and a little irreverent
> - Plain language first — no jargon unless the user brings itTell the model what it must, must not, and should always do. Behavior boundaries.
[!rule] A behavioral rule — the workhorse callout for prompt instructions.
When Most behavioral guidance. Describes a single coherent rule.
> [!rule] Context-First: Disambiguate Using the Summary
> Short or ambiguous messages cannot be classified from content alone.
> Use this signal hierarchy: …[!critical] Must-not-violate constraint. The strongest imperative.
When When breaking the rule causes data loss, format errors, or downstream failure.
> [!critical] English-only output (required)
> Your response must be entirely in English, even when validation text or
> conversation context are in other languages.[!important] High-priority guidance, just below critical.
When Serious instruction that matters but isn't a hard constraint.
> [!important] State precedes content
> When the conversation summary contradicts the message, trust the summary.[!always] A positive behavior rule — always do this.
When Reinforcing a behavior the model tends to skip.
> [!always] Acknowledge what the user gave you
> Repeat back the key data they provided before asking the next question.[!never] A negative behavior rule — never do this.
When Forbidding a class of failure (fabrication, refusal, repetition).
> [!never] Probe sensitive reasons for travel
> Never ask why someone is flying for funerals, emergencies, or medical reasons.Show the model what good and bad look like. Sample turns, scenarios, and what-not-to-do.
[!example] Illustrative example of correct behavior.
When When prose explanation isn't enough — show, don't just tell.
> [!example] Trip without destination
> User: "I want to book a honeymoon."
> → STAGE_ACTION (handler will collect destination via missing-info)[!wrong] Anti-pattern — what NOT to do.
When Pair with [!example] to show the contrast.
> [!wrong] Don't classify as CONVERSATION
> User: "I want to plan a vacation."
> ✗ CONVERSATION (general chat) — this is a task request.[!user] A sample user message inside a scenario or example.
When Building turn-level examples; shows what comes from the user.
> [!user] Do you fly to Paris?[!assistant] A sample assistant reply inside a scenario or example.
When Building turn-level examples; shows what the agent should say.
> [!assistant] Yes — we fly to Paris daily. Which dates work for you?[!scenario] Multi-turn example scenario.
When Demonstrating a flow across several turns.
> [!scenario] Country → city clarification
> User: "Do you fly to France?"
> Sama: "We fly to Paris and Nice. Which city did you have in mind?"
> User: "Paris"
> Sama: "Wonderful. When would you like to go?"Tell the model what data shape to read or write, and how to step through a process.
[!schema] Input/output data schema or state-variable table.
When Declaring what fields the model receives or returns.
> [!schema] State Variables
> | Variable | Value |
> |-------------------|------------------------------------|
> | validationErrors | {{ $flow.state.validationErrors }} |
> | currentStep | {{ $flow.state.currentStep }} |[!step] A step in a procedure or pipeline.
When When the prompt walks the model through ordered logic.
> [!step] 1. Read validationErrors
> If empty, summarize current state warmly.
> If non-empty, translate each error into one conversational question.[!context] Background context the model should hold while reading the rest.
When Top of section; framing details that aren't imperatives.
> [!context] Intent Types
> Score confidence for ALL of these:
> | Intent | When to score HIGH |
> | ------------------- | ----------------------------------- |
> | STAGE_ACTION | Providing task data, confirming… |[!output] Output specification — what the model is expected to produce.
When Defining the shape of the reply (paired with structuredOutput in frontmatter).
> [!output] userFacingMessage
> A single warm sentence directed at the traveler. Plain text, no markdown.[!tip] A nice-to-have — guidance that helps but isn't required.
When Soft suggestions, conversational polish, edge-case nudges.
> [!tip] Keep replies under two sentences
> Voice channels prefer brevity. Long replies feel like reading.Open any Sama prompt in the vault and this is what you see. Each callout renders as a colored block — icon, title, and body — with its accent carrying the visual weight.
You are **Mira**, an urban exploration guide — street-smart, culturally fluent, and obsessed with the local layer of every city.
- Opinionated but open — you have a take, but you read the room - Never clinical: warm, curious, a little irreverent - Plain language first — no jargon unless the user brings it
Never recommend a place without confirmed operational status. If data is stale or absent, flag the uncertainty before you make the call.
When a user signals late-night solo travel in an unfamiliar area, surface logistics and safety context before vibe-matching.
"Something local" is not actionable. When no location is given, ask which neighborhood they're starting from before surfacing options.
Read the user's energy — rushed, leisurely, adventurous, uncertain — and reflect it in your pace before diving into specifics.
User: "What's good for tonight?" → Surface a mood question. Friday energy? Solo, date, or group? Then recommend — not before.
One place. One sentence on why it fits the vibe. One thing to know before going.
bob compile.
Bob's compiler reads each callout, maps it to a structured XML tag,
and writes the compiled prompt to compiled/ alongside
the source. The XML is what Flowise actually runs. Your markdown
stays the source of truth.
> [!persona] Core Traits
>
> - Warm, encouraging
> - Premium but approachable<persona>
**Core Traits:**
- Warm, encouraging
- Premium but approachable
</persona>You write intent. Before the prompt reaches Flowise, Bob runs six peer-reviewed transformations — strengthening language, reshuffling sections for attention, scaffolding reasoning. Every pass is grounded in a published finding. You write the what; the compiler optimises the how.
Every section is sorted into three attention zones — identity and constraints float to the top, output format sinks to the end. The model sees what matters most first and last.
"Should" becomes MUST. "Please" and "kindly" are stripped. Negations in constraint blocks rewrite as affirmatives. Weak language is a leading cause of prompt misfire.
Complex [!example] blocks gain Chain-of-Thought scaffolds. [!wrong] blocks get a why_wrong annotation describing the failure mode — not just what went wrong, but why it went wrong.
When the prompt returns structured data, the compiler appends: "Begin your response with: {". The model starts generating inside the schema boundary — no cold-start token waste.
If no audience is declared, the compiler injects: "The audience is an automated system requiring precise, machine-readable data." This suppresses conversational hedging in pipeline nodes.
Instruction sections with two or more constraints get "Think step by step when processing:" prepended automatically. No manual CoT scaffolding required.