How to Repurpose One Idea Into Five Platform-Native Posts With Claude Code

Most people who start taking content seriously go through the same sequence. You have an idea you like, and you write it up for LinkedIn. Then you sit down to write the X version and the Threads version, and by the fourth one you are bored of your own idea, so the fifth comes out noticeably worse than the first. Nobody keeps that up for long, and the usual next step is to write the post once, paste it into five places, and call the result repurposing.

It does not work, and the reason is not that your writing got worse. The reason is mechanical. This guide writes out the method I use instead, in full: the files it runs on, how to fill them, how to watch the system fail and repair it, and the parts I still will not hand to an agent. It is the written version of a workshop I recorded, and the video sits above this article if you would rather watch the run happen.

Everything here is running in my own business. I spent fifteen years at Google and eBay running go-to-market and analytics across 208 markets, and I now run an AI-native growth agency, Ravenopus, built on more than thirty AI agents. The method below is one function inside that system, alongside the ones that handle research and reporting, and it has run my own publishing since July 2026.

Why one caption cannot work on five platforms

The five platforms you would be pasting into do not rank posts in the same way. Each one is, in effect, asking a different question about the post you hand it.

• LinkedIn asks how long you stayed. It ranks partly on dwell time, which is the number of seconds a post actually held someone.
• Threads asks what you are likely to do next. Meta publishes the list of predictions its feed makes, including whether you will reply and whether you will scroll straight past.
• X asks a similar question but shows its working. It has published the code that ranks the feed, which predicts about two dozen separate actions on every post and weights each one.
• Instagram asks something different again. It runs a language model over the post itself to judge how informative it is, and that judgment feeds what gets recommended to people who do not follow you.
• TikTok asks the bluntest question of the five. Its community guidelines label the content the For You feed will not recommend at all, so the first question is not how a post ranks but whether it is allowed to compete.

One caption answers one of those questions, if you are lucky, and underperforms on the other four. You then look at the numbers and conclude that those four platforms are dead for you, when what actually happened is that you sent them a post built for somebody else’s ranking system.

Why better prompts do not fix it

You can try to solve this with prompting, and it partly works, but it does not hold, because you never type the same prompt twice. You write a good one on Monday, and on Thursday you are in a hurry and the Thursday version is missing the two clauses that were doing all the work.

What fixed it for me was writing the rules down instead. I keep one file per platform that says what that platform rewards and what it punishes, and the agent writes against the file rather than against whatever I happened to type that morning. The prompt itself becomes a single disposable line, because everything that matters lives somewhere it cannot drift.

The platform physics file

I call it the platform physics file. There is one per platform, and it is a plain text file with headings in it, with nothing to log into and no dashboard. Mine live in a folder called physics, one file for each channel I actually post on.

The file has ten sections. Six of them do most of the work, and when you open a ten-section file for the first time it is not obvious which six, so here is the full layout with those six marked.

#	Section	What it answers	Where the answer comes from
1	My lane	Who am I reaching here, and about what?	You
2	The ranking engine	What does the platform say it rewards, and what does it demote?	The platform’s own documentation
3	The one lever	If I designed for only one signal here, which one, and what changes?	Your decision, read from section 2
4	Format	Which formats does it reward, in what order?	Platform documentation and large-sample studies
5	Shape of a post	How it must open, how long it runs, how it ends	Studies first, then your own teardown
6	Cadence and timing	How often, how far apart, and when	Studies first, then your own analytics
7	Harvested patterns	Which shapes of post have actually won in my niche?	The teardown loop, on your own posts
8	Corrective lines	What does the agent keep getting wrong here?	You, every time a draft is wrong
9	Off-limits	What will I not do on this platform?	You
10	Sources and dates	Where did all of this come from, and when was it checked?	You

Four of the six are the sections you would expect. The other two are the reason the method works at all, so they are worth taking slowly.

The ranking engine, including the half nobody writes down

Section 2 asks what the platform rewards, and it also asks what the platform demotes or will not recommend at all. That second half is the part almost nobody records. Nearly all platform advice is a list of things to do, and almost none of it lists what quietly gets you suppressed. Suppression is what actually damages accounts, because nothing ever tells you it is happening; you simply get less reach and conclude that you got worse at writing.

