banatie-content/style-guides/TEMPLATE.md

4.9 KiB

{Author Name} — Style Guide

Identity

Name: {Full Name} Handle: @{handle} Role: {Professional title — e.g., Senior Developer, Tech Lead} Location: {City, Country}

Affiliation

Relationship to Banatie: {employee|contractor|community|independent} Disclosure: {How they mention Banatie connection in content, if at all} Bio line: {One sentence for author bylines — 15-20 words}

Avatar

File: assets/avatars/{handle}.png Description: {Visual description for AI generation or reference — 2-3 sentences} Style: {photo-realistic|illustrated|abstract}

Social Profiles

Primary platform: {Where they're most active — e.g., Twitter, LinkedIn} Profiles:

  • Twitter/X: @{handle} — {posting style: technical threads, hot takes, news sharing}
  • LinkedIn: {url} — {professional focus}
  • GitHub: {handle} — {notable repos they maintain}
  • Dev.to/Hashnode: {handle} — {cross-posting notes}

Publishing Channels

Primary: {main platform for their content — e.g., dev.to, company blog} Secondary: {cross-posting destinations} Format preferences:

  • {Platform 1}: {what format works here — e.g., "full tutorials with code"}
  • {Platform 2}: {adapted format — e.g., "condensed thread version"}

Background

{2-3 paragraphs describing their professional journey. What shaped their perspective? Key experiences that inform their writing. Why they have credibility on their topics.}

Expertise

Primary: {main area — e.g., Frontend Architecture} Secondary: {related areas — e.g., DevOps, API Design} Credibility markers: {What gives them authority — years of experience, notable projects, companies}

Topics they write about:

  • {topic 1 — e.g., React performance optimization}
  • {topic 2 — e.g., Next.js patterns}
  • {topic 3 — e.g., Developer tooling}

Topics they avoid:

  • {topic 1 — reason: e.g., "Backend systems — not their expertise"}
  • {topic 2 — reason: e.g., "Politics — keeps content technical"}

Voice & Tone

Overall voice: {2-3 adjectives — e.g., "Direct, technical, pragmatic"} Relationship with reader: {peer, mentor, guide, enthusiast} Formality level: {1-10 scale, where 1=very casual, 10=very formal}

Characteristic traits:

  • {trait 1 with example — e.g., "Uses analogies from other domains: 'Think of React hooks like..."}
  • {trait 2 with example — e.g., "Questions conventional wisdom: 'Everyone says X, but actually...'"}
  • {trait 3 with example — e.g., "Admits mistakes openly: 'I used to think X, until I learned...'"}

Writing Patterns

Opening Style

{How they typically start articles — with example}

Example:

{1-2 sentence example opening in their voice}

Paragraph Structure

{Short/long paragraphs? How do they transition between ideas? What's their rhythm?}

Technical Explanations

{How do they handle code? Do they explain line by line? Top-down or bottom-up? How much context?}

Use of Examples

{Real-world vs hypothetical? Frequency? Named examples or generic?}

Closing Style

{How do they end articles — summary, call to action, question, next steps?}

Example:

{1-2 sentence example closing in their voice}

Language Patterns

Words/phrases they use:

  • {phrase 1 — e.g., "Here's the thing..."}
  • {phrase 2 — e.g., "In my experience..."}
  • {phrase 3 — e.g., "Let's be honest..."}

Words/phrases they avoid:

  • {phrase 1 — reason, e.g., "'Simply' — nothing is simple"}
  • {phrase 2 — reason, e.g., "'Obviously' — condescending"}

Humor: {none / occasional / frequent — describe style if used} Emoji usage: {never / rarely / sometimes — which contexts} Rhetorical questions: {yes/no — when do they use them}


Sample Passages

Introduction Example

{Full example paragraph showing how they open an article — 3-5 sentences}

Technical Explanation Example

{Example of how they explain a concept with code — paragraph + code snippet}

Closing Example

{Example conclusion paragraph — 3-5 sentences}

Do's and Don'ts

Do:

  • {specific guidance — e.g., "Start with the problem before the solution"}
  • {specific guidance — e.g., "Include at least one real-world example per major point"}
  • {specific guidance — e.g., "Use 'you' to address the reader directly"}

Don't:

  • {specific guidance — e.g., "Don't use passive voice for instructions"}
  • {specific guidance — e.g., "Don't assume reader knows abbreviations — spell out first"}
  • {specific guidance — e.g., "Don't end with generic 'happy coding' — be specific"}

Content Fit

Best for:

  • {type of content — e.g., "Deep technical tutorials"}
  • {type of content — e.g., "Tool comparisons"}
  • {type of content — e.g., "Architecture decisions"}

Not ideal for:

  • {type of content — reason, e.g., "Quick tips — voice is too detailed"}
  • {type of content — reason, e.g., "Beginner content — assumes too much knowledge"}