SEO Content Briefs skill for Codex

A good brief lets a writer who has never seen the SERP produce a page that deserves to outrank it. It states the reader, the intent, the angle nobody else covers, the must-cover subtopics with reasons, the evidence to collect, and how the draft will be judged. It never sets a target word count or keyword density.

Inputs

• Primary keyword or cluster (from keyword-research), target URL (new or existing), audience, product context, and the conversion goal of the page.
• Top 5–10 organic results for the primary query. Reading SERPs needs network access and varies by location; if Codex cannot fetch them, ask the user for URLs or pasted content and note the brief’s reliance on that sample.
• Search Console queries for the existing URL, if updating a page.
• Internal sources: product docs, support tickets, sales FAQs, customer data, subject matter experts the team can interview. These are where information gain comes from.

Respect copyright when analysing competitors: summarize structure and coverage; never paste their text into the brief.

Workflow

- [ ] 1. Intent and format verdict
- [ ] 2. SERP teardown table
- [ ] 3. Coverage matrix: what all, most and few results cover
- [ ] 4. Angle and information gain
- [ ] 5. Outline
- [ ] 6. Evidence, examples, expert input
- [ ] 7. Links, metadata, schema
- [ ] 8. Acceptance criteria

1. Intent and format verdict

State in one line: dominant intent, winning format (step-by-step guide, comparison table, template + explanation, tool, glossary entry), and what the searcher needs to be able to do after reading. If the SERP is mixed, say which slice you are targeting.

2. SERP teardown

#	URL	Type	Angle	Strengths	Weaknesses	Freshness
1	vendor.com/guide	Guide	Beginner overview	Clear steps, screenshots	No config examples	2026-03
2	forum thread	UGC	Real problems	Edge cases from users	Unstructured	2025-11

Also note SERP features (AI Overview, People Also Ask, video, images, forums). A forum result in the top 5 signals that searchers want lived experience the guides lack.

3. Coverage matrix

List subtopics across results and mark how many cover each:

• Table stakes (covered by most top results): must be in the draft.
• Differentiators (covered by one or two): include when they serve the intent.
• Gaps (covered by none, but asked in PAA, forums, support tickets): the information gain candidates.

4. Angle

Write the angle as one sentence that a competitor could not truthfully write. Sources of real information gain: first-party data, tested results, original screenshots or code, expert quotes, a decision framework, templates, cost/time numbers, failure cases. “More comprehensive” is not an angle.

5. Outline

• H1 and 2–3 title options (title rules are in on-page-seo).
• An answer-first intro spec: what must be said in the first two sentences.
• H2s in reader order, each with: purpose, key points, the evidence it needs, and an estimate of depth (a paragraph, a table, a full procedure).
• Mark which section answers each People Also Ask or support-ticket question.
• End with the next step that ties to the conversion goal, without turning the article into an ad.

6. Evidence and inputs

List exactly what the writer must obtain, and from whom:

• Data points with sources (first-party metrics, official docs, standards).
• Screenshots, code samples or configs that must be tested before publishing.
• SME interview questions (3–6), named owner and deadline.
• Claims that need citations; prefer primary sources.

7. Links, metadata, schema

• 3–6 internal links out (to deeper or next-step pages) with suggested anchors; 2–4 existing pages that should link in to this one. See internal-linking.
• Meta description draft, URL slug (short, stable, no dates unless the page is dated by nature).
• Structured data type if applicable (Article/BlogPosting, Product). FAQ markup earns no rich result now; do not ask for it.

8. Acceptance criteria

Checks an editor can tick before publishing:

• Answers the core question in the first 150 words.
• Every table-stakes subtopic present; at least one information-gain element delivered with evidence.
• All code/commands tested; versions stated.
• Named author with relevant experience; facts cited.
• No sections written only to include a keyword.

Gotchas

• Briefs that copy the top result’s H2s produce a page that is a remix, which is exactly what Google’s helpful content guidance describes as unhelpful. Use competitors to find table stakes, then add what they lack.
• Word count targets from tools reflect the average of current results, not what the reader needs; they lead to padding.
• Briefing one page for a cluster that has two intents splits the article. Go back to clustering instead.
• Fresh SERPs change; date the brief and the SERP sample.
• If the honest answer to the query is short, brief a short page. A glossary entry can rank with 300 words if it is the best answer.

Output template

# Brief: How to set up PgBouncer for Postgres
**Target:** new page /guides/pgbouncer-setup · **Primary:** pgbouncer setup
**Supporting:** pgbouncer config example, pgbouncer pool_mode, pgbouncer transaction mode
**Reader:** backend engineer hitting connection limits on managed Postgres
**Intent/format:** informational, step-by-step guide with tested config (8/10 results)
**Goal:** reader runs a working PgBouncer in transaction mode; CTA to our managed pooling
**SERP sample:** 2026-10-28, google.com, US, desktop

## Angle
Benchmarked pool sizes on Postgres 17 with our own load test, plus the prepared statement
breakage and how each driver handles it in 2026.

## Table stakes / differentiators / gaps
...

## Outline
H1: How to Set Up PgBouncer for Postgres Connection Pooling
Intro: state the one-line answer (transaction pooling in front of Postgres, config below).
H2 When you need a pooler (short; with connection-count math)
H2 Install and minimal pgbouncer.ini (tested config block)
H2 Choosing pool_mode (table: session vs transaction vs statement)
H2 Sizing default_pool_size (formula + our benchmark chart)
H2 Prepared statements in transaction mode (driver table)
H2 Monitoring with SHOW POOLS
H2 Next step: managed pooling (one paragraph)

## Evidence needed
- Benchmark results (owner: Priya, by Nov 4)
- Driver behaviour table verified against current docs

## Links
Out: /docs/connection-limits, /blog/postgres-17-upgrade · In: /postgres/performance

## Metadata
Title options ×3 · Meta draft · Slug: /guides/pgbouncer-setup · Schema: Article

## Acceptance criteria
[checklist from step 8]