Here is how one line in that section gets made. The first thing in my LinkedIn file is dwell time. LinkedIn’s engineers have published their reasoning: clicks and viral actions are rare and binary, clicks are noisy as well, and dwell is the one thing they can measure every time a post is shown to someone. They also describe a model that predicts how likely you are to scroll past a post, and they reduce a post’s score in proportion to that prediction, which means scrolling past is not neutral and actually costs you. So the line I type into the file is a working instruction rather than a summary of the research: write to be read to the end, not to be liked.

Write the absences down as well. Meta, for example, publishes the list of predictions behind the Threads feed but no weights for them, so nobody outside Meta can tell you which of them matters most. That absence belongs in the file, because it tells you exactly how much to trust anyone who quotes you a multiplier.

The one lever, which has to be able to reject a draft

Section 3 is the one people get wrong most often. It is not a summary of the ranking engine. It is a decision: you read the signals you wrote into section 2, you pick the single one you are going to design for, and then you write down what you will now do differently because of it.

That last line has to be something that can actually reject a draft. “Focus on engagement” cannot reject anything, because there is no post it says no to. “Is there a line in this that somebody could disagree with out loud?” can, because you either find that line or you admit there is not one. Expect to choose a different lever on different platforms; if your answer is the same on all five, you have probably written a general belief about content rather than a reading of each platform.

The one rule before anything goes in: tag where every line came from

This rule is the whole difference between a physics file and a folder of screenshots of somebody’s LinkedIn advice. Every line in the file carries one of four tags.

• Official: the platform said it itself, in its documentation, engineering blog, help center, or published code.
• Measured: a third party published a study that states its sample size and its method.
• Mine: you measured it on your own account.
• Folklore: you have heard it everywhere and cannot find a source.

Folklore still gets written down, deliberately, and that is the step people skip. Take the claim that a comment is worth fifteen likes on LinkedIn. It appears on a great many slides, so I went looking for where it came from. LinkedIn has never published a comment-to-like ratio, either on its engineering blog or in its help documentation, and nobody outside LinkedIn has credibly measured one. So the claim goes into the file tagged as folklore rather than being deleted, because if I simply deleted it, I would read it again in six months on someone else’s slide and type it straight back in. I also do not replace it with a better number, because there is no better number to put in its place. What is documented is the direction, which is that comments matter more than likes without any published measure of how much, so the direction is what goes in.

If a line cannot take any of the four tags, it does not go into the file at all.

Shape of a post: keep the limit and the target on separate lines

Section 5 holds two things that are easy to confuse, so they belong on separate lines. The first is the opener rule, which concerns only the first line; mine for X says the first line has to work as the entire post, and that if it needs the second line to make sense, it is a preamble rather than a hook. The second is the length band, which concerns the whole post.

Within the length band, keep the platform’s hard limit apart from the band that actually performs. One is what the platform will let you type and the other is what works, and they are often nowhere near each other. On X, for instance, the ceiling depends on your account tier, and even on a long-post tier the feed folds the post behind a “show more,” so the part that has to earn the tap is still the first couple of lines. Threads, by contrast, has a 500-character cap that applies to everyone. LinkedIn’s cap is 3,000 characters. The “800 to 1,000” band you will see everywhere has no study behind it; it is usually credited to a large industry report of about 1.8 million posts, but that report’s own summaries give a different band (700 to 900, for image captions only), and it has never published its method. So no length band goes into my LinkedIn file at all, not even tagged as measured: length is a judgment call until your own numbers in section 7 overrule it.

Writing to hit a number is how you end up padding. No prompt reliably produces posts that differ this much in shape from platform to platform; you can ask for it and get it some of the time, and the inconsistency is exactly the problem, whereas the file has the spread written down every time.

Corrective lines: the section that grows

The file I actually run is much longer than a blank template, and it got that way one line at a time. Every time the agent writes something I do not like, I add a line to the section it got wrong instead of just fixing the post. That is why section 8, corrective lines, is by far the longest section in my files; every line in it records a mistake I only had to see once. The failure demonstration further down shows three of those lines being written.

I am describing the shape of my files rather than their contents, because mine are specific to my lane and would be wrong for yours, which is the whole argument for building your own.

Harvested patterns: the teardown loop

