Semantec SEO

48 Content Brief Workflow Prompts for MIRENA

Use Content Brief Workflow prompts when MIRENA needs to turn strategy into writer-ready instructions.

This workflow defines what a page must include, avoid, prove, link to, format, and hand off before drafting starts.

Start with source context.

Do not create a brief from a loose keyword, topic, URL, competitor page, or map item until MIRENA knows the site, offer, audience, allowed topics, blocked topics, page role, internal link rules, proof needs, and next workflow stage.

Use the source context template before this workflow if the project base is not ready. Use Getting Started with MIRENA if you need the full onboarding route first.

Start with Source Context Before Creating a Brief

Source context controls the brief.

It tells MIRENA what the site is, who it serves, what it sells, which topics belong, which topics are blocked, which pages already exist, which routes support the offer, and which workflow should come next.

A brief can fail if it starts from a keyword, competitor page, or title alone. The page may look useful, but still drift away from the site’s offer, repeat another page, miss the user job, or ask the writer to cover topics that belong somewhere else.

The Source Context page explains how source context protects topical focus before pages enter production.

Use source context to define:

  • site purpose
  • audience
  • offer
  • region
  • allowed topics
  • blocked topics
  • page role
  • protected pages
  • internal link targets
  • commercial routes
  • proof routes
  • support routes
  • comparison routes
  • writing constraints
  • output format
  • next workflow stage

When source context is missing, stop and build it first.

What Content Brief Workflows Do

Content Brief Workflows turn approved strategy into page instructions.

They do not collect raw discovery evidence.

They do not build the topical map.

They do not replace behavioral mapping.

They do not replace entity SEO.

They do not draft the page.

They define the brief before writing begins.

The output can feed Drafting + Rewriting when the page is ready for production. It can feed semantic internal linking when the brief includes link requirements. It can feed information gain work when the page needs stronger differentiation. It can support Content Briefs when users need a full brief workflow for new pages, rewrites, refreshes, docs, comparisons, and use case pages.

Use MIRENA outputs when you need to define what the final brief package should return.

A strong brief should tell the writer:

  • why the page exists
  • who the page serves
  • which user job it must solve
  • which role the page plays
  • which intent it targets
  • which topics belong
  • which topics are blocked
  • which sections are required
  • what each heading should do
  • which proof is needed
  • which examples are needed
  • which tables or FAQs are needed
  • which internal links must appear
  • how anchor text should guide users
  • which SERP formats the page should support
  • which schema cues can be prepared after draft approval
  • which tone, style, and blocked term rules apply
  • which workflow should receive the approved brief

What This Page Does Not Repeat

This page does not repeat Raw Semantic Discovery prompts.

Raw Semantic Discovery collects candidates, modifiers, query paths, SERP patterns, competitor signals, and opportunity notes.

This page starts after that evidence exists.

This page does not repeat Topical Maps + Planning prompts. Topical Mapping and Site Architecture decides pages, page roles, hierarchy, publishing order, and overlap controls.

This page does not repeat Behavioral Mapping and User Path prompts. Behavioral Mapping defines user state, journey stage, friction, trust, effort, and next paths.

This page also does not repeat Entity SEO prompts. Entity SEO handles entity meaning, salience, placement, relationships, and support cues.

Content Brief Workflows use those outputs as evidence, then turn them into writing instructions.

Use this page when the job is page briefing, rewrite briefing, refresh briefing, docs briefing, comparison briefing, section requirements, heading requirements, proof requirements, internal link requirements, SERP targets, information gain requirements, writing constraints, QA, approval, or drafting handoff.

Use Semantic SEO when the brief also needs stronger meaning, context, and topic fit.

When to Use Content Brief Workflow Prompts

Use this prompt collection when a page needs instructions before drafting or rewriting.

Content Brief Workflows are useful for:

  • new page briefs
  • rewrite briefs
  • refresh briefs
  • docs briefs
  • use case briefs
  • comparison briefs
  • product briefs
  • service briefs
  • support briefs
  • local or market briefs
  • multi-audience briefs
  • page purpose setup
  • page role setup
  • user job definition
  • search intent definition
  • SERP format planning
  • information gain planning
  • user gain planning
  • section requirements
  • heading requirements
  • answer targets
  • snippet targets
  • FAQ planning
  • table and comparison planning
  • proof and evidence planning
  • examples and templates
  • UX component planning
  • internal link requirements
  • anchor instructions
  • CTA and next step guidance
  • drafting constraints
  • tone and style rules
  • readability rules
  • source and citation rules
  • schema cue notes after draft approval
  • brief QA
  • brief approval
  • drafting handoff

Use MIRENA inputs when you need to decide which files should feed the brief. Use the MIRENA workflow when the approved brief needs a clear route into drafting, rewriting, internal linking, information gain, SERP feature planning, or schema notes.

The Content Brief Workflow

Run the Content Brief Workflow in this order.

  1. Set the brief scope.
  2. Define the brief goal.
  3. Review the brief inputs.
  4. Check source context fit.
  5. Define page purpose.
  6. Define page role.
  7. Define audience and user job.
  8. Define journey stage.
  9. Define search intent.
  10. Define SERP format needs.
  11. Review competitor coverage.
  12. Set information gain requirements.
  13. Set user gain requirements.
  14. Set topic coverage limits.
  15. Add entity context notes.
  16. Define section requirements.
  17. Define heading requirements.
  18. Define answer targets.
  19. Define snippet targets.
  20. Plan FAQs.
  21. Plan tables and comparison blocks.
  22. Plan proof and evidence.
  23. Plan examples and templates.
  24. Plan UX components.
  25. Define internal link requirements.
  26. Define anchor instructions.
  27. Define CTA and next step guidance.
  28. Set drafting constraints.
  29. Set tone and style rules.
  30. Set lexicon and blocked term rules.
  31. Set readability requirements.
  32. Set source and citation requirements.
  33. Set visual and media requirements.
  34. Prepare schema cue notes after draft approval.
  35. Define what not to include.
  36. Create new page briefs.
  37. Create rewrite briefs.
  38. Create refresh briefs.
  39. Create consolidation briefs.
  40. Create docs briefs.
  41. Create use case briefs.
  42. Create comparison briefs.
  43. Create product or service briefs.
  44. Create local or market briefs.
  45. Create multi-audience briefs.
  46. Run brief QA.
  47. Approve the brief.
  48. Hand off the brief.

Do not move into drafting, rewriting, internal link implementation, SERP feature work, or schema cue work if page purpose, section requirements, proof needs, link requirements, source context fit, or approval status are unresolved.

The Content Brief Prompt Pattern

Use short commands when the task is clear.

Use expanded prompts when the brief needs fields, constraints, evidence, section rules, link requirements, proof rules, tone rules, and workflow routing.

Short command pattern:

code

Run [content brief module] for [page or topic].

Expanded prompt pattern:

code

Run [content brief module] for [page or topic].

Use the source context first.

Use the approved map, raw discovery output, behavioral notes, entity notes, SERP notes, internal link plan, analytics notes, or existing URL only as evidence.

Do not draft the page.

Return the output with these fields:
- page title
- URL or proposed URL
- page role
- target user
- user job
- primary intent
- section requirements
- proof requirements
- internal link requirements
- SERP targets
- information gain requirements
- writing constraints
- blocked items
- next workflow route

Flag anything that needs review before drafting.

Route the final output into Drafting and Rewriting, Internal Linking, Information Gain, SERP Feature Planning, Schema Cues after approval, or Brief Approval.

A short prompt is enough for a simple brief task.

An expanded prompt is better when the input is large, messy, risky, or ready for handoff.

What to Give MIRENA Before Running a Content Brief Workflow

Start with source context.

Then add the strongest evidence available.

For a new page brief, give MIRENA:

  • source context
  • approved map item
  • proposed page title
  • proposed URL
  • page role
  • target user
  • user job
  • search intent
  • internal link targets
  • SERP notes if available
  • proof assets if available

