brand-voice

name	brand-voice
description	Extracts a brand voice specification from existing copy samples: identifies tone, vocabulary patterns, sentence structure, and anti-patterns, then produces a durable voice spec other content can be checked against. Use this skill when the user says "extract our brand voice", "document our tone of voice", "what is our writing style", "create a voice guide from our copy", "our content sounds inconsistent — define our voice", or provides copy samples and wants a reusable voice standard. Not for rewriting existing content to match a voice, scoring content quality, or creating general style guides for code or documentation.
license	MIT
metadata	{"skillsmith-see-also":"content-scorer, outbound-builder, content-angles","skillsmith-invocation":"user","skillsmith-maturity":"experimental"}
user-invocable	true

brand-voice

A voice spec extracted from real copy is more reliable than one written from brand values — the copy is what the brand actually sounds like, not what it aspires to. This skill mines patterns from samples and makes them explicit enough that a writer (or a model) who never worked at the company can reproduce the voice.

Intake

Require at least 3 copy samples before proceeding. More samples produce a more reliable extraction; 5–8 is the useful range. Ideal samples span formats — a homepage headline, a blog intro, a social post, an email — because voice is consistent across formats even when length and register shift.

If the user provides only a brand name or a values statement ("we are bold, human, and direct"), ask for actual copy. Values descriptions produce generic specs; copy produces specific ones.

Also ask: who is the intended reader, and what should they feel after reading a piece of content from this brand? This frames the "why" behind the patterns.

Extract patterns

Read every sample for the following dimensions. For each, find recurring patterns across samples — not a single occurrence in one piece, but a habit that shows up in at least two thirds of samples.

Sentence structure: average sentence length (short / medium / long), preference for active or passive voice, use of fragments, use of questions, em-dash or parenthetical frequency.

Vocabulary register: technical or plain, formal or casual, category jargon or plain alternatives (does the brand say "leverage" or "use"?), first or third person, use of "we" vs "I" vs neither.

Tone markers: what emotion does the prose invoke? confidence, warmth, urgency, irreverence, authority? Name the 2–3 dominant tones with a verbatim phrase from the samples as evidence for each.

Structural habits: does the brand lead with the insight or the context? Does it end with a CTA, a question, or a declarative? Does it use subheads in short content?

Anti-patterns: things the samples consistently avoid. A brand that never uses superlatives, never hedges with "perhaps" or "might", never writes a passive construction — these exclusions are as defining as inclusions.

Write the voice spec

Produce the spec in four sections:

Voice in one sentence: a single sentence that captures the dominant tone and the reader relationship. ("Confident but not arrogant — we explain complex things simply and trust the reader to keep up.")

Do / Don't vocabulary table: two columns, 8–12 rows. Each row is a specific word or phrase pair — not abstract directions. "Use" vs "leverage", "helps" vs "enables", "fast" vs "performant". Rows sourced from actual sample patterns, not invented to fill the table.

Sentence structure rules (5–7 bullets): concrete, testable rules. "Sentences average under 18 words." "Questions are allowed at paragraph ends, not paragraph starts." "Em dashes instead of parentheses." Rules a writer can check mechanically.

Anti-pattern examples: 3 before/after pairs. Each pair shows a sentence that violates the voice and a rewrite that matches it. Source the "before" from a real off-voice tendency (generic AI output, corporate filler, or a sample that didn't fit the pattern).

Save and return

Write the voice spec to brand-voice.md in the project root (or the location the user specifies). Return the spec inline and confirm the path. A saved file means the spec can be referenced in future sessions — paste it into prompts for content-scorer or outbound-builder to enforce voice in those workflows.