One Pillar Post Into 12 Platform-Native Variants With Make and Claude (My Actual Scenario Blueprint)

My Make scenario runs at 6:47 AM every Tuesday. By 7:03 AM, twelve platform-native drafts are sitting in an Airtable view, color-coded by status. The pillar post that fed them is a 2,100-word piece I dropped into a Google Doc the night before. Total monthly cost for the whole pipeline: about $4.20. I have not manually copy-pasted a pillar paragraph into a Claude prompt in nine months, and the quality of what comes out is better than what I used to ship by hand at 11 PM on a Sunday.

This post is the actual scenario blueprint — module by module, with the prompt template, the cost math, and the three things that break often enough that I built guards around them. If you have Make.com (the workflow tool formerly known as Integromat) on a paid plan and a Claude API key, you can rebuild this in an afternoon. I'm not selling a template; I'm describing the shape so you can adapt it.

The job the scenario does

One pillar post in. Twelve platform-native pieces out, written for the specific affordances of each surface:

• 3 for LinkedIn — one long-form text post, one carousel script (10 slides), one document-attachment teaser
• 3 for X (Twitter) — one standalone hook, one 5-tweet thread, one quote-reply prompt
• 2 for Instagram — one carousel caption, one Reel script (15-30 seconds)
• 2 for YouTube — one Shorts script (under 60 seconds), one Community Post poll
• 1 for the newsletter — a 120-word teaser blurb with a "read full" CTA
• 1 for Reddit — a comment-shaped hook for the relevant subreddit (no link spam)

Twelve isn't magic. The number forces the model to think across formats — fewer, and it just paraphrases the same point three ways. More, and you start getting filler. Twelve fills a calendar week and a half without repeating the same opening.

Each output goes into a single Airtable row keyed to the pillar, with columns for platform, intent, draft text, status (draft / approved / scheduled / live), and a "human-touched?" boolean. Nothing publishes itself. The scenario stops at draft — I do not believe in unattended posting to my own audience.

What you need before you build

Component	Why
Make.com Core or Pro plan	Free tier (1,000 ops/month) runs out by the 4th pillar. Core ($10.59/mo, 10K ops) is enough for ~30 pillars
Anthropic API key	Use a workspace key with a monthly budget cap. Claude Sonnet 4.5 is the default model here
Google Drive folder	Watched as the trigger source for new pillar drafts
Airtable base	Two tables: Pillars and Variants (one-to-many)
About 3 hours, once	After the first build, future tweaks are 10-minute edits

You do not need Buffer, Hootsuite, or any scheduler at this stage. Scheduling is a separate scenario downstream and not the interesting part.

The scenario shape

Top to bottom, the Make scenario has nine modules:

1. Google Drive — Watch Files in the /pillars/inbox/ folder (polling every 15 minutes during work hours)
2. Google Docs — Get a Document's Content to pull the markdown text
3. Anthropic Claude — Create a Message ("structure extraction" prompt — returns JSON)
4. JSON — Parse JSON of the structure output
5. Iterator over the 12-variant array (defined as a static array inside a Set Multiple Variables module)
6. Anthropic Claude — Create a Message ("variant generation" prompt — one call per iteration)
7. Text Parser — Match Pattern to extract the body, intent, and "why this format fits" rationale
8. Airtable — Create a Record in Variants, linked to the pillar
9. Google Drive — Move a File from /pillars/inbox/ to /pillars/processed/

That's 9 modules, but the Iterator multiplies module 6, 7, and 8 by twelve. So each pillar costs 9 + (3 × 12) = 45 operations in Make. On the Core plan's 10,000 ops, that's headroom for 222 pillars per month — vastly more than anyone actually writes.

Step 1: The structure-extraction call

Before you spawn 12 variant calls, do one cheap call that returns the pillar's bone structure. This is what makes the per-variant calls short and consistent. The system prompt for module 3:

You are a content strategist. Given a pillar blog post,
extract its skeleton as JSON. Return ONLY valid JSON:

{
  "thesis": "one sentence — the single claim of the post",
  "key_points": ["3 to 5 supporting points, each one sentence"],
  "best_quote": "the single most quotable line, verbatim",
  "counter_argument": "the strongest objection the post addresses",
  "primary_audience": "one phrase",
  "tone_words": ["3 adjectives that describe the voice"]
}

Pillar post:
<<<
{{2.content}}
>>>

This returns roughly 250 tokens of structured signal. The cost on Sonnet 4.5: about $0.004 per pillar. The reason to do this is leverage — instead of asking Claude to "read the post and write a LinkedIn post" twelve times (twelve full re-readings of the pillar), you let it read once, then hand the JSON skeleton to each of the twelve specialist calls. The variant calls run on ~400 tokens of input instead of ~3,500. That's the bulk of the cost saving.

Step 2: The variant matrix

The 12-variant array is a static JSON blob defined once in a Set Multiple Variables module. Each item names the platform, the intent, and any format constraints. Trimmed:

json[
  { "platform": "LinkedIn", "format": "long-form post",
    "intent": "contrarian hook", "constraints": "1300 chars max, no hashtags, one line break per beat" },
  { "platform": "LinkedIn", "format": "carousel script (10 slides)",
    "intent": "teach the framework", "constraints": "slide 1 is the hook, slide 10 is the CTA" },
  { "platform": "X", "format": "single tweet",
    "intent": "save-bait", "constraints": "under 280 chars, no link, one specific number" },
  { "platform": "X", "format": "5-tweet thread",
    "intent": "story-led", "constraints": "tweet 1 is the hook, tweet 5 is the takeaway" }
]

This JSON is what the Iterator chews through. Keeping it as a config blob means I can tune "I want more Threads, fewer Reels" by editing one module, not the rest of the scenario.

Step 3: The per-variant Claude prompt

Module 6 runs once per array item. The prompt template:

You are writing one social post derived from a pillar article.

PILLAR SKELETON:
{{4.structure}}

THIS VARIANT:
- Platform: {{5.platform}}
- Format: {{5.format}}
- Intent: {{5.intent}}
- Constraints: {{5.constraints}}

Write the post natively for this platform. Do not announce
that it is a repurposing. Do not include the words "in this post"
or "as I wrote about". Write as if this is the first time you
are making the argument on this surface.

Then on a new line write:
INTENT_CHECK: 
WHY_THIS_FORMAT_FITS: 

If you cannot make the variant work for this platform
(e.g. the thesis does not suit a Reel), return:
SKIP: 

The SKIP clause is important. Without it, Claude will dutifully cram a long argumentative essay into a 15-second Reel script and the result is unreadable. Letting the model refuse a bad fit is the single change that doubled the average draft quality for me. Skipped variants come back blank in Airtable, marked with a yellow flag, and I either accept the skip or hand-write that one.

Step 4: Parsing and storing the output

Make's Text Parser — Match Pattern module pulls the three sections out of each response (the body, the INTENT_CHECK, the WHY_THIS_FORMAT_FITS) using a regex with three named capture groups. Each goes into a separate Airtable field. The Variants table looks like this:

Field	Notes
Pillar (link)	The originating pillar
Platform	LinkedIn / X / IG / YouTube / Newsletter / Reddit
Format	long-form, thread, Reel, etc.
Intent	hook / teach / story / debate-bait / save-bait
Body	The raw draft
Intent check	Claude's self-assessment, useful for filtering
Format fit	Claude's reasoning, useful for filtering
Status	draft / approved / edited / scheduled / live
Human touched?	A checkbox I tick after editing

The "Human touched?" column is the single most important field in the base. Untouched drafts never publish. Period.

What it costs

The honest cost breakdown per pillar, at Sonnet 4.5 prices (input $3/M, output $15/M as of mid-2025):

• Structure extraction: 1 call, ~3,500 in / ~250 out = $0.014
• Variant generation: 12 calls × ~400 in / ~600 out = 12 × $0.010 = $0.120
• Total per pillar: about $0.13

At 8 pillars per month, that's $1.04 of Claude spend plus $10.59 of Make subscription = $11.63 total. Round to $1.45 per pillar in the marginal cost. The first version I built used GPT-4 for everything and cost about $0.40 per pillar — three times as much for output that was, in side-by-side review with the same editor, slightly worse on tone fidelity. Your mileage will vary; rerun the comparison every six months.

The three things that break most often

Google Drive trigger latency. Make polls Drive on a schedule, not in real time. If you drop a pillar in the folder and the next poll is 12 minutes away, you wait. Acceptable for the use case — but if you've ever tried to "demo this live" to a client, that wait is awkward. Either pre-trigger the scenario before the demo or use a webhook from Notion / Google Apps Script instead.

Anthropic API timeouts on long pillars. Anything over ~6,000 words and the structure-extraction call occasionally hits a 60-second timeout in Make's default. The fix is to add a Router module right after Get Content that branches on word count — if over 5,000 words, chunk the pillar into two halves, extract each, then merge the JSON skeletons in a downstream module. I needed this exactly twice in nine months, both for SaaS competitor breakdown posts.

The Airtable row limit. Free Airtable bases cap at 1,200 records. Twelve variants × 100 pillars = 1,200 rows. If you back-process old pillars in a batch, you'll hit it. Either move to a Team plan ($24/seat/mo for 50K rows) or archive shipped variants to a separate base. I went with archiving; I do not need scheduled IG carousels from 2024 cluttering the active view.

When NOT to automate this

Three conditions where I bypass the scenario and write by hand:

• The pillar is breaking news or has a deadline tied to an external event. The 12-minute trigger lag plus the human review cycle means you've lost the timing. Write the social posts first, the pillar second.
• The pillar's thesis is something you've never argued in public before. The model is interpolating from your previous voice. If the post is a sharp pivot, the variants will smooth the pivot out. Hand-write the first few until the new position is documented in your archive.
• You have under 10 pillars per quarter. The setup time is real. If you only ship one long post a month, just spend the hour by hand and stay closer to the work.

If none of those apply, the scenario is the better path. It is not faster than a human in raw minutes per pillar — total wall-clock from drop-to-approve is still 45 to 60 minutes including review. What it removes is the context-switching cost: the mental load of opening four browser tabs, remembering the LinkedIn character limit, recalling whether you already used that hook on X last week, deciding the Reel angle. The scenario absorbs the decision fatigue. You do the editing, which is the part you should actually be doing.

The 12-minute saved per platform isn't the value. The value is that the work happens at all on the weeks you are too tired to write.