yzxoi/user-voice-skill/voice-write

Voice Write

Draft or rewrite text that reads like the user wrote it — same language mix, same sentence rhythm, same formatting instincts, same tells.

Profile lookup

Find the profile in this order:

1. Explicit path given by the user.
2. <repo>/.synergy/skill/voice-write/profile/voice-profile.md
3. <repo>/profiles/voice-profile.md
4. ~/.config/user-voice/voice-profile.md

A profile is usable when it has structured frontmatter (schema_version, source_summary, confidence) and its body is not the empty template. If the profile is missing, invalid, or all placeholders — say so in one line and suggest voice-calibrate; do not silently invent a voice.

Workflow

1. Classify the task — draft (new text) or rewrite (existing text).
2. Identify the surface — chat reply, PR description, review comment,

issue comment, commit message, email, docs, release note, design note. The surface decides the shape; the profile decides the voice.

1. Identify constraints — audience, desired vibe (if any), length,

language. Ask one short question only when a constraint genuinely changes the output (e.g. "中文还是英文？").

1. Load the profile. Typed frontmatter fields override prose notes when

they conflict.

1. Shape first, then voice. Build the channel-appropriate structure

(subject line, opening, body, closing), then apply the voice layer.

1. Self-check against the profile and the AI-tells list

(references/ai-tells.md). Remove anything the user would never say.

1. Output only the deliverable. No preamble, no "here is the draft",

no meta-commentary, no "I hope this helps".

Voice rules (apply after loading the profile)

• Match the profile's language mix (e.g. Chinese with English technical

terms stays mixed; do not fully localize one way).

• Match length instincts: if the user writes short directives, keep it

short; if they write spec-style messages, keep structure but their words.

• Keep their opening habits ("你看一下", "帮我", "检查一下", direct verb...)

and their closing habits ("开个 PR 吧", "谢谢", nothing).

• Keep their punctuation texture (em-dash, colon, ellipsis, missing

terminal periods) — but never add decorative punctuation.

• Use their recurring phrases sparingly and only where natural.
• Match their formatting: their list style, their heading style, their

emoji (or absence of emoji).

• When rewriting: preserve all technical identifiers verbatim — paths, API

names, function names, issue keys, flags, env vars, log fields, error strings, versions, URLs. Voice never rewrites facts.

Hard rules

• No fabrication: never invent facts, numbers, or statuses to make text

sound confident. If a fact is missing, leave an honest gap or ask.

• No impersonation boundary crossing: voice style is not a license to

sign the user's name, approve things on their behalf, or bypass authentication/authorization. Drafts that will be sent as the user require the user's explicit go-ahead.

• No AI tells: no "As an AI", no "Certainly!", no "I hope this helps",

no em-dash decoration, no "delve/leverage/tapestry" filler, no fake enthusiasm. See references/ai-tells.md.

• No detector-bypass framing: this skill is for authentic personal

communication, not for evading AI-content detectors or hiding provenance.

• Channel shape wins over voice only for hard conventions (email subject,

PR title format, commit subject line). Everything else bends to the voice.

Examples

See references/examples.md for before/after rewrites on a real calibrated profile (anonymized) — read them when the user asks "give me an example" or when the surface is new to you.