I Used Claude Code and Obsidian to Build a B2B SEO Content Strategy

Heads up, we set up a system using Claude Code and Obsidian in part one! If you’re already onboarded to Claude Code, proceed without haste. Otherwise, go back and get set up.

After telling my friends in product marketing that they could likely create a very powerful workflow for SEO content using Claude Code and Obsidian, I thought I’d better test my theory by actually developing a workflow and creating a demo. I wanted something that couldn’t be confused for a real company, so I decided to work in my one-day goal of being a spec-fic writer, and create a fictional futuristic tech product company called Continuum Scheduler, and try to build some SEO content from that.

This is the full SEO content strategy build for my fictional company, from the first discovery prompt to critiqued, publishable drafts. I’ll show you the actual prompts I used, the outputs Claude returned, what worked, and what didn’t. It took about three and a half hours (across multiple sessions) and burned through a meaningful chunk of my monthly token budget. But burning tokens in the name of experimentation is what we’re doing right now.

Is this a tutorial on how to create AI Slop? I’ve been around sloppy SEO content before, back when content farms were producing hundreds of unusable articles a week and someone (me) had to read them all. I once worked for a horse medication company doing just this (triggered). This is a long way from that, but the content is not “done for you.” The AI amplifies what you bring to it, and a sharp marketer still makes the difference between content that passes a brief and content that’s actually good.

A short detour into my (fake) product: Continuum Scheduler

What is it: Continuum Scheduler is a coordination system for distributed teams. Scheduling for teams where time doesn’t behave consistently: time zones, async work, deep-space latency.

Why this company: It’s fictional, and the weird angle is the point. A typical B2B SaaS company would have produced generic output. Continuum Scheduler forced real strategic decisions: Claude had to find genuinely unclaimed keyword territory, build positioning that actually differentiated, and produce a voice with real character. The strangeness brought an interesting challenge to the workflow, but still fun for the demo.

The goal: Build a content strategy with pillar and cluster articles, then draft a few pieces to show how the workflow handles SEO structure, interlinking, and critical feedback. I’m using a pillar and cluster model because that’s what I’m familiar with, and I will note that I am in fact, not a product marketer.

If you read the previous article, you’ll know that this workflow doesn’t make you faster, but it makes you more powerful. I went into this expecting to learn more about creating an SEO content strategy; I came out of it genuinely wondering if my fictional tech company could be a product. The idea that distributed team coordination is a systems design problem, not a behavior problem or a tools problem, was genuinely revealing to me.

You can play along with me

You can work through this with the prompts as written, copying them one by one. Or drop the companion workflow file into your project and let Claude run the whole thing.

Download the companion workflow file
Drop it into your Obsidian vault and run
Read @CONTENT_STRATEGY_WORKFLOW.md and let's begin.

A note on tracking time and building instinct around tokens

I’ve been tracking time spent per phase throughout this demo so you can see the real effort behind the workflow. When it comes to tokens, what matters is building your own instinct for which phases are expensive, which prompts are efficient, and when you’re being wasteful. I’ve been able to develop that by checking my usage regularly as I work.

Resources:

• Anthropic console usage dashboard
• Understanding token counts and costs

Ready to begin? Open both windows

Before you start Phase 1, you need both tools pointing at the same vault:

1. Obsidian: Open your target vault or folder. You’ll use this to read and edit files as they’re created.
2. Terminal: Navigate to your vault / folder and start a Claude Code session with claude. This is where you’ll interact with Claude.

When Claude creates or edits files, you’ll see them appear in Obsidian. When you make edits in Obsidian, you can reference them in Claude Code with @filename.md.

Phase 1: Strategy & Discovery

This is where Claude turns messy positioning into a reusable strategic foundation. Don’t rush this one; every later phase inherits its assumptions.

Phase 1A: Initial Discovery (The Conversation)

What happened

I fed Claude the Continuum Scheduler website I’d been building, which already had some product copy and feature descriptions. Then I ran the discovery prompt and let it interview me.

I should say upfront: my strategy going in was flakey at best. I vaguely knew what Continuum Scheduler was (a coordination system for teams where time doesn’t behave consistently, including the bit where your colleague might technically be in the past). But I hadn’t thought hard about who would actually buy it or why, and Claude was going to have to drag that out of me.

