---
name: content-brief
description: Generate a content brief anchored to the same authoritative sources AI grounding systems prefer — Wikipedia/Wikidata for canonical structure, the agent's own web search for live citation snapshot, and analyze_page for current top-source signals. No SERP API costs, no scraping. Output is a paste-ready outline with H2 structure, must-cover entities, schema recommendations, and a coverage-gap analysis against the user's existing pages. Built and maintained by Momentic.
version: 1.0.0
---

# content-brief

Most "AI content briefs" are dressed-up SERP scrapes — they tell you what's currently ranking, which is interesting but not load-bearing for AI citation. This skill anchors the brief to the same authoritative sources AI grounding systems weight heavily: Wikipedia (canonical structure), Wikidata (entity graph), and the live citation surface from the agent's own web search.

The result: a brief structured around **what AI systems consider the canonical shape of the topic**, cross-referenced with **what's actually being cited right now**, gap-analyzed against **the user's existing corpus**.

## Prerequisites

- Server: `https://momenticmarketing.com/mcp`
- Tools used: `lookup_entity`, `analyze_page`, `parse_freshness_signals` (optional, see Step 6)
- Agent capability needed: web search (Claude WebSearch, Perplexity native, ChatGPT browse) and HTTP fetch

## Process

### Step 1 — Identify the target

Get from the user:
- **Target query** or **target topic** ("how to set up Postgres replication", "best espresso machines under $500", "what is glycemic load")
- **User's domain** (for gap analysis)
- Optional: known competitors, target reader (technical / general / marketer / etc.)

### Step 2 — Resolve the canonical entity

For most queries, there's an entity at the heart. Call `lookup_entity({ name: '<topic-as-entity>' })`:

- "Postgres replication" → resolves to the Postgres entity, replication is a sub-topic
- "best espresso machines under $500" → resolves to the espresso machine entity (commercial intent layered on top)
- "glycemic load" → resolves directly to that entity

If the topic doesn't have a Wikidata entity (rare for technical/medical topics, common for brand-specific or hyper-local topics), skip to Step 3 and note: "no canonical entity available; brief will be query-fanout-driven instead of structure-driven."

### Step 3 — Capture the canonical structure

If you have a resolved entity:

1. From `wikipediaSections`: this is the **canonical sub-topic structure** as established by editorial consensus. Take the level-2 sections (the H2-equivalents) as the suggested H2 outline for the brief. Include level-3 headings as suggested sub-sections.
2. From `instanceOf`: this drives the schema recommendation (e.g. `Drug`, `SoftwareApplication`, `Person`, `Organization`).
3. From `wikipedia.summary`: this is the canonical one-paragraph description. Write one yourself but use this as a sanity check.
4. From related Wikidata claims (if you call `lookup_entity` and walk the response): named entities to mention (founders, parent companies, related concepts).

### Step 4 — Live citation snapshot via agent web search

Use your web search to capture **what's actually surfacing right now** for the target query:

1. The user's **target query**, exact phrasing
2. **Three to five fan-out variants** per the framework — for a query like "best espresso machines under $500", expand to:
   - "best espresso machines 2026"
   - "espresso machine reviews under 500"
   - "top rated espresso machines"
   - "espresso machine guide"
   - "<brand> espresso machine review" (for top brands)

For each query, capture the top 5 result URLs and titles.

Deduplicate. You should now have ~10–20 unique URLs that are surfacing for the topic.

### Step 5 — Structural analysis of the top sources

For each of the top ~10 unique URLs, call `analyze_page(url)`:

- Capture: title, meta description, H1, H2 count, H3 count, schema types, word count, internal/external link counts
- The H2 hierarchy of the top sources, aggregated, tells you **the working consensus on how this topic should be structured** — distinct from the Wikipedia structure (which is editorial) but useful as a real-world cross-check

Compare:
- Where do the top sources structurally agree with Wikipedia?
- Where do they diverge? (Often: top sources skew toward commercial/practical, Wikipedia toward foundational. Both matter.)
- What schema do the top sources use? (Most use `Article`/`Review`/`HowTo` — match or beat them.)

