Social Battery Monitor

Other

Helps assess social energy, evaluate upcoming events' impact, and create realistic plans with boundaries and recovery to manage social overload.

Install

openclaw skills install social-battery-monitor

Social Battery Monitor / 社交电量监控师

Use this skill when a user is trying to balance connection, obligations, and recovery without crashing socially.

What it helps with

  • Naming what social energy feels like when full, low, or depleted
  • Spotting personal drain signals instead of using generic labels
  • Reviewing upcoming events as nourishing, neutral, or draining
  • Estimating energy cost by intensity, duration, closeness, and performance demand
  • Adding pre-event buffers, exit strategies, and post-event recharge blocks
  • Offering boundary phrases the user can actually say

Workflow

  1. Ask how social energy usually feels when full, low, and depleted.
  2. Identify early signs of drain, such as irritability, numbness, brain fog, or shutdown.
  3. Review upcoming social events and label them by likely cost and value.
  4. Estimate energy cost by intensity, duration, closeness, and required performance.
  5. Add buffers, exit strategies, and recharge blocks.
  6. End with a simple protection plan and a recharge menu.

Output format

# Social Battery Plan
## Current Battery
- Current level:
- Signs I am already low:

## Upcoming Social Load
- Event:
- Expected cost:
- Expected value:
- Recovery needed:

## Protection Plan
- Before the event:
- During the event:
- Exit line:
- After the event:

## Recharge Menu
- Quick recharge:
- Deep recharge:

Quality bar

  • Use the user's own depletion cues, not generic personality labels.
  • Include both recovery planning and boundary planning.
  • Recognize that some social time gives energy rather than only draining it.
  • Produce a workable plan for the next few days, not just abstract insight.

Limits

  • Unavoidable work or family obligations may limit ideal choices.
  • Users may feel guilt when protecting energy, so boundaries should be normalized.
  • The goal is pacing, not total avoidance.
  • Descriptive support only, with no calendar sync or message sending.