Claude was apprehensive about the relativistic angle, perhaps reasonably. When I described the core product problem: how do you schedule a meeting when two people aren’t in the same temporal frame of reference, and what if you accidentally book a call with someone who’s in their Friday when you’re in your Tuesday? There was a noticeable pivot in how it responded. It could see the earthbound problems clearly: timezone cognitive load, the async black hole, the ambiguous non-response, and those were familiar for it. The relativity stuff it handled more carefully, and it felt like it was giving some very “shit sandwhich” style feedback about a business plan it clearly had concerns about.

It organised the whole thing into two tiers. Tier 1: the earthbound problems - high search volume, emotionally resonant, the “what time is that for you?” tax that every distributed team knows. Tier 2: the relativistic problems - zero competition, entirely unclaimed territory, the place where Continuum gets to be genuinely weird. As for “the grandfather paradox as a scheduling conflict”, it said “no existing tool has a resolution pathway for this”, so we can be a category king here, nice. It told me, directly, that leading with the relativistic angle and letting earthbound content follow is a harder content job but a more defensible long-term position. I thought this was pragmatic advice, which I noted and proceeded to ignore anyway.

But the category frame it found was genuinely useful: coordination systems for teams where time itself is the variable. That’s not a product category that exists, which means no one owns it. It said there is no universal “now.” Sufficiently distributed teams don’t share a present. They share a coordination system. This started to scratch my brain and had me thinking there might be something I could actually build. But let’s not get ahead of ourselves; we’re currently staking SEO claim to these terms. The actual solution can come later.

Phase 1B: Build the Content Pillars

What happened

Claude came up with four pillars, three of which made obvious strategic sense: async coordination (crowded, but high volume: the traffic engine), timezone and scheduling intelligence (closer to the product, higher intent, where the real buyers are), and coordination systems design (systems-level thinking for the enterprise buyers who actually sign contracts).

Pillar 3 was my favourite: The Physics of Coordination. What happens to scheduling when time itself stops being consistent. This had zero competition and was entirely unclaimed territory. This is the one I’d been hoping for. The cluster topics Claude proposed under it were things like: There is no universal “now”: what general relativity means for distributed teams., How NASA schedules around communication blackouts. And very excited for this one, The grandfather paradox as a merge conflict: causality and calendar systems. I don’t know exactly what that article is yet, but I want to read it.

Claude was clear-eyed about the trade-off: Pillar 3 has no direct search demand. It won’t drive signups. But it does something the other three pillars can’t: it makes someone following an idea land on Continuum rather than looking for a scheduling tool. “They’re not searching for a scheduling tool,” it said, “they’re following an idea.” Now, it was getting on board my spec-fic train-of-thought.

Its actual recommendation was to start with Pillar 2, which was closest to conversion, and the most bounded scope, and publish one Pillar 3 piece a month from day one. Pillar 3 is not for traffic, but it will establish the thing that makes Continuum different.

Phase 1C: Voice & Style Guide

What happened

The brief I gave Claude here was roughly: this is a fictional B2B company, making something that sits at the intersection of physics and workplace ops. The reader is a head of ops or an ops-adjacent buyer: smart, pressed for time, probably skeptical. The writing should be digestible for them but not dumbed down. It should feel vaguely futuristic without being alienating, and numbers matter and factual grounding matters.

What came back was better than I expected, and I’ll admit I went back and forth with it a bit on tone before it landed. The thing it got exactly right was the humour:

“We have a sense of humour, but we don’t perform it. The comedy in our content comes from stating genuinely absurd things with complete seriousness. We never wink at the reader.”

The whole product is a bit absurd, you know? Scheduling for teams operating across relativistic drift is genuinely funny if you say it with a straight face. The moment you start nudging the reader (“get it? because time travel?”), it collapses. Claude got it.

Output

The full output is below. The voice guide is used in later prompts when it comes time to actually write blog posts.

Phase 1D: Create STRATEGY.md

What happened

This was the payoff prompt for everything in Phase 1: one instruction to pull the discovery conversation, the pillars, and the voice guide into a single reference document. I fed it a lot of material about Continuum and it ran with it, and my full output is below.

Output

Phase 1 Summary

By the end of Phase 1 (about 37 minutes across four prompts) I had three new documents: a strategy, a voice guide, and a content architecture.

