Brand Context

The brand context document

This is the document every specialist loads at the start of every task. That makes it the highest-leverage thing you write and the easiest to ruin, in two directions: too thin and everyone guesses, too long and everyone pays for it on every delegation.

Write it as a briefing for a competent colleague who has never seen the product. Not a manifesto, not an archive.

What goes in

Six sections, in this order, because that's roughly the order a reader needs them.

• What the product is. Two or three sentences, plain, no category jargon. What it does and what it replaces.
• Who it's for. The primary segment, specifically enough to predict a problem and a buyer. Secondary segments named as secondary.
• Positioning. The alternative you beat, the differentiators worth claiming, and the proof for each.
• Messaging. The core message and the three or four pillars, each with its proof and its grade.
• Voice. How the team writes, with two or three real examples, and the phrases that are off-limits.
• Open questions. What isn't settled, and what would settle it.

Section 6 is the one people delete and the one that earns its place. It's how a specialist knows to hedge a claim rather than assert it.

What stays out

• Campaign and task detail. A launch brief, this quarter's theme, a specific piece's angle. Those belong in the delegation that needs them. Everything in this document is read by every task, so anything task-specific is a cost paid many times for one use.
• Long-form source material. Interview transcripts, full competitor teardowns, the complete messaging framework. Store those as assets and reference them.
• Anything you can't support. An aspiration written as a fact will be published as a fact by someone downstream.
• Preferences about how a person likes to work. Those live in the per-user preferences document, not here. This document describes the product, not the reader.

Length

Keep it to a page or two. The size cap in the tool is a backstop, not a target.

The test: could a specialist read this and write a draft without asking a question, and is there anything here they wouldn't need? Cut against the second question every time you revise. A document that has only grown has stopped being maintained.

Merging rather than replacing

The write overwrites the whole document for the entire team, so a careless save destroys work that wasn't yours.

• Load the current document first, every time. Never write from memory or from the earlier part of this conversation.
• Merge into the existing structure. Fit new information into the section it belongs in rather than appending a new one.
• Preserve what you weren't asked to change, including wording you'd have written differently. Someone agreed to that sentence.
• When new information contradicts what's there, don't silently replace it. Say what changed, why, and what it was before, then let the user decide.
• Resolve an open question by moving it into the relevant section, not by deleting it.

Before saving

Show the user the full document in the conversation and get agreement. Nothing pauses to confirm the write and there is no previous version to recover, so this is the only review the document gets. Then say what changed in a line or two, so the change is legible without diffing.

references/template.md has the document skeleton and a worked example.