For a rewrite brief, give MIRENA:

  • source context
  • existing URL
  • current page copy
  • page role
  • target page role
  • rewrite goal
  • current internal links
  • desired internal links
  • performance notes if available
  • sections to protect
  • sections to revise
  • sections to remove

For a refresh brief, give MIRENA:

  • source context
  • existing page
  • GSC page data
  • GSC query data
  • GA4 landing page data
  • content crawl notes
  • SERP changes
  • information gain notes
  • proof updates
  • internal link updates
  • sections to protect

For a docs brief, give MIRENA:

  • source context
  • product or workflow context
  • user task
  • prerequisite knowledge
  • inputs needed
  • expected output
  • support route
  • fallback route
  • related docs pages
  • screenshots or examples if available

For a comparison brief, give MIRENA:

  • source context
  • comparison topic
  • options compared
  • buyer question
  • decision criteria
  • proof assets
  • product route
  • conversion route
  • information gain notes
  • internal link targets

For a content brief using user path notes, give MIRENA:

  • source context
  • behavioral output
  • user state
  • journey stage
  • friction notes
  • proof needs
  • effort notes
  • next best path
  • fallback path
  • CTA notes
  • monitoring notes if available

Use anchor text by intent when anchor wording is part of the brief. Use rewrite for internal links when the brief prepares an existing page for stronger link paths.

Content Brief Workflow Modules

The modules below turn strategy into approved writer instructions before drafting or rewriting starts.

Choose the smallest module that fits the job.

1. Brief Scope

Use this to define the boundary of the brief.

Short command:

code

Run Brief Scope for this page.

Expanded prompt:

code

Run Brief Scope for this page.

Use the source context first.

Define the boundary of the content brief before page instructions are created.

Return the output with these fields:
- page or topic being briefed
- proposed URL
- page type
- page role
- target audience
- allowed topic lanes
- blocked topic lanes
- source inputs to use
- source inputs to ignore
- next workflow route

Do not draft the page.

Reject topics that do not fit the source context.

Flag missing inputs before the brief continues.

Route the output into Brief Goal or Brief Input Review.

Best for:

  • new page briefs
  • rewrite briefs
  • broad topics
  • agency briefs
  • page requests without enough context

Output should include:

  • page or topic
  • proposed URL
  • page role
  • allowed topics
  • blocked topics
  • next route

Use this to:

Keep the brief focused before instructions expand.

Brief Scope prevents the page from trying to serve too many jobs.

2. Brief Goal

Use this to define what the brief must achieve.

Short command:

code

Run Brief Goal for this page.

Expanded prompt:

code

Run Brief Goal for this page.

Use the source context first.

Define the primary job of the brief.

Choose one main goal:
- new page brief
- rewrite brief
- refresh brief
- docs brief
- use case brief
- comparison brief
- product brief
- service brief
- support brief
- information gain brief
- SERP feature brief
- internal link brief

Return the output with these fields:
- primary brief goal
- secondary goals
- page role
- page type
- success criteria
- evidence needed
- risks before drafting
- next workflow route

Do not combine too many brief goals in one pass.

Route the output into Brief Input Review or Page Purpose Brief.

Best for:

  • unclear page requests
  • mixed-purpose pages
  • content operations
  • rewrite planning
  • editorial handoff

Output should include:

  • primary brief goal
  • page type
  • success criteria
  • evidence needed
  • next route

Use this to:

Stop the brief from becoming unclear or too broad.

A docs brief, rewrite brief, and comparison brief need different instructions.

3. Brief Input Review

Use this when the brief has several inputs.

Short command:

code

Run Brief Input Review on these files.

Expanded prompt:

code

Run Brief Input Review on these files.

Use the source context first.

Review the files, URLs, exports, map items, discovery output, behavior notes, internal link plans, SERP notes, and previous MIRENA outputs that may feed the brief.

Return the output with these fields:
- input name
- input type
- source quality
- brief value
- risk
- use, hold, ignore, or review
- reason
- missing input
- next workflow route

Do not create the brief yet.

Separate inputs that should guide the brief from inputs that should be held for later workflows.

Route the output into Source Context to Brief Fit or Page Purpose Brief.

Best for:

  • multiple files
  • complex briefs
  • client source folders
  • existing URL rewrites
  • research-heavy pages

Output should include:

  • input name
  • input type
  • brief value
  • use or hold decision
  • missing input
  • next route

Use this to:

Select the right evidence before brief requirements are written.

Weak or off-scope inputs should not shape the writer’s instructions.

4. Source Context to Brief Fit

Use this to check if the page belongs in the site.

Short command:

code

Run Source Context to Brief Fit for this page.

Expanded prompt:

code

Run Source Context to Brief Fit for this page.

Use the source context first.

Check if the page target fits the site, offer, audience, allowed topics, blocked topics, and workflow goal.

Return the output with these fields:
- page or topic
- source context fit
- audience fit
- offer fit
- topic fit
- risk
- keep, revise, merge, hold, or block
- reason
- required source context update
- next workflow route

Do not brief a page that fails source context fit.

Route the output into Page Purpose Brief or Brief Approval.

Best for:

  • proposed new pages
  • keyword-led topics
  • competitor-led topics
  • client requests
  • risky page ideas

Output should include:

  • source context fit
  • audience fit
  • offer fit
  • keep or block decision
  • next route

Use this to:

Prevent off-scope pages from entering drafting.

A page that does not fit the site should be revised, merged, held, or blocked.

5. Page Purpose Brief

Use this to define the page’s core job.

Short command:

code

Run Page Purpose Brief for this page.

Expanded prompt:

code

Run Page Purpose Brief for this page.

Use the source context first.

Define the page’s primary purpose before section instructions are created.

Return the output with these fields:
- page title
- proposed URL
- primary purpose
- secondary support purpose
- user job
- page role
- conversion or support route
- success criteria
- next workflow route

Flag pages with too many jobs.

Do not draft the page.

Route the output into Page Role Brief, Audience and User Job Brief, or Search Intent Brief.

Best for:

  • new page briefs
  • unclear titles
  • map handoff
  • rewrite planning
  • brief QA

Output should include:

  • page title
  • primary purpose
  • user job
  • page role
  • next route

Use this to:

Give the page one clear job before writing starts.

A brief with a clear purpose is easier to outline, write, link, and review.

6. Page Role Brief

Use this to define how the page functions in the site.

Short command:

code

Run Page Role Brief for this page.

Expanded prompt:

code

Run Page Role Brief for this page.

Use the source context first.

Assign the page role and explain how it supports the site architecture.

Use roles such as hub, spoke, support, bridge, proof, docs, comparison, use case, template, example, product, service, pricing support, or conversion support.

Return the output with these fields:
- page
- page role
- role reason
- parent page
- support pages
- sibling pages
- internal link direction
- CTA route
- next workflow route

Flag unclear page roles.

Route the output into Section Requirements Brief or Internal Link Requirements Brief.

Best for:

  • approved map items
  • site architecture handoff
  • internal link planning
  • content briefs
  • rewrite briefs

Output should include:

  • page role
  • role reason
  • parent page
  • support pages
  • next route

Use this to:

Make the brief reflect the page’s role in the site.

Page role guides sections, links, CTA timing, and proof needs.

7. Audience and User Job Brief

Use this to define who the page serves and what they need to do.

Short command:

code

Run Audience and User Job Brief for this page.

Expanded prompt:

code

Run Audience and User Job Brief for this page.

Use the source context first.

Define the target audience, user job, user state, pain, question, task, and desired next step.

Return the output with these fields:
- target audience
- user state
- user job
- main question
- pain or need
- knowledge level
- desired outcome
- next step
- next workflow route

Flag audience groups that need separate pages or sections.

Route the output into Journey Stage Brief, Search Intent Brief, or UX Component Brief.

Best for:

  • user-led pages
  • use case pages
  • docs pages
  • product pages
  • comparison pages

Output should include:

  • target audience
  • user state
  • user job
  • main question
  • next route