This whole process felt very collaborative. I came in with a lot of raw material, Claude asked the right questions, pushed back when things didn’t add up, and reflected my own thinking back at me in a form I could actually use. It wasn’t making decisions for me, it was making it possible for me to make better decisions faster.

If I were doing this for a real product, I’d spend longer here. But even in demo mode, Phase 1 did what it’s supposed to: by the time I moved to SEO research, I knew what Continuum stood for, who we were speaking to, and what it sounded like.

Phase 2: SEO & Keyword Research

This is the phase that checks whether the strategy can meet search behaviour in the real world. I ran the same prompt against all four pillars in parallel, and each one wrote its findings to a separate keywords.md file.

Phase 2A: Keyword Research Per Pillar

What happened

I ran this prompt once per pillar, and Claude spun up four parallel research passes, each one searching, assessing, and writing findings to its own file. The earthbound pillars came back roughly as expected: async coordination is crowded (Notion, Loom, every remote-work publication owns this space), timezone intelligence has more breathing room at the analytical end, coordination systems design competes with management consulting content.

And then the Pillar 3 results came back,

Relativistic coordination: zero. Entirely unclaimed term — Continuum can define it. Scheduling without shared time reference: zero. Entirely unclaimed — direct Continuum positioning. No universal now relativity: very low. Nearly unclaimed as a phrase.

Look. Are we all going to Mars in twenty years? Maybe. Elon thinks so. And if we are, these are going to be actual real problems… how do you schedule a standup when your colleague is in a different gravitational field and their Thursday is arriving slightly later than yours? The keyword research confirmed that nobody is writing about this from a coordination angle yet. Not NASA, not the scheduling software companies, not anyone.

So yes, I am claiming this keyword territory now. It’s a long game. A very long game.

Output

The full Pillar 3 findings are below. I’m showing this one in full because it’s the most interesting example of what the research phase can surface when the topic is genuinely weird.

Why it mattered

When you do this for your own project:

• Which pillars have the clearest, lowest-competition keyword opportunities?
• Where is the gap between what ranks and what actually answers the reader’s question?
• Which pillars can you own vs. which ones will require you to out-write much larger competitors?
• Where can you earn inbound links by connecting concepts no one else has connected?

Phase 2B: SEO Plan Overview

What happened

The SEO plan synthesised all four keyword files into a single priority matrix, 30+ keywords scored A through D. The most useful thing it did was tell me what to skip. Several keywords came back flagged as D or “avoid entirely”, e.g. async vs sync communication (high competition, dominated by Notion and every remote-work publication), time dilation explained (Wikipedia owns this and will for the foreseeable future). Having an AI tell you that some of your ideas aren’t worth pursuing is oddly liberating. Now I know where to best spend my time.

Output

Phase 2C: Cluster Topic Identification

What happened

The first ideas AI gives you in a brainstorm are always the obvious ones. Ask for content ideas and you’ll get 10 tips for distributed teams and how to run a better meeting. That’s not Claude being bad at its job, that’s how brainstorming works (humans do this, too). You have to move through the generic ideas to get to the good ones. In a human brainstorm, after 20 minutes you start finding the less obvious angles. After 40 minutes you’re somewhere new. After two hours of deep work you might be in genuinely weird territory.

That’s where we were now.

The earthbound clusters were real problems I’d actually seen in workplaces: Cross-Timezone Meeting Fatigue Is Real — Here’s What’s Causing It. The Hidden Cost of Timezone Math. Why Teams Default to Meetings (Even When Everyone Wants Fewer). These aren’t generic, they’re the specific things that make distributed work genuinely hard, named precisely.

And then the Pillar 3 clusters: Causality Is a Scheduling Problem: What Distributed Systems Got Right That Calendar Software Missed. The research behind that one surfaced Lamport’s 1978 paper on logical clocks, which solved the problem of causality in distributed systems without a shared clock. Calendar software, in 2026, still hasn’t asked the same question. That’s not just a content gap. That’s a product gap.

By the end of Phase 2C I was delusionally, increasingly convinced that this SEO strategy might cause me to build a real product. This is where I think it’s exciting, what extended deep work with AI can do for marketers. It’s not just faster brainstorming. It’s brainstorming that keeps going until it reaches somewhere genuinely new.

Output

This is a demo, so I approved the list as-is. If you’re working on a real thing… do your due diligence.

