README.md
# content-brief-authoring
The skill is [SKILL.md](SKILL.md). Generated by `scripts/build-tested-on.mjs` from openaddict.com. CI checks it against the site, so edit the script, not this file.
## Tested on OpenAddict
Set up for testing, not yet run. What has been searched and run so far: [openaddict.com/skills/coverage](https://openaddict.com/skills/coverage).
references/brief-governance-patterns.md
# Brief governance patterns
Versioning, single-approver, archival alongside the published piece, audit trail.
---
## Versioning
Every brief has a version. Significant changes bump the version; cosmetic edits do not.
**Version-bump triggers:**
- Target keyword change (the piece is now optimizing for a different keyword)
- Audience shift (the JTBD has changed)
- Scope expansion or contraction (word count target moves by 50%+; new H2s added or removed)
- Success criteria change (the metric the piece is being measured against shifts)
**No version bump for:**
- Typo fixes
- Anchor text adjustments on internal links
- Adding a sentence of clarification to an existing field
- Reformatting
The writer always works from the current version. If a writer is mid-draft when the brief bumps from v2 to v3, the strategist tells the writer immediately and decides whether to restart, integrate the changes, or freeze the v2 draft.
The brief has a version field at the top: `brief_version: 3`. The version is the contract identifier.
---
## Single approver
The brief approver is the editorial owner of the content program. Single approver, not a committee.
**Why single approver:**
- A committee bog dilutes the brief. Each member adds a field; nobody removes fields. The brief grows from 1 page to 4 pages and stops being readable.
- A committee splits accountability. When the published piece misses, no single person owns the brief that produced it.
- A single approver enforces taste. The program has a consistent editorial voice because one person is gatekeeping.
**The approver is also the editor.** The same person who approves the brief reviews the draft. This prevents the gap between "what the brief asked for" and "what the editor wants"; the same person owns both sides.
Splitting these roles is how briefs and reviews drift apart. The strategist who briefed the piece sees the gap; an external editor reads the draft and changes the lede because of personal taste, not because of the brief.
**The exception:** for high-stakes pieces (pillar content, thought leadership with named author, comparison pieces involving competitors), a second reader is useful. The second reader provides input but does not approve. The single approver still decides.
---
## Archival
After publish, the brief is archived alongside the content piece.
**Common archival patterns:**
- **Notion database row.** Brief and published-piece URL on the same row. Custom fields for brief version, approver, publish date, success-criteria results.
- **dbt model with content metadata.** For warehouse-native content tracking; brief stored as JSON in the model's seed data.
- **CMS metadata fields.** Contentful, Sanity, and similar CMSs allow custom metadata fields; the brief lives in a "brief" field on the content entry.
- **Git repo.** For docs sites and developer-facing content programs; brief in a sibling markdown file to the published piece.
**Why archival matters.** Future content audits reference both brief and published piece to assess gap between intent and execution. Without the brief in the archive, an audit cannot tell whether the piece succeeded against the original goal or drifted from it.
The audit question is "did we ship what we briefed, and did the briefed piece achieve its success criteria?" Both halves need source-of-truth records: the brief for what was asked, the published piece for what was delivered, the metrics for what the piece achieved.
---
## Audit trail
A content program that runs at scale needs an audit trail. The audit trail answers four questions per piece:
1. **What did we brief?** The archived brief, with version history.
2. **What did we publish?** The published URL, with publish date and last-update date.
3. **How did the piece perform against the success criteria?** Rank position at 30 / 60 / 90 days; AI citation count if measured (Profound, Frase, AirOps); conversion data from the analytics stack.
4. **What did we learn?** A short post-publish note: what worked, what did not, what to brief differently next time.
The audit trail compounds. After 50 pieces, the program can see patterns: pillar pieces with comprehensive outlines outperform pieces with thin outlines; comparison pieces with explicit "when X wins" / "when Y wins" framing outperform pieces with implicit positioning; entity-coverage scores above 80 correlate with citation count.
The audit trail is what turns content production from a per-piece activity into a learning system. Without the trail, every piece is a one-off; with the trail, the program improves quarter over quarter.
---
## The "post-mortem on a failed piece" pattern
When a piece misses its success criteria, the post-mortem walks the brief.
1. Read the brief. Was it complete? Were the 12 fields populated?
2. Read the published piece. Did it follow the brief?
3. Identify the gap. Was the brief wrong (target keyword too competitive, intent misclassified)? Was the execution off (writer drifted from outline, entities missed)? Was the SERP harder than expected (well-executed brief, well-written piece, still no rank)?
4. Update the brief template if the failure is systemic (next time, run a deeper SERP check before briefing).
5. Update the writer-handoff if the failure is communication (next time, the brief is read aloud at handoff).
6. Accept the failure if the failure is variance (some pieces miss; the program does not chase every miss).
The post-mortem is short, half a page. It feeds the audit trail and informs the next brief. It does not turn into a multi-page analysis that nobody reads.
---
## Brief field: governance metadata
The brief carries governance metadata at the top:
> **Brief metadata**
> - Brief version: 3
> - Approver: editorial-lead@team.com
> - Approval date: 2026-04-22
> - Writer assigned: J. Smith (or AI agent: Frase v4)
> - Target publish date: 2026-05-15
> - Archive location: Notion content-pipeline database, row #847
The metadata is six lines, not a paragraph. It identifies the contract; the rest of the brief is the contract terms.
references/brief-templates.md
# Brief templates by content type
Six templates. The 12 fields are constant; the weight of each field shifts based on the content type. Each template names the fields that lean heavier and the fields that lean lighter for that type.
---
## Pillar piece
Comprehensive coverage of a topic, 3,000+ words, anchors a topic cluster. The piece other content links up to.
**Heavier fields:** heading structure (the outline is the spine), entity coverage (a pillar that misses entities loses credibility), internal linking (links to and from the supporting cluster pieces), word count (calibrated to top SERPs, often long).
**Lighter fields:** anti-patterns (the writer assigned to a pillar usually knows the topic), tone reference (default brand voice; tone shifts are rare for pillars).
**Brief shape:** 2 pages. The H2 outline takes ~40% of the brief because pillar structure is decisive. Entity list is long (15 to 25 entities). Internal-link section names every cluster piece that should link in or out.
**Worked example.** Target keyword: "experimentation analytics dashboards." Cluster: experimentation methodology. Intent: commercial-investigation. SERP format: long-form articles plus comparison tables. Word count target: 2,800 to 3,400. Outline: H2 #1 "what an experimentation dashboard does," H2 #2 "platform-native vs warehouse-native," H2 #3 "the metrics that earn their keep," H2 #4 "build vs buy," H2 #5 "common dashboards that ship trusted results." Entities: lift, p-value, MDE, CUPED, sequential testing, Statsig, PostHog, Optimizely, dbt, Mixpanel, Snowflake. Internal links: 5 supporting pieces queued.
---
## Supporting / cluster piece
Narrower topic, 1,000 to 2,000 words, links up to the pillar. One question, one answer.
**Heavier fields:** target keyword (specific long-tail), search intent (cluster pieces have to match SERP precisely), JTBD (one specific reader problem), internal linking (must link up to pillar with anchor text matching the pillar's target).
**Lighter fields:** entity coverage (smaller scope, fewer entities required), thought-leadership POV (cluster pieces serve the cluster, not the writer's opinion).
**Brief shape:** 1 page. JTBD in one sentence. H2 outline is 3 to 5 sections. Entity list is short (5 to 10). The "links up to pillar" specification is mandatory; an orphan cluster piece is a wasted slot.
**Worked example.** Target keyword: "CUPED variance reduction." Pillar: experimentation analytics dashboards. Intent: informational. JTBD: data analyst wants to apply CUPED in a dbt model and needs the formula plus the gotchas. Outline: H2 "what CUPED does," H2 "the formula," H2 "implementing in dbt," H2 "common pitfalls." Internal link up to pillar with anchor "experimentation analytics dashboards."
---
## Comparison piece (X vs Y)
Commercial intent, structured comparison, decision framework. The reader wants help choosing.
**Heavier fields:** anti-patterns (snark and trash-talk are the failure mode), heading structure (table-style comparison plus "when X wins" / "when Y wins" sections), success criteria (commercial intent piece; the metric is signups or sales-qualified leads, not traffic alone).
**Lighter fields:** word count flex (top-ranking comparison pieces vary widely; SERP-calibrate).
**Brief shape:** 1 to 2 pages. The comparison criteria are listed in the brief, not invented by the writer. If the brand is one of X or Y, the brief specifies honest positioning: what the brand wins on, what the competitor wins on. The brief explicitly forbids "X is the worst, Y is the best" framing.
**Worked example.** Target keyword: "Statsig vs PostHog." Intent: commercial. SERP format: comparison tables plus prose. Comparison criteria: pricing model, MAU thresholds, MCP support, custom-metric depth, frontend visual editor, mobile SDK. "When Statsig wins": teams with strong custom-metric needs, teams that already pay for Snowflake. "When PostHog wins": product analytics-led teams, teams that want session replay alongside experimentation. Anti-pattern explicitly listed: do not write "PostHog is the clear winner" or "Statsig is overpriced." Honest comparison or do not write the piece.
---
## Listicle
Informational or commercial intent, scannable, ranked or unranked list. "10 best X" or "7 ways to Y."
**Heavier fields:** selection criteria (why are these 10 the chosen ones; the writer needs to defend the list), ordering rationale (why is item #1 first; explicit ranking criteria), depth-per-item (how many words per item; even depth is the discipline).
**Lighter fields:** narrative arc (listicles have minimal narrative; the list itself is the structure).
**Brief shape:** 1 page. The selection criteria are listed in the brief. The order is suggested in the brief, with note that the writer can reorder if the research warrants. Depth-per-item is specified (e.g., 150 words each for 10 items, plus 200-word intro and 150-word conclusion = ~1,850 words).
**Worked example.** Target keyword: "best feature flag tools 2026." Intent: commercial. Selection criteria: official MCP support, free tier exists, hosting model. The 10 items pre-listed in the brief: LaunchDarkly, Statsig, PostHog, GrowthBook, Optimizely, VWO FME, Split.io, Kameleoon, Flagsmith, Unleash. Depth: 150 words per tool covering pricing, MCP status, when this tool wins.
---
## How-to guide
Informational intent, step-by-step, screenshots, prerequisites, troubleshooting. The reader wants to do something specific.
**Heavier fields:** step granularity (each step is one action, not three), prerequisites (what the reader needs before starting), troubleshooting section (common failure modes the reader will hit).
**Lighter fields:** thought-leadership POV (how-to guides serve the task, not the writer's perspective on it).
**Brief shape:** 1 to 2 pages. The brief lists the steps in outline form so the writer can spot missing prerequisites or merged steps before drafting. The screenshot list is queued (which screens, in what state). Troubleshooting bullets are listed; the writer expands each into a paragraph.
**Worked example.** Target keyword: "how to set up a Statsig experiment." Prerequisites: Statsig account, SDK installed, exposure events instrumented. Steps: H2 "create the experiment in the console," H2 "define the assignment unit," H2 "configure the metrics," H2 "set the duration and MDE," H2 "launch and monitor." Troubleshooting: SRM check failure, exposure events not firing, metric definition mismatch.
---
## Thought leadership / opinion
Commercial or branding intent, distinctive POV, signal of expertise. The piece exists to differentiate the brand voice in the category.
**Heavier fields:** thesis (one sentence; the whole piece defends it), anticipated counter-arguments (what would a smart skeptic say; the piece must address them), tone reference (often a sharper voice than default; the brief specifies the shift).
**Lighter fields:** SERP entity coverage (thought leadership often deliberately diverges from SERP consensus; entity coverage is a softer requirement).
**Brief shape:** 1 page. The thesis is one sentence at the top. The supporting arguments are listed (3 to 5). The anticipated counter-arguments are listed with notes on how the piece responds to each. The brief explicitly names the writer or contributor; thought leadership has authorship, not anonymous editorial.
**Worked example.** Thesis: "warehouse-native experimentation is the right default for any team running 50+ experiments per quarter." Supporting arguments: cost crossover at scale, custom metric flexibility, audit trail, data-team integration. Counter-arguments to address: setup cost, time-to-first-experiment, missing UI tooling. Tone shift: sharper, more declarative than default brand voice. Author: named senior data leader.
references/common-brief-failures.md
# Common brief failures
Ten-plus failure patterns with diagnoses and fixes. Cross-references to other reference files where applicable.
---
## "The brief was too thin"
**Symptom.** Brief contains target keyword, word count, deadline, maybe a one-line angle. Writer fills in everything else from priors. Output is generic, drifts off-topic, does not rank.
**Diagnosis.** The strategist treated the brief as a task assignment instead of a contract. The 12 fields were not populated; the writer's defaults filled the gaps; the defaults were not aligned with the program's intent.
**Fix.** Populate all 12 fields. If a field cannot be populated (the success criteria is genuinely unknown, the SERP is too volatile to call), name the gap explicitly and flag it as "writer's call, defend the choice in the first draft."
---
## "The brief was too thick"
**Symptom.** Brief is 4 pages with executive summary, brand-voice refresher, comprehensive competitive landscape, plus the actual brief. Writer skims for the outline. Output is not better than from a thin brief.
**Diagnosis.** Strategist optimized for brief authorship instead of brief consumption. Each field added felt important; nobody asked "would the writer behave differently if this field were missing?"
**Fix.** Cut fields that do not change writer behavior. Brand-voice refresher: link, do not repeat. Competitive landscape: link to research, do not summarize. Executive summary: the brief is the executive summary. Target: 1 to 2 pages.
---
## "The writer ignored the brief"
**Symptom.** The published piece misses the SERP intent, drops required entities, ignores internal-link guidance. Editor's review surfaces the gap.
**Diagnosis.** No success-criteria acknowledgment at handoff. The writer read the brief once at the start, drafted from memory plus priors, never re-read.
**Fix.** Require acknowledgment at handoff (see `writer-handoff-protocols.md`). The acknowledgment restates the success criteria in the writer's voice. Saying it is what keeps it load-bearing.
---
## "The brief had the wrong target keyword"
**Symptom.** The piece publishes; the target keyword turns out to have search volume of 50/month, or to be navigational (a brand wins position 1 forever), or to have a SERP the team cannot win. The piece does not rank.
**Diagnosis.** SERP not validated before briefing. The strategist assumed the keyword was good without pulling the SERP and the volume.
**Fix.** SERP-validate before briefing. Pull the keyword volume (Ahrefs, Semrush, GSC). Pull the SERP top 10. If the SERP looks unwinnable for the brand at current authority, pick a different keyword.
---
## "The piece does not match the SERP intent"
**Symptom.** SERP shows mostly listicles; the briefed piece is a long-form article. Or SERP shows long-form articles; the briefed piece is a listicle. Either way, the piece does not rank.
**Diagnosis.** SERP intent override was not applied. The strategist's priors about what the keyword "should" look like overrode what the SERP actually shows.
**Fix.** Apply the SERP override pattern (see `search-intent-classification.md`). The format choice line in the brief must match the dominant SERP format.
---
## "The piece has no internal links"
**Symptom.** Piece publishes with zero internal links to other pages on the site. Or with one or two links that the writer added arbitrarily.
**Diagnosis.** Internal linking was treated as an afterthought. The brief did not specify outbound links; the writer added some at the end without strategic intent.
**Fix.** Specify 3 to 5 outbound links in the brief, with anchor text and target page. Queue 1 to 3 inbound updates as post-publish tasks (see `internal-linking-strategy.md`).
---
## "The piece is generic; could have been written about anything"
**Symptom.** Reading the piece, you cannot tell what brand it came from, what makes it different from the SERP top 10, or why this piece exists. The piece reads as AI-generated even when a human wrote it.
**Diagnosis.** Entity coverage and POV were missing from the brief. The writer hit the target keyword but did not differentiate; the piece blends into SERP consensus.
**Fix.** Specify gap entities (entities mentioned by 1 to 2 SERP pages but not by the rest). Specify a POV for the piece: what the brand argues that the rest of SERP does not. Generic content has no POV; effective content makes a specific claim.
---
## "The brief is comprehensive but the piece does not rank"
**Symptom.** Brief had all 12 fields. Writer followed the brief. Piece is well-written, hits the entities, follows the outline. Three months post-publish: position 47.
**Diagnosis.** The SERP was harder than expected. The brief was right; the keyword was over-competitive at the brand's current authority. This is variance, not failure.
**Fix.** Do not iterate by adding fields to the brief. Iterate by SERP-validating more carefully next time, by accepting that some keywords are out of reach until the brand earns more authority, or by pivoting to a less-competitive long-tail variant.
---
## "We never went back to evaluate"
**Symptom.** Pieces publish; nobody checks performance at 30 / 60 / 90 days. The program runs without feedback.
**Diagnosis.** Success criteria were defined in the brief but no measurement task was queued at publish time.
**Fix.** Make 30 / 60 / 90 day check-ins part of the publish checklist. The check-in is a 5-minute task: read the rank, the citation count, the conversion data; update the audit trail (see `brief-governance-patterns.md`). Not optional.
---
## "Different writers produce wildly different output from the same brief"
**Symptom.** Two writers given the same brief produce pieces that read like they came from two different programs. The brief was supposedly identical; the output is not.
**Diagnosis.** The brief was actually too vague. Different writers filled gaps with their own priors; the gaps were where the divergence lives.
**Fix.** Tighten the anti-patterns and the voice notes. The brief explicitly forbids common writer drifts (off-topic tangents, off-brand tone, AI clichés). The voice reference is specific (not "use brand voice" but "use the voice of section 3 of the voice guide; default tone, no sharper").
---
## "The piece succeeded but we cannot tell why"
**Symptom.** A piece outperforms expectations: top-3 rank, high citation count, conversion above target. The team cannot explain what made it work.
**Diagnosis.** The brief and the published piece have multiple distinguishing features (specific outline, gap entities, sharp POV); without controlled comparison, the team cannot isolate the cause.
**Fix.** Document hypotheses about why the piece worked in the post-publish note. Test the hypotheses by briefing the next 3 pieces with the same pattern. If the pattern replicates, it is the cause; if not, the success was variance. The audit trail compounds (see `brief-governance-patterns.md`); patterns emerge over 20+ pieces.
---
## "We approved the brief but the writer wrote a different piece"
**Symptom.** The brief was for a comparison piece; the writer delivered a thought-leadership piece. The brief was for 1,800 words; the writer delivered 3,400 words. The brief was for a senior data engineer audience; the writer wrote for a non-technical CMO.
**Diagnosis.** The handoff acknowledgment was skipped. The writer read the brief, drafted from a different mental model, and did not surface the divergence early.
**Fix.** Require acknowledgment that restates the brief's parameters: word count, audience, format. If the writer's acknowledgment misstates anything, the strategist catches it before drafting starts. After 1,500 words of writing, restarting is expensive; before drafting, restating is cheap.
references/entity-coverage-checklist.md
# Entity coverage checklist
Entity discovery from SERP, gap analysis, AEO and GEO citation drivers.
---
## Why entity coverage matters
AI engines (ChatGPT, Perplexity, Claude, Gemini, Google AI Mode) tend to cite content that:
- Mentions the entities the SERP top-ranking pages mention
- Includes specific statistics with sources
- Contains citation-formatted proof points
- Demonstrates topical depth via entity coverage
Entities are the named things the topic depends on: tools, methods, experts, datasets, statistics, brands, frameworks, standards, organizations. A piece on "experimentation analytics" that does not mention CUPED, sequential testing, p-values, or named platforms (Statsig, PostHog, Optimizely) reads as thin both to humans and to ranking systems.
Traditional SEO has known about entity coverage for years (Google's Hummingbird and BERT updates emphasized it). AEO and GEO double the stakes: AI engines explicitly use entity coverage as a citation signal because they can extract the entity graph from the page and assess topical depth at retrieval time.
---
## The entity discovery workflow
Run before authoring the brief; do not delegate to the writer.
**Step 1.** Pull the SERP top 10 for the target keyword.
**Step 2.** For each top-10 page, extract the named entities. Tools that automate this: Frase (built-in entity gap analysis), AirOps (workflow builder runs the same analysis), Surfer SEO (entity coverage scoring), or manual extraction with a structured prompt.
**Step 3.** Tag each entity by frequency:
- Mentioned by 7+ of 10 pages: required coverage. The brief lists these.
- Mentioned by 3 to 6 pages: standard coverage. The brief lists these with shorter notes.
- Mentioned by 1 to 2 pages: gap entities. The brief includes these as differentiation opportunities.
- Mentioned by 0 pages but relevant: brand-owned entities the team knows matter even if SERP misses them.
**Step 4.** For each required and standard entity, write a one-line note in the brief explaining why it matters and where to mention it. Example:
> **CUPED.** Variance-reduction technique mentioned by 9 of 10 SERP pages. Mention in the methodology H2 with the formula. Required.
**Step 5.** Add the gap entities (1 to 2 page mentions) as differentiation opportunities. The writer can choose to include them; they add depth without crowding the required entities.
---
## AEO and GEO citation drivers
Beyond entity coverage, AI engines weight several other signals when deciding what to cite.
**Specific statistics with sources.** "Statsig charges per MAU starting at 100K MAU" cites better than "Statsig is expensive at scale." Numbers with sources are higher-citation; vague qualifiers are lower-citation.
**Named experts or quotes.** "As Ronny Kohavi noted in his book Trustworthy Online Controlled Experiments, the most common SRM diagnosis is..." cites better than "experts agree that SRM diagnoses are common." Named attribution earns citation; anonymous attribution does not.
**Direct definitions.** "CUPED stands for Controlled-experiment Using Pre-Experiment Data" cites better than a passage that uses CUPED without defining it. AI engines extract definitions and use them as the canonical answer when users ask "what is CUPED."
**Comparison tables.** Tables with explicit columns and rows cite better than prose comparisons. AI engines extract structured data preferentially.
**Specific tool names with version numbers.** "dbt Cloud (v1.7+)" cites better than "dbt." Specificity is the citation signal.
---
## Brief field: how to populate entity coverage
The brief lists the required entities, the standard entities, and the gap entities, with one-line notes per entity.
> **Required entities (mention all)**
>
> - **CUPED:** variance-reduction technique (9/10 SERP pages). Mention in methodology H2 with formula.
> - **Sequential testing:** confidence-adjustment for peeking (8/10). Mention in pitfalls H2.
> - **MDE (minimum detectable effect):** power-calculation input (10/10). Mention in setup H2.
> - **Statsig, PostHog, Optimizely:** named platforms (10/10 mention at least one). Brief should mention all three with one-sentence positioning.
>
> **Standard entities (mention if relevant)**
>
> - **A/A test:** sanity check (5/10). Mention in pitfalls H2.
> - **Bonferroni correction:** multiple-testing adjustment (4/10). Mention in pitfalls H2.
>
> **Gap entities (differentiation opportunity)**
>
> - **CUPAC:** successor to CUPED (1/10). Mention in methodology H2 as the next-generation technique. Differentiates the piece from SERP consensus.
> - **Bayesian inference:** alternative to frequentist hypothesis testing (1/10; mentioned occasionally in advanced experimentation content). Mention in advanced section if word budget allows.
The "Bayesian inference" entity is the example: it is a specific technical concept that some advanced experimentation content covers, where most SERP top-10 pieces stop at frequentist hypothesis testing. Adding the gap entity differentiates the piece without crowding the required-coverage list.
---
## The entity-coverage failure mode
The most common failure: the writer mentions all the required entities once each, in passing, without weight. The piece passes the entity-coverage check on a string-match basis but does not actually demonstrate topical depth.
The fix in the brief: specify weight per entity. "Mention CUPED in passing in H2 #2; develop CUPED with formula and example in H2 #4." The brief is not just a list of entities to include; it is a placement plan.
The writer's draft references the brief's entity placement plan. The editor reviews against placement, not just against presence.
references/heading-structure-patterns.md
# Heading structure patterns
H2 patterns, H3 sub-section patterns, featured-snippet bait, and the anti-patterns the brief should explicitly forbid.
---
## H2 patterns that work
**Question-style H2s.** "What is CUPED?" "How does CUPED reduce variance?" "When should I use CUPED?" These match how readers think and how Google's "People Also Ask" box surfaces queries. They are also the easiest format for AI engines to extract as citation candidates.
**Declarative H2s.** "CUPED reduces variance by adjusting for pre-experiment covariates." "The formula uses a regression coefficient computed before assignment." Declarative H2s work for pieces that have a strong thesis or that summarize before they explain.
**Comparison H2s.** "Platform-native: faster, narrower, opinionated." "Warehouse-native: slower, broader, custom-metric capable." Symmetrical H2s pair to set up a comparison; the reader sees the structure on the table of contents alone.
**Imperative H2s.** "Configure the assignment unit." "Define the metrics." "Set the duration and MDE." Common for how-to guides; each H2 is one action.
The discipline: pick one pattern and use it consistently within a piece. Mixing question + declarative + imperative reads as inconsistent and signals AI generation when the mixing is random.
---
## H3 patterns under H2s
H3s should add navigational value, not just structure for its own sake.
**When to add H3s:**
- The H2 covers a topic with 3 to 5 sub-topics that the reader might want to jump to
- The H2 section is long enough (700+ words) that scanning needs sub-anchors
- The piece has a table of contents that benefits from sub-entries
**When not to add H3s:**
- The H2 is short (under 400 words)
- The H3s would be a cosmetic enumeration that does not add navigation
- The piece is short overall (under 1,200 words); H3s are usually unnecessary
**No orphan H3s.** Every H2 either has zero H3s or 2+ H3s. A single H3 under an H2 reads as a typo or an aborted edit.
**No H2-H3-H4 cascades.** If a section needs H4s, the structure is wrong. Either the H2 is too broad and should split into two H2s, or the H4 is decoration that should be a paragraph.
---
## The featured snippet bait pattern
Place a 40 to 60 word answer paragraph immediately following the H2 question. Google often pulls this paragraph as the featured snippet; AI engines often quote it as the citation.
**Example.**
> ## What is CUPED?
>
> CUPED (Controlled-experiment Using Pre-Experiment Data) is a variance-reduction technique that adjusts experimental measurements using pre-treatment covariates. The covariate's regression coefficient against the outcome is computed before assignment, then used to subtract baseline variance from the experiment's measurement, increasing statistical power without changing the experiment's design.
The paragraph is self-contained: read alone, it answers the H2 question completely. The rest of the section expands on the answer with examples, formulas, edge cases.
The discipline: the snippet paragraph is the most important paragraph in the section. Write it first; expand the section around it.
---
## H2 ordering
H2s should match the reader's mental model, not the writer's enthusiasm.
**The standard order for informational pieces:**
1. What is it (definition, plain language)
2. Why does it matter (why the reader cares)
3. How does it work (mechanism, technical depth)
4. When to use it (decision criteria)
5. Common pitfalls (what goes wrong)
6. Wrap-up or call-to-action
**The buried-lede anti-pattern.** H2 #4 has the actual answer the reader came for. The reader bounced at H2 #2.
**The fix.** Put the obvious answer first. The writer's clever angle goes in H2 #4 or H2 #5, not H2 #1.
---
## Anti-patterns the brief should forbid explicitly
**Repetitive H2 structure.** All H2s start with "How to" or all start with "The." Repetitive structure signals AI generation to AEO/GEO crawlers and to readers. Vary the patterns within a piece, but keep one dominant pattern.
**Buried lede.** The actual answer is in H2 #4. The brief specifies which H2 carries the keystone answer; usually H2 #1 or H2 #2.
**Section length unevenness.** H2 #1 is 1,500 words; H2 #2 is 80 words. The 80-word section reads as a placeholder. Briefs should specify approximate word counts per H2 to enforce balance.
**H3-only enumeration.** A section that is just an H2 plus a list of H3s with one paragraph each. Either the H2 should hold all the content, or the H3s deserve more depth. The half-and-half shape is a sign of incomplete thinking.
**Misnumbered H2s in numbered series.** "5 ways to Y" with 6 H2s, or with 4. The mismatch reads as careless.
---
## Brief field: how to populate the heading structure
The brief lists the H2s in order with one-line notes. H3s only when they earn their keep.
> **Heading structure outline**
>
> - H2 #1: "What is X?" (snippet paragraph mandatory; ~250 words section)
> - H2 #2: "Why X matters" (~300 words; one specific reader scenario)
> - H2 #3: "How X works" (~600 words; H3s: "the formula," "the assumption," "the implementation"; show the math)
> - H2 #4: "When to use X" (~400 words; decision-criteria list)
> - H2 #5: "Common pitfalls" (~400 words; 3 to 5 specific pitfalls with diagnoses)
> - H2 #6: "Wrap-up" (~150 words; call-to-action to related cluster piece)
The writer follows the outline; deviations are flagged in the first draft for editor review.
references/internal-linking-strategy.md
# Internal linking strategy
Outbound and inbound linking patterns, orphan-content prevention, self-cannibalization check.
---
## Two link directions to specify
Every brief specifies links in two directions.
**Outbound from this piece.** 3 to 5 pages this piece should link to. Anchor text and target page named explicitly. The writer is not deciding internal links during drafting; the strategist already knows the cluster and which pieces should reinforce each other.
**Inbound to this piece, post-publish.** 1 to 3 existing pages that should add a link to this piece after it publishes. This is a follow-up task queued in the brief, not a request to the writer.
---
## Outbound link selection
The cluster pieces. The brief lists the supporting cluster pieces this piece should link to, with anchor text that matches each target's primary keyword.
**Example for a pillar piece on "experimentation analytics dashboards":**
> **Outbound links (writer integrates)**
>
> 1. Link to "CUPED variance reduction" (cluster piece) using anchor "CUPED" or "variance reduction with CUPED" in the methodology H2.
> 2. Link to "warehouse-native experimentation" (sister pillar) using anchor "warehouse-native experimentation" in the platform-vs-warehouse comparison H2.
> 3. Link to "feature flag tools comparison" (commercial-intent piece) using anchor "feature flag tools" in the deployment H2.
> 4. Link to "data warehouse setup" (foundation piece) using anchor "data warehouse" in the prerequisites H2.
The discipline: anchor text matches the target's primary keyword. Generic anchors ("click here," "this article") do not pass ranking signals; keyword anchors do.
---
## Inbound link queue
The brief queues 1 to 3 existing pages that should add a link to the new piece after it publishes. The strategist updates these as part of the publish checklist.
**Example continuing the same pillar:**
> **Inbound link updates (post-publish task)**
>
> 1. Update "feature flagging" pillar to link to the new piece in the "measuring feature impact" section using anchor "experimentation analytics dashboards."
> 2. Update "PostHog vs Statsig" comparison to link to the new piece in the analytics-comparison H2.
> 3. Update homepage "Resources" section to add the new piece to the "Pillars" list.
The inbound queue prevents the orphan-content failure mode.
---
## The orphan-content failure mode
Symptom: piece publishes, no other piece links to it, search engines deprioritize it, AI engines do not see it as cluster-anchored.
Cause: internal linking was an afterthought, handled by the writer or by SEO at publish time without strategic intent. The writer linked out to 3 pages because the brief said to; nobody linked back in because nobody owned that task.
Fix: the brief queues the inbound updates explicitly. The publish checklist includes the inbound updates as a tracked task. Without a tracked task, the inbound updates do not happen; without inbound links, the piece is an orphan.
The "5-link rule" diagnostic. Every published piece should have at least 5 internal links pointing to it within 30 days of publish. If a piece has fewer than 5 inbound links at the 30-day check, audit the inbound queue and add the missing links.
---
## The self-cannibalization check
Before briefing a new piece, check whether it would compete with an existing piece for the same keyword cluster.
**The check.** Search the site for the target keyword. If an existing piece is in the top 5 of internal search results, flag it.
**Three options when self-cannibalization is detected:**
1. **Consolidate.** Merge the planned piece into the existing piece. Update the existing piece with the new angle, the new entities, the new examples. Keep one URL ranking; do not split ranking authority across two URLs.
2. **Differentiate.** Sharpen the angle of the new piece so it does not compete. The existing piece covers "what is feature flagging"; the new piece covers "feature flag rollout strategies for enterprise teams." Different intent, different audience, different SERP target.
3. **Kill one.** Determine which piece serves the cluster better. Redirect the loser to the winner. This is rare and usually signals the program does not have clear pillar structure.
The discipline: flag self-cannibalization in the brief, not after the piece is written. Late detection is the expensive failure mode; the writer has already invested hours that now have to be either rewritten or thrown away.
---
## Brief field: how to populate internal linking
> **Internal linking**
>
> **Outbound (3 specified, 2 optional)**
> - Required: link to "CUPED variance reduction" with anchor "CUPED" in methodology H2
> - Required: link to "warehouse-native experimentation" with anchor "warehouse-native" in comparison H2
> - Required: link to "feature flag tools 2026" with anchor "feature flag tools" in deployment H2
> - Optional: link to "data warehouse setup" with anchor "data warehouse" in prerequisites H2 (writer's call based on flow)
> - Optional: link to "experiment-design skill" with anchor "experiment design" in introduction (writer's call)
>
> **Inbound (post-publish, queued)**
> - Update "feature flagging" pillar (insert link in section 4)
> - Update "PostHog vs Statsig" comparison (insert link in analytics-comparison H2)
>
> **Self-cannibalization check**
> - Existing pieces on adjacent keywords: "experiment dashboards introduction" (different angle, no conflict)
> - No conflict; proceed with brief
The brief is explicit about what is required, what is optional (writer chooses), and what is queued for post-publish. Three layers of discipline.
references/search-intent-classification.md
# Search intent classification
Four-intent framework, dominant SERP format check, override patterns when intent and format mismatch.
---
## The four standard intents
**Informational.** The reader wants to learn. Queries: "what is CUPED," "how does feature flagging work," "experimentation analytics explained." SERP usually shows articles, guides, explainers, sometimes videos. Conversion is downstream (the reader signs up for the newsletter or returns to the site weeks later); ranking is the immediate goal.
**Navigational.** The reader wants a specific brand, product, or page. Queries: "Statsig pricing," "LaunchDarkly login," "PostHog docs." SERP usually shows the brand site at #1 and a sitelinks block. Ranking against navigational intent is mostly impossible unless you are the brand. The exception: the reader-bypass pattern where adjacent brands rank for "competitor X login" by writing comparison content; play this carefully because it can read as bait.
**Commercial.** The reader is researching a purchase. Queries: "best feature flag tools," "Statsig vs LaunchDarkly," "Optimizely review." SERP usually shows comparisons, reviews, "best X" listicles, sometimes detailed guides. The reader is in active evaluation; this is the highest-conversion intent for B2B SaaS content.
**Transactional.** The reader is ready to buy. Queries: "Statsig signup," "buy LaunchDarkly," "PostHog free trial." SERP usually shows product pages, pricing pages, signup flows. Editorial content does not rank here; brand-owned commercial pages do.
---
## The dominant SERP format check
After classifying intent, scan the SERP top 10 and tag the dominant format.
- **Article.** Long-form prose, single-author voice. Common for informational intent.
- **Listicle.** "10 best X," "7 ways to Y." Common for commercial-investigation intent.
- **Comparison.** Side-by-side X vs Y, table-heavy, decision frameworks. Common for high-funnel commercial intent.
- **Video.** YouTube embeds dominate the top of SERP. Common for how-to and tutorial queries.
- **Tool.** Calculator, generator, interactive tool. Common for "X calculator" or "X generator" queries.
- **Hybrid.** SERP shows a mix; usually tells you the keyword is contested or the intent is split.
The dominant format tells you the shape of the piece, which is more decisive than the intent label. An informational keyword whose SERP is mostly listicles wants a listicle, not a long-form article.
---
## The override pattern
When intent and format mismatch, the format wins.
**Case 1.** The intent feels informational ("how to design an A/B test") but the SERP shows mostly listicles ("7 steps to designing an A/B test"). Write the listicle. The SERP is the source of truth, not your priors about what the intent "should" look like.
**Case 2.** The intent feels commercial ("best feature flag tools") but the SERP shows mostly long-form articles that mention many tools without ranking them. Write the long-form article. Listicle format would feel out of place against the SERP.
**Case 3.** The SERP is genuinely split: half listicles, half long-form articles. Either format can rank. Pick based on the brand's voice and the piece's role in the cluster.
The reason. Rankings come from matching the SERP's accepted shape; deviating costs ranking. Google's ranking algorithm is partly trained on what users click and stay on, which is selected from existing top-ranking content. Existing top-ranking content sets the shape; new content has to match the shape to compete.
---
## The AEO and GEO consideration
AI engines (ChatGPT, Perplexity, Claude, Gemini, Google AI Mode) tend to favor pieces that match SERP intent format because the intent classification was trained on the SERP corpus.
A piece that mismatches the SERP format faces two problems: it is harder to rank in traditional search, and it is less likely to be cited by AI engines. The mismatch is a double cost.
The exception: thought leadership that deliberately diverges. A piece arguing "the listicle format is misleading for this category; here is why" can rank by drawing traffic on the controversy and earning citations on the contrarian thesis. This is rare and risky; do not default to it.
---
## Brief field: how to populate intent + format
The brief field reads like this:
> **Search intent + SERP format**
> Intent: commercial-investigation
> Dominant SERP format: long-form article + comparison table hybrid (top 5 are articles with embedded comparison tables; positions 6 to 10 are pure listicles)
> Format choice for this piece: long-form article with one comparison table at the midpoint
> SERP intent override: none (format choice matches dominant)
The "format choice" line is decisive. The writer reads this line first and shapes the piece around it.
references/writer-handoff-protocols.md
# Writer handoff protocols
Human-writer handoff, AI-agent handoff, success-criteria anchoring.
---
## The handoff has the same shape regardless of writer
Whether the writer is a human freelancer, a staff editor, an internal SME, or an AI agent (Claude, ChatGPT, a Frase brief-runner, an AirOps workflow), the brief-to-writer handoff has the same five-step shape.
1. Brief delivered with all 12 fields populated.
2. Writer asks clarifying questions before drafting (or the agent surfaces ambiguities as the first response).
3. Writer or agent acknowledges the success criteria explicitly.
4. First draft references the brief: which fields the draft addresses, which fields it could not address, why.
5. Editor reviews against the brief, not against personal taste.
The shape is the same; the medium differs. Human writers acknowledge in Slack or email; AI agents acknowledge in the first message of the agent thread. Both cases: the acknowledgment is required, not optional.
---
## Human-writer handoff
**Step 1: brief delivery.** The brief is delivered as a single document (Notion page, Google Doc, dbt-style markdown file in the repo). The writer can read it in 5 minutes; if reading takes longer, the brief is too thick and should be cut.
**Step 2: clarifying questions.** Before drafting, the writer asks clarifying questions. Common ones:
- Is the target audience right? Is the JTBD specific enough to write to?
- Is the SERP intent classification right? Do I write a listicle or an article?
- Are these entities really required, or are some optional?
- Is the success criteria measurable from my side, or is it a downstream-only metric?
The strategist answers questions in the same document; clarifications are versioned with the brief, not pasted into Slack and lost.
**Step 3: acknowledgment.** The writer acknowledges in writing: "I have read the brief. I am writing to the success criteria of [X]. I will hit all required entities. I am clear on the SERP format choice." Acknowledgment is a 3-line message, not a treatise.
**Step 4: first draft with reference.** The first draft is delivered with a reference note: "Hit 4 of 5 required entities; the 5th (CUPAC) was not in the SERP coverage I could find sources for, so I substituted the standard CUPED treatment per the brief's gap-entity guidance." The reference note tells the editor what to focus on in review.
**Step 5: editor review against brief.** The editor reads the brief first, the draft second. The review framing is "the brief said X; the draft did Y; gap is Z." Personal taste comes after brief review, not before.
---
## AI-agent handoff
The shape is the same; the medium is structured.
**Step 1: brief delivery as structured input.** The brief becomes a YAML or JSON object the agent ingests. Frase, AirOps, and similar tools structure briefs in their own schema; the same 12 fields appear regardless. Example minimal YAML structure:
```yaml
target_keyword: experimentation analytics dashboards
supporting_cluster:
- CUPED variance reduction
- sequential testing
- feature flag rollout
search_intent: commercial-investigation
serp_format: long-form-article-with-comparison-table
target_audience: senior data engineer at 500-person SaaS
jtbd: choose between platform-native and warehouse-native experimentation
word_count_target: 2800
heading_outline:
- { level: 2, text: "What an experimentation dashboard does" }
- { level: 2, text: "Platform-native vs warehouse-native" }
- { level: 2, text: "Metrics that earn their keep" }
- { level: 2, text: "Build vs buy" }
- { level: 2, text: "Common dashboards that ship trusted results" }
required_entities:
- { name: "CUPED", note: "mention with formula in methodology H2" }
- { name: "Statsig, PostHog, Optimizely", note: "mention all three" }
internal_links:
outbound:
- { target: /skills/cuped, anchor: "CUPED" }
- { target: /skills/warehouse-native, anchor: "warehouse-native experimentation" }
inbound_queued:
- { source: /pillars/feature-flagging, anchor: "experimentation analytics dashboards" }
anti_patterns:
- "do not use the team's do-not-use word list (see brand voice guide)"
- "do not write a listicle; SERP wants long-form"
success_criteria:
- "rank top 10 for target keyword in 90 days"
- "cited by ChatGPT for 'experimentation dashboard' queries within 60 days"
voice_reference: /brand/voice-guide
brief_version: 2
brief_approver: editorial-lead@team.com
```
**Step 2: ambiguity surfacing.** The agent's first response surfaces ambiguities. "The brief lists CUPED as required, but the SERP top 10 only mention CUPED in 6 of 10 results; should I emphasize it or treat it as standard coverage?" The strategist answers; the brief gets versioned with the answer.
**Step 3: acknowledgment.** The agent acknowledges in structured output: "Reading brief version 2. Target: 2,800 words. Format: long-form with comparison table. Will hit 4 required entities; need clarification on CUPED weight." Single message, machine-readable.
**Step 4: first draft with reference.** The agent's draft is delivered with a structured note: which fields the draft addressed, which entities are present and where, what success criteria the draft is targeting.
**Step 5: editor review.** The editor reviews the agent's draft using the same brief-first framing. Tools like Frase highlight which entities are present in the draft; the editor scans the highlights to confirm coverage.
---
## Success-criteria anchoring
The most-skipped handoff step is success-criteria acknowledgment. The writer or agent reads the brief, drafts the piece, delivers it; the success criteria sit in the brief unread.
The fix: every handoff acknowledgment includes the success criteria verbatim. "I am writing to the success criteria: rank top 10 for 'experimentation analytics dashboards' in 90 days; get cited by ChatGPT for the topic within 60 days; drive 50 trial signups in the first 30 days."
The acknowledgment is the contract restated in the writer's voice. Saying it out loud is what keeps it load-bearing during drafting.
SKILL.md
---
name: content-brief-authoring
description: "How to author a content brief that actually guides a writer (human or AI) to produce a piece that ranks, converts, or both. Per-piece editorial brief: target keyword and cluster, search intent, audience and JTBD, heading structure, entity coverage for AEO/GEO, internal linking strategy, success criteria. The middle path between thin briefs (a keyword and a deadline) and thick briefs (a 4-page document nobody reads). Triggers on content brief, brief the writer, brief the article, brief authoring, content brief template, brief audit, per-piece brief, editorial brief, target keyword brief, search intent brief. Also triggers when briefing a human writer or an AI agent on a single content piece."
category: content
catalog_summary: "Per-piece editorial brief: target keyword, intent, audience, outline, entity coverage, internal linking, success criteria, and the discipline that distinguishes useful briefs from bloat"
display_order: 2
---
# Content Brief Authoring
A senior content strategist's playbook for authoring per-piece content briefs that actually guide writers to produce content worth publishing.
Most content briefs are some flavor of broken. The thin version is a keyword, a word count, and a deadline; the writer fills in everything else from scratch and the output is generic. The thick version is a 4-page document nobody reads, that the writer skims for the headline and the outline and ignores the rest. Either way, the brief failed at its job: making the writer's work easier and the output more predictable.
This skill is the middle path. It defines the 12 fields that earn their keep in a content brief, the fields that bloat without helping, and the discipline of writing briefs that route a writer (human or AI) toward a content piece that ranks for its target keyword, gets cited by AI engines, converts the right reader, or whatever the success criteria say. It assumes you have decided what to write (see `content-strategy` for program-level decisions) and now you are briefing each piece. The piece itself gets written separately (see `content-and-copy`).
When to use this skill: briefing a writer (human or AI) on an individual content piece, auditing existing briefs that are not producing good content, building a brief template for a content program, or running a brief-generation pipeline through Frase, AirOps, or another tool.
---
## What this skill is for
This skill spans the per-piece editorial brief discipline. It composes with three sister skills, and the distinction between them is what keeps each one sharp.
- `creative-brief` is a project brief. It bridges discovery to execution at the project level: a new website, app, brand, or campaign. Audience, goals, scope, success at project scope.
- `content-strategy` is a program-level editorial strategy. Pillars, calendar, topic clusters, governance. What to produce across a quarter or a year.
- `content-and-copy` is the writing itself. Voice, structure, edit pass, tone calibration. Execution scope for general editorial.
- This skill is the per-piece brief between `content-strategy` (program decided) and `content-and-copy` (piece gets written). It briefs a single content artifact: keyword, intent, audience, outline, entities, success criteria.
The clean reading order: `content-strategy` decides what to produce; this skill briefs each piece; `content-and-copy` writes it. If the team is briefing a redesign or a new brand build, that is `creative-brief`, not this skill.
The audience: content strategists, SEO content marketers, editorial leads, content ops managers, agencies running content programs at scale, and any PM or marketer briefing a writer (human or AI). The voice is senior content strategist to junior content marketer. Specific, opinionated, honest about what makes a brief useful versus useless.
---
## Thin vs thick vs effective briefs
The keystone distinction. Three concrete shapes.
**Thin brief.** Keyword, word count target, deadline. Maybe a one-line summary of the angle. The writer fills in everything else from scratch. Output is generic, drifts off-topic, does not rank, and does not convert. The cost is the rewrite cycle: editor spends two hours rewriting because the writer chose the wrong intent, the wrong audience, or the wrong outline.
**Thick brief.** A 4-page document with executive summary, brand-guidelines refresher, comprehensive competitive analysis, voice guidelines, plus the actual brief somewhere in the middle. The writer skims for the outline, ignores the rest. Output is not materially better than from a thin brief because the writer never read most of the document. The cost is the authoring time: the strategist spends three hours producing pages of context the writer will never absorb.
**Effective brief.** One to two pages. Every field earns its keep. Writer reads all of it because there is no fluff. Output is predictable enough that the editor does not have to rewrite the lede. The cost is the discipline of cutting fields that do not change writer behavior.
The discipline. Every field in the brief has a job. If you can remove the field without degrading the output, remove it. The brief is the contract between editorial leader and writer; vague contracts produce vague output, overstuffed contracts produce output that reflects only the parts the writer read.
Most briefs that are not working are thin, not thick. The instinct to add more usually makes the brief worse. The instinct to be more specific in fewer fields usually makes the brief better.
---
## The 12 fields of an effective brief
A useful brief has 12 fields. Skip any of them and the writer fills the gap from priors; the gap is where output drifts.
1. **Target keyword + supporting cluster.** Primary keyword plus 3 to 5 supporting keywords from the same cluster. The cluster is what tells the writer the topic has range; the primary is what the piece optimizes for.
2. **Search intent classification.** Informational, navigational, commercial, or transactional. Plus the dominant SERP format check (article, listicle, comparison, video, tool). The intent decides what kind of piece this is; the format decides the shape.
3. **Target audience.** Specific role and sophistication level. Not "anyone interested in X." A senior data engineer at a 500-person SaaS company is a target; "data people" is not.
4. **Job to be done.** The problem the reader is trying to solve when they land on the piece. One sentence. Specific.
5. **Word count / depth target.** Calibrated to the SERP, not to a content quota. If the top 10 are all 1,200 words, briefing 3,000 wastes effort; if the top 10 are all 4,000 words, briefing 1,500 produces a piece that cannot rank.
6. **Heading structure outline.** H2s and H3s explicit, ordered logically. The outline is where the writer reads the brief most carefully; spend time here.
7. **Required entities, statistics, citations.** For AEO and GEO, the named tools, methods, experts, and statistics the piece must cover. The entity gap is the agent's prioritization signal.
8. **Internal linking strategy.** 3 to 5 pages this piece should link out to with anchor text; 1 to 3 existing pages that should link back to this piece after publish.
9. **External proof points.** Required citations, sources, expert quotes. Not optional.
10. **Anti-patterns.** What not to do. Off-topic tangents the writer might wander into, off-brand voice, AI clichés the brief explicitly forbids by listing them in a do-not-use list (the standard set of overused corporate-speak adjectives, throat-clearing openers, and verbs that signal AI generation).
11. **Success criteria.** What good looks like. Rank for the target keyword in 90 days. Get cited by ChatGPT for the cluster within 60 days. Drive 50 trial signups in the first 30 days. Measurable, time-bound, tied to the program goal.
12. **Author voice and tone reference.** Link to the brand-voice guide. If the piece needs a tone shift from the default voice, note it here in one sentence.
The fields that do not earn their keep, and should be omitted from briefs unless the writer is brand new to the program:
- Long executive summary (the brief itself is the executive summary)
- Brand-guidelines refresher (link to it; do not repeat)
- Comprehensive competitive landscape (link to research; do not dump)
- Brief history of the publication, company, or brand (irrelevant to this piece)
Detail and templates per content type in [`references/brief-templates.md`](references/brief-templates.md).
---
## Search intent classification
The four standard intents:
- **Informational.** The reader wants to learn. SERP usually shows articles, guides, explainers.
- **Navigational.** The reader wants a specific brand or page. SERP usually shows the brand site at #1; ranking against navigational intent is mostly impossible unless you are the brand.
- **Commercial.** The reader is researching a purchase. SERP usually shows comparisons, reviews, "best X" listicles.
- **Transactional.** The reader is ready to buy. SERP usually shows product pages, pricing pages, signup flows.
The dominant SERP format check. After classifying intent, scan the SERP top 10 and tag the dominant format: article, listicle, comparison, video, tool, hybrid. The dominant format tells you the shape of the piece, which is more decisive than the intent label.
The override pattern. When the intent feels informational but the SERP shows mostly listicles, write the listicle. When the intent feels commercial but the SERP shows mostly long-form articles, write the article. The SERP is the source of truth, not your priors. Rankings come from matching the SERP's accepted shape; deviating costs ranking.
The AEO/GEO consideration. AI engines tend to favor pieces that match SERP intent format because the intent classification was trained on the SERP corpus. Mismatched format is a citation risk in addition to a ranking risk.
Detail in [`references/search-intent-classification.md`](references/search-intent-classification.md).
---
## Heading structure design
Heading hierarchy patterns the brief should specify:
- H2 sections that match common follow-up questions for the keyword. The reader's mental model is a series of questions; the H2s answer them in order.
- H3s under H2s only when they add navigational value. No orphan H3s. No H2-H3-H4 cascades that nobody scrolls through.
- Featured snippet bait pattern: a 40 to 60 word answer paragraph immediately following an H2 question. Google often pulls this paragraph as the snippet; AI engines often quote it as the citation.
- H2 ordering that matches the reader's mental model, not the writer's enthusiasm. Put the obvious answer first; the writer's clever angle goes in H2 #4, not H2 #1.
Anti-patterns the brief should explicitly forbid:
- H2s that all start with "How to" or all start with "The." Repetitive structure signals AI generation to AEO/GEO crawlers and to readers.
- Buried lede: H2 #4 has the actual answer. The reader bounced at H2 #2.
- Section length wildly uneven: H2 #1 is 1,500 words, H2 #2 is 80 words. The 80-word section reads as a placeholder.
Detail in [`references/heading-structure-patterns.md`](references/heading-structure-patterns.md).
---
## Entity coverage for AEO and GEO
AI engines (ChatGPT, Perplexity, Claude, Gemini, Google AI Mode) tend to cite content that mentions the entities the SERP top-ranking pages mention, includes specific statistics with sources, contains citation-formatted proof points, and demonstrates topical depth via entity coverage.
The entity discovery pattern, run before briefing the piece:
1. Pull SERP top 10 for the target keyword.
2. Identify entities mentioned across multiple pages: named tools, named methods, named experts, named data sources, named statistics.
3. Identify entities mentioned by 1 to 2 pages but not in your existing content. This is the entity gap.
4. Add the gap entities to the brief as required coverage.
The brief lists the entities the writer must mention, with light context on why each matters. The writer is not expected to research each entity from scratch; the brief includes a one-line note ("CUPED is the variance-reduction technique used by data-warehouse-experimentation teams; mention in the methodology section") so the writer can integrate without breaking flow.
Tools that automate this: Frase has entity-gap analysis built in; AirOps composes the same analysis through its workflow builder; Surfer SEO ships entity coverage scoring. The skill is tool-agnostic; the workflow is what matters.
Detail in [`references/entity-coverage-checklist.md`](references/entity-coverage-checklist.md).
---
## Internal linking strategy
The brief should specify two link directions:
- **Outbound from this piece.** 3 to 5 pages this piece should link to. Anchor text and target page named explicitly. The writer should not be deciding internal links during drafting; the strategist already knows the cluster and which pieces should reinforce each other.
- **Inbound to this piece, post-publish.** 1 to 3 existing pages that should add a link to this piece after it publishes. This is a follow-up task queued in the brief, not a request to the writer.
The orphan-content failure mode: piece publishes, no other piece links to it, search engines deprioritize it, AI engines do not see it as cluster-anchored. Prevented by upstream-link planning in the brief.
The self-cannibalization check: if this piece would compete with an existing piece for the same keyword cluster, the brief flags it explicitly. The options are consolidate (merge into the existing piece), differentiate (the brief sharpens the angle so the two do not compete), or kill one. Flagging late, after the piece is written, costs more than flagging in the brief.
Detail in [`references/internal-linking-strategy.md`](references/internal-linking-strategy.md).
---
## Brief templates by content type
Different content types call for different brief shapes. The 12 fields are constant; the weight of each field shifts.
- **Pillar piece.** Comprehensive coverage of a topic, 3,000 words plus, anchors a topic cluster. Brief emphasizes structure, comprehensiveness, internal links to and from supporting pieces.
- **Supporting / cluster piece.** Narrower topic, 1,000 to 2,000 words, links up to the pillar. Brief emphasizes specificity, single-question scope.
- **Comparison piece (X vs Y).** Commercial intent, structured comparison, decision framework. Brief emphasizes objectivity (or honest positioning if the brand is one of X or Y), table structure, "when X wins" / "when Y wins" framing.
- **Listicle.** Informational or commercial intent, scannable, ranked or unranked. Brief emphasizes selection criteria, ordering rationale, depth-per-item.
- **How-to guide.** Informational, step-by-step, screenshots. Brief emphasizes step granularity, prerequisites, troubleshooting section.
- **Thought leadership / opinion.** Commercial or branding, distinctive POV, signal of expertise. Brief emphasizes thesis, supporting arguments, anticipated counter-arguments.
Each template gets a worked example in [`references/brief-templates.md`](references/brief-templates.md).
---
## The brief-to-writer handoff
Whether the writer is human or AI, the handoff has the same shape.
- Brief delivered with all 12 fields populated.
- Writer asks clarifying questions before drafting (or the AI agent surfaces ambiguities in the brief as the first response).
- Writer or agent acknowledges the success criteria explicitly.
- First draft references the brief: "this draft hits 4 of the 5 required entities; the 5th is missing because the SERP coverage was thin and I could not find a reliable source."
- Editor reviews against the brief, not against personal taste. "The brief said X; the draft did Y" is the review framing.
For AI handoff specifically, the brief becomes a structured prompt or a tool input. Frase, AirOps, and similar tools structure briefs as YAML or JSON for machine consumption; the same 12 fields apply. The structured format is the only difference; the contract is the same.
Detail in [`references/writer-handoff-protocols.md`](references/writer-handoff-protocols.md).
---
## Brief governance
Versioning. Every brief has a version. Significant changes (target keyword change, audience shift, scope expansion) bump the version; cosmetic edits do not. The writer always works from the current version, not a stale draft pasted into Slack three weeks ago.
Approval. The brief approver is the editorial owner of the content program. Single approver, not a committee. The approver is also the editor on the back end, so the same person is responsible for both the contract and the review. Splitting these roles is how briefs and reviews drift apart.
Archival. After publish, the brief is archived alongside the content piece (Notion database row, dbt model, content management system metadata, whatever the team's source of truth is). Future content audits reference both brief and published piece to assess gap between intent and execution. Without the brief in the archive, a content audit cannot tell whether the piece succeeded against the original goal or drifted from it.
Detail in [`references/brief-governance-patterns.md`](references/brief-governance-patterns.md).
---
## Common failure modes
Rapid-fire. Diagnoses and fixes in [`references/common-brief-failures.md`](references/common-brief-failures.md).
- "The brief was too thin." Fill all 12 fields or accept generic output.
- "The brief was too thick." Every field needs a job; remove the rest.
- "The writer ignored the brief." Anchor success criteria to the brief; review against the brief.
- "The brief had the wrong target keyword." SERP-validate before briefing.
- "The piece does not match the SERP intent." SERP intent override applies; do not write an article when the SERP wants a listicle.
- "The piece has no internal links." Internal linking belongs in the brief, not as an afterthought.
- "The piece is generic; could have been written about anything." Entity coverage and POV missing from brief.
- "The brief is comprehensive but the piece does not rank." Brief was right; SERP was harder than expected; iterate based on real performance, not by adding fields to the brief.
- "We never went back to evaluate." Success criteria measured 30 / 60 / 90 days post-publish.
- "Different writers produce wildly different output from the same brief." Brief was actually too vague; tighten anti-patterns and voice notes.
---
## The framework: 12 considerations for brief authoring
When authoring or auditing a content brief, walk these 12 considerations.
1. **Target keyword + cluster.** Primary plus 3 to 5 supporting.
2. **Search intent + dominant SERP format.** Match the SERP, not your priors.
3. **Target audience + JTBD.** Specific role and problem, not "anyone interested in X."
4. **Word count calibrated to SERP.** Not to a content quota.
5. **Heading structure.** Explicit H2s and H3s, ordered to match reader mental model.
6. **Entity coverage.** Entities the SERP top 10 mention; gap entities added explicitly.
7. **Internal linking.** 3 to 5 outbound links specified; 1 to 3 inbound updates queued.
8. **External proof points.** Citations and sources required.
9. **Anti-patterns.** What not to do, including AI clichés and off-brand voice.
10. **Success criteria.** Measurable, time-bound, tied to original program goals.
11. **Brief versioning + approval.** Single approver; version bumps for material changes.
12. **Brief stays under 2 pages.** Every field earns its keep; remove fields that do not.
The output of the framework is a brief document the writer can absorb in 5 minutes and execute against in the next 5 hours.
---
## If required data is unavailable
This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.
---
## Reference files
- [`references/brief-templates.md`](references/brief-templates.md) - Pillar, supporting, comparison, listicle, how-to, and thought-leadership brief templates with field-weight notes per type.
- [`references/search-intent-classification.md`](references/search-intent-classification.md) - Four-intent framework, SERP format check, override patterns.
- [`references/heading-structure-patterns.md`](references/heading-structure-patterns.md) - H2 and H3 patterns, featured snippet bait, anti-patterns.
- [`references/entity-coverage-checklist.md`](references/entity-coverage-checklist.md) - Entity discovery from SERP, gap analysis, AEO/GEO citation drivers.
- [`references/internal-linking-strategy.md`](references/internal-linking-strategy.md) - Outbound and inbound linking patterns, orphan prevention, self-cannibalization check.
- [`references/writer-handoff-protocols.md`](references/writer-handoff-protocols.md) - Human-writer handoff, AI-agent handoff, success-criteria anchoring.
- [`references/brief-governance-patterns.md`](references/brief-governance-patterns.md) - Versioning, approval, archival, audit trail.
- [`references/common-brief-failures.md`](references/common-brief-failures.md) - Ten-plus failure patterns with diagnoses and fixes.
---
## Closing: the brief is the contract
A content brief is the contract between editorial leader and writer. If the contract is vague, the output is vague. If the contract is overstuffed, the output reflects only the parts the writer read. The discipline is writing contracts the writer can absorb in 5 minutes and execute against in the next 5 hours; that is the entire job.
Most briefs that are not working are thin, not thick. The instinct to add more pages usually makes the brief worse. The instinct to be more specific in fewer fields usually makes the brief better.
When in doubt about whether a brief is ready, ask: are all 12 fields populated, do they each earn their keep, is the SERP intent matched, are the entities listed, are the internal links specified, is the success criteria measurable, and is the document under 2 pages? If yes to all of those, ship the brief and let the writer work.