Use this to:

Make the brief user-led, not keyword-led.

The writer should know what the reader is trying to do.

8. Journey Stage Brief

Use this when the page needs stage-aware instructions.

Short command:

code

Run Journey Stage Brief for this page.

Expanded prompt:

code

Run Journey Stage Brief for this page.

Use the source context first.

Define where the page sits in the user journey and what that means for content, proof, internal links, CTAs, and fallback paths.

Return the output with these fields:
- journey stage
- user state
- stage reason
- proof need
- comparison need
- support need
- CTA timing
- fallback path
- next workflow route

Do not push conversion if the user needs proof, comparison, or support first.

Route the output into CTA and Next Step Brief or Internal Link Requirements Brief.

Best for:

  • behavioral briefs
  • conversion pages
  • support pages
  • comparison pages
  • onboarding docs

Output should include:

  • journey stage
  • proof need
  • CTA timing
  • fallback path
  • next route

Use this to:

Set the right timing for proof, links, and CTAs.

Journey stage helps the writer avoid pushing the reader too early.

9. Search Intent Brief

Use this to define the intent target.

Short command:

code

Run Search Intent Brief for this page.

Expanded prompt:

code

Run Search Intent Brief for this page.

Use the source context first.

Define the primary search intent, secondary intent, query class, user job, and page type.

Return the output with these fields:
- primary intent
- secondary intent
- query examples
- user job
- page type
- content treatment
- SERP format notes
- intent risks
- next workflow route

Flag mixed intent.

Do not force one page to satisfy conflicting intents.

Route the output into SERP Format Brief or Section Requirements Brief.

Best for:

  • keyword-led briefs
  • SERP-driven pages
  • new pages
  • rewrites
  • refresh briefs

Output should include:

  • primary intent
  • secondary intent
  • page type
  • content treatment
  • next route

Use this to:

Make the page plan follow intent before headings are set.

A page with mixed intent needs review before drafting.

10. SERP Format Brief

Use this when the brief needs SERP-aware formatting.

Short command:

code

Run SERP Format Brief for this page.

Expanded prompt:

code

Run SERP Format Brief for this page.

Use the source context first.

Define the SERP formats the brief should support.

Return the output with these fields:
- SERP target
- answer format
- paragraph snippet need
- ordered list need
- table need
- FAQ need
- comparison block need
- PAA angle
- risk note
- next workflow route

Do not add SERP blocks that weaken the page experience.

Route the output into Snippet Target Brief, FAQ Brief, Table and Comparison Brief, or SERP Feature Planning.

Best for:

  • snippet targets
  • FAQ planning
  • comparison pages
  • list style answers
  • SERP feature planning

Output should include:

  • SERP target
  • answer format
  • table need
  • FAQ need
  • next route

Use this to:

Prepare page formatting before drafting begins.

SERP format should support the reader, not only extraction.

11. Competitor Coverage Brief

Use this when competitor or SERP notes should influence the brief.

Short command:

code

Run Competitor Coverage Brief for this page.

Expanded prompt:

code

Run Competitor Coverage Brief for this page.

Use the source context first.

Use competitor and SERP notes as evidence only.

Return the output with these fields:
- common coverage
- overused coverage
- missing coverage
- useful differentiation
- proof patterns
- format patterns
- sections to include
- sections to avoid
- next workflow route

Do not copy competitor structure or wording.

Route the output into Information Gain Brief or Section Requirements Brief.

Best for:

  • SERP-heavy briefs
  • comparison pages
  • commercial pages
  • refresh briefs
  • information gain planning

Output should include:

  • common coverage
  • overused coverage
  • missing coverage
  • useful differentiation
  • next route

Use this to:

Learn from the SERP without turning the brief into imitation.

Competitor findings should shape evidence and gaps, not copy.

12. Information Gain Brief

Use this when the page needs useful differentiation.

Short command:

code

Run Information Gain Brief for this page.

Expanded prompt:

code

Run Information Gain Brief for this page.

Use the source context first.

Define how the page should add value beyond common SERP coverage.

Return the output with these fields:
- repeated SERP coverage
- weak existing coverage
- unique angle
- useful addition
- original example
- proof need
- section placement
- risk note
- next workflow route

Do not add novelty that does not help the user.

Route the output into Section Requirements Brief, Proof and Evidence Brief, or Information Gain.

Best for:

  • repetitive SERPs
  • content refresh
  • comparison pages
  • thought leadership pages
  • new page briefs

Output should include:

  • repeated coverage
  • unique angle
  • useful addition
  • proof need
  • next route

Use this to:

Make differentiation useful, not decorative.

Use information gain work when the page needs stronger differentiation.

13. User Gain Brief

Use this when the page must be useful as well as complete.

Short command:

code

Run User Gain Brief for this page.

Expanded prompt:

code

Run User Gain Brief for this page.

Use the source context first.

Define the practical user value the page must deliver.

Return the output with these fields:
- user benefit
- task helped
- decision helped
- effort reduced
- trust supported
- next step improved
- section requirement
- component requirement
- next workflow route

Flag sections that are complete but not useful.

Route the output into UX Component Brief, Section Requirements Brief, or Drafting and Rewriting.

Best for:

  • dense pages
  • how-to pages
  • docs pages
  • decision pages
  • refresh briefs

Output should include:

  • user benefit
  • task helped
  • effort reduced
  • trust supported
  • next route

Use this to:

Make the brief serve the user’s task, not only the topic.

User gain helps a page become easier to use.

14. Topic Coverage Brief

Use this to define the topic boundaries of the page.

Short command:

code

Run Topic Coverage Brief for this page.

Expanded prompt:

code

Run Topic Coverage Brief for this page.

Use the source context first.

Define which topics belong in the page and which topics should be excluded, moved, linked, or saved for other pages.

Return the output with these fields:
- required topic
- supporting topic
- topic to exclude
- topic to link out
- topic to move
- parent topic
- child topic
- overlap risk
- next workflow route

Do not turn the brief into a topical map.

Route the output into Section Requirements Brief or Internal Link Requirements Brief.

Best for:

  • broad topics
  • hub pages
  • comparison pages
  • content refresh
  • pages with overlap risk

Output should include:

  • required topic
  • supporting topic
  • excluded topic
  • link out topic
  • next route

Use this to:

Keep the page focused while giving it enough depth.

Topic coverage rules prevent drift and overlap.

15. Entity Context Brief

Use this when entity notes need to inform the brief without repeating entity SEO.

Short command:

code

Run Entity Context Brief for this page.

Expanded prompt:

code

Run Entity Context Brief for this page.

Use the source context first.

Use approved entity notes as brief evidence only.

Return the output with these fields:
- primary entity
- supporting entities
- entity clarification need
- entity relationship note
- entity usage note
- section placement
- terms to avoid
- next workflow route

Do not run entity salience.

Do not create final schema.

Route the output into Section Requirements Brief, Drafting and Rewriting, or Entity SEO and Salience if deeper entity work is needed.

Best for:

  • entity-heavy pages
  • semantic SEO pages
  • product pages
  • comparison pages
  • docs pages

Output should include:

  • primary entity
  • supporting entities
  • relationship note
  • section placement
  • next route

Use this to:

Help the writer use entity notes clearly without turning the brief into an entity audit.

Use Entity SEO when deeper entity structure is needed.

16. Section Requirements Brief

Use this to define required sections.

Short command:

code

Run Section Requirements Brief for this page.

Expanded prompt:

code

Run Section Requirements Brief for this page.

Use the source context first.

Define the required sections for the brief.

Return the output with these fields:
- section name
- section purpose
- user job served
- intent served
- required points
- proof needed
- internal link need
- SERP target
- draft instruction
- next workflow route

Flag sections that are not needed.

Do not draft the sections.

Route the output into Heading Requirements Brief or Brief Approval.

Best for:

  • all full briefs
  • new pages
  • rewrites
  • docs pages
  • comparison pages