Phase 2 Summary

By the end of Phase 2 I had a keyword strategy, a priority matrix, and 19 approved cluster article ideas, all in about 24 minutes.

But the more interesting outcome was the shift in the work itself. Phase 1 was strategy and foundations. Phase 2 is where the research started generating genuine curiosity: ideas I wanted to follow, questions I hadn’t thought to ask, territory that felt genuinely unclaimed. That’s the thing about going deep with AI, you have to earn the interesting output. The obvious stuff comes first. Keep going.

Phase 3: Content Map & Briefs

This is where the workflow gets big. The content map turns scattered keyword ideas into a publishable system, then the brief generation turns that system into execution-ready work.

Phase 3A: Build the Content Map

What happened

Claude created CONTENT_MAP.md, the master architecture document, but the useful thing wasn’t the file structure. It was that the system started noticing relationships between articles before we had even reached the interlinking phase.

Output

Why it mattered

The most useful section was Content Relationships, where Claude grouped articles three ways:

• Entry points — top-of-funnel pieces likely to be a reader’s first touch (e.g. 1.1 When Async Breaks Down, 2.1 Cross-Timezone Meeting Fatigue, all four Physics articles via inbound links)
• Conversion-adjacent — articles where the reader has buying authority or is actively evaluating (2.5 World Time Buddy Alternative, 4.4 The Meeting Audit, 4.1 Scheduling as a Systems Problem)
• Pillar bridges — clusters that sit at the intersection of two pillars and link both ways (1.3 Response Time Culture bridges Async ↔ Timezone; 4.3 Team Handoffs bridges Async ↔ Coordination Systems; 3.4 Causality Is a Scheduling Problem bridges Physics ↔ Coordination Systems)

This bridging logic became the seed of the interlinking plan in Phase 4 — Claude had effectively pre-mapped the cross-pillar links while building the architecture.

Phase 3B: Generate All Briefs

# Brief: [Article Title]

## Overview
- **Type:** Pillar / Cluster
- **Pillar:** [which pillar]
- **Primary keyword:** [exact keyword]
- **Secondary keywords:** [2-3 supporting terms]
- **Target reader:** [specific description]
- **Search intent:** [what is this person trying to do]
- **Funnel stage:** Top / Middle / Bottom
- **Estimated word count:** [range]

## The reader's problem
[2-3 sentences from their perspective]

## What this article must do
[3-5 bullet points]

## Recommended structure
[Proposed H1, H2s, and H3s]

## Key points to cover
[Substance of the article - arguments, explanations, examples, data]

## What to avoid
[Anything that would make this generic, off-brand, or cannibalise another piece]

## Internal linking opportunities
[TBD]

## SEO notes
- Meta description: [150-160 characters including primary keyword]
- H1 suggestion: [strong H1 with primary keyword naturally included]
- Competitor positioning: [any specific SEO considerations]

What happened

I did not expect this. I asked Claude to generate briefs for every piece in the content map, and it spawned 23 agents simultaneously — one for each pillar and cluster article — and ran them all in parallel. I watched them go. Thirteen minutes later, 23 complete brief files had been created. It was genuinely impressive to watch. It was also, I knew immediately, going to hurt my token budget. I checked my usage, and I confirmed, it did.

Scale

The scale:

Per agent: ~14,000 tokens each
Total across all 23 agents: ~323,743 tokens
Wall-clock time: 13 minutes

Running sequentially would take the same total tokens but ~4 hours of wall-clock time. Parallel costs real money but buys real time. If content is a significant part of your work, it’s worth it, but watch your usage dashboard while it runs. This is a good moment to build your instinct for what parallel agents actually cost versus single-session work.

Output

Example brief (Cluster 1.5: Async Code Review):

Phase 3C: Posting Schedule

What happened

A 6-week schedule, week-by-week, with rationale and an explicit trade-offs section. The decisions Claude made on its own were the interesting part — most weren’t directly specified in the prompt:

• Pillar order P2 → P1 → P4 → P3 was based on cluster readiness, not stated importance.
• Week 1 has no pillar because no pillar had enough supporting clusters live yet.
• Conversion-adjacent clusters land after their pillar, so decision-stage pieces have context before they publish.
• Bridge clusters are flagged for retroactive linking, so links can be added once both target pillars are live.

