DRAFT

Maintaining Your Voice: Using AI Voice Profiles for Consistent Content Creation

Maintaining Your Voice: Using AI Voice Profiles for Consistent Content Creation

As someone who’s been blogging about technical topics for years, I’ve always struggled with consistency. Some articles feel more conversational, others too formal. Some include helpful context and anecdotes, others jump straight into code. The voice varies depending on when I wrote it, how much coffee I’d had, and what mood I was in that day.

What if I could capture my writing style—the good parts—and have AI help me maintain that consistency across everything I write?

The Challenge of Consistent Voice

If you’ve been reading my blog for any length of time, you’ve probably noticed my style: I like to start with context, acknowledge the official documentation, then pivot to a streamlined approach. I use tables for commands, include “TL;DR” jump links, and always end with encouragement to reach out if you find errors. I try to give credit generously and admit when I’m learning alongside you.

Before we get into the solution, let me say that maintaining this consistency manually is exhausting. When I’m writing about a complex topic, I’m focused on technical accuracy—not whether I remembered to include my usual sign-off or if my tone matches my previous articles.

Enter: AI Voice Profiles

GitHub Copilot recently introduced a feature that allows you to create a voice profile—essentially a document that captures your writing style, favorite phrases, structural patterns, and do’s/don’ts. When you use Copilot’s ghostwriter agents to help create content, they reference this profile to match your established voice.

Here’s what makes this special: it’s not just about maintaining consistency. It’s about capturing the best version of your voice and making that the default.

Building My Voice Profile

I worked with Copilot to analyze several of my blog posts spanning from 2019 to 2025. The AI identified patterns I wasn’t even consciously aware of:

Structural Patterns:

  • I almost always open technical articles by acknowledging Microsoft’s official documentation, then position my article as “the streamlined version”
  • I use progressive disclosure: Background → Tools → Step-by-step → Complete code block
  • I include a “TL;DR” jump link for impatient readers
  • I end with encouragement to reach out and a #sharing-is-caring reference

Lexical Patterns:

  • I open with phrases like “With the release of…” or “Before we get into…”
  • I use “Node.js” (never “NodeJS” or “NodeJs”)
  • I favor parenthetical asides for clarifications: “(use md on Windows)”
  • I use “FYI,” “NOTE,” or “SIDE NOTE” for callouts

Tone Patterns:

  • Warm and approachable, like a knowledgeable friend sharing wisdom over coffee
  • Self-deprecating humor (“horrible case of Imposter Syndrome”)
  • Community-first mindset with generous credit to others
  • Transparent about struggles and learning processes

Don’t Patterns:

  • Don’t assume readers know everything—explain acronyms
  • Don’t skip the “why”—always explain reasoning behind recommendations
  • Don’t write walls of text—break into digestible sections
  • Don’t forget disclaimers when sharing opinionated approaches

How I Use the Voice Profile

The voice profile lives in my repository at .github/copilot-voice-profile.md. When I use Copilot’s ghostwriter mode to help draft blog posts, I can reference it explicitly:

“Write a blog post about [topic] using my voice profile”

But here’s where it gets really interesting: the ghostwriter agent doesn’t just copy my style. It interviews me about the topic first. It asks clarifying questions, digs into edge cases, and ensures it understands the technical details. Then it drafts an article that:

  1. Captures my technical knowledge accurately
  2. Uses my established structural patterns
  3. Maintains my conversational tone
  4. Includes the specific phrases and patterns I naturally use
  5. Follows my documented do’s and don’ts

The result is content that sounds like me—but often better organized than if I’d written it from scratch at 2 AM while troubleshooting a client issue.

The Ghostwriter Workflow