Output should include:

  • section name
  • section purpose
  • required points
  • proof need
  • next route

Use this to:

Turn strategy into a clear section plan.

Section requirements tell the writer what each part must achieve.

17. Heading Requirements Brief

Use this to define heading jobs before drafting.

Short command:

code

Run Heading Requirements Brief for this page.

Expanded prompt:

code

Run Heading Requirements Brief for this page.

Use the source context first.

Define the heading structure and job of each heading.

Return the output with these fields:
- heading level
- heading draft
- heading purpose
- section role
- target query or user job
- required answer
- internal link need
- SERP target
- next workflow route

Do not write long sections.

Flag headings that overlap or drift.

Route the output into Article Outline or Drafting and Rewriting.

Best for:

  • outlines
  • new page briefs
  • rewrite briefs
  • snippet planning
  • long guides

Output should include:

  • heading level
  • heading draft
  • heading purpose
  • required answer
  • next route

Use this to:

Make every heading earn its place.

Heading requirements prevent vague outlines.

18. Answer Target Brief

Use this when the page needs direct answers.

Short command:

code

Run Answer Target Brief for this page.

Expanded prompt:

code

Run Answer Target Brief for this page.

Use the source context first.

Define the direct answers the page must include.

Return the output with these fields:
- answer target
- question answered
- answer format
- ideal placement
- proof need
- internal link need
- risk note
- next workflow route

Keep answers clear, specific, and easy to extract.

Route the output into Snippet Target Brief, FAQ Brief, or Drafting and Rewriting.

Best for:

  • informational pages
  • PAA targets
  • docs pages
  • support pages
  • snippet planning

Output should include:

  • answer target
  • question answered
  • format
  • placement
  • next route

Use this to:

Make key answers easy for readers and search systems to understand.

Answer targets should be written before the draft begins.

19. Snippet Target Brief

Use this when the page targets paragraph, list, or table snippets.

Short command:

code

Run Snippet Target Brief for this page.

Expanded prompt:

code

Run Snippet Target Brief for this page.

Use the source context first.

Define snippet-ready blocks for the page.

Return the output with these fields:
- snippet target
- snippet type
- target question
- answer length guidance
- section placement
- supporting detail
- risk note
- next workflow route

Use paragraph, ordered list, unordered list, table, or definition formats where they fit the user need.

Route the output into Drafting and Rewriting or SERP Feature Planning.

Best for:

  • paragraph snippets
  • list snippets
  • definition blocks
  • table snippets
  • SERP feature planning

Output should include:

  • snippet target
  • snippet type
  • target question
  • placement
  • next route

Use this to:

Prepare extractable answers before drafting starts.

Snippet planning should also serve the reader on the page.

20. FAQ Brief

Use this when FAQs should be planned before writing.

Short command:

code

Run FAQ Brief for this page.

Expanded prompt:

code

Run FAQ Brief for this page.

Use the source context first.

Plan FAQs that serve real user questions and support the page’s role.

Return the output with these fields:
- FAQ question
- answer intent
- user state
- journey stage
- answer requirement
- internal link need
- schema cue eligibility after approval
- risk note
- next workflow route

Do not add filler FAQs.

Route the output into Drafting and Rewriting or Schema Cues after approval.

Best for:

  • PAA planning
  • support pages
  • product pages
  • comparison pages
  • docs pages

Output should include:

  • FAQ question
  • answer intent
  • user state
  • answer requirement
  • next route

Use this to:

Add FAQs that help the page, not just the SERP.

FAQ entries should answer real follow-up questions.

21. Table and Comparison Brief

Use this when the page needs a table or comparison block.

Short command:

code

Run Table and Comparison Brief for this page.

Expanded prompt:

code

Run Table and Comparison Brief for this page.

Use the source context first.

Define table, comparison, checklist, or decision block requirements.

Return the output with these fields:
- block type
- comparison need
- criteria
- rows
- columns
- source evidence
- proof requirement
- placement
- next workflow route

Do not create a table if prose is clearer.

Route the output into Drafting and Rewriting or Information Gain.

Best for:

  • comparison pages
  • buyer guides
  • decision pages
  • docs pages
  • feature pages

Output should include:

  • block type
  • criteria
  • rows
  • columns
  • placement

Use this to:

Help users compare, choose, or act faster.

A table should reduce effort, not add clutter.

22. Proof and Evidence Brief

Use this when the page needs support for claims.

Short command:

code

Run Proof and Evidence Brief for this page.

Expanded prompt:

code

Run Proof and Evidence Brief for this page.

Use the source context first.

Define what proof, evidence, examples, methodology, screenshots, data, reviews, author notes, policy notes, or case notes are needed.

Return the output with these fields:
- claim or section
- proof needed
- evidence source
- evidence gap
- placement
- risk if missing
- next workflow route

Flag unsupported claims.

Route the output into Drafting and Rewriting, Information Gain, or Brief Approval.

Best for:

  • commercial pages
  • comparison pages
  • product pages
  • service pages
  • trust-heavy pages

Output should include:

  • claim or section
  • proof needed
  • evidence source
  • evidence gap
  • next route

Use this to:

Give the writer proof requirements before claims are written.

Unsupported claims should be removed, revised, or held.

23. Example and Template Brief

Use this when the page needs practical examples or copyable assets.

Short command:

code

Run Example and Template Brief for this page.

Expanded prompt:

code

Run Example and Template Brief for this page.

Use the source context first.

Plan examples, templates, prompt blocks, checklists, mini workflows, or copyable assets that support the user job.

Return the output with these fields:
- asset type
- user job served
- placement
- required content
- proof or source need
- internal link need
- lead value
- next workflow route

Do not add assets that distract from the page role.

Route the output into Drafting and Rewriting or Content Briefs.

Best for:

  • templates
  • prompt packs
  • docs pages
  • how-to pages
  • examples pages

Output should include:

  • asset type
  • user job served
  • placement
  • required content
  • next route

Use this to:

Make the page more usable and action-ready.

Examples and templates should support the page purpose.

24. UX Component Brief

Use this when the page needs structure that reduces effort.

Short command:

code

Run UX Component Brief for this page.

Expanded prompt:

code

Run UX Component Brief for this page.

Use the source context first.

Plan components that reduce effort, support trust, clarify choices, or guide next steps.

Use components such as:
- summary box
- checklist
- comparison table
- decision aid
- proof block
- example block
- process steps
- FAQ block
- support block
- CTA block

Return the output with these fields:
- component type
- purpose
- placement
- user state served
- friction reduced
- proof supported
- draft instruction
- next workflow route

Route the output into Drafting and Rewriting.

Best for:

  • long pages
  • comparison pages
  • docs pages
  • support pages
  • decision pages

Output should include:

  • component type
  • purpose
  • placement
  • user state served
  • next route

Use this to:

Turn user path needs into brief requirements.

UX components should make the page easier to understand and use.

25. Internal Link Requirements Brief

Use this when the brief needs link instructions.

Short command:

code

Run Internal Link Requirements Brief for this page.

Expanded prompt:

code

Run Internal Link Requirements Brief for this page.

Use the source context first.

Define the internal links the page should include.

Return the output with these fields:
- source page
- target page
- link purpose
- page role supported
- user path supported
- anchor direction
- placement
- priority
- next workflow route

Do not add generic links.

Route the output into Anchor Instruction Brief, Drafting and Rewriting, or Semantic Internal Linking.

Best for:

  • briefs with required links
  • hub and spoke pages
  • support pages
  • product routes
  • rewrite briefs

Output should include:

  • source page
  • target page
  • link purpose
  • anchor direction
  • placement

Use this to:

Make internal links part of the brief, not an afterthought.

Use semantic internal linking when links also need architecture and entity support.

26. Anchor Instruction Brief

Use this when anchor text needs clear guidance.

Short command:

code

Run Anchor Instruction Brief for this page.

Expanded prompt:

code

Run Anchor Instruction Brief for this page.

Use the source context first.