The trade-offs section was sharp. Claude flagged that the Physics pillar cadence in this schedule (4 pieces in 6 weeks) directly contradicts STRATEGY.md, which specifies “1 piece per quarter” for that pillar. That’s the kind of self-flagged contradiction I’d otherwise have missed.

Output

| Week | Publish date | Content type | Article title | Pillar | Notes |
|------|--------------|--------------|---------------|--------|-------|
| 1 | Mon 27 Apr | Cluster | When Async Breaks Down | Async Coordination | Entry point |
| 1 | Tue 28 Apr | Cluster | Cross-Timezone Meeting Fatigue Is Real | Timezone | Entry point |
| 1 | Wed 29 Apr | Cluster | The Hidden Cost of Timezone Math | Timezone | Entry point |
| 1 | Thu 30 Apr | Cluster | Why Teams Default to Meetings | Coord. Systems | Entry point |
| 2 | Mon 4 May  | Cluster | How to Write Async Updates That Get Read | Async | Builds P1 depth |
| 2 | Tue 5 May  | **Pillar** | Timezone & Scheduling Intelligence | Timezone | First pillar — 2 clusters live |

Phase 3D: Brief Quality Audit

Optional but the highest-leverage prompt in Phase 3. After 23 briefs and three planning documents, things drift. The audit is the moment to catch contradictions before any writing happens.

What happened

A 15KB audit. Four sections (keyword conflicts, coverage gaps, brief quality, strategic coherence) and a prioritised action list at the end. The honesty was the surprise — but maybe it shouldn’t have been. One thing I’ve noticed the more I use Claude: if you ask it to critique something another Claude session wrote, it will always find problems, if that’s what you’re asking for. It’s a bit like a human that way. Ask someone to find fault and they’ll find fault. Ask someone to build and they’ll build. The framing of the request shapes what comes back. The audit prompt is explicitly adversarial — find the contradictions — and it did.

The genuinely critical finding:

Pillar 2’s primary keyword contradicts the SEO plan. The pillar brief sets scheduling across time zones as the target, but SEO_PLAN.md classifies that exact keyword as D-grade / SKIP (“Calendly, Doodle dominate — avoid direct competition”). The pillar brief and the SEO plan cannot both stand.

This is exactly the kind of failure that’s easy to miss when you’ve been generating documents in sequence. By Phase 3B, the SEO plan had been written 30+ minutes ago and 23 parallel agents had no shared memory of which keywords were marked skip. The audit caught it.

Other findings worth calling out:

• Pillar/cluster cannibalisation across 4 pillars. Multiple pillar briefs listed their own clusters’ primary keywords as secondaries — the pillar and cluster were optimising for the same query.
• An A-grade keyword with no owner. scheduling without shared time reference was flagged in SEO_PLAN as “entirely unclaimed; A-grade quick win” but appeared only as a secondary on two briefs. Nobody was set up to actually rank for it.
• Three different pillar priority orders across STRATEGY.md, SEO_PLAN.md, and CONTENT_MAP.md. A writer reading any one of those documents would come away with a different view of which pillar leads.
• Audience gap: the procurement evaluator. STRATEGY names ops/HR as the primary buyer, but every brief targets practitioners. There’s no piece a procurement-stage reader could land on and find directly useful.
• Continuum-mention pattern is mechanical. Almost every brief contains the same instruction: “mention Continuum once, naturally, mid-to-late.” Read in sequence across the content set, this produces a detectable rhythm. The fix Claude suggested — vary it: some pieces have zero mentions, some have two — is exactly right.

The action priority Claude gave at the end:

1. Change P2 pillar’s primary keyword (direct contradiction with SEO strategy)
2. Demote cluster primary keywords from pillar secondaries (cannibalisation across 4 pillars)
3. Decide who owns scheduling without shared time reference (A-grade keyword unclaimed)
4. Resolve the P4 pillar vs 4.1 cluster strategic tension (cluster carries the stronger keyword)
5. Pick one pillar priority order and propagate to all planning docs

Phase 3 Summary

By the end of Phase 3, every single piece of content — 4 pillar briefs + 19 cluster briefs — had a complete, writer-ready brief, a 6-week posting schedule sequencing all 23 pieces, and a strategic audit flagging the contradictions to fix before writing starts.

Phase 4: Interlinking Plan