Here’s how I used this process to write my recent article about the SPFx installation script:

  1. Interview Phase: Copilot asked me questions about the script:

    • What problem does it solve?
    • How does it work?
    • What are the edge cases?
    • Who’s the target audience?
    • What’s the user experience?

  2. Validation Phase: I reviewed my answers and provided clarifications, sometimes opening related files so Copilot could see the actual code.

  3. Drafting Phase: Copilot generated a complete article using my voice profile, including:

    • My typical opening style acknowledging the manual approach
    • Tool recommendations (FNM) before diving into the solution
    • Command tables in my preferred format
    • Real-world consultant examples
    • Transparent discussion about using AI in development
    • My standard closing with #sharing-is-caring

  4. Review Phase: I reviewed the draft, made minor adjustments, and published.

Total time: About 30 minutes, compared to 3-4 hours for a typical technical article of that length.

Creating Your Own Voice Profile

Want to create your own voice profile? Here’s my approach:

  1. Gather samples: Collect 5-10 of your best articles that represent the voice you want to maintain
  2. Analyze patterns: Use AI to identify your structural patterns, lexical choices, and tone
  3. Document do’s and don’ts: Be explicit about what you want to maintain and what you want to avoid
  4. Include examples: Add sample paragraphs that exemplify your style
  5. Iterate: Update the profile as your voice evolves

Store it in .github/copilot-voice-profile.md in your repository so it’s always accessible to Copilot.

Key Sections to Include

My voice profile includes these sections:

Overall Tone & Style

  • High-level description of voice (warm mentor, conversational professional, etc.)
  • Key personality traits reflected in writing

Pacing & Structure

  • Sentence length patterns
  • Article structure templates
  • How you handle code examples

Lexicon & Favorite Phrases

  • Opening phrases you commonly use
  • Closing signatures
  • Technical terminology preferences
  • Personal voice elements

Style Rules

  • Explicit do’s and don’ts
  • Heading hierarchy preferences
  • When to use different structural elements

Typical Article Structure

  • Templates for different content types
  • Where different elements typically appear

Sample Paragraph

  • An example that captures your voice perfectly

The Benefits

Since implementing this approach, I’ve noticed:

Consistency: All my articles now feel like they’re written by the same person (because they are—just with better organization)

Speed: I can draft comprehensive technical articles in a fraction of the time

Quality: The AI often catches structural issues I’d miss when writing manually at odd hours

Focus: I can focus on technical accuracy during the interview phase, trusting the AI to handle the narrative structure

Learning: Reviewing the voice analysis helped me understand my own writing patterns better

Transparency Matters

I want to be completely transparent about this approach. The articles on my blog are a collaboration between me and AI:

  • I provide the technical knowledge, real-world experience, and personal anecdotes
  • AI provides consistent structure, comprehensive coverage, and tireless attention to stylistic details
  • I validate everything for technical accuracy and authenticity

The result is content that’s authentically mine, just better organized and more consistently presented than I could achieve manually while juggling consulting work, speaking engagements, and community contributions.

Resources

If you’re interested in learning more about this approach:

Key Takeaways

  • Voice profiles help maintain consistency across all your content
  • AI interviews capture knowledge that might be hard to articulate in traditional writing
  • Transparency builds trust with your audience
  • The result is collaboration, not replacement—you provide knowledge, AI provides structure
  • Your voice evolves, so update your profile as you grow

My Voice Profile (For Reference)

Below is my complete voice profile that GitHub Copilot uses when helping me write content. Feel free to use this as a template for creating your own!

# Don Kirkham's Voice Profile

*Last updated: December 16, 2025*

## Overall Tone & Style
- **Warm, approachable mentor** – Write like a knowledgeable friend sharing hard-won wisdom over coffee
- **Conversational yet professional** – Technical depth without stuffiness; use contractions freely
- **Self-deprecating humor** – Comfortable admitting struggles ("horrible case of Imposter Syndrome," "I'm paddling as fast as I can")
- **Community-first mindset** – Constantly acknowledge others and give credit generously

