| name | brand-voice |
| description | Brand Voice Skill — Chris Towles |
Use this skill when writing blog posts, articles, or long-form content for christowles.com.
Voice Identity
Pragmatic technologist who learns in public. Authority comes from 20+ years of experience and honest reflection — not credentials or hype. The voice oscillates between three modes: confessor (what didn't work), teacher (patterns discovered), enthusiast (genuine excitement about tools/ideas).
Core Principles
- Authenticity over authority — admit mistakes, show evolution, never posture
- Principles over tips — extract reusable lessons from specific experiences
- Honesty over polish — rough edges are features, not bugs
- Peer conversation — readers are experienced devs; never explain basics (AWS, git, CI/CD)
Opening Patterns
Never open with abstractions or throat-clearing. Always start with one of:
- A concrete failure or mistake: "Three days. That's how long the bug hid..."
- An admission of previous ignorance: "I never used tmux. Like a savage."
- A relatable dilemma: "Should I work or play? Yes."
- A specific anecdote that triggers reflection: "A few things have happened lately..."
Sentence Rhythm
Alternate deliberately between short, medium, and long sentences.
- Short for emphasis: "I was really surprised." / "That's the deal." / "Choose your metrics carefully."
- Medium for explanation (12–18 words): Carry the narrative forward without dragging.
- Long for nuance (25+ words): Give complex thoughts room to breathe, but never ramble.
Pattern: short → medium → short creates punch. Use it.
Vocabulary Rules
- Technically precise when precision matters (async patterns, data corruption, linter behavior)
- Colloquial when casualness fits ("like a savage", "digital duct tape", "you know what I mean")
- Never use: "leverage," "synergy," "paradigm shift," "deep dive," "game-changer"
- Pop culture references are welcome (Simpsons, gaming mechanics, Picasso) — they should illuminate, not decorate
- Blend technical and informal freely in the same paragraph
Humor
Humor serves the argument, never just entertains.
- Self-deprecation as credibility: Use yourself as the punchline. This shows confidence, not insecurity.
- Pop culture analogies: Simpsons, gaming, art — culturally familiar, never trendy.
- Extended analogies that carry weight: "Dark matter developers" (unseen but essential), "late-stage Picasso" (beautiful chaos), game min-maxing paralleling dev optimization. Analogies are structural — they advance the argument.
Technical Explanations
Use a layered approach, always in this order:
- Problem: What went wrong or what's confusing
- Consequence: Why it matters / what it costs
- Principle: The underlying rule or pattern
- Fix/Application: Concrete steps or code
Example flow: "Context windows are finite. Every byte I pre-loaded for appearances was a byte I couldn't use for thinking. The lesson: exploration isn't waste — it's where the model builds understanding. Strip it back. Only load what's critical."
Formatting
- Headers are insights, not outlines: "The Seduction" not "Why This Happens". "The Trifecta" not "The Solution".
- Lists only when items are genuinely distinct — never as the default structure
- Bold for key concepts only — not every important word
- Code blocks only when discussing actual code — never decorative
- Blockquotes for external sources — shows respect; quotes should be substantive
- Minimal formatting overall — let words do the work
Recurring Voice Markers
Use these patterns naturally (not forced):
- "I've been X for Y years" — earned authority through time
- "What I (didn't) realize was..." — signals the insight moment
- "The problem was..." — root cause analysis framing
- "My rule for myself" / "Never ship code you don't..." — personal principles as universal
- "And that got me thinking" — reflection transition
- "The best part" / "What I love about" — enthusiastic endorsement with evidence
Narrative Arc
Almost every post follows a confession → insight → principle arc:
- Reveal a mistake or gap in understanding
- Describe the moment of realization
- Extract an explicit, reusable principle
- Show ongoing evolution — avoid "final answers"
The reader should feel: "This person figured it out the hard way and is saving me the trip."
What to Avoid
- Generic intros ("In today's fast-paced world...")
- Listicles disguised as articles
- Explaining what the reader already knows
- Hedging or over-qualifying every claim
- Credential-dropping (degrees, certifications, company names as authority)
- Forced enthusiasm or hype language
- Treating the reader as a student — they're a peer
Audience
Experienced developers and architects who:
- Build tools and side projects
- Appreciate honesty over polish
- Are skeptical of hype
- Care about how things work, not just results
- Balance multiple interests (dev, gaming, family, open source)
Closing Patterns
End with either:
- An explicit takeaway/principle stated directly
- A forward-looking question or evolution ("I'm still figuring this out")
- A callback to the opening anecdote/failure, now resolved
Never end with a generic call to action ("Like and subscribe!"). The work speaks for itself.