This is the phase that turns a pile of articles into a content system. It decides where authority should flow, what readers should discover next, and which links have to wait until later pieces exist.

Phase 4A: Map the Link Architecture

What happened

Claude presented both layers but in a different format than the prompt suggested — it went article-by-article instead of layer-by-layer, which turned out to be more useful. Each article got a section with “Outbound: Mandatory” and “Outbound: Contextual” lists, with context notes for every single link.

The most interesting part was how it described the contextual links — it didn’t just name the target article, it named the specific section where the link belonged and explained why. Example from 1.1 (When Async Breaks Down):

→ 1.2 in Information Rot failure-mode section, where send-and-receive decoupling is the cause. Anchor: how to structure updates so they actually get acted on

This is the specificity that makes a brief usable. A writer working on 1.1 doesn’t have to guess where the link to 1.2 belongs — it belongs in that exact section, covering that exact concept, with that exact anchor text.

Phase 4B: Write the Interlinking Plan to File

What happened

Claude wrote a 38KB interlinking plan. The important thing was not the size of the document, but the operating model: a writer could open one article section and know which links belonged there, why, and what anchor text to use.

Output

#### P1 — Async Coordination

**Outbound: Mandatory (down to clusters)**
- → 1.1 — anchor: where async tends to break down
- → 1.2 — anchor: how to write updates that actually get read
- → 1.3 — anchor: building a response-time culture without micromanaging
- → 1.4 — anchor: the trade-offs between async standup formats
- → 1.5 — anchor: keeping async code review from collapsing into a meeting

Phase 4 Summary

By the end of Phase 4, the full content set had a linked architecture ready for writers to execute. Every article had:

• Mandatory structural links (up to pillar, down to clusters, sibling connections)
• Contextual links with specific section placement and anchor-text guidance
• A clear forward-link schedule (which links can be added at publish, which need to be added retrospectively when their targets go live)

The interlinking plan is often the output that gets skipped when under time pressure, but it’s one of the highest-leverage SEO decisions in the whole workflow. This one linked 23 pieces together in a way that passes authority from cluster up to pillar, makes cross-pillar discoveries possible, and prevents readers from getting lost.

Key insight: This phase exists so writers can stop worrying about link placement and just follow the spec. The hard work of finding the overlaps and thinking about the architecture is done. The file is a blueprint — execute it exactly.

Phase 5: Writing & Drafting

This is the execution phase: the briefs become drafts, then the drafts get checked for SEO structure, formatting, and readiness to move into final files.

Phase 5A: The pillar article

Which pillar: Timezone & Scheduling Intelligence

What happened

Claude produced a 3400-word pillar draft with a strong spine: scheduling is a systems problem, not a calendar problem. The structure moved from diagnosis (what breaks in distributed teams) to design (what the systems view requires) to implementation (how to actually fix it).

Opening paragraph:

The complaint is always the same. You’ve given your team the tools for scheduling across time zones — Calendly for external meetings, World Time Buddy bookmarked, a shared calendar with three timezone columns running down the side — and the calls are still happening at the wrong times.

The first section named three structural failures rather than listing tips:

1. Time zone cognitive load — the invisible tax of mental arithmetic
2. Synchrony bias — why teams default to meetings even when async would work
3. Unequal burden distribution — why someone always takes the bad slot and why it compounds

Each failure mode was diagnosed with mechanism (why it happens), not just symptom (how it feels).

The systems-view section made the abstract concrete:

Meeting policy as infrastructure means writing the rules down. Which meetings recur, and why. Which require synchronous attendance, and which can be missed without consequence. What async substitutes exist when sync isn’t possible.

The meta description matched the brief spec exactly: “Scheduling across time zones fails because it’s a systems problem, not a calendar problem. Here’s the framework distributed teams actually need.” (157 characters)

Self-assessment Claude offered: “The diagnosis section (the three failure modes) is the strongest part — it names things that were previously unnamed. The implementation guidance is functional but thinner than the diagnosis. A human editor should push the systems-design section deeper and add one or two concrete examples of what ‘meeting policy as infrastructure’ actually looks like in practice.”

The draft hit the brief’s structure exactly as specified. This is the payoff of Phase 3 — Claude’s job in Phase 5 was execution, not design. The time spent was 9 minutes (wall clock) at 19,000 tokens.

Scale