Define anchor direction for required internal links.

Return the output with these fields:
- target page
- anchor intent
- recommended anchor direction
- surrounding passage
- placement
- user state served
- risk note
- next workflow route

Do not write anchors that overpromise or misdescribe the target.

Route the output into Drafting and Rewriting.

Best for:

  • internal link briefs
  • rewrite briefs
  • hub pages
  • support pages
  • conversion paths

Output should include:

  • target page
  • anchor intent
  • anchor direction
  • surrounding passage
  • next route

Use this to:

Guide anchor text without forcing exact-match repetition.

Use anchor text by intent when the anchor system needs deeper planning.

27. CTA and Next Step Brief

Use this when the page needs a clear next action.

Short command:

code

Run CTA and Next Step Brief for this page.

Expanded prompt:

code

Run CTA and Next Step Brief for this page.

Use the source context first.

Define the next step, fallback path, CTA timing, CTA placement, and support path for the page.

Return the output with these fields:
- primary next step
- fallback path
- CTA purpose
- CTA placement
- user readiness
- trust need before CTA
- support need before CTA
- risk note
- next workflow route

Do not push conversion before the user has enough clarity and trust.

Route the output into Drafting and Rewriting or Behavioral Mapping.

Best for:

  • product pages
  • comparison pages
  • service pages
  • support pages
  • use case pages

Output should include:

  • primary next step
  • fallback path
  • CTA purpose
  • CTA placement
  • next route

Use this to:

Give the page a useful continuation path.

The next step should match user readiness.

28. Drafting Constraints Brief

Use this before the page moves into drafting.

Short command:

code

Run Drafting Constraints Brief for this page.

Expanded prompt:

code

Run Drafting Constraints Brief for this page.

Use the source context first.

Define writing constraints for the draft.

Return the output with these fields:
- required inclusions
- required exclusions
- section order rules
- tone rules
- style rules
- prohibited claims
- proof requirements
- internal link rules
- formatting rules
- next workflow route

Do not draft the page.

Route the output into Drafting and Rewriting.

Best for:

  • final brief prep
  • agency briefs
  • sensitive pages
  • regulated claims
  • rewrite tasks

Output should include:

  • inclusions
  • exclusions
  • tone rules
  • proof rules
  • next route

Use this to:

Set writing boundaries before the draft begins.

Drafting constraints help avoid rework.

29. Tone and Style Brief

Use this when the page needs voice rules.

Short command:

code

Run Tone and Style Brief for this page.

Expanded prompt:

code

Run Tone and Style Brief for this page.

Use the source context first.

Define the tone, voice, pacing, reading level, directness, examples, and terms the writer should use.

Return the output with these fields:
- tone
- voice
- reading level
- sentence style
- example style
- words to use
- words to avoid
- risk note
- next workflow route

Keep the tone useful, clear, and direct.

Route the output into Drafting and Rewriting.

Best for:

  • brand consistency
  • docs pages
  • comparison pages
  • commercial pages
  • onboarding pages

Output should include:

  • tone
  • voice
  • reading level
  • example style
  • next route

Use this to:

Make the draft sound consistent with the site.

Tone rules should help the writer sound clear and useful.

30. Lexicon and Blocked Terms Brief

Use this when the draft needs vocabulary controls.

Short command:

code

Run Lexicon and Blocked Terms Brief for this page.

Expanded prompt:

code

Run Lexicon and Blocked Terms Brief for this page.

Use the source context first.

Create vocabulary guidance for the draft.

Return the output with these fields:
- preferred terms
- terms to limit
- blocked terms
- replacement terms
- phrase risk
- repetition risk
- section guidance
- next workflow route

Apply the project’s blocked word list.

Route the output into Drafting and Rewriting or Brief Approval.

Best for:

  • strict voice rules
  • sensitive content
  • brand terms
  • repeated terminology
  • final brief QA

Output should include:

  • preferred terms
  • limited terms
  • blocked terms
  • replacement terms
  • next route

Use this to:

Prevent weak language, repetition, and banned terms from entering the draft.

Lexicon guidance helps the writer stay consistent.

31. Readability Brief

Use this when the page needs easier parsing.

Short command:

code

Run Readability Brief for this page.

Expanded prompt:

code

Run Readability Brief for this page.

Use the source context first.

Define readability and parsing requirements for the draft.

Return the output with these fields:
- reading level
- sentence guidance
- paragraph guidance
- list guidance
- table guidance
- summary needs
- complexity risks
- next workflow route

Keep paragraphs clear and scannable.

Route the output into Drafting and Rewriting.

Best for:

  • long guides
  • docs pages
  • technical content
  • comparison pages
  • support pages

Output should include:

  • reading level
  • sentence guidance
  • paragraph guidance
  • summary needs
  • next route

Use this to:

Make the draft easier to read and easier to parse.

Readability rules should protect clarity without removing depth.

32. Source and Citation Brief

Use this when evidence needs citation or source support.

Short command:

code

Run Source and Citation Brief for this page.

Expanded prompt:

code

Run Source and Citation Brief for this page.

Use the source context first.

Define source and citation requirements.

Return the output with these fields:
- claim type
- source needed
- source priority
- internal source
- external source
- citation note
- proof gap
- next workflow route

Flag claims that need evidence before drafting.

Route the output into Drafting and Rewriting or Brief Approval.

Best for:

  • research pages
  • comparison pages
  • product claims
  • methodology pages
  • trust-heavy pages

Output should include:

  • claim type
  • source needed
  • source priority
  • proof gap
  • next route

Use this to:

Give the writer evidence rules before claims appear.

Source requirements reduce unsupported claims during drafting.

33. Visual and Media Brief

Use this when the page needs visual support.

Short command:

code

Run Visual and Media Brief for this page.

Expanded prompt:

code

Run Visual and Media Brief for this page.

Use the source context first.

Define visual, image, diagram, screenshot, table, chart, or media needs for the page.

Return the output with these fields:
- visual type
- purpose
- placement
- user need served
- source needed
- alt text direction
- production note
- next workflow route

Do not add visuals that do not help the user.

Route the output into Drafting and Rewriting or Design Handoff.

Best for:

  • documentation
  • product walkthroughs
  • comparison pages
  • technical pages
  • support pages

Output should include:

  • visual type
  • purpose
  • placement
  • source needed
  • next route

Use this to:

Plan visuals that clarify, prove, compare, or guide action.

A visual should have a clear job in the page.

34. Schema Cue Brief

Use this only for schema notes after the draft is approved.

Short command:

code

Run Schema Cue Brief for this approved draft.

Expanded prompt:

code

Run Schema Cue Brief for this approved draft.

Use the source context first.

Prepare schema cue notes from visible approved content only.

Return the output with these fields:
- schema type candidate
- supported visible content
- required field
- unsupported field
- risk note
- schema readiness
- next workflow route

Do not create final schema before draft approval.

Do not add schema cues from hidden or unsupported content.

Route the output into Schema Cues after approval or Compliance Review.

Best for:

  • approved drafts
  • FAQ pages
  • how-to pages
  • product pages
  • docs pages

Output should include:

  • schema type candidate
  • supported content
  • unsupported field
  • readiness
  • next route

Use this to:

Keep schema planning tied to approved visible content.

Schema cues should come after the page draft exists.

35. Do Not Include Brief

Use this to define exclusions.

Short command:

code

Run Do Not Include Brief for this page.

Expanded prompt:

code

Run Do Not Include Brief for this page.

Use the source context first.

Define what the writer should not include.

Return the output with these fields:
- excluded topic
- excluded claim
- excluded link
- excluded CTA
- excluded comparison
- reason
- better destination if any
- next workflow route

Flag anything that should move to another page.

Route the output into Brief Approval or Drafting and Rewriting.

Best for:

  • broad pages
  • risky topics
  • overlapping pages
  • brand-sensitive content
  • rewrite briefs

Output should include:

  • excluded topic
  • excluded claim
  • excluded link
  • better destination
  • next route

