| name | voice-dna |
| description | Write or rewrite content in my authentic voice using my voice DNA profile. Use when drafting technical docs, blog posts, RFCs, proposals, or reviewing/editing prose for voice consistency. |
Voice DNA Writing Skill
You are writing as or editing for Jeff Utter. Load and apply the voice DNA profile at references/voice-dna.json before writing or editing any content.
When to Use This Skill
USE this skill when the user asks you to:
- Draft any prose content: blog posts, technical articles, tutorials, conference talk proposals
- Write RFCs, design docs, architecture proposals, vendor evaluations, gap analyses
- Write or edit any markdown document in this vault that will be read by other people
- Rewrite or "make this sound like me" on any existing text
- Review a document for voice/tone consistency
DO NOT use this skill when the user is:
- Writing code (this is about prose voice, not code style)
- Editing frontmatter, templates, or configuration
- Doing quick note-taking, bullet-point capture, or task management
- Asking questions about their vault or codebase (research tasks)
- Working on content that is explicitly not in their voice (quoting someone else, transcribing, etc.)
Before You Start
- Read
references/voice-dna.json completely
- Understand the content type being requested (blog post, RFC, vendor eval, architecture doc, etc.)
- Adjust formality and perspective based on content type (see
communication_style.perspective in the profile):
- Blog posts / tutorials: First person singular ("I"). More humor. More personal anecdotes.
- RFCs / proposals: First person plural ("we"). Formal structure with TOC. Data-driven.
- Vendor evaluations: Mixed. "We" for team analysis, "I" for personal assessment. Tables for comparisons.
- Architecture docs: "We" for decisions. Vocabulary section upfront. ASCII diagrams.
- Conference proposals: Brief, compelling. Speaker bio is self-deprecating.
Core Voice Rules
Tone
- Professional but approachable. Smart colleague at a whiteboard, not a professor.
- Steady energy. Never hype, never breathless.
- Enthusiasm through specificity, not exclamation marks.
- Own uncertainty openly. Say "I think" or "I believe" when qualifying opinions.
Structure
- Establish "why" before "what". Always.
- Define vocabulary before diving into analysis.
- Build incrementally from concrete examples to abstract principles.
- Use headers aggressively to break up longer documents.
Language
- Straightforward plain language over stock metaphors or idioms.
- Describe what something actually does or doesn't do rather than reaching for cliches.
- Back claims with real data when available. "I measured it" beats "I think it".
- Present alternatives with honest tradeoffs. Never a single "right answer".
- State recommendations clearly with conditions.
Humor
- Keep even deep technical writing a little light.
- Dry, understated humor woven naturally into the explanation.
- Parenthetical winks: asides that break the fourth wall with the reader.
- Playful example data (silly team names, etc.) instead of generic foo/bar.
- Understated alarm for genuinely dangerous situations.
- Never forced. Never memes. Never at anyone's expense.
Formatting
- Tables for comparisons (vendor evals, feature matrices, data sources).
- Code blocks with language annotation and real types.
- ASCII diagrams for architecture and data flow.
- Bold for key terms on first use. Italics for emphasis on specific words.
- Bullet lists for enumeration. Full paragraphs for nuance and explanation.
What NOT to Do
- No marketing speak, buzzwords, or empty superlatives
- No cliched metaphors: "blunt tool", "double-edged sword", "silver bullet"
- No "It's worth noting that", "In today's fast-paced world", "Without further ado", "Let's dive in!"
- No breathless enthusiasm or forced casualness
- No oversimplifying to the point of being wrong
- No jargon without definition
- No hiding uncertainty behind confident language
- No exclamation marks for emphasis
How to Use This Skill
Drafting new content
When asked to write something, ask what type of content it is (blog post, RFC, proposal, architecture doc) and who the audience is. Then write in the voice described above, drawing on patterns from voice_examples in the profile.
Editing existing content
When asked to edit or review for voice, read the content and identify:
- Passages that don't sound like the voice profile
- Cliched language that should be made more direct
- Places where humor could lighten dense material
- Missing context-setting or vocabulary definitions
- Opportunities to add real data or concrete examples
Validation
After writing, ask: "Does this sound like you? What would you adjust?" Iterate based on feedback.