Almost everything in sections 2 through 5 can be looked up, either in a platform’s own documentation or in a published study. Section 7 cannot. It is the half of the file that concerns your audience rather than the platform: whether your readers want a personal story or a firm opinion, and whether your posts land better when they close on a question or simply stop. No ranking document will ever tell you that, so you have to get it by taking apart posts that actually won in your niche, starting with your own.

That is also why it lives in a separate section. When a platform changes something, you re-verify section 2, and section 7 remains yours.

The way to fill section 7 is a teardown. I run it in five steps, and the kit writes it out in nine, because it also covers coding more dimensions, testing what you find one pattern at a time, and re-running it later.

Step 1: Pull your posts. Take the last three to six months of posts from your lane on one platform, which usually means twenty to forty posts, together with their numbers from the platform’s own analytics. Start with your own account if you have enough posts, because your voice and your audience are then held constant, and any difference you find is a much cleaner reading on form. Other people’s accounts in your lane can supply ideas to test, but never conclusions, because you cannot see their reach.

Step 2: Rank by a ratio, never by raw counts. This step decides whether the rest is worth doing. Raw likes and raw views mostly tell you which post is oldest and which one got lucky. Put whatever you chose as your lever in section 3 on the top of the ratio, and reach (however many people saw the post, measured the same way for every post) on the bottom. Write that choice down before you open the data, so you cannot later pick the metric that flatters your favorite post. If you rank by raw likes, your top group is simply the posts that traveled furthest, and the differences you find will be the differences between big posts and small ones, which you already knew.

Step 3: Take the top fifth and the bottom fifth. Use the same accounts and the same window for both. Without the losing posts you are not analyzing anything, only describing successful ones, and every successful post has a hook, a point, and a reason to care, so you learn nothing. The information is entirely in the difference between the two groups. Before you look for patterns, set aside any post that something other than its form probably carried, such as a reshare from a much larger account or a news moment, and note why.

Step 4: Code every post on the same dimensions, then ask only for the differences. Hand an agent both groups with their numbers attached and have it note the same handful of things about each post: what type of first line it opens with, how long it is, whether it contains a specific number or stays abstract, what format it uses, and whether it ends somewhere a reader can respond or closes the subject off. Two instructions in that prompt do the real work. The first is to report only the dimensions where the top group and the bottom group actually differ, and, where a dimension looks the same in both groups, to say so and drop it. The second is to give no advice and no encouragement to be authentic, only the deltas. That second instruction sounds rude, but it matters, because every model wants to end on encouragement and you asked for the differences. The ready-to-paste version of the prompt is in the free kit.

Step 5: Write what survives into section 7, dated and graded. Each difference that holds up goes into the file with the date and a confidence level of high, medium, or hypothesis. A pattern that repeats across at least three winners and is largely absent from the losers can be high; a single instance is a hypothesis, worth testing in a post and not yet worth asserting. Then test the patterns forward, one at a time, and re-run the teardown every quarter, after any post that breaks out, and whenever the platform announces a change.

What one honest result looks like

The cleanest result I have had from this came from my own LinkedIn account, and it only makes sense with its caveat attached.

There were two posts by the same author, six weeks apart, in the same register, both decently written and both with a strong first line. One is among my best posts and the other is the single worst post on my account: a 3.02% engagement rate against 0.24%, or roughly thirteen to one. The only difference I can see is the last line. The winner ends on a direct question, while the loser ends on a statement that is true and well put but leaves the reader nowhere to go.

That is two posts, however, which makes it a lead rather than a measured rate. The losing post was also doing two other things wrong at the same time, so I cannot honestly assign the whole gap to its last line. It therefore went into section 7 tagged as a hypothesis, with a date on it, and I watched the next twenty posts to see whether it held. The date exists for exactly that purpose: platforms change and so do audiences, and an undated file is one you will eventually be confidently wrong about without knowing which line went stale.

Run it, watch it fail, and fix the file

This is the part of the method that almost never appears in a tutorial, because tutorials tend to be written afterward, once everything already works. One idea goes in, five posts come out, one per platform, and each is written against that platform’s physics file. The whole system is the files plus an agent that reads them before it writes anything.

The setup