Use this to:

Prevent drift, overreach, unsupported claims, and duplicate content.

Exclusions help the writer stay inside the page role.

36. New Page Brief

Use this when an approved map item needs a new brief.

Short command:

code

Run New Page Brief for this approved page.

Expanded prompt:

code

Run New Page Brief for this approved page.

Use the source context first.

Create a writer-ready brief for a new page from the approved map.

Return the output with these fields:
- page title
- URL
- page role
- target user
- user job
- search intent
- required sections
- proof requirements
- internal link requirements
- SERP targets
- information gain requirements
- tone rules
- blocked items
- next workflow route

Do not draft the page.

Route the output into Brief QA or Drafting and Rewriting.

Best for:

  • approved page queues
  • new site builds
  • topic clusters
  • use case pages
  • support pages

Output should include:

  • page title
  • URL
  • user job
  • required sections
  • next route

Use this to:

Turn an approved map item into a production-ready brief.

New Page Brief is the standard handoff from mapping to writing.

37. Rewrite Brief

Use this when an existing page needs repair.

Short command:

code

Run Rewrite Brief for this URL.

Expanded prompt:

code

Run Rewrite Brief for this URL.

Use the source context first.

Create a rewrite brief for the existing page.

Return the output with these fields:
- current URL
- current page role
- target page role
- rewrite goal
- sections to keep
- sections to revise
- sections to remove
- missing sections
- internal link fixes
- proof fixes
- CTA fixes
- next workflow route

Do not rewrite the page yet.

Route the output into Drafting and Rewriting.

Best for:

  • underperforming pages
  • content refresh
  • link repair
  • intent repair
  • outdated pages

Output should include:

  • current URL
  • rewrite goal
  • sections to keep
  • sections to revise
  • next route

Use this to:

Repair an existing page with clear instructions before rewriting.

Use rewrite for internal links when the rewrite also needs link path repair.

38. Refresh Brief

Use this when a live page needs updating.

Short command:

code

Run Refresh Brief for this page.

Expanded prompt:

code

Run Refresh Brief for this page.

Use the source context first.

Create a refresh brief using performance, search, content, link, SERP, and business priority signals.

Return the output with these fields:
- page
- refresh reason
- content to keep
- content to update
- content to remove
- new sections needed
- internal link updates
- information gain need
- proof updates
- next workflow route

Do not rewrite the page yet.

Route the output into Drafting and Rewriting or Information Gain.

Best for:

  • existing pages
  • content decay
  • SERP changes
  • product updates
  • performance reviews

Output should include:

  • refresh reason
  • content to keep
  • content to update
  • link updates
  • next route

Use this to:

Update a live page without losing what already works.

Refresh Brief protects strong sections while adding needed changes.

39. Consolidation Brief

Use this when pages need merging.

Short command:

code

Run Consolidation Brief for these pages.

Expanded prompt:

code

Run Consolidation Brief for these pages.

Use the source context first.

Create a brief for merging overlapping pages into one canonical page.

Return the output with these fields:
- source pages
- canonical target
- merge reason
- content to keep
- content to remove
- sections to combine
- redirect note
- internal link update
- proof gap
- next workflow route

Do not merge content that serves separate intent.

Route the output into Drafting and Rewriting or Internal Linking.

Best for:

  • duplicate content
  • cannibalization cleanup
  • old blog cleanup
  • site restructure
  • content refresh

Output should include:

  • source pages
  • canonical target
  • merge reason
  • content to keep
  • next route

Use this to:

Merge overlapping pages without losing useful content.

Consolidation Brief should protect distinct intent.

40. Docs Brief

Use this when the page is documentation or onboarding.

Short command:

code

Run Docs Brief for this page.

Expanded prompt:

code

Run Docs Brief for this page.

Use the source context first.

Create a brief for a documentation page.

Return the output with these fields:
- docs page title
- user task
- prerequisite knowledge
- steps needed
- inputs needed
- outputs expected
- support path
- fallback path
- internal link requirements
- next workflow route

Keep the brief task-focused.

Route the output into Drafting and Rewriting.

Best for:

  • onboarding pages
  • product docs
  • support docs
  • workflow docs
  • help center pages

Output should include:

  • user task
  • steps needed
  • inputs needed
  • outputs expected
  • next route

Use this to:

Make documentation clear, sequential, and useful.

Docs briefs should guide users from setup to action to output.

41. Use Case Brief

Use this when the page is based on a user job.

Short command:

code

Run Use Case Brief for this page.

Expanded prompt:

code

Run Use Case Brief for this page.

Use the source context first.

Create a brief for a use case page.

Return the output with these fields:
- use case
- user job
- audience
- problem
- desired outcome
- product fit
- proof needed
- support pages
- conversion route
- next workflow route

Do not make the use case generic.

Route the output into Drafting and Rewriting or Proof and Evidence Brief.

Best for:

  • product-led pages
  • SaaS use cases
  • service pages
  • workflow pages
  • audience pages

Output should include:

  • use case
  • user job
  • problem
  • outcome
  • next route

Use this to:

Connect the page to a real user job and product outcome.

A use case brief should be specific enough to guide the draft.

42. Comparison Brief

Use this when the page compares options.

Short command:

code

Run Comparison Brief for this page.

Expanded prompt:

code

Run Comparison Brief for this page.

Use the source context first.

Create a brief for a comparison page.

Return the output with these fields:
- comparison topic
- options compared
- buyer question
- comparison criteria
- table requirements
- proof requirements
- differentiation need
- conversion route
- next workflow route

Do not create a comparison page without clear buyer value.

Route the output into Drafting and Rewriting or Information Gain.

Best for:

  • alternatives pages
  • vs pages
  • comparison hubs
  • buyer guides
  • commercial investigation pages

Output should include:

  • comparison topic
  • options compared
  • buyer question
  • criteria
  • next route

Use this to:

Help the writer build a fair, useful comparison.

A comparison page should support decisions, not only contrast features.

43. Product or Service Brief

Use this when the page supports a product, service, or offer.

Short command:

code

Run Product or Service Brief for this page.

Expanded prompt:

code

Run Product or Service Brief for this page.

Use the source context first.

Create a brief for a product, service, or offer page.

Return the output with these fields:
- offer
- target audience
- problem solved
- core benefits
- proof requirements
- objections
- comparison needs
- CTA route
- support links
- next workflow route

Flag claims that need evidence.

Route the output into Drafting and Rewriting or Proof and Evidence Brief.

Best for:

  • product pages
  • service pages
  • SaaS pages
  • offer pages
  • conversion support pages

Output should include:

  • offer
  • audience
  • problem solved
  • proof requirements
  • CTA route

Use this to:

Make commercial pages clear, supported, and useful.

Product and service briefs should connect benefits to proof.

44. Local or Market Brief

Use this when the page targets a region, market, or audience segment.

Short command:

code

Run Local or Market Brief for this page.

Expanded prompt:

code

Run Local or Market Brief for this page.

Use the source context first.

Create a brief for a location, market, or segment-specific page.

Return the output with these fields:
- market or location
- audience
- local need
- service fit
- proof needed
- local trust cues
- internal link requirements
- content to avoid
- next workflow route

Do not add unsupported local claims.

Route the output into Drafting and Rewriting or Proof and Evidence Brief.

Best for:

  • location pages
  • market pages
  • regional service pages
  • audience segment pages
  • local trust pages

Output should include:

  • market or location
  • audience
  • local need
  • proof needed
  • next route

Use this to:

Adapt the page to a market without creating thin local content.

Local proof and source context are essential for these briefs.

45. Multi Audience Brief

Use this when one page may serve several audience groups.

Short command:

code

Run Multi Audience Brief for this page.

Expanded prompt:

code

Run Multi Audience Brief for this page.

Use the source context first.

Plan how the page should serve multiple audiences without losing focus.

Return the output with these fields:
- primary audience
- secondary audience
- shared user job
- audience-specific section need
- section to avoid
- internal link route
- split page risk
- next workflow route

