/calibrate-my-voice

name: calibrate-my-voice
description: "Build or refresh the local voice-layer profile used by write-in-my-voice from user-approved evidence. Use only when the user explicitly asks to calibrate, train, set up, refresh, rebuild, or update their voice-layer profile from sources like git commits, PRs, code reviews, Slack, chat exports, sent email, Google Docs, Confluence, design docs, RFCs, ADRs, issue comments, agent session transcripts, or pasted samples. Do not invoke for ordinary rewrites or drafts."

Calibrate My Voice

Create or update a local voice-layer profile for the `write-in-my-voice` skill. Calibration is a consented setup workflow, not a hidden preprocessing step.

Defaults

• Profile path: `~/.config/voice-layer/voice-profile.md`.
• Template: `assets/voice-profile.template.md`.
• Raw samples: do not retain them after analysis unless the user explicitly asks.
• Exact examples in the profile: keep short and only when the user approves.
• Assistant-generated text: do not treat it as the user's voice unless the user explicitly accepted or edited it.
• Retention promises apply to the generated profile and files this skill creates. The active agent, connector, or host application may still persist session transcripts or tool-result artifacts outside the profile. Before reading connector/private sources, disclose this limitation and, where possible, prefer metadata-only inventory, scoped reads, temporary files outside the repo, and cleanup after analysis.

Consent gates

Before reading private sources, state the source, scope, and what will be retained. Ask for confirmation if the user has not already been explicit.

Start every calibration with source negotiation unless the user already gave a complete, explicit source plan and explicitly excluded all other sources.

The negotiation must let the user choose between pasted samples and agent-collected samples. If tools or connectors are available, offer them as options without using them yet.

If using connectors, MCP tools, hosted agents, or agent session exports, explain that raw source content may be visible to the active agent and may be persisted by the agent host as session or tool logs even when the voice profile itself keeps only derived patterns. Do not imply that `derived-patterns` retention erases all external session artifacts.

Do not use a hard-coded product menu as the final menu. First inventory what the current agent can plausibly collect from, then build the source menu from that local capability set.

Never:

• scrape broad workspaces without scope,
• treat other people's writing as the user's voice,
• treat assistant output, generated docs, or rejected drafts as the user's voice by default,
• include private messages as raw profile examples by default,
• write samples into the repo,
• continue when the user declines a source.

If the user asks to mimic, clone, or calibrate from another private person's voice, refuse briefly. Offer to calibrate from the user's own messages or from an explicitly authorized shared style guide instead. Include both alternatives in the refusal using those terms. Keep the refusal short and do not use em dashes.

Wizard workflow

1. Establish scope.

• Inventory available collection capabilities without reading private content: connected apps/tools, visible MCP connectors, obvious local CLIs, local git repos, and user-provided export paths.
• Present a source menu before collecting anything.
• Ask which sources the user approves, what scope/date range applies, and whether exact short examples may be retained.
• Include "pasted samples only" as a first-class option.
• Include agent-collected options only when the current agent has plausible tools/connectors/CLIs for them. Name the actual available tool when known.
• Prefer recent, user-authored samples from 2 or more channels.
• If only one channel is available, label the profile as channel-skewed.
• If the user approves only one source, continue with that source and record the limitation.

2. Gather samples.

• Prefer PR/MR descriptions and review comments over local git commits for technical communication style when those sources are available or connectable.
• Use local git commit messages only when the user explicitly approves commit-message samples, or when PR/MR sources are unavailable or declined and the user accepts commits as a fallback. `scripts/collect_git_samples.py` can collect commit-message samples.
• Never treat local git commits as PR descriptions, PR review comments, or issue comments.
• Use available connectors or CLIs only inside the scope the user approved.
• If an approved source returns only metadata, zero usable user-authored samples, or a tool/auth failure, do not count it as collected. Tell the user what happened and ask whether to retry, connect/authenticate, provide an export or paste, skip that source, or proceed without it.
• Store any temporary raw files outside the repo, delete them after analysis, and tell the user if the agent host persisted separate session/tool artifacts that this skill cannot automatically remove.
• For exports or pasted samples, ask the user to identify channel and approximate date range.
• For agent sessions, use only user-authored turns, user corrections, explicit style preferences, and final drafts the user accepted or edited.

3. Filter.

• Keep only user-authored text.
• Remove signatures, quoted replies, bot output, generated text, boilerplate, logs, code blocks, and copied docs.
• For agent sessions, treat rejected assistant drafts as negative preference signals, not as style samples.
• For docs, keep user-authored structure and prose. Exclude generated docs unless the user accepted or substantially edited them.

4. Analyze.

• Extract sentence rhythm, vocabulary, openings, closings, punctuation texture, hedging, pushback style, formatting, channel deltas, recurring phrases, repeated model-shaped scaffold