---
name: brand-voice-context
description: Build durable BRAND.md and VOICE.md context that every writing and planning playbook can draw on.
---

# Brand & Voice Context

## Use this when

blog brand, create brand context, brand voice doc, establish editorial brand, brand guidelines for blog.

## Process

Interview the user once, and store the result so every future strategy, brief, calendar, write, and rewrite job can start from the same context instead of re-deriving it.

Audience: primary and (optional) secondary audience role, reader expertise level, 3-5 active problems the reader is trying to solve, and common misconceptions worth correcting.

Positioning: official entity name, homepage URL, logo, official social/profile links, one-sentence mission, the brand's distinctive (even contrarian) point of view, explicit anti-positioning ("what we are NOT"), and the top 3 competitors each with a one-line differentiator.

Editorial rules: 3-7 always-do rules (e.g. "cite primary sources only"), 3-7 never-do rules (e.g. "no clickbait titles"), taboo phrases specific to this brand, and any required disclosures (affiliate, AI-content, conflict-of-interest).

Topic boundaries: what's fully in scope (core pillars), partially in scope (adjacent, only with an original angle), and explicitly out of scope.

Voice: pronoun stance (first/second/third-person or mixed), contraction policy, a hard sentence-length ceiling, a paragraph-length ceiling (default 150 words), headline patterns to favor and to avoid, and the summary-box label. Pre-fill these from an existing writing-persona profile when one exists; this file mirrors the persona's tone fingerprint in prose rather than duplicating it as the source of truth.

Write two files at the project root: BRAND.md (audience, positioning, editorial rules, topic scope) and VOICE.md (pronoun stance, lexical rules, headline patterns, voice fingerprint, readability target). When present, every writing and planning playbook should treat them as auto-loaded context. When absent, behavior is unchanged; these are opt-in, never something to demand before writing.

To update, re-run the interview with current values as defaults and let the user accept or change each one, then overwrite both files.

