For 2 months, I’d open Claude, type a topic, and ask for a draft. No outline. No research pass. No structure beyond whatever Claude improvised on the spot.
Some of those articles were fine. Most weren’t — not because the writing was weak, but because the thinking behind it was thin. I’d cover the obvious points, miss the ones a reader actually searched for, and end up rebuilding the middle of the article after the fact.
I kept blaming the drafts. The problem was never the draft. It was that I hadn’t decided what the article needed to do before I asked Claude to write it.
The Short Answer
I don’t ask Claude to write the article first.
I ask it to help me build the brief first — the research, the structure, the intent, the gaps.
Only then do I ask for a draft.
Step 1: I Hand Claude the Research First
Quick answer
I don’t open a blank chat and ask Claude to research my topic.
I gather the raw material myself first: competitor pages, SERP notes, People Also Ask questions, source reading. Then I paste it in before asking for anything structural.
Claude without source material will still hand you an outline. It just won’t be grounded in anything. It pattern-matches on the words in your prompt, which tends to produce the same five or six sections every competing page already has.
The raw material I bring to that first conversation usually includes the top-ranking pages for the target keyword, the People Also Ask questions, any forum or community threads where people ask the same question in their own words, and my own notes from actually using whatever I’m writing about.
I don’t paste in entire pages. Full competitor articles bury the signal in navigation text, ads, and boilerplate. I pull the specific sections that matter: headers, the first couple of sentences under each one, and any data points or claims worth noting. That keeps the research tight enough that Claude can actually reason across all of it in one pass instead of skimming.
Once that’s pasted in, I ask Claude to sort it into two groups: what every ranking page already covers, and what none of them mention. The first group tells me what the brief can’t skip. The second is where the article earns its place.
I go deeper on how I actually run that comparison in my competitor analysis and content gap guides. This step assumes that work is already done and shows where it lands inside the brief.
Step 2: I Confirm Search Intent Before Claude Touches Structure
Quick answer
Before Claude proposes a single heading, I check what the SERP is actually rewarding.
A brief built on the wrong format produces a structurally wrong article, no matter how well-researched it is.
This is easy to get wrong even with solid research, because keyword data doesn’t describe format. A keyword tool tells you volume and difficulty. It says nothing about whether the top-ranking pages are single in-depth reviews, ten-item listicles, or comparison tables.
A brief can hit every subtopic competitors cover and still be built for the wrong one of those. Keywords are ambiguous that way. SERPs aren’t. They show exactly what Google has already decided the query wants, regardless of what the keyword itself implies.
I pull the top results before Claude sees the topic, note the dominant format, and tell Claude explicitly which intent the brief needs to satisfy. I don’t let it infer that from the keyword alone.
Sometimes the SERP is mixed: half listicles, half single reviews. That’s not a data problem to ignore. It’s a signal that the query supports two different content types, and the brief needs to pick one deliberately instead of trying to satisfy both.
Step 3: I Build the Skeleton Before I Build the Copy
Quick answer
The brief isn’t an outline of headers.
It’s a document that tells Claude what job each section does, which terms need to show up, and what to deliberately leave out.
A header list tells Claude what to write about. It doesn’t tell Claude why a section exists or how it connects to the one before and after it. That gap is exactly where generic AI structure creeps back in. Every section reads like its own mini-article instead of one piece of a bigger argument.
Here’s the difference in practice:
Header only:
“## Best Running Shoes for Flat Feet”
Brief entry for the same section:
Purpose: help overpronators narrow options fast, since most competing pages list picks without explaining who each shoe actually suits. Must include: arch-support terminology, the stability vs. motion-control distinction, at least two budget-tier options. Must not include: marathon-specific advice. That’s a different search intent, covered elsewhere.
That second version is something Claude can actually execute without guessing. Here’s what goes into every brief I write:
| Brief element | What it does |
|---|---|
| Target keyword + intent | Locks the format before drafting starts |
| Section-by-section purpose | One sentence per section: what job it does |
| Semantic entities to cover | Terms and concepts competitors treat as required |
| Competitor gaps to exploit | What no ranking page currently answers |
| Exclusions | What not to cover, and why |
| Internal link opportunities | Where this piece connects to existing coverage |
Semantic entities get skipped more than any other row in that table. I pull them from three places: the specific terms competitor pages define or link out to, the phrasing inside the People Also Ask questions, and the related searches at the bottom of the results page. I don’t just list the terms. I mark which ones need their own sentence of explanation and which ones just need to appear naturally in passing. Treating every entity as equally important is how briefs end up with an awkward paragraph defining a term nobody actually asked about.
Claude is good at expanding a well-defined purpose into a paragraph. It’s much weaker at inventing that purpose from a bare header. The brief does the inventing. The draft just executes it.
I keep the brief itself inside a Claude Project alongside the eventual draft, so both stay in the same working context as the piece moves through revisions. This step just assumes the brief has somewhere permanent to live.
Step 4: I Critique the Brief Before Claude Drafts From It
Quick answer
I don’t take Claude’s first brief as final.
Before a single paragraph of the actual article gets written, Claude critiques its own structure. Then I do a second pass myself.
Claude’s self-critique catches structural inconsistency: a section that contradicts the stated intent, or terminology that shows up in the entity list but never in a section purpose. It doesn’t always catch when a section sounds justified but isn’t actually necessary. That’s an editorial call, not a pattern-matching one.
What I look for in my own pass:
- A section that restates the intro instead of adding new information
- Entities included because they’re common, not because they earn a section
- Structure that would duplicate an existing article’s depth instead of complementing it
That last one matters more than people think. A brief that duplicates an existing article doesn’t just waste effort. It puts two of your own pages competing against each other in search.
This is the same critique-before-commit logic I use once a full draft exists. I get into that process in more detail in my Claude Artifacts guide.
Step 5: What Actually Changes Once the Brief Is Done
Quick answer
Drafting gets faster.
The bigger shift is that editing stops being about structure and starts being about voice.
When the brief is solid, I’m not discovering the article’s shape while I write it. Claude already knows the shape. My revisions shift from “this section is in the wrong place” or “this doesn’t answer the actual query” to “this doesn’t sound like me yet.” That second kind of problem is what my SEO writing workflow and my voice training piece are built to solve.
Accuracy is the other thing a brief doesn’t cover on its own. Any claim or number that made it in still needs verifying once it’s in the actual draft, which is a separate pass I write about in my fact-checking guide. This step just clears the structural noise so those later passes can focus on what they’re actually for.
Common Mistakes When Building Briefs With Claude
Treating the brief and the outline as the same thing. An outline is a list of headers. A brief explains why each section exists. Skip the reasoning and you get generic structure with different words.
Skipping intent validation because the keyword feels obvious. The keyword rarely tells you the format. The SERP does.
Letting the brief demand more than the word count can hold. A brief that lists a dozen required entities for an article capped at 1,800 words guarantees a rushed, shallow draft. If there’s a hard word cap, decide what gets cut from the brief, not from the draft after the fact.
Treating the brief as done after the first version. The critique pass in Step 4 exists because first-pass briefs tend to carry over structure from competitor pages without questioning it.
Skipping the check against what you’ve already published. A brief that duplicates an existing article’s depth doesn’t add authority. It splits it.
Pasting in raw research without synthesizing it first. Handing Claude ten unedited competitor pages produces a brief that reads like ten competitor pages stitched together. Trim it down to what matters before Claude ever sees it.
The Real Takeaway
None of this makes Claude a better writer. It makes Claude a better-informed one.
The quality of an article gets decided before the first paragraph exists: in the research handed over, the intent confirmed, and the structure committed to before drafting starts. Skip that stage and you’re not saving time. You’re moving the same work later, into revision, where it costs more to fix.
A solid brief doesn’t guarantee a good article. It just means every step after it — drafting, editing, publishing — gets faster and more consistent, because the hard thinking already happened.