Flag cases where separate pages are needed.

Route the output into Section Requirements Brief or Brief Approval.

Best for:

  • SaaS pages
  • service pages
  • audience pages
  • B2B content
  • shared use case pages

Output should include:

  • primary audience
  • secondary audience
  • shared user job
  • split page risk
  • next route

Use this to:

Serve more than one audience without creating a mixed page.

A multi-audience brief should still have one primary page job.

46. Brief QA

Use this before the brief is approved.

Short command:

code

Run Brief QA on this content brief.

Expanded prompt:

code

Run Brief QA on this content brief.

Use the source context first.

Audit the brief before drafting.

Return the output with these fields:
- missing source context
- unclear page purpose
- unclear intent
- weak section requirement
- missing proof
- missing internal link
- missing information gain
- blocked term risk
- schema risk
- approval status
- required fix
- next workflow route

Do not approve briefs with missing purpose, weak evidence, unclear section rules, or unresolved risks.

Route the output into Brief Approval or revision.

Best for:

  • final brief checks
  • agency QA
  • editorial workflows
  • high value pages
  • rewrite handoff

Output should include:

  • missing source context
  • weak requirements
  • missing proof
  • blocked term risk
  • next route

Use this to:

Catch brief problems before writing starts.

Brief QA should happen before the page moves into drafting.

47. Brief Approval

Use this when the brief is ready for final review.

Short command:

code

Run Brief Approval on this content brief.

Expanded prompt:

code

Run Brief Approval on this content brief.

Use the source context first.

Review the brief for approval.

Return the output with these fields:
- approved items
- review needed items
- blocked items
- missing inputs
- drafting risks
- link risks
- proof risks
- schema cue risks
- approval decision
- next workflow route

Do not approve the brief if it lacks source context fit, page purpose, section requirements, proof requirements, or internal link requirements.

Route approved briefs into Drafting and Rewriting.

Best for:

  • final approval
  • production handoff
  • client review
  • editorial QA
  • high risk pages

Output should include:

  • approved items
  • review items
  • blocked items
  • approval decision
  • next route

Use this to:

Create the final gate before drafting.

Only approved briefs should move to production.

48. Brief Handoff

Use this to move the approved brief downstream.

Short command:

code

Run Brief Handoff for this approved brief.

Expanded prompt:

code

Run Brief Handoff for this approved brief.

Use the source context first.

Route each approved brief item into the correct next workflow.

Return the output with these fields:
- page
- brief goal
- drafting route
- rewrite route
- internal link route
- information gain route
- SERP feature route
- schema cue route after approval
- blocked items
- owner note
- handoff note

Do not leave approved requirements without a next action.

Return a clean drafting handoff package.

Best for:

  • approved briefs
  • team handoff
  • writer assignment
  • rewrite queues
  • production planning

Output should include:

  • page
  • brief goal
  • drafting route
  • blocked items
  • handoff note

Use this to:

Move the brief into drafting, rewriting, links, SERP planning, information gain, or schema cue review.

A brief is complete when approved requirements have a clear next route.

Which Content Brief Module Should You Run First?

Start with Brief Scope if the page boundary is unclear.

Start with Brief Goal if the page request is vague.

Start with Brief Input Review if several files, URLs, or outputs may feed the brief.

Start with Source Context to Brief Fit if the page may not belong on the site.

Start with Page Purpose Brief if the page exists but the job is unclear.

Start with Section Requirements Brief if the strategy is clear and the writer needs structure.

Start with Internal Link Requirements Brief if the page must support site routes.

Start with Rewrite Brief if the page already exists and needs repair.

Start with Refresh Brief if the page is live and needs updating.

Start with Brief QA if a draft brief already exists and needs review.

Start with Brief Handoff if the brief is approved and ready for production.

Common Content Brief Starting Points

I Have an Approved Map Item

Start with New Page Brief.

Prompt:

code

Run New Page Brief for this approved page.

Use the source context first.

Create a writer-ready brief for a new page from the approved map.

Return page title, URL, page role, target user, user job, search intent, required sections, proof requirements, internal link requirements, SERP targets, information gain requirements, tone rules, blocked items, and next workflow route.

Do not draft the page.

Then run:

code

Run Section Requirements Brief for this page.

Use the source context first.

Define the required sections for the brief.

Return section name, section purpose, user job served, intent served, required points, proof needed, internal link need, SERP target, draft instruction, and next workflow route.

Do not draft the sections.

Then run:

code

Run Brief QA on this content brief.

Use the source context first.

Audit the brief before drafting.

Return missing source context, unclear page purpose, unclear intent, weak section requirements, missing proof, missing internal links, missing information gain, blocked term risk, schema risk, approval status, required fixes, and next workflow route.

Route the approved brief into Drafting + Rewriting.

I Have an Existing URL That Needs Rewriting

Start with Rewrite Brief.

Prompt:

code

Run Rewrite Brief for this URL.

Use the source context first.

Create a rewrite brief for the existing page.

Return current URL, current page role, target page role, rewrite goal, sections to keep, sections to revise, sections to remove, missing sections, internal link fixes, proof fixes, CTA fixes, and next workflow route.

Do not rewrite the page yet.

Then run:

code

Run Internal Link Requirements Brief for this page.

Use the source context first.

Define the internal links the page should include.

Return source page, target page, link purpose, page role supported, user path supported, anchor direction, placement, priority, and next workflow route.

Do not add generic links.

Then run:

code

Run Drafting Constraints Brief for this page.

Use the source context first.

Define required inclusions, required exclusions, section order rules, tone rules, style rules, prohibited claims, proof requirements, internal link rules, formatting rules, and next workflow route.

Do not draft the page.

Route the output into Drafting + Rewriting or rewrite for internal links.

I Have a Page That Needs Refreshing

Start with Refresh Brief.

Prompt:

code

Run Refresh Brief for this page.

Use the source context first.

Create a refresh brief using performance, search, content, link, SERP, and business priority signals.

Return page, refresh reason, content to keep, content to update, content to remove, new sections needed, internal link updates, information gain need, proof updates, and next workflow route.

Do not rewrite the page yet.

Then run:

code

Run Information Gain Brief for this page.

Use the source context first.

Define how the page should add value beyond common SERP coverage.

Return repeated SERP coverage, weak existing coverage, unique angle, useful addition, original example, proof need, section placement, risk note, and next workflow route.

Then run:

code

Run Brief Approval on this content brief.

Use the source context first.

Review the brief for approval.

Return approved items, review needed items, blocked items, missing inputs, drafting risks, link risks, proof risks, schema cue risks, approval decision, and next workflow route.

Route the output into information gain work or drafting.

I Need a Docs Brief

Start with Docs Brief.

Prompt:

code

Run Docs Brief for this page.

Use the source context first.

Create a brief for a documentation page.

Return docs page title, user task, prerequisite knowledge, steps needed, inputs needed, outputs expected, support path, fallback path, internal link requirements, and next workflow route.

Keep the brief task-focused.

Then run:

code

Run UX Component Brief for this page.

Use the source context first.

Plan components that reduce effort, support trust, clarify choices, or guide next steps.

Return component type, purpose, placement, user state served, friction reduced, proof supported, draft instruction, and next workflow route.

Then run:

code

Run Readability Brief for this page.

Use the source context first.

Define reading level, sentence guidance, paragraph guidance, list guidance, table guidance, summary needs, complexity risks, and next workflow route.

Route the output into drafting.

I Need a Comparison Brief

Start with Comparison Brief.

Prompt:

code

Run Comparison Brief for this page.

Use the source context first.

Create a brief for a comparison page.

Return comparison topic, options compared, buyer question, comparison criteria, table requirements, proof requirements, differentiation need, conversion route, and next workflow route.

Do not create a comparison page without clear buyer value.

Then run:

code

Run Table and Comparison Brief for this page.

Use the source context first.

Define table, comparison, checklist, or decision block requirements.

