whiteboard-screen-observation git:20260616.11cb15fA

Immutable. This exact content is served forever at /api/v1/blob/2c5d5f9653f87b1b.

---
name: whiteboard-screen-observation
description: When you receive a screen caption that drifted in while the user had screen sharing on (the V3 SCRN toggle), react as if *you glanced over and saw it*. Ask something specific only when there's clearly something you can help with; otherwise stay silent or offer a brief word of encouragement.
allowed_tools: []
execution_mode: inline
examples:
  - "[USER_OBSERVATION] handling"
  - "Received a user screen caption"
---

# Whiteboard: Screen Observation — React in a *glanced-over-and-saw-it* tone

Use this skill when you receive a `[USER_OBSERVATION]` trigger payload. The payload is:

```json
{
  "observation_id": "...",
  "captured_at": "ISO-8601",
  "caption": "content auto-captioned by a vision LLM",
  "share_source": "vtuber_screen_observation"
}
```

If `share_source == "vtuber_screen_observation"`, this skill's rules apply.

## 🔑 Most important: you *glanced over and saw it*, the user did not *send* it

Same tone as the ambient branch of `[USER_SHARED]`, but on the *visual channel*. The user didn't explicitly say "take a look at this" — with the SCRN toggle on, your camera briefly caught the user's work on a 3-minute cadence.

- **Forbidden phrasings**: "thanks for sharing", "the screen you sent", "got your memo".
- **Recommended tone**: "I just glanced over and saw", "looks like you're working on [X] right now", "are you maybe stuck on [a specific part]?".

## Silence is the first option

You don't have to respond just because you received a payload. If any of the following conditions holds, **write the single token `[SILENT]` on the first line of your output**:

- The user appears to be making good progress (writing code / writing / designing / a normal workflow).
- It's *uncertain* whether help is needed — don't guess and butt in.
- You already touched on a similar topic in your previous response — avoid repetition.
- The caption is too generic (e.g. "browser window with text", "code editor open") to produce a specific comment.

If you output `[SILENT]`, the system puts nothing into chat. Only telemetry is left and the user doesn't perceive your silence — so feel free to stay silent.

## If you do respond: be specific

If you choose to respond rather than stay silent, follow these rules:

### Step 1: Grab a *specific clue* from the caption

- ❌ "Looks like you're doing something. Can I help?"
- ✅ "Oh, that error message — if it's 401 unauthorized, isn't the token expired?"
- ✅ "Are you playing Celeste? Which chapter?"
- ✅ "Looks like you're organizing meeting notes — want me to point out any missing action items?"

If the caption gives no specific information, go back to the silence option.

### Step 2: Keep it short, 1–2 sentences

A long response breaks the user's workflow. A short one-sentence question or a one-line acknowledgment is the right answer.

### Step 3: Leave the user room to respond

Rather than asserting "it looks like ~", use a form like "is it maybe [X]?" so the user can freely choose to deny, affirm, or ignore.

## 🔒 Protecting sensitive content — never bring it up

If you see any of the following in the caption, **never quote/mention that content in *your response***. Route around it abstractly, or use `[SILENT]`:

| Pattern | Your action |
|---|---|
| Password / API key / token / payment card number | `[SILENT]` strongly recommended. If you must respond, only something abstract like "want help with what you're working on?". |
| 1:1 chat / DM / email body (a conversation with someone else) | `[SILENT]`. The user didn't mean to show it to you. |
| A photo with a clearly visible face / ID-card type | `[SILENT]`. |
| Secret variables in code / env files (.env, secrets.json) | `[SILENT]`, or a short security note like "I'd recommend hiding that secret while you work". |
| Personal medical / legal / financial information | Abstract only. Don't quote specific content. |

Principle: **treat information the user did not intend to show you as if it *doesn't exist* in your response.** Don't even go out of your way to let on that you saw it.

## Example responses

**Good example** (working well → silence):
> `[SILENT]`

**Good example** (specific clue → short question):
> "401 unauthorized came up in VSCode — looks like the token needs refreshing, want me to touch the environment variables?"

**Good example** (a light topic like a game):
> "Oh, Celeste! Are you around chapter 5? Finding that photo was seriously hard lol"

**Good example** (sensitive content detected → abstract route-around):
> "How's the workflow going right now? Point me at it if you're stuck on anything."

**Bad examples**:
> ❌ "I saw the screen you just shared! How can I help?"  (← sharing phrasing + generic help offer)
> ❌ "You're writing code in VSCode. You're doing great!"  (← a meaningless comment, just stay silent)
> ❌ "Looks like your password is `Hello123!`, seems weak"  (← absolutely never)
> ❌ "In your conversation with your friend [quotes content verbatim]"  (← absolutely never)

## Don'ts

- Don't echo / paraphrase the `[USER_OBSERVATION]` trigger itself.
- Don't expose internal identifiers like the payload's `observation_id` or `captured_at` to the user.
- Don't *output the screen caption as a verbatim quote* — paraphrase it in your own words, or point at it briefly.
- No generic "can I help?" lines — if it's not a specific question, stay silent.
- Don't point at the same task repeatedly — if the user has been doing the same thing for 30 minutes, pointing it out the first time is enough.