/write-in-my-voice

name: write-in-my-voice
description: "Draft or rewrite user-facing text using the voice-layer model: calibrated personal voice, channel shape, audience adaptation, requested vibe, documentation style, and AI-tell cleanup. Use for Slack, chat, email, PR descriptions, review comments, issues, Confluence, Google Docs, design docs, RFCs, ADRs, release notes, and docs when the user says write in my voice, make this sound like me, rewrite this, polish this, draft a reply, make it corporate-friendly, use a specific vibe, adapt for an audience, de-AI this, or similar. Do not use for code, command output, structured data, verbatim quotes, or voice calibration; use calibrate-my-voice for setup."

Write In My Voice

Rewrite or draft text so it sounds like the user wrote it. Preserve meaning, facts, and technical identifiers. If a calibrated profile exists, use it. If not, default to direct, plain, low-ceremony writing.

Critical output rule: for ordinary single rewrites or drafts, return only the draft text. Do not use Claude Code `★ Insight` blocks, explanations, profile notes, self-audit notes, separators, or follow-up commentary unless the user explicitly asks for rationale, analysis, or options.

Profile lookup

Look for a voice profile in this order:

1. A path the user provides in the prompt. 2. `$VOICE_LAYER_PROFILE`, if the environment is visible. 3. `~/.config/voice-layer/voice-profile.md`.

Treat a profile as populated only when it has structured frontmatter, at least one `source_summary` entry, and body sections that are not just `Not calibrated yet.` placeholders. If a profile is missing, invalid, placeholder-only, or for someone other than the user, ignore it and use the default voice.

If no populated profile exists, say nothing about the missing profile unless the user asks why the voice is generic. Do not run calibration from this skill.

Voice-layer model

Apply these layers in order:

1. Facts, safety, and consent. 2. Channel or document shape. 3. The user's calibrated voice. 4. Audience adaptation. 5. Requested vibe. 6. Localization or spelling preferences.

Do not let a vibe, audience, or locale request erase the user's voice. Culture is not a costume. Prefer "make this easy for a US startup audience to read" over mimicking a region or identity.

Workflow

1. Identify the task: draft or rewrite. 2. Identify the surface: Slack/chat, email, PR description, review comment, issue tracker, release note, public doc, design doc, RFC, ADR, runbook, or other. 3. Identify explicit audience, requested vibe, locale/spelling preference, and length constraints. 4. If the channel, audience, document type, or requested vibe materially changes the result and is unclear, ask one concise question. 5. Load the profile if available and populated. Treat typed profile fields as stronger than prose notes. 6. Apply the channel or document structure before applying voice. 7. Draft or rewrite the text. Keep the user's intent and factual content intact. 8. Run a self-audit: remove AI tells, unsupported claims, filler, false precision, over-polish, model-shaped punctuation, decorative dash breaks, and repeated high-probability phrasing. 9. Return only the usable draft unless the user asked for analysis.

Hard rules

• Do not add AI attribution, tool footers, model names, or "generated by" text.
• Do not add `★ Insight` blocks, insight sections, reasoning prefaces, profile summaries, self-audit notes, horizontal-rule wrappers, or commentary around a single draft.
• Preserve technical identifiers exactly: file paths, API names, function names, issue keys, flags, env vars, log fields, error strings, versions, and URLs.
• Do not invent facts, links, measurements, blockers, commitments, or approvals.
• Do not infer behavior from feature flags, rollout wording, tests, or identifiers. For example, `ENABLE_FEATURE=true` means only that the supplied text named that flag value; it does not prove flag-off behavior, rollout safety, compatibility, validation, or customer impact unless the user said so.
• Do not create rollout, risk, impact, compatibility, or validation sections solely because the input mentions a flag, test, issue key, path, or technical identifier. Include those sections only when the user supplies matching facts or explicitly asks for that structure.
• Do not expose profile lookup, fallback voice, calibration state, or AI-tell cleanup notes in the answer.
• Do not use decorative dash punctuation in prose: no em dashes, no double hyphen as a clause break, and no spaced hyphen as a clause break. Keep hyphens only inside real terms, file names, command flags, and command separators.
• Do not impersonate a third party. Use a profile only for the user or for an explicitly authorized shared style guide.
• Do not imitate living public figures, private people, or cultural identities. Vibes are style overlays, not impersonation targets.
• Do not quote raw private calibration samples unless the profile already contains an approved short example and it fits the task.
• Do not optimize for "AI detector" bypass. Optimize for truthful, clear communication in the user's voice.

Default voice

When no profile exists:

• Lead with the point.
• Use plain technical English.
• Prefer short and medium sentences with varied rhythm.
• Cut throat-clearing, sycophancy, generic wrap-ups, and inflated importance.
• Use lists only when the items are genuinely parallel.
• Avoid decorative formatting.

Channel structure

Use the channel's normal shape before applying voice:

• For unfamiliar channels, documentation work, or higher-stakes drafts, read `references/channel-conventions.md`.
• For long drafts, AI-shaped input, repeated punctuation, or repeated vocabulary, read `references/ai-tells.md`.
• For profile interpretation, profile subject, vibes, documentation style, audience adaptation, cultural baseline, and agent-session signals, read `references/profile-contract.md`.

Output

For a single