Inside Nate Herk's Claude Code + Blotato Content System

Nate Herk built a Claude Code skill that turns one YouTube URL into a finished LinkedIn post, Instagram carousel, and X post, and he built it on top of my API. I watched the whole thing with the uncomfortable attention of someone whose product is being stress-tested on camera in front of a very large audience.

Then he pasted his prompt and said this, out loud, on video: “I kind of use this templated prompt from Sabrina. So shout out Sabrina.”

Nate is one of the most-watched AI automation educators working today, north of 900,000 YouTube subscribers, and when someone who teaches this for a living builds on your API in public, you get to watch a genuine expert hit your rough edges in real time. He hits three of them in seventeen minutes.

So this post is me reading someone else’s build of my own product, using my own prompt template, and telling you which parts to copy and which parts I would do differently.

How Nate Herk Built a Social Media Skill in Claude Code (Video Guide)

This is the full 17-minute build from Nate Herk’s channel, published in March 2026. The written breakdown below adds the part a tutorial cannot: which of his choices hold up five months later, where the API has changed underneath him, and the three things I would build differently.

The Prompt That Made This Work

Most people watching that video will copy the skill. The thing actually worth copying is one sentence Nate appended to the end of his build request.

He asked Claude Code to create a skill called “repurpose YouTube video,” described the output he wanted, and then closed with this: ask me clarifying questions one at a time until you are 95 percent confident that you can complete the task successfully.

That single line is why his build works and most people’s do not. It converted a vague request into an interrogation. Claude asked him what language to build in, whether the tool should auto-publish or stage for approval, whether an LLM should rewrite the copy per platform, what tone each platform gets, what kind of Instagram post to make, and how he wanted to review the output.

Nate answered “whatever you think is best” to the language question and got Python. He answered the approval question with a hard requirement: always make sure I review it before you ever publish anything on my social media accounts. That answer is the single best decision in the entire build, and I will come back to it.

The reason this matters more than the skill file: a skill built from an interrogation encodes your preferences. A skill built from a one-line prompt encodes the model’s defaults. Same tool, completely different output quality, and the difference costs you ninety seconds of answering questions.

If you want to run this pattern against your own accounts, you need API access, and this is the one place I have to be direct about how our billing works. The 7-day trial covers the app but explicitly excludes the API, and generating an API key from Settings ends the trial and starts the paid Starter plan immediately. So if you are building an agent workflow rather than testing the web app, plan on starting the subscription rather than trialing it. I would rather you know that before you generate a key than after.

Reading Nate’s Architecture as the Person Who Wrote the API

Here is his own whiteboard of the flow, drawn in the video before he built anything.

The diagram says the transcript extraction happens on our side. What his build actually did was different, and the difference is instructive.

When he ran it, Claude Code tried to fetch the video itself and came back with “YouTube is blocked by the web fetch tool. Let me try alternative approaches.” Claude routed around it and got the transcript another way. So the planning diagram and the shipped build disagree about who does that step.

Both are legitimate, which is the interesting part. Our source extraction endpoint does accept youtube as a source type alongside article, pdf, audio, and four others, so the whiteboard version is buildable exactly as drawn. Nate’s agent simply solved the problem before it got there. If you are copying this build and your transcript step is flaky, that is the fix: hand the extraction to the API rather than letting the agent improvise a scraper.

The division of labor in the working version comes out like this. Claude Code owns the reasoning, the transcript, the per-platform rewriting, and the file organization. The API owns visual generation from templates and the actual publishing. That split is the correct one, and it is worth stating plainly because several AI-generated summaries of this video get it backwards. It is also the same split I run on my own Claude Code setup, for the same reason: the agent should own judgment, and the API should own anything that touches a live account.

What Happens on Run One (Nobody Shows You This Part)

Most tutorials cut the failures. Nate left his in, and this is the most useful footage in the video.

The first real run produced the text posts and then failed on the visuals. Rather than hand-patching it, Claude wrote a “Known Issues and Findings” section into the skill document itself.

The second run fixed three separate bugs and logged them.

Read those three bugs, because two of them are about our API and one is a lesson about template systems generally. It was reading the status field at the top level when the response nests it inside an item object. It was auto-selecting the first template in the list, which happened to be a video template, when it wanted images. And it was sending a free-form prompt where the endpoint wants structured JSON matching each template’s input schema.

Then Nate asked for his profile picture and a verified badge on the carousel slides, and the agent found something I would not have thought to document as a headline feature.

It discovered that image template inputs accept base64 data URIs, so there is no external hosting step and no upload endpoint needed for a small brand asset. It also hit a size ceiling, resized the image to 400x400, and wrote that constraint back into the skill so future runs start from it.

This is the actual argument for the skill format over a one-off prompt. By his own count he ran it twice, and it got measurably better each time, because each failure became a line in a file rather than a thing he had to remember. He makes the point himself: imagine what this looks like after ten runs with feedback each time.

Three Things I Would Build Differently

He built this in one sitting as a teaching demo, and there are three changes I would make before running it against a real audience. The first is a real gap. The other two are refinements.

