content-brief

name	content-brief
description	Produces a content contract - BRIEF.md (audience, goal, message, voice, structure) - before drafting; primes the editorial gate. Use before writing any content deliverable.

content-brief

The front-end of the content domain — the content analogue of design-brief. You turn "what they're writing and for whom" into a concrete content contract (BRIEF.md: audience, goal, key message, voice, structure) before a word of prose is drafted. Generic-in-generic-out is the failure mode; this skill forces the audience/goal/voice/outline to be decided first, so the draft (executor) and the editorial gate have a contract to be judged against.

What this does / does not do

Does: resolve the content sub_target, establish audience + goal + the single key message + voice + an outline (clarifying when the brief is thin), and write a BRIEF.md that the editorial/accessibility/ compliance gates audit drafts against; write a content-brief receipt. Does not: write the content itself (executor drafts under the brief), run the editorial verdict (the editorial gate does — this primes it), or apply to software/code tasks.

When NOT to use

• The task is software/code (not content) — there is no content brief to write; use the software path.
• A current, committed BRIEF.md already fits and nothing changed — re-running rewrites a contract the drafting is built against; edit the brief instead.
• The user wants the drafted content judged — that's the editorial gate, not content-brief.

Reference Routing

Situation	Reference
The BRIEF.md content-contract template	references/brief-template.md
Per-sub_target must-declares · vocabulary · overlay	../vocabulary.md · ../acceptance/{overlay,sub-targets}.md

Inputs

• The content need: sub_target (microcopy/long-form/documentation/legal/localization/marketing-copy), audience, goal, voice (or establish them via clarification).
• Mode B only: existing content to extract an implicit brief from.
• The content domain pack (../vocabulary.md, ../acceptance/) + content refs (avoid-ai-writing, beautiful_prose, taste-skill).

How to do it

Mode A — from intent

1. Resolve the sub_target from intake.json; load its must-declare row in ../acceptance/sub-targets.md.
2. Establish the spec (the content overlay's first checks): a specific audience (a person + their context, not "users"), the goal (what the reader should do/believe after), the one key message, and a named voice/register. If any is thin, run the Clarification Protocol — do not draft on a thin brief; push back on banned-default vibes ("modern/clean") for concrete words.
3. Outline before prose (ordering heuristic): a structure that covers the goal with no dead section.
4. Write BRIEF.md from references/brief-template.md with the chosen values + the sub_target's must-declares + the banned-AI-ism list (so the draft and the editorial gate share one contract).

Mode B — from existing content

Read the existing piece; extract the implicit audience, goal, message, voice, and structure; flag where they are unclear or inconsistent; write the BRIEF.md that should have governed it (and note the gaps for a revision pass).

Gate (before marking complete)

• Audience is a specific reader, not "users". - [ ] Goal is a falsifiable reader outcome.
• Exactly one key message. - [ ] A named, consistent voice. - [ ] An outline with no dead section.
• The sub_target's must-declares are all present (or N/A with a reason).
• The banned-AI-ism list is carried into the brief (primes the editorial gate).

A gate failure is fixed before lock, not waived — these mirror the editorial/accessibility/compliance gates so the brief passes the audits it primes.

Output

• BRIEF.md at the product root (or content/BRIEF.md if that dir exists) — persistence: Spec-Anchored (versions with the content). Audience · goal · key message · voice · outline · sub_target must-declares · banned AI-isms · (legal) jurisdiction + required clauses · (localization) locales.
• receipt (<workspace>/receipts/content-brief-receipt.json): base schema + mode, sub_target, audience_declared, goal_declared, key_message, voice, brief_path, gate_checks. persistence: Spec-Anchored.

Proactive Triggers

• The audience is "users" / the vibe is "modern, clean": push back for a specific person and concrete feeling words before writing the brief — generic in, generic out.
• More than one key message: that is more than one piece — split, or pick the one that serves the goal.
• A legal sub_target with no jurisdiction: stop — clause completeness depends on it (compliance gate).

Completion Criteria

Done when: a BRIEF.md exists with a specific audience, a falsifiable goal, one key message, a named voice, and an outline; the sub_target's must-declares are present; a content-brief receipt records mode + the gate checks.

Not done if: the brief was written from a vague audience/goal; more than one key message survived; a legal brief lacks a jurisdiction; it was run for a software/code task.

Next step: executor drafts the content under the brief; the editorial/accessibility/compliance gates audit the draft against it.

Related Skills

• editorial / accessibility / compliance gates: audit the drafted content against this brief. content-brief writes the contract; the gates enforce it (parallel to design-brief ↔ aesthetic gate).
• specify: writes the task card (the what/why of the work); content-brief writes the content contract (audience/voice/structure) for a content deliverable. Complementary, not a substitute.