I have built YouTube repurposing twice: once as a product (Tube2Blog, my tool that turns videos into blog drafts) and once as an internal pipeline for my own channel and this blog. That double exposure taught me the thesis of this post: repurposing is not a scheduling problem, it is an angle problem. Any automation can move a transcript from platform A to platform B. The hard part is that a YouTube walkthrough, a LinkedIn post, and a blog article are three different arguments aimed at three different readers — and that is precisely the part Claude Cowork's plugins are good enough to automate now, with one gate I still refuse to remove.
Here is the machine as I actually run it, including the part of the original vision that turned out to be wrong.
The shape of the pipeline
The flow has four stages, and keeping them separate is what makes the system debuggable:
- Detect — notice a new video on the channel.
- Extract — get the transcript and the video's actual claims into a working file.
- Transform — produce per-platform drafts, each with its own angle, from that file.
- Gate — a human approves anything that publishes. Always.
Cowork's role is stages 1–3, orchestrated through a scheduled task and executed with plugins and connectors. Stage 4 is deliberately manual, and I will defend that below.
Where Cowork plugins actually fit
Cowork's extension model has two halves that people conflate: connectors reach into your apps (mail, calendars, project tools), while plugins extend what a session can do. Scheduled tasks — added to Cowork in the February 25 update — tie the two together: the task saves your prompt as standing instructions and runs it on a cadence, using whatever connectors and plugins you have configured. That combination is what makes a repurposing machine possible without writing a custom backend: the schedule is the trigger, the plugins are the hands, the instructions are the brief.
If Cowork itself is new to you, start with my full Cowork AI employee guide — this post assumes the onboarding discipline described there (scoped folders, earned connectors) is already in place.
An honest correction: there is no magic webhook
The fantasy version of this build — the one I originally wanted — is event-driven: video goes live, machine fires instantly. Cowork's scheduled tasks are cadence-based, not event-based, so my "trigger" is actually a recurring sweep: the task checks the channel for new uploads since the last run, and does nothing if there are none. In practice this distinction costs nothing — repurposed content does not need to ship within minutes of a video — but I am spelling it out because the gap between "triggered by the moment the video went live" and "a scheduled sweep that notices new videos" is exactly the kind of detail that separates people who run these systems from people who write about them.
The sweep's first action is writing a working file into the pipeline folder: video title, URL, transcript, and a short list of the concrete claims made in the video. Everything downstream reads from that file, never from memory — the same files-as-interface rule I use in every multi-session agent pipeline I run.
The transform stage: one transcript, three arguments
This is where the machine earns its keep, and where my Tube2Blog experience shaped the instructions most. The naive transform is summarization, and summarized transcripts read like summaries — flat, voiceless, obviously derivative. The transform that works asks a different question per platform:
- Blog: what would someone search that this video answers? The draft restructures the material around that query, adds what the video could not show (code blocks, links), and drops the verbal filler that works on camera.
- LinkedIn: what is the one professional lesson in here? A LinkedIn draft is an opinion with evidence, not an announcement with a link.
- X: what is the sharpest single claim? One claim, stated plainly, thread only if the material genuinely has steps.
Two rules in the standing instructions do most of the quality work. First, a verbatim constraint: the draft may quote the transcript exactly or paraphrase with attribution, but may never invent a quote — transcripts are messy, and models under pressure to "clean up" a quote will happily improve what I never said. Second, a brand-voice constraint carried in a skill rather than re-prompted each time; packaged procedures are how you keep ten runs consistent, and my Cowork skills guide covers how I structure those.
The gate I refuse to automate
Drafts land in a review folder; nothing publishes without me. I keep this gate for a reason that has nothing to do with model quality: repurposed content carries my name into feeds I do not monitor minute-to-minute. A hallucinated detail in a draft costs one edit; the same detail published under my byline costs trust I have spent years building. The approval step takes minutes per batch, and it is the correct price. My rule across every automation I run — this one, and the SEO and social pipeline on this site — is that automation ends where my byline begins.
This also changes how you should measure the machine. The honest metric is not "zero-touch publishing"; it is that the marginal cost of repurposing a video dropped from an afternoon of writing to a review pass over drafts that already exist. That is the entire economic point, and it survives the human gate intact.
What broke, so you can skip it
- Over-connected first build. My first version had every connector I might want. Unused connectors are pure attack surface — Cowork reads content, content can carry hostile instructions, and the fix is granting reach the way you grant folder access: only what the job needs.
- One mega-session doing everything. Detect-extract-transform-gate as a single heroic run degrades unpredictably. Splitting stages around file handoffs made failures local and retries cheap.
- Letting the drafts share an angle. Early runs produced three lengths of the same summary. The per-platform question framing above was the fix; it went into the standing instructions and the quality jumped immediately.
For the video-production side of this pipeline — where the YouTube content itself comes from — my Higgsfield video workflow covers the upstream half.
The feedback loop that keeps it improving
The review gate produces a byproduct most people throw away: rejections with reasons. When I edit or discard a draft, the reason — wrong angle, too promotional, buried the interesting claim — goes into a short notes file in the pipeline folder, and every few weeks those notes get folded back into the standing instructions and the brand-voice skill. This is the difference between an automation that plateaus at week-two quality and one that keeps climbing: the machine cannot learn from silent edits, but it absolutely improves from edits that leave a trace. Ten minutes of instruction-tuning per month has done more for draft quality than any model upgrade in the same period.
Should you build this?
If you publish video and do not repurpose it, you are leaving your best material stranded on one platform, and this is now a weekend build on infrastructure you already have. Start with the sweep and the blog draft only, run it for two weeks, then add platforms one at a time as the drafts prove out. Keep the gate.
Building this for other people's channels is part of my client work: the sweep, the per-platform briefs, and the guardrails that keep a byline safe. The door for that is my contact page — those conversations usually start with someone showing me a year of videos that never left YouTube.