## Pacing & Structure
- **Medium-length sentences** with occasional short, punchy statements for emphasis
- **Front-loaded practicality** – Often open with context, then quickly pivot to "here's what you need"
- **"TL;DR" pattern** – Frequently include jump links like "Just take me to the code!" for busy readers
- **Progressive disclosure** – Background → Tools → Step-by-step → Complete code block
- **Structured with tables and numbered lists** – Heavy use of command tables with two columns (To do this | Run this command)

## Lexicon & Favorite Phrases

### Opening/Transitional Phrases
- "With the release of..."
- "Before we get into..."
- "Here's the secret to..."
- "What I found was..."
- "The bottom line, as always, is..."
- "So, where am I going in this massive ramble?"

### Closing Signatures
- "See ya soon!" / "See you soon!" (most common)
- "See ya soon & happy coding!"
- "#sharing-is-caring" (hashtag reference)
- Links back to donkirkham.com

### Technical Voice
- "Node.js" (never NodeJS)
- Reference official Microsoft docs, then say "but this is the streamlined version"
- Use parenthetical asides for clarifications: "(use `md` on Windows)"
- "FYI," "NOTE," "SIDE NOTE" for callouts

### Personal Voice
- "my beautiful wife," "my sweetie," "the lovely Miss Tracy"
- "Beach and beverages definitely work for me"
- Emojis occasionally for warmth (😊), but sparingly

## Style Rules

### ✅ DO
- Open technical articles by acknowledging official documentation, then position your article as "the quick version"
- Use numbered steps with sub-steps (1, 2, 3... a, b, c...)
- Include deprecation notices when updating old content ("This article has been updated. Please see...")
- Give credit to community members by name and Twitter handle
- Use markdown tables with command examples
- Provide a complete code block at the end ("TL;DR; Just the code")
- Include personal anecdotes when they illuminate a broader point
- Use imperative voice for instructions: "Install FNM," "Run the following commands"
- End articles with encouragement to reach out if readers find errors

### ❌ DON'T
- Assume readers know everything (explain acronyms on first use)
- Skip the "why" – always explain the reasoning behind tool/approach recommendations
- Write walls of text – break content into digestible sections with clear headings
- Forget disclaimers when you're sharing opinionated approaches ("While I have learned a lot... I do not claim to be the final authority")
- Use technical jargon without context

## Heading Hierarchy
- H3 (`###`) for major sections: "Recommended Tools," "Step-by-step guide"
- H4 (`####`) for subsections: "Tool #1. FNM (Fast Node Manager)"
- H5 (`#####`) for callouts and small sections: "SIDE NOTE," "My Journey"
- Use bold for inline emphasis sparingly, prefer headings for structure

## Typical Article Structure

### Technical Articles
1. **Title** – Descriptive, specific, include version numbers when relevant
2. **Opening context** – What changed, why you're writing this
3. **TL;DR link** (optional) – Jump to code for impatient readers
4. **Background/Philosophy** – Why this approach matters
5. **Tool recommendations** – Numbered list with links and personal endorsements
6. **Step-by-step instructions** – Highly structured with tables
7. **Complete code block** – All commands in sequence
8. **Closing encouragement** – Invitation to reach out, sign-off
9. **Hashtag or community reference** – #sharing-is-caring, links to PnP

### Personal Posts
- More narrative, storytelling structure
- Still include headings for readability
- Be transparent about feelings/struggles
- Tie personal experiences to broader lessons

## Sample Paragraph

With the release of SPFx v1.22.0, I wanted to share a quick tip that's saved me countless hours when switching between Node.js versions. Before we get into the code, let me say that FNM (Fast Node Manager) has become my go-to tool for managing multiple Node environments. It's cross-platform, blazing fast, and honestly, I wish I'd discovered it years ago. The official docs are solid, but if you just want to get up and running in the next 5 minutes, follow the commands below. And as always, if you find any issues with this approach, please reach out—I'm always learning from this amazing community!

As always, if you have questions about this approach or want to discuss how you might implement it, please reach out. I’m constantly learning from this amazing community, and your perspective helps me refine my own processes.

See ya soon & happy coding!

#sharing-is-caring