The prompt is one line: “Run the waterfall on idea.md, all five platforms.” It is deliberately short. The instructions live in a skill file, the rules for each platform live in the physics files, and how I sound lives in a voice file, so the prompt stays disposable, which matters because a long prompt is one you retype slightly differently every time.

For the demonstration I chose a deliberately ordinary idea. The idea file contained two lines. The idea was that nobody quits the gym because the workout is too hard; they quit because they walk in on the third day with no plan and do not know what to do first. The angle was that the thing that stops people is not effort but the blank five minutes at the start.

The idea file contains no warning about inventing statistics or making up a story about my gym. Those are not rules about this idea; they are rules about me, and they hold for every idea I will ever run, so they live in the voice file, written once. The general principle is that if you catch yourself typing the same instruction twice, it belongs in a file rather than in the prompt.

What came back

The LinkedIn post ran about nine hundred characters, opened on the scene, and ended on a question. The X post was 107 characters with one idea and no link. Instagram was fine. TikTok did not return a caption at all; it returned a script, with a hook in the first second and the on-screen text called out on its own line, because the format line in my TikTok file says to produce a script and never a caption. That is the file doing work that no prompt of mine had been doing.

Then there was Threads. Here are the X and Threads posts side by side.

X: “Most people don’t quit the gym because it’s hard. They quit because they walk in and don’t know what to do.”

Threads: “Most people don’t quit the gym because the workout is hard. They quit because they don’t know what to do when they walk in.”

On its own, the Threads post is a perfectly acceptable sentence. Next to the X post, though, it is clearly the same post. Being the same is not automatically a problem, since a post that worked on both platforms would save work rather than create it, so sameness is only the signal that tells me to look more closely. When I do, the X post is fine and the Threads post is not, and the reason is not that it resembles the X post. The reason is that it does not do what a Threads post has to do.

It is also worth noticing what did not happen. The two posts share no sentence; not one is carried over whole. My skill file says never to carry a sentence from one platform to another, and the agent followed that instruction exactly while still producing the wrong output.

Name what is wrong before looking for a cause

Before looking for a cause, I had to state what was actually wrong with the Threads post, and there were three things.

1. It closes. It leaves nothing for anyone to add, on the platform where whether someone will reply is one of the predictions the feed makes.
2. It wastes the room. It is 123 characters in a space that allows 500.
3. It is all conclusion. There is no scene in it, nothing a reader can picture. On X that is correct, because there is no room for one; on Threads, with five hundred characters to use and most of the people who would see it never having heard of me, a bare thesis gives a stranger nothing to stop for.

These three do not have the same standing, and it is worth saying so before acting on any of them. The first can be sourced: it comes straight from section 2 of my Threads file, which records Meta’s own published list of what the feed predicts, and replying is on that list. The other two are my judgment. The 350-to-500-character band is my decision not to waste the room, and needing a scene is my reading of a single bad post. Neither is measured, so when they go into the file they are tagged as mine, at hypothesis, with a date, and if the next twenty posts do not support them they come back out.

Find the bug in the file

Two of the three problems, the length and the ending, belong to the same section: section 5, shape of a post, which is the section that was supposed to prevent exactly this. So that is the section I opened, for both platforms at once, since the complaint was that the two posts came out the same.

My X file said to front-load the hook, prefer the concrete over the abstract, and keep to one idea per post. My Threads file said the same three things, with a 500-character ceiling added. Every rule in the X file was also true on Threads.

So the bug was not disobedience. I had written two files that agreed with each other and handed a model one idea, and it returned the shortest post that satisfied both sets of rules, which is an X post. Nothing anywhere in the Threads file said what a Threads post actually has to do. The prompt was not the problem; the file was.

Write the fix into the file, not the post

I did not touch the post. I opened the Threads physics file and went to section 8, corrective lines, which exists for exactly this purpose, and added three lines, one for each problem. Each line carries its reason, so that a future version of me does not tidy it away.

1. The last line has to leave something for a stranger to add. If it closes the argument, it fails.
2. Use the room: 350 to 500 characters. This is my own rule sitting inside Meta’s cap, not a second cap.
3. Put the reader somewhere. A post with no scene in it is a thesis rather than a post.