Decide what happens when a post fails, before it fails. This is the one thing genuinely missing from the build, and it is invisible until the day it matters. Publishing through our API is asynchronous. The create call returns a submission ID, which is a receipt, not a confirmation. Proof requires polling the status endpoint until the post reaches a terminal state, and a post queued for a future time sits in a non-terminal state until it actually fires, so an agent that blocks on the result of a scheduled post will sit there far longer than whoever wrote the loop expected. Failures are usually permanent rather than transient, so the right move is to read the error message rather than retry blindly. A demo never hits this because you are watching it run. An unattended pipeline hits it the first week, and if nothing is checking, the failure is silent: you think you published all week and you published nothing.

Move where the review gate lives, without weakening it. He was right to demand manual review, and that instinct is the correct one. My change is smaller: his review happens by reading files in a drafts folder, which works when you are at your desk and does not when you are not. Publishing is the one step in this pipeline that cannot be undone. Scheduling instead of instant-posting gives you a real window to cancel, and our schedule endpoints let you update or delete a queued post right up until it fires. Same gate, more forgiving failure mode.

Give it your brand context before you scale it, not after. Nate flags this himself and then moves on, which is the right call in a setup tutorial and the wrong one in production: the agent knew nothing about his business, his colors, his logo, or his previous posts. He is explicit that he gave it nothing and got usable output anyway. The gap between “usable” and “publishable without editing” is almost entirely context, and the cheapest version is a single file with your positioning, your banned words, and three posts that performed well. That file does more for output quality than any prompt tuning.

The Part Where He Cleans Up the Project

The last four minutes are file organization, which is easy to skip and worth watching.

He ran /init to generate a CLAUDE.md file from the existing project structure, then noticed four Python scripts sitting loose in the root and asked Claude to move them into a scripts folder and update every reference to them.

His rule of thumb: keep CLAUDE.md under about 150 lines, because it loads before every single message and a bloated one burns your context window on every turn.

The reason this matters for a content pipeline specifically is that you are going to keep adding skills. Nate names the obvious next ones: a skill for finding inspiration, a skill for short-form video. Each new skill compounds against a project the agent understands and fights against one it does not. If you want a sense of where that ends up, I keep a running set of the Claude skills I actually use for social media, and the same structural rule applies to all of them.

Where This Build Is Now Five Months Old

The video is from March 2026 and I am writing this in August, so a few things have moved underneath it.

The most useful change: analytics coverage has expanded well beyond where it was. Published-post metrics are now collected for eight of the nine platforms, with LinkedIn the only one returning nothing yet, on every paid plan. That opens a loop Nate’s build could not close in March, because the same agent that published a post can now ask which posts actually performed. Closing that loop properly still takes work he did not build: something has to retrieve the numbers, decide what counts as a win, and write that judgment back into the skill.

Engagement is the honest limit. Reading and replying to comments and DMs works on Instagram and Facebook, not across all nine publishing destinations. If your plan is an agent that runs your whole inbox everywhere, that is not today.

One thing worth flagging because it still catches people: he used OpenRouter instead of an Anthropic key for the content rewriting, which is a reasonable call and still works. Just note that it splits your setup across two bills and two failure points, so when the copy comes back wrong, check which model actually wrote it before you blame the skill.

Nate Herk’s Claude Code and Blotato Setup FAQs

Do I need to know Python to build this?

Not to get started. Nate answered “whatever you think is best” when Claude asked what language to use, and it chose Python on its own. He never hand-wrote the scripts, though he did direct, review, and debug them, and that reading is the actual skill here. What you need is the ability to describe the output you want precisely and to recognize a bad result when you see one.

Can Claude Code post to all nine platforms, or only the three in the video?

All nine are available. Nate only wired up LinkedIn, Instagram, and X because that was his demo scope, and he says on camera that it could do six more. The publishing call is the same shape with a different target, so adding one is mostly a prompt change, but each platform still brings its own media rules and account connection, so budget a little more than a one-line edit.

What is the difference between a Claude Code skill and just prompting it every time?

A skill is a file the agent reads before it works, so your corrections survive. Nate’s first run failed on visuals, and rather than fixing it in chat, the agent wrote the failure into the skill document. The next run started from that knowledge. A one-off prompt loses everything the moment the session ends.

Why did his first run fail, and will mine?

Probably, and that is fine. Every failure on the first pass is the kind of thing an agent finds and fixes on the second, provided you tell it to write what it learned back into the skill file. That instruction is the difference between a build that improves and one that breaks the same way every week.

What I Would Actually Tell You to Copy

If you take one thing from Nate’s build, take the clarifying-questions line, not the skill file. The skill file encodes his tone rules, his platform choices, and his review preferences, and none of those are yours. The interrogation pattern is what produced a skill worth keeping, and it works on any build, not just this one.

The whole thing works because of two moves that cost almost nothing. Questions up front turn a vague request into a specification. Logged failures turn every bad run into something the next run already knows. Add the review gate Nate insisted on and the status polling a demo does not need, and you have a system that gets better while you sleep instead of one that surprises you in public. Build it deliberately over an afternoon rather than letting it publish something you have not read.