This draft took 9 minutes, used 19,000 tokens with Opus, and consumed about 12% of a 5-hour window allowance. Brief-driven drafting is efficient, but Opus pillar work is still expensive enough to notice.

Phase 5B: Single cluster drafting

In this demo I skipped the single-article approach and went straight to batch drafting all five Timezone pillar clusters using Phase 5C below. If you’re working on one article at a time rather than a full pillar set, the workflow file covers this — the rules are identical to 5C, just without the sub-agent scaffolding.

Phase 5C: Batch cluster drafting (same pillar)

What happened

Claude drafted five cluster articles across the Timezone pillar in parallel. Sonnet handled all five; each sub-agent worked independently from its brief.md and keywords.md, wrote to its own draft.md, and reported back.

The interesting part was that the system did not just produce drafts. One sub-agent noticed that 2.2’s funnel-stage classification in the brief (“Awareness”) didn’t match the article’s actual content — the reader building a case to leadership is mid-funnel, not top. This is exactly the kind of alignment check that parallel drafting surfaces: brief vs. actual output.

Output

Scale

This took about 12 minutes in parallel, compared with roughly 45+ minutes sequentially. Sonnet was significantly cheaper than Opus here: about 5k tokens per agent, or 25k total across five cluster drafts.

Phase 5D: SEO Pass

What happened

I ran this once on 2.1 (Cross-Timezone Meeting Fatigue). Claude verified the keyword placement, secondary keywords, meta description, and internal links, then flagged two long paragraphs and one 41-word sentence for human editorial attention. Useful, but mostly mechanical. A proper human SEO review would still need to decide whether the flagged sections actually hurt the read.

Phase 5E: Move to Final

What happened

This step was mostly a file hygiene check: Claude copied the approved draft to final.md, confirmed the meta description was in frontmatter, checked the headings, and verified the internal links were markdown-formatted correctly. No formatting issues found.

Phase 5 Summary

By the end of Phase 5, the content set had:

• 1 pillar article drafted (Timezone & Scheduling Intelligence) — 3400 words, Opus, 19k tokens, 9 minutes
• 5 cluster articles drafted in parallel (Pillar 2 full cluster set) — ~2000 words each, Sonnet, ~5k tokens per agent, 12 minutes total
• 1 cluster article SEO-audited and readability-flagged (Cross-Timezone Meeting Fatigue) — 4 minutes
• 1 article moved to final.md after formatting check (Cross-Timezone Meeting Fatigue) — 2 minutes

Note: The demo above walks through Pillar 2 in detail. The same prompts ran for all four pillars at roughly the same time and token cost each.

Phase 6: Critical Review

This is the quality gate. The point is not to ask Claude whether it did well; it is to give it a specific skeptical reader and make the work survive that person’s attention span.

The critical reader prompt

What happened

One note: when I shared the sci-fi Continuum articles, Claude immediately identified them as fictional. I ran the critical review against less sci-fi pieces — the async communication article — instead. Here’s what it said:

Output

Why it mattered

Feedback is (usually) always useful and this feedback was surprisingly good. The useful thing is that you don’t have to agree with all of it. The critique is a perspective, not a verdict. What it gives you is specific, named problems to react to, and reacting to specific problems is much easier than staring at a draft wondering why it doesn’t quite work. Even if you push back on half the feedback, the other half is probably right. For a real project, I’d spend much longer than 10 minutes here.

The Big Picture

This is the outcome of the workflow: what the vault looked like at the end, what the run cost in time and tokens, and what I learned from directing the whole thing.

Vault structure

Here’s what the final vault looks like:

/[COMPANY NAME]
├── STRATEGY.md
├── VOICE_GUIDE.md
├── SEO_PLAN.md
├── CONTENT_MAP.md
├── INTERLINKING_PLAN.md
├── POSTING_SCHEDULE.md
│
├── /pillars
│   └── /[pillar-1-slug]
│       ├── brief.md
│       ├── keywords.md
│       ├── draft.md
│       └── final.md
│   └── /[pillar-2-slug]
│       ├── brief.md
│       ├── keywords.md
│       ├── draft.md
│       └── final.md
    └── [more pillars...]
│
└── /clusters
    └── /[cluster-1-slug]
        ├── brief.md
        ├── keywords.md
        ├── draft.md
        └── final.md
    └── [more clusters...]

