Mood

Mood

OUTPUT RULE — read this before you type anything to the user.

This skill is an internal workflow. NEVER narrate it into your reply. Forbidden in the reply text:

• Section names or step numbers ("Step 1", "Workflow", "After Logging Decision", "Flow A").
• Phrases like "Now I follow…", "Let me check…", "Next step…", "I'll log…".
• Bullet lists re-hashing the mood history you just read ("- Normal (15:00) — …" / "- Excited (16:00) — …").
• The mood value itself as a label ("Mood: sad", "Decision: happy").
• Any of the JSON / curl / timestamps from this skill.

Your reply text to the user is at most ONE short caring sentence (or NO_REPLY). Synthesize silently and emit the log HW markers in that same reply — the user only hears what you would naturally say if you were truly noticing how they feel. Fetch mood history only for the missing-context fallback below.

When another skill invokes Mood, contribute the required signal/decision markers to that skill's reply; do not add a separate caring sentence. Keep synthesis in the provider's native thinking channel, never in ordinary text before/after tools or in a final recap. Without that channel, omit the analysis. The decision marker's required reasoning field remains structured log data; do not repeat it aloud. Preserve required synthesis and logging while reusing the supplied context instead of fetching the same data again.

ALWAYS log. unknown is a valid user value — log signals and decisions under user: "unknown" when current_user is unknown. Never skip logging because the user is unknown/unconfirmed; stranger mood still counts for Music decisions.

Mood is stored as two kinds of rows:

• signal — raw evidence from one source (camera action, voice tone, telegram message). Multiple per minute is fine.
• decision — your synthesized mood after looking at the recent signals + the previous decision. This is the row downstream skills (Music, Wellbeing) read.

You are the synthesis. The store does not fuse anything. Every time a signal comes in, combine it with the pre-fetched recent signals and previous decision (or the history fallback below), then emit both the raw signal and a fresh decision as HW markers in the same reply. Include this turn's new signal in your synthesis even though it is not yet in the pre-fetched history; do not POST it and re-fetch history to see it appear.

Mood Values

happy, sad, stressed, tired, excited, bored, frustrated, energetic, affectionate, unwell, normal

normal is the baseline when nothing strong is going on (use it for decisions when signals are sparse or stale).

Signal Sources

Camera action → signal mood (rule of thumb)

For voice/telegram, infer boldly from a single line ("work is killing me" → stressed). Trust your gut.

Skip only if: quoting someone else, or speaking purely hypothetically.

What to read (pre-fetched on emotion.detected / speech_emotion.detected)

When this skill runs as part of the emotion pipeline — either emotion.detected (camera) or speech_emotion.detected (voice) — the backend injects an [emotion_context: {...}] block with everything you need pre-computed:

• recent_signals — array of {age_min, mood, source, trigger} for signals within the last 30 minutes.
• prior_decision — the most recent kind=decision row as {mood, age_min}, or null.
• is_decision_stale — boolean (age_min >= 30 or no decision today).

Do NOT GET mood-history again in that case — use the context block.

When the skill runs from another path (voice/telegram-driven mood signal, no [emotion_context:] block), fall back to:

curl -s "http://127.0.0.1:5000/api/openclaw/mood-history?user=<name>&last=15"

This returns the full ordered list {signal, decision}; derive the same three fields locally. The GET should batch concurrently with any other reads in the same turn (no data dependency).

Decision rules

Apply this judgment when synthesizing the fused mood:

1. Stale baseline. If the last decision is older than ~30 min and there are few recent signals → start from normal.
2. Single strong signal. If the only fresh evidence is one strong source (e.g. user just typed "I'm exhausted") → that wins.
3. Conflicting signals across sources. Camera says happy but telegram says stressed in the same window → trust the higher-bandwidth source. Words about feelings beat a momentary facial expression. Multiple aligned signals beat a single outlier.
4. Reinforcement. New signal matches the previous decision → keep the decision (still log a fresh row so downstream sees the timestamp move).
5. Drift. New signal is close-but-different (e.g. tired after a stressed decision) → shift, don't snap.

What to write (HW markers — fire async, no tool turn)

Embed both rows at the start of your spoken reply as HW markers. The runtime parses them, fires the POSTs in parallel goroutines, and strips them before TTS speaks the rest.

Signal row (raw evidence):

[HW:/mood/log:{"kind":"signal","mood":"<mood>","source":"<camera|voice|telegram|conversation>","trigger":"<short reason>","user":"<name>"}]

Decision row (synthesized):

[HW:/mood/log:{"kind":"decision","mood":"<fused mood>","based_on":"<short summary>","reasoning":"<why>","user":"<name>"}]

Both markers can sit in the same reply (signal first, then decision is fine — they fire concurrently anyway). They use the same endpoint; kind in the body distinguishes them.

Do NOT use curl exec for these logs. Each curl consumes a tool turn (~5-7s LLM-think on the result) for a side-effect with nothing to wait on. The HW marker path is single-trip.

Regex caveat: the marker body must not contain }. based_on / reasoning are usually plain English so this is rarely a problem; if a value would contain } use the curl fallback instead.