Those three lines fix the post that went wrong, but the larger lesson concerns what was in the file before I touched it. My Threads section said to front-load the hook, that concrete beats abstract, and that posts have a 500-character maximum. Every one of those is either a preference or a ceiling, and not one of them is something a post has to do. A 123-character post satisfies “500 maximum” perfectly; it simply does nothing with the room.

The test I take from this run is that if a line in your file can be satisfied by doing nothing, it is not finished yet. “500 maximum” needed a floor beneath it. “Concrete beats abstract” needed to say what concrete looks like on this platform, which is why the third corrective line is about a scene. And there was no rule about endings at all, which is why a post that simply stopped was allowed through.

That last gap is the uncomfortable one, because I already had what I needed. Section 3 of the file named replies as the lever I was designing for, but it never received its final line, the one that says what I do differently because of that choice. It said “replies” and stopped. The research had been done and never turned into anything the agent could follow, so the problem was unfinished information rather than missing information. It is also why every one of these fixes went into the file: had I corrected the prompt instead, I would have fixed this one post, whereas a line in the file applies to every post after it.

The re-run

I ran the same one-line prompt again. Nothing else changed anywhere except the three lines added to the Threads file. This is what came back:

“Why do people stop going to the gym? I’m fairly sure it’s not the workout.

It’s day three. You walk in, there are forty machines (and the two you know how to use are taken), no plan, and you stand there thinking about where to even start - and then you leave, and going back the week after is somehow harder.

That’s not discipline, that’s five blank minutes.

What could help? A written plan for the first month, from a trainer? Somebody walking you through one session? Anything else?”

The habit I most want you to take from this is checking the new draft against the corrective lines, one at a time. Does the last line leave something for a stranger to add? It asks what would help, offers two answers of its own, and leaves the door open. Is it using the room? It runs to 487 of 500 characters. Does it put the reader somewhere? It places them on day three, among forty machines, with the two they know how to use already taken. The post now works on Threads, not because it differs from the X post but because it does the things a Threads post has to do.

Section 8 is, in the end, a record of everything the agent has gotten wrong at least once, written down rather than remembered, so that it still holds on a day when you are tired and not paying attention. Plan for your first three runs to be bad. The first runs are where most of the corrective lines come from, so a bad early run is part of the setup rather than a sign it has failed.

Scheduling what comes out

I use four rules for publishing the output. Three of them are not algorithm rules at all; they concern how a queue looks from the outside and how to avoid shipping something that changed after you scheduled it. One of them is mechanical, and it is marked below.

1. Nothing publishes before 8:00 in the morning, my time. That is my own rule rather than a platform’s. If something goes out wrong, I want to be awake to catch it, rather than discovering at lunchtime that it published at five in the morning.
2. Vary the minute. Never schedule on the hour, or at fifteen, thirty, or forty-five minutes past. A queue that fires at nine, then nine fifteen, then nine thirty reads as a queue. Nobody is counting your minute hand, but it looks scheduled, and I would rather it did not.
3. Do not expect a second post in the same window to do much for you. This is the mechanical one, and it is what section 6, cadence and timing, is for. X’s published ranking code includes an author-diversity step: when more than one of your posts lands in the same load of someone’s feed, they are ranked against each other, your best one keeps its full value, and each additional one is discounted progressively. Because this works per feed refresh rather than per day, a filler post cannot hurt your good one; it simply does nothing for you.
4. Scheduled is not approved. This is the rule that has actually saved me. A post gets scheduled a week out, then the source draft is edited, and the queue is now holding a version you already rejected. I run a script that compares every future scheduled post against the file it came from and flags anything that no longer matches or still contains unresolved brackets.

In a single afternoon I once scheduled thirty-three posts across five platforms. That was not a matter of writing speed. Every timing decision had already been made once, in a file, so scheduling became one review pass rather than thirty-three separate decisions.

What I still will not hand over

Three things are never generated at all, and that list has not changed since I wrote it: the ideas, my own stories, and replies. The reasoning is the same for all three. Nobody follows me for my formatting or for the time I post; they follow for what actually happened to me and what I made of it, and if that part is generated, there is nothing left to follow.

