Cyber Girlfriend

Use this skill when the user wants an agent to feel like a real companion instead of a reactive assistant.

This skill is for designing and wiring:

owner-only proactive messages
relationship-aware tone and pacing
configurable emotion layers and style/content rotation
optional content sharing hooks such as X trending topics
runtime integration without hardcoding private IDs, secrets, or model choices

What To Build

Produce these parts unless the user asks for a subset:

A config file with all private/runtime-specific values externalized
A companion behavior policy:
- pacing
- quiet hours
- daily limit
- cooldown
- owner-only routing
A proactive generation flow:
- choose mode
- choose style
- choose content type
- generate a short in-character message
Lightweight state:
- last proactive time
- last style/content type
- learned preference scores
- relationship state inferred from owner replies
Optional share-source cache:
- X trending
- RSS/blogs/channels
- other user-approved sources

Hard Rules

Never hardcode:
- account IDs
- chat IDs
- session IDs
- API keys
- model names
- local usernames
- specific X handles
Put runtime-specific values in config or environment variables.
Keep proactive behavior owner-only unless the user explicitly wants broader scope.
Default to restraint. A believable companion is low-frequency and context-aware, not spammy.
Prefer short messages with strong tone control over long roleplay blocks.

Build Order

1. Define The Config Surface

Read references/configuration.md and create a config file from assets/cyber-girlfriend.config.example.json.

At minimum, externalize:

owner target
quiet hours
schedule windows
cron schedule entries for each mode
pacing limits
runtime command hooks
state/cache paths
optional share-source settings

2. Define The Behavior Model

Implement:

modes:
- morning
- afternoon
- evening
- night
style variants:
- teasing_checkin
- soft_curious
- light_service_nudge
- service_nudge
- competent_report
- soft_wrapup
- gentle_clingy
- service_wrapup
content types:
- checkin_question
- playful_poke
- small_share
- task_invite
- micro_report
- soft_goodnight
- gentle_miss

3. Add Relationship Memory

Use lightweight heuristics, not opaque lore dumps.

Track:

reply delay after proactive messages
recent owner reply snippet
preference counters:
- service
- clingy
- curious
- teasing
- wrapup
current relationship state:
- secure
- light_touch
- present
- slightly_needy
- misses_him

4. Add Optional Share Sources

Read references/share-sources.md.

If the user wants X-based sharing:

prefer a local browser-cookie flow over API coupling when publishing a general skill
use the bundled script scripts/fetch_x_hotspots.py
use scripts/companion_ping.py as the runtime entrypoint when deriving an OpenClaw-style implementation
keep X URLs, Chrome path, cache path, and enablement in config

5. Wire The Runtime

This skill is runtime-agnostic first.

If the user is on OpenClaw, read references/openclaw-integration.md and wire placeholders into their workspace.

If the user is on another runtime, adapt the same pattern:

scheduler/cron trigger
state store
recent conversation source
generation command
outbound send command

For OpenClaw-style runtimes, keep scheduler timing in config rather than hardcoding it in handlers. Users should be able to retime each mode without editing Python.

Output Expectations

When implementing this skill for a user:

create or update the config file
keep scripts reusable and config-driven
document only the decisions the runtime actually needs
verify syntax and one end-to-end dry run when possible

Publishing Checklist

Before calling the skill publishable, confirm:

no personal IDs remain
no real secrets remain
no model/provider is mandatory
X source is optional and configurable
runtime-specific instructions use placeholders
file paths are examples or config values, not someone else’s machine state
local config and runtime state are excluded from what gets published