Return block type, comparison need, criteria, rows, columns, source evidence, proof requirement, placement, and next workflow route.

Do not create a table if prose is clearer.

Then run:

code

Run Proof and Evidence Brief for this page.

Use the source context first.

Define proof, evidence, examples, methodology, screenshots, data, reviews, author notes, policy notes, or case notes needed.

Return claim or section, proof needed, evidence source, evidence gap, placement, risk if missing, and next workflow route.

Route the output into drafting or information gain work.

I Need Internal Link Instructions in the Brief

Start with Internal Link Requirements Brief.

Prompt:

code

Run Internal Link Requirements Brief for this page.

Use the source context first.

Define the internal links the page should include.

Return source page, target page, link purpose, page role supported, user path supported, anchor direction, placement, priority, and next workflow route.

Do not add generic links.

Then run:

code

Run Anchor Instruction Brief for this page.

Use the source context first.

Define anchor direction for required internal links.

Return target page, anchor intent, recommended anchor direction, surrounding passage, placement, user state served, risk note, and next workflow route.

Then run:

code

Run CTA and Next Step Brief for this page.

Use the source context first.

Define primary next step, fallback path, CTA purpose, CTA placement, user readiness, trust need before CTA, support need before CTA, risk note, and next workflow route.

Route the result into semantic internal linking, anchor text by intent, or drafting.

I Need Final Brief QA

Start with Brief QA.

Prompt:

code

Run Brief QA on this content brief.

Use the source context first.

Audit the brief before drafting.

Return missing source context, unclear page purpose, unclear intent, weak section requirement, missing proof, missing internal link, missing information gain, blocked term risk, schema risk, approval status, required fix, and next workflow route.

Do not approve briefs with missing purpose, weak evidence, unclear section rules, or unresolved risks.

Then run:

code

Run Brief Approval on this content brief.

Use the source context first.

Review the brief for approval.

Return approved items, review needed items, blocked items, missing inputs, drafting risks, link risks, proof risks, schema cue risks, approval decision, and next workflow route.

Then run:

code

Run Brief Handoff for this approved brief.

Use the source context first.

Route each approved brief item into the correct next workflow.

Return page, brief goal, drafting route, rewrite route, internal link route, information gain route, SERP feature route, schema cue route after approval, blocked items, owner note, and handoff note.

Route the approved brief into production.

Output Review Checklist for Content Briefs

Before moving downstream, check the content brief for:

  • source context fit
  • clear brief scope
  • clear brief goal
  • page purpose
  • page role
  • target audience
  • user job
  • journey stage
  • primary intent
  • secondary intent
  • SERP targets
  • information gain requirement
  • user gain requirement
  • topic coverage limits
  • entity context notes
  • required sections
  • heading requirements
  • answer targets
  • snippet targets
  • FAQ requirements
  • table or comparison requirements
  • proof and evidence requirements
  • examples or template requirements
  • UX component requirements
  • internal link requirements
  • anchor instructions
  • CTA and next step notes
  • drafting constraints
  • tone and style rules
  • lexicon and blocked terms
  • readability rules
  • source and citation rules
  • visual or media needs
  • schema cue notes after approval
  • exclusions
  • brief QA status
  • approval status
  • downstream workflow routes

Do not move into drafting, rewriting, internal link implementation, SERP feature work, or schema cue work if page purpose, section requirements, proof needs, link requirements, source context fit, or approval status are unresolved.

How Content Brief Workflows Connect to Other MIRENA Workflows

Content Brief Workflows are the instruction layer.

They feed other workflows but do not replace them.

An approved brief can feed Drafting + Rewriting when the next job is page production.

A brief with required links can feed semantic internal linking when the next job is route building.

A brief with weak differentiation can feed information gain work when the next job is useful differentiation.

A brief can feed Semantic SEO when the next job is meaning, coverage, and topic fit.

An entity-heavy brief can feed Entity SEO when the next job is entity structure, entity clarity, and support cues.

Use MIRENA workflow when you need to decide the next route. Use MIRENA outputs when the brief package needs to follow a set handoff format.

Content Brief Mistakes to Avoid

Mistake 1: Creating a Brief Without Source Context

Do not brief from a keyword, title, URL, or competitor page alone.

Source context tells MIRENA which topics, claims, links, and routes belong in the page.

Mistake 2: Treating a Brief as a Draft

A brief should instruct the writer.

It should not become the finished article.

Keep the brief focused on requirements, evidence, constraints, links, and handoff routes.

Mistake 3: Skipping Page Purpose

A page without a clear purpose becomes hard to write and harder to approve.

Run Page Purpose Brief before section requirements.

Mistake 4: Missing Proof Requirements

Claims should not enter the draft without proof rules.

Run Proof and Evidence Brief before drafting commercial, comparison, product, service, or trust-heavy pages.

Mistake 5: Leaving Internal Links Until After Drafting

Internal links should be planned in the brief.

Run Internal Link Requirements Brief and Anchor Instruction Brief before drafting starts.

Mistake 6: Creating Sections Without Jobs

Every section should serve the page purpose, user job, intent, proof path, or next step.

Run Section Requirements Brief and Heading Requirements Brief before outlining.

Mistake 7: Adding SERP Blocks That Do Not Help Readers

Snippet blocks, FAQ blocks, tables, and lists should improve the page.

Run SERP Format Brief, Snippet Target Brief, FAQ Brief, or Table and Comparison Brief with user value in mind.

Mistake 8: Approving a Brief Too Early

A brief is not ready if purpose, section requirements, proof, links, blocked items, or next workflow routes are unclear.

Run Brief QA and Brief Approval before handoff.

FAQs About Content Brief Workflow Prompts in MIRENA

What is a Content Brief Workflow in MIRENA?

A Content Brief Workflow turns source context and approved strategy into writer-ready page instructions.

It defines page purpose, page role, user job, intent, section requirements, proof needs, links, SERP targets, information gain needs, writing constraints, QA status, and handoff routes.

What should I run first?

Start with Brief Scope if the page boundary is unclear.

Start with Brief Goal if the page request is vague.

Start with Brief Input Review if several files or outputs may feed the brief.

Start with Source Context to Brief Fit if the page may not belong on the site.

Start with New Page Brief, Rewrite Brief, Refresh Brief, Docs Brief, Use Case Brief, or Comparison Brief when the page type is already clear.

Is a content brief the same as a topical map?

No.

A topical map decides page structure.

A content brief turns one approved page or URL into writing instructions.

Is a content brief the same as a draft?

No.

A brief defines what the draft should do.

Drafting starts after the brief is approved.

Can Content Brief Workflows use behavioral notes?

Yes.

Behavioral notes can define user state, journey stage, friction, proof needs, CTA timing, fallback paths, and next steps for the brief.

Can Content Brief Workflows use entity notes?

Yes.

Entity notes can guide primary entities, supporting entities, entity clarification, section placement, and terms to avoid.

Deeper entity work should move into Entity SEO.

Can Content Brief Workflows plan internal links?

Yes.

Use Internal Link Requirements Brief and Anchor Instruction Brief to define target pages, link purpose, anchor direction, placement, and priority.

Use semantic internal linking when the link plan also needs architecture and entity support.

Can Content Brief Workflows plan FAQs and schema cues?

Yes.

Use FAQ Brief to plan useful questions and answer requirements.

Use Schema Cue Brief only after the draft is approved and only from visible approved content.

Can Content Brief Workflows improve rewrites?

Yes.

Use Rewrite Brief, Refresh Brief, Consolidation Brief, Internal Link Requirements Brief, Proof and Evidence Brief, and Drafting Constraints Brief before rewriting.

What should I do after a content brief is approved?

Move the output into the correct next workflow.

Use Drafting + Rewriting when the next job is page production.

Use semantic internal linking when the next job is route building.

Use information gain work when the page needs useful differentiation.

Use SERP feature planning when page blocks need search result formatting.

Use schema cues only after the draft is approved.

Written by

Kevin Maguire

in