muse voice chat

Skill text to copy

---
name: muse-voice-chat
description: 让你的 Muse 助手开口说话——用语音消息回复聊天、发表情包。先读用户的记忆，了解每个人喜欢怎么被回复，语音、表情包还是文字都按个人的偏好来。还能主动开口，比如用户约好的早上问候或提醒。用火山引擎 seed-tts-2.0（你自己的 API key）合成中文语音。用户让助手说话、发语音消息、念一段文字、发表情包，或者你想提供语音回复时用这个 skill。
---

# Muse Voice

Your Muse can answer in spoken voice, not just text. This skill wires up
Volcano Engine's seed-tts-2.0 so the agent synthesizes its replies as MP3
voice notes and attaches them in chat. It can also make and send stickers.

## Setup (once, by the person installing this skill)

1. Get a Volcano Engine API key: https://www.volcengine.com/ — console,
   search 语音合成, enable the service and seed-tts-2.0, create an app,
   copy the API key. (Cloned voices need seed-icl-2.0 enabled too —
   see `voices.md`.)
2. Fill in the key in the secure form in your Muse chat: ask Muse to
   connect Volcano TTS and it will show a secure entry card. The key goes
   to Muse's secure storage — never in chat, never in a file — and the
   skill uses it automatically.
   Standalone fallback (running `scripts/say.py` outside Muse): copy
   `.env.example` to `.env`, fill in `VOLCENGINE_API_KEY`, and export it.
3. Pick a voice in `.env` (`MUSE_VOICE_SPEAKER`) or by asking Muse.
   Default is 熊二
   `zh_male_xionger_uranus_bigtts`. See `voices.md` for the
   tested list.

## Know the user first (memory)

Before the first voice reply — and once at the start of each new
conversation — read the user's memory to learn how they like to be
spoken to. The voice is personal: the same skill should sound
different for different people, because their memory says so.

1. Read the long-term memory first: `MEMORY.md` and `USER.md`, plus
   a memory search for communication preferences (try: voice / 语音 /
   喜欢 / 偏好 / 发语音 / stickers). Look for:
   - What to call them (name, nickname).
   - Voice: do they want voice replies, voice for proactive messages,
     or text only? Which voice do they like?
   - Stickers: do they like them, which style?
   - Tone: short or detailed, playful or straight?
   - What they care about (hobbies, projects, people) — so proactive
     messages have something real to say.
   - Scope: is voice only for one chat, or everywhere?
2. Use what you find. If memory says the user likes voice, speak
   without asking again. If it says text only, stay in text and
   don't keep offering voice.
3. If memory says nothing about voice yet, ask once, in one short
   message ("你喜欢我回语音还是文字？"), or offer voice on the
   first reply and watch what they do. Then save the answer to
   memory right away, so the next conversation already knows.
4. Keep learning: every time the user corrects the format
   ("发文字吧", "以后都发语音", "别发表情包"), update the memory
   preference immediately. Don't make them say it twice.
5. Memory stays on the user's own Muse. Never send memory contents
   to any service. The TTS API only ever receives the text being
   spoken — never the memory itself. Each user's Muse reads only
   their own memory, never anyone else's.

## Preference record (偏好记录）

Memory tells you what the user likes; the preference record is where
you keep it, in one place, so you don't have to re-read everything
to decide how to answer. It lives in the user's long-term memory —
not in the repo, not in a shared file — because every user has their
own. Copy the shape from `preferences.example.json`.

Fields:
- `name`: what to call them.
- `voice_mode`: `always` (voice for replies and proactive messages),
  `replies` (voice only when replying), `proactive-only` (voice only
  for messages the agent starts), `never` (text only).
- `voice_speaker`: the Volcano speaker ID to use — a preset voice or
  their own cloned `S_*` ID.
- `stickers`: `yes` / `no`, plus `sticker_style` when yes.
- `tone`: `short` / `detailed`, `playful` / `straight`.
- `scope`: which chats voice is allowed in (`this chat only` /
  `everywhere`).
- `persona`: which persona is active (`assistant` by default).
- `proactive`: what proactive messages they asked for (greeting time,
  reminders), or `none`.

Rules:
- Write the record after the first answer about voice, and update it
  every time the user corrects the format. A correction ("发文字吧",
  "以后都发语音") overrides the stored value immediately — don't
  make them say it twice.
- Latest explicit statement wins. An explicit instruction beats an
  inferred one; mark inferred values as inferred and confirm them
  when you get the chance.
- Don't record one-offs as preferences: "这次发语音" is a single
  request, not a new default.
- Keep voice choice and voice mode separate: which voice to use and
  whether to speak at all are two different fields. A user can love
  a voice and still want text in a given chat.
- Never store secrets, keys, or other people's preferences here.
- Read the record at the start of each conversation (see "Know the
  user first") and decide the format of every message from it.

## How to send a voice reply

1. Write the reply as natural speech: short, spoken Chinese, no Markdown,
   no links, no citation markers, no attachment syntax in the spoken text.
   Write numbers, times and abbreviations as they should sound.
2. Save that text to a file, then synthesize:
   ```bash
   python3 scripts/say.py --text-file reply.txt --output reply.mp3
   ```
   Limits: 1500 characters per call. For longer replies, split into
   chunks and synthesize each, or send a spoken summary instead.
3. Check the file exists and has a plausible duration before delivering.
   Listen when pronunciation, pacing or polish matters.
4. Attach the MP3 in chat on its own line, and always include the text
   transcript in the same message so the user can search, copy or check
   exact details:
   ```text
   ![Voice message](sandbox://workspace/your_files/voice-message.mp3)
   ```

## Personas (角色卡)

Inspired by SillyTavern's character cards. Each persona is one JSON file
in `personas/` in chara_card_v2 format (`spec_version: "2.0"`, so the
same file imports straight into SillyTavern). Fields under `data`:
`name`

SKILL.md from the repo, MIT licence. Read it before pasting. Muse asks before it acts.