The run that taught me this came early on, when one draft opened with a line along the lines of “I spent months thinking my video got buried for what it said.” It was fluent, well built, and sounded like me, and it never happened. I had never told the agent anything of the kind; the shape of the post called for a personal opening, so it produced one. One of the lines in my voice file comes directly from that run, and it does more work than anything else in the file: if you do not have the number or the story, write FILL in brackets and say what is missing, never estimate, and never go and source your own. The free kit ships with a version of that rule as a default.

Approval is a ladder, not a rule

You will hear in almost every AI workshop, including from people I genuinely respect, that there is nothing to worry about because a human approves everything. The word doing all the work in that sentence is “everything.” Most of what a system like this does never becomes a post at all: it pulls analytics, checks whether a scheduled post still matches the copy it came from, and sorts an inbox into drafts. I do not read any of that, and if I did there would be no time left for the parts that need me. A blanket rule therefore leaves two options, both bad: you quietly break it, or you never get any leverage.

Approval works better as a ladder, and which rung something sits on depends entirely on what it costs to be wrong.

Rung	What sits here	Cost of being wrong
Goes out without me seeing it	Which minute inside the window a post publishes; the company-page reshare of something I already put out	One wasted slot
Every post gets my eyes first	All posts, without exception, because a post in my voice is the whole asset. I am in the approval loop rather than the publishing one: I read it, and then the agent publishes it	A correction, and occasionally a legal one
I write it myself	The ideas, my stories, the replies	I stop being the person people were reading in the first place

The common mistake is putting something on the wrong rung, which is easy to do, because the right rung is rarely obvious until you have been wrong about it once.

The most expensive item on that list is replying. It may well be the highest-leverage thing I do, and it is also the thing I will not hand over, because a reply is a conversation with a specific person, and if it does not come from me, it is not worth having. So I am slower than I could be, I know roughly what that costs, and I pay it on purpose. You may well draw your line somewhere else. Whatever you decide, draw it deliberately and write it into the file, so that the line stays where you put it.

How to start: one file, this week

The whole system is a folder: five physics files, one voice file, the skill files that say what to do with them, and an idea file. All of it is plain markdown that you can open in anything. I run mine in Claude Code, but nothing in it is specific to that tool, and any agent that can read a folder will run it, which also means nobody can start charging you for it later. Claude Code itself does require a paid Claude plan; the free Claude.ai plan does not include it. If you have not installed it yet, the Claude Code Setup Guide covers that from the beginning.

Do not try to build five files at once. Build one:

1. Pick the platform where you already have some audience.
2. Fill in the six sections that matter, plus cadence and timing. Tag every line as official, measured, mine, or folklore, and date the file.
3. Run one idea through it.
4. Read the output hard and find the one thing that is wrong with it.
5. Add a line to the file to cover it, instead of fixing the post, and run the idea again.

Then keep repeating the last two steps. Most of the skill is in that loop, and once it is running, adding the remaining platforms goes quickly.

Get the files

The free kit. The Content Waterfall Kit is the folder described above, ready to install: a blank physics file for each of the five platforms with all ten sections, the voice file, the teardown prompt ready to paste, and three commands. /waterfall-setup interviews you and fills in the files so you are not staring at blanks; /waterfall, followed by an idea, gives you the five posts; and /waterfall-teardown runs the teardown loop and writes what it finds into section 7. The physics files ship blank on purpose, because the parts about your audience can only come from you. It is free, delivered by email.

The paid bundle. If you would rather not do the platform research yourself, the paid bundle contains the Content Waterfall Kit templates, the same ones the free kit ships, together with the Platform Physics Packs. The Packs are the same five files with the platform half already researched: what each platform publishes about its own ranking, taken from the source, and the format and timing figures from studies that state both their sample size and their method, where such a study exists. Every prefilled line is tagged and dated, every sourced claim names its source, and everything in the files that concerns you is left blank, because it has to be. The bundle is $197, at built-not-hired.com/platform-physics-packs.

One caution applies whichever version you use. Every prefilled line carries a date because this information moves quickly; in a single week in the summer of 2026, X went from publishing none of its ranking weights to publishing all of them. Check the date at the top of a physics file before you trust it, since a stale file is worse than an empty one: the agent will follow it confidently.

This is the Agent-Staffed Function pattern applied to one content surface: one accountable person, an agent, written rules, and a loop that turns every mistake into a line in a file.

Get the free Content Waterfall Kit →

See the bundle with the Platform Physics Packs →