Time & Token Breakdown

These numbers are directional, not a billing report. I tracked wall-clock time closely, but only checked token usage at a few points, so the token column is most useful for comparing which phases were cheap, moderate, or expensive.

The expensive bit was not “using Claude.” It was parallelising the work. Phase 3B alone created 23 brief agents at roughly 14,000 tokens each. Phase 5 then added the heavier drafting work. Phases 1, 2, 4, and 6 were useful, but they were not where the token budget went.

My takeaways

Prompt engineering made a huge difference

Not “give me feedback on this article”, but “read this as a Head of People Operations at a Series B startup who found it through Google, is busy and skeptical, and will stop reading the moment it stops being useful.” That precision is what made the feedback useful: Claude can’t give you honest criticism in the abstract. It needs a reader with a specific problem and a specific reason to bail.

The other high-leverage moment: asking Claude to critique its own output. The Phase 3D audit, asking Claude to find contradictions in documents it had itself generated, surfaced issues that might have stayed invisible otherwise. Claude doesn’t notice its own drift unless you explicitly ask it to look. The stricter you are about building in these review prompts, the more useful the output becomes.

As a non-professional content writer, going back and forth between different Claude sessions and models — asking each to critique the same piece — also helped me develop real instincts about what good content writing actually requires. The critique wasn’t just useful for the content, it was educational for me.

Prompting is good and automating is better

Running this prompt-by-prompt, session by session, was more cognitively expensive than I expected. Every new session meant re-establishing context, re-orienting to where I was in the workflow, reconstructing what decisions had been made. I was spending mental energy managing the process rather than thinking about the content.

The copy-paste approach is worth doing once, because it forces you to understand what each prompt is doing and why. But once you’ve run through it and refined the prompts, I’d want the system to carry itself. That’s why I created the companion workflow file.

Publish early, then edit like a human

The drafts are what I’d call “AI flavoured”, because you know it when you read it. The structure is solid, the briefs did their job, but there’s a faint signature of content written to a spec rather than content written with instinct. This harkens back to the content farms of the 2010s I mentioned earlier (horse medication!) but it’s a different writing style, just distinctly… not written by an actual person inside the actual business.

I’ve started publishing some of it, and it still needs sharp human editing before it really sings. That’s fine. A marketer once gave me advice I think about a lot: stake your SEO claim early (get the page up, get the slug indexed) and improve the article over time. If your goal is SEO, a good-but-not-great article that exists beats a perfect article that doesn’t. I’m not making any promises about Google’s algorithm here, but the principle makes sense to me. Publish, then refine.

The real gain was scale, not speed

I created Continuum Scheduler as a sci-fi project, not a real product. I did make a website for it, which is live at continuumscheduler.com, and you can see the blog posts going up there. Working through the content strategy for this surfaced thinking I hadn’t consciously done before, and I’ve worked on distributed teams. I’ve been on the 6am call and the 10pm call, I knew the cognitive overhead of trying to meet with my colleague in New Zealand and also think about waking up at 5am for a call when I’d rather be asleep. I never really thought about what the problem was, at a deeper level, and this workflow helped me do just that… go deeper. Designing a content strategy requires you to have opinions, and having those opinions tested makes them sharper.

This isn’t a “work faster” workflow, it’s a “work more powerfully” workflow. You’re not in the weeds, you’re thinking at a different level. Having now run through the whole thing, I want to be more precise about that. It is faster. Three and a half hours to go from a flakey strategy for a fictional sci-fi company to a complete content architecture, 23 writer-ready briefs, and 23 finalised articles, that’s faster than any solo human alternative. A small agency would take weeks and charge accordingly. But, this was done with minimal oversight from me, for the point of a demo and trialling a workflow. If you’re doing this for real, please do it with more finesse. Or else, I’ll be thinking about horse medication all over again.

It was also, genuinely, cognitively taxing in a way I didn’t expect. Directing a system like this (making the strategic calls, reviewing the outputs, catching the contradictions) is a different kind of mental effort than writing. It’s architecture work, not execution work, and as more of us are getting on board with Claude Code, we’re getting used to this kind of cognitive overhead. You might need to go and touch grass a little bit more often with this kind of work.

Download the companion workflow file and drop it into your Obsidian vault and run the whole thing from a single claude session. And let me know what you create.