Long-Form Blog Post Outlines That Don't Sound Like AI: The Claude Method

Here's the outline Claude gave me last Tuesday for a 1,800-word post on onboarding email sequences:

# Onboarding Emails
## Introduction
## Why Onboarding Matters
## Best Practices
## Examples
## Conclusion

Five H2s. Every one of them the kind of header you could swap onto any blog post about any topic. If a reader saw only this outline — no body, no title — they would have no idea whether the article was about onboarding emails, SEO audits, or yoga mats.

The article itself wasn't bad. The headers were. And the headers are doing most of the work, because readers (and skim-readers, which is most readers) will judge your post in under 10 seconds by its structure alone.

This is the exact failure I see when clients send me "AI-written" drafts to fix. The prose has been smoothed, the tone is professional, the length is right. But the skeleton is the giveaway. Generic H2s = generic article. And Claude will hand you that skeleton every single time, unless you change how you prompt it.

There are three layers I use in sequence. Each one blocks a different failure mode. Skip one, and the outline regresses.

Layer 1: Role Prompting — Set the Writer's Stance, Not the Topic

Most prompts start with the topic: "Write an outline for a blog post about onboarding emails." That gives Claude nothing to be. It defaults to the median of every blog post it has ever seen.

The fix is to give it a stance, an audience, and a viewpoint in the first 40 words. Here's the role block I prepend to every outline request:

You are a senior content strategist with 10 years of experience writing
for B2B SaaS marketing teams. You write for marketers who already know
the basics of email — they want specific, opinionated plays they can
ship this week, not a 101 explainer. Your writing style is direct,
skeptical of best-practice fluff, and always includes one contrarian
take per post.

Three things that block are doing:

1. "Senior content strategist" — sets the depth. A strategist thinks in terms of frameworks and trade-offs, not feature lists.
2. "They already know the basics" — this is the single most important sentence. It explicitly forbids the 101 rehash that produces "What Is Onboarding Email?" as H2 #1.
3. "One contrarian take per post" — Claude loves contrarianism once told to. Without this, the model gives you consensus.

The full prompt is roughly 100 words. I've tested it with and without the role block, and the H2 quality jump is significant — measurable in the sense that I'd ship roughly 70% of the role-prompted outlines with light edits, versus maybe 20% without.

Layer 2: Anti-Cliché Guardrails — Name the Patterns You Don't Want

Here's the thing about Claude: it knows what a generic blog outline looks like. It produces one because you didn't tell it not to. The model is a pattern completer, and the most common pattern in its training data for "blog outline" is exactly Introduction / Why / Best Practices / Examples / Conclusion.

The fix is to name the anti-patterns explicitly. Here's a guardrail block I append:

DO NOT use any of these H2 patterns:
- "Introduction" / "Conclusion" / "Overview" as H2
- "Why X Matters" / "Benefits of X" / "Best Practices for X"
- Generic question H2s like "What Is X?" or "How Does X Work?"
- "Key Takeaways" as a final section
- Any H2 that could appear in a post about a different topic

Each H2 must be answerable to a specific reader question. If two
posts in different verticals could share an H2, rewrite it.

That last line is the load-bearing one. "If two posts in different verticals could share an H2, rewrite it" forces Claude to actually think about the content of the header rather than slotting in a category label.

The other guardrails I rotate in depending on the post:

• For thought-leadership pieces: "Avoid the Ted Talk structure (problem / hero / call to action)."
• For how-tos: "Each H2 should describe a step, not a phase. 'Write the cold open' is good; 'The first step' is bad."
• For data-heavy posts: "At least two H2s should lead with a specific number or finding, not a generic concept."

These don't all go in one prompt. I add the relevant 1-2 depending on what kind of post I'm outlining. The point isn't to write a longer prompt; it's to block the specific failure mode of that post type.

Layer 3: Sub-Question-Driven H2 Structure — Force Specificity

Layers 1 and 2 raise the floor. Layer 3 raises the ceiling. This is where outlines go from "acceptable" to "actually good."

The technique: before you ask Claude for H2s, you write 4-6 sub-questions that a reader of this post would actually ask. The H2s are then the answers to those questions, phrased as headings.

For the onboarding email post, my sub-questions were:

1. What's the one email most teams skip that drives 40% of the activation lift?
2. How long should the welcome sequence be before it stops paying off?
3. Is a plain-text email better than a designed email for the first touch?
4. When should you stop the sequence and switch to a broadcast cadence?
5. What does a bad onboarding sequence look like — and why do people keep shipping them?

Now the H2s aren't guesses. They map to the questions. Here's the final outline Claude produced with the role block, guardrails, and sub-questions:

# The Onboarding Email Sequence That Actually Moves Activation
## The Welcome Email Most Teams Skip (And Why It Works)
## Sequence Length: When the 5th Email Stops Paying Off
## Plain Text vs. Designed: The First-Touch Test
## When to Exit the Sequence and Go to Broadcast
## The Onboarding Sequences I See Fail (And the Pattern They Share)

Five H2s. None of them is "Benefits of Onboarding Emails." A reader scanning these knows exactly what they'll learn and in what order. The contrarian take is the last H2 — Claude did that on its own once the role block was in place.

The general rule I'd suggest: write 4-6 sub-questions by hand before you prompt. They don't have to be perfect. They just have to be specific. The specificity of your sub-questions is the upper bound on the specificity of your H2s. If your questions are vague, Claude's headers will be vague. If your questions are sharp, Claude's headers will be sharp.

The Full Prompt

Here's the prompt, ready to paste into Claude. Tweak the topic, role, and sub-questions for your post.

You are a senior content strategist with 10 years of experience
writing for B2B SaaS marketing teams. You write for marketers who
already know the basics of email — they want specific, opinionated
plays they can ship this week, not a 101 explainer. Your writing
style is direct, skeptical of best-practice fluff, and always
includes one contrarian take per post.

Draft an outline for a 1,800-word blog post on the topic: [YOUR TOPIC].

DO NOT use any of these H2 patterns:
- "Introduction" / "Conclusion" / "Overview" as H2
- "Why X Matters" / "Benefits of X" / "Best Practices for X"
- Generic question H2s like "What Is X?" or "How Does X Work?"
- "Key Takeaways" as a final section
- Any H2 that could appear in a post about a different topic

Each H2 must be answerable to a specific reader question. If two
posts in different verticals could share an H2, rewrite it.

Here are the sub-questions this post should answer:
1. [sub-question 1]
2. [sub-question 2]
3. [sub-question 3]
4. [sub-question 4]
5. [sub-question 5]

The H2s should be the answers to those questions, phrased as
headings. Include a 1-sentence note under each H2 explaining
what the section will cover.

That last instruction — "include a 1-sentence note under each H2" — is the small thing that makes a big difference. It forces Claude to think about what goes in the section, not just what the section is called. Half the time, those notes become the seed of the section's actual content.

The Test That Actually Catches It

After you have the outline, do the cover-the-titles test: read only the H2s out of context. If a colleague who knows nothing about the post can guess the topic from the H2s alone, the outline works. If they shrug, the H2s are too generic — go back and tighten the sub-questions or add more guardrails.

Generic outlines are not a Claude problem. They are a prompt problem. The model knows what a good outline looks like — it just needs to be told you actually want one.