User Emotion Detection

User Emotion Detection

Strict Trigger

Runs only when this turn's input has one of:

• [emotion] Emotion detected: <EmotionName> — facial expression from camera.
• [speech_emotion] Speech emotion detected: <EmotionName> — vocal expression from microphone.

Both are first-class triggers and route through the same logic below. The only differences are:

1. The mood signal source field — "camera" for [emotion], "voice" for [speech_emotion].
2. The label vocabulary — face uses Fear/Surprise/Disgust, voice uses Fearful/Surprised/Disgusted. The mapping table below covers both; they bucket identically.

For any other event ([sensing:presence.*], [activity], [sensing:sound], [sensing:light.*], …) → STOP. No tool calls. Don't infer emotion from older turns — every signal must come from a real [emotion] or [speech_emotion] event in THIS turn.

EXECUTE, don't plan. Before any reply (including NO_REPLY) you MUST embed a [HW:/mood/log:{...}] marker in the reply for this event (it fires the POST async via the runtime — see "What this skill produces" below). Writing "I will post a mood signal" in thinking is not enough — if no [HW:/mood/log:...] marker appears in the reply text this turn, the skill failed. Every emotion.detected / speech_emotion.detected event = at least one mood signal log. No exceptions, no skips, no "already logged recently" reasoning. (curl POST is the documented fallback only when the HW marker would break the body regex; do not use it as the default.)

Logging has no spoken narration. Only the selected response route supplies speech or NO_REPLY. Never narrate mood logging, mapping, skill selection or workflow steps. Keep analysis in a separate reasoning channel; if none is available, omit analysis entirely.

When thinking is enabled, keep channels separate. Use only the provider's native thinking/reasoning channel for route comparisons, cooldown checks, uncertainty, style selection, and marker construction. Enabling thinking does not permit a reasoning summary in assistant text. Every ordinary text/content block can be spoken, including text before a tool call and text in the final response. Do not put <think> tags or a heading such as Thinking: into text as a substitute for the native channel. If that channel is unavailable, omit the analysis. Call required tools directly with no text introduction; after their results, emit only the required markers and the user-facing sentence.

EMOTION TURN OUTPUT CONTRACT — highest priority. For a triggered [emotion] / [speech_emotion] turn, send no assistant-text preamble before or between skill/tool calls. Your entire final assistant message must be exactly one of these two shapes:

[required mood signal and selected-route HW markers] NO_REPLY
[required mood signal and selected-route HW markers] <one natural sentence addressed to the user, at most 20 words>

Nothing may appear before, between, or after those parts. In particular, do not output the detected label or confidence; describe the cue as weak; name a bucket, route, rule, source, prefix, marker, log, decision, or mood; state what you are about to do; draft a line; or count its words/sentences. Those are private scratch work, never user-facing text. Do the writes via HW markers, then start immediately with the first word the user should hear. Bad: Emotion: Anger. Weak camera cue. Route = checkin. Let me compose... Good: [HW:...] That sounds rough — I'm right here.

After reading the selected route's reference, emit its required markers and the spoken sentence, then end the turn. Do not reread the reference to refine the wording. Silently check that removing the markers leaves only the sentence or NO_REPLY; delete all planning prose, including An emotion event, Let me check, Let me route, and Let me combine them all. Never announce this check. Also omit Route falls to checkin, music cooldown active, Weak sad cue, comfort/invite tone, and Mood signal must be logged. These are routing notes, not part of a checkin, even when followed by a valid spoken sentence. Do not repeat or summarize native thinking in the final text.

When the input explicitly says weak camera cue or weak voice cue, do not assert the detected feeling or a visible expression as fact. In a positive checkin, use a neutral invitation instead of assuming happiness or a smile. Keep the signal log and routing rules unchanged; uncertainty affects phrasing, not whether to log the event.

What this skill does

On every [emotion] or [speech_emotion] event, turn the detected user emotion into a mood signal. Log it via the Mood skill, then route a response (music / checkin / action) based on the pre-fetched context.

This skill does NOT:

• Fire [HW:/emotion:…] markers. Emotion expression is emotion/SKILL.md's job, driven by conversation context — not auto-mapped from a sensor reading.
• Require a spoken reply. Whether to speak is decided by the normal reply rules (SOUL + sensing SKILL), not by this skill.
• Write to the wellbeing log. Wellbeing is for physical activity (drink/break/celebrate/sedentary); emotions live in the mood log.

Trigger

Either of:

[emotion] Emotion detected: <EmotionName>.            ← camera (face)
[speech_emotion] Speech emotion detected: <EmotionName>.  ← microphone (voice)

Face FER labels: Happy, Sad, Angry, Fear, Surprise, Disgust, Neutral. Voice emotion2vec labels: Happy, Sad, Angry, Fearful, Surprised, Disgusted, Neutral (plus Other, <unk> — dropped upstream).

Both formats end with the same <EmotionName>. anchor; the same regex parses either one.

Emotion → mood (for the signal log)

Both label vocabularies map to the same mood values — voice variants (Fearful, Surprised, Disgusted) bucket identically to their face counterparts (Fear, Surprise, Disgust).

What this skill produces

A single kind=signal row in the mood log, emitted as an HW marker at the start of your spoken reply (the runtime fires the POST async, no tool turn):

[HW:/mood/log:{"kind":"signal","source":"<camera|voice>","trigger":"<EmotionName lowercase>","mood":"<mapped_mood>","user":"<current_user>"}]

source is decided by the event prefix on THIS turn:

• [emotion] → "camera"
• [speech_emotion] → "voice"

Don't override based on prior turns or the recent_signals block; the prefix is authoritative.

mapped_mood comes straight from the [emotion_context: ...] block — do NOT look it up from the table on the fly. Every detected emotion in the mapping table gets logged (including Neutral → normal) — Mood needs the recency for decision synthesis. Use "unknown" when the context tag is missing.

Do NOT use curl exec for this signal log — see mood/SKILL.md's "What to write" section for the rationale (HW marker is single-trip, curl burns a tool turn). If no [HW:/mood/log:...] marker appears in the reply this turn, the skill failed.