### Step 6 — Freshness layer (optional but recommended)

For each top source URL, you have its HTML from the fetch. Call `parse_freshness_signals({ html, url })`:

- Captures `dateModified`/`datePublished` from JSON-LD, OG, visible text
- The freshest sources are the ones grounding systems are likely to weight currently
- Note which sub-topics the freshest sources are emphasizing — those are the **freshness-weighted priorities** for the brief

### Step 7 — Gap analysis against the user's corpus

Pull the user's site sitemap (via `analyze_site`) or ask the user for their relevant existing URLs. For each existing page that touches the topic, call `analyze_page(url)` to see what they cover.

Compare against the canonical Wikipedia structure + top-source consensus structure:

- ✓ Sub-topics the user already covers
- ✗ Sub-topics the user is missing
- ⚠ Sub-topics the user covers superficially (low word count, missing schema, missing entities)

### Step 8 — Synthesize the brief

Output structure:

```
# Content Brief: <target query>

**Target query:** <query>
**Canonical entity:** <Wikidata QID + label>, <instanceOf>
**Recommended schema type:** <type from Wikidata instanceOf or top-source consensus>
**Audit date:** <YYYY-MM-DD>

## Reader

<inferred from query intent: commercial / informational / navigational / mixed>
<reader sophistication: technical / general / marketer / etc.>

## Outline (H2 structure)

<numbered list. Each H2 sourced from Wikipedia level-2 sections, intersected with top-source H2 consensus, ordered by priority. For each: a one-sentence "what to cover" note.>

## Must-cover entities

<entities sourced from Wikidata claims + frequent mentions in top sources. Each with a sameAs URL where applicable, so the writer can mention with full entity-graph alignment.>

## Recommended schema markup

<paste-ready JSON-LD outline based on instanceOf type>

## Live citation snapshot

The top 10 URLs currently surfacing for <query> + variants:

| URL | Title | Word count | Schema | Date modified |
|---|---|---|---|---|
| ... |

Patterns:
- <observation about average length, common schema, common structure>
- <freshness pattern: are top sources updated frequently or set-and-forget?>

## Gap analysis vs. user corpus

User has: <existing relevant pages, with one-line state>
User is missing: <specific sub-topics, ranked by freshness-weighted priority>

## Suggested word count

<X> — derived from average top-source word count plus a 10–20% premium for depth advantage.

## Suggested internal links to add

<For each existing user page that's adjacent: "Link from <X> with anchor '<anchor>' once the new piece publishes.">

## What was NOT covered

<Explicit list: surfaces I couldn't fetch, languages I skipped, brand-specific topics with no Wikidata anchor, etc.>
```

## Notes for the agent

- **Wikipedia first, top-source consensus second.** When the two structures conflict, lead with Wikipedia (it's the editorial canonical) but preserve the top-source patterns as a "what is currently being rewarded by retrieval" overlay. Don't choose one; surface both.
- **Don't pad the outline.** If the topic has 4 canonical sub-topics, the brief has 4 H2s. Briefs full of inflated outlines produce inflated content that fails Stage 5 (Information Gain) in the GEO ladder.
- **Anchor entities to their sameAs.** Every named entity in the must-cover list should come with the canonical URL (Wikipedia or official source). The writer can then use that URL as an outbound link, which is a Stage 4 (Trustworthy) signal.
- **Freshness optional but valuable.** If the user has tight time, skip Step 6. But for any "best X 2026" or recency-sensitive query, freshness analysis is what tells you whether the topic needs annual refresh treatment.
- **No Wikidata entity? Don't fabricate.** Fall back to query-fanout-driven structure: take the 5 fan-out variants, examine the H2 patterns of the top sources for each, derive the brief outline from the union. Note in the brief that the structure is empirical (top-source-derived) rather than canonical (Wikipedia-derived).
- **Pair with `schema-recommender`** for the JSON-LD generation — it has the full set of paste-ready payloads.
- **Pair with `geo-aeo-readiness`** post-publish to verify the new piece passes Extractability and is fresh.