Verticals v3 (youtube-shorts-pipeline): a topic-to-Short pipeline with niche profiles

What problem Verticals v3 solves, and for whom

The repository is named youtube-shorts-pipeline, but the product inside it is called Verticals v3, and the README is explicit that v2 was an esports news pipeline while v3 is a general purpose content engine. That distinction matters if you are searching for the older project: the command surface, the configuration model and the niche system all changed.

The problem it targets is assembly labour, not ideation. You supply a topic string and a niche name. The pipeline researches it, writes a 60 to 90 second script, generates b roll frames, records a voiceover, burns word level captions, mixes background music with voice ducking, renders a thumbnail, and uploads the result to YouTube as a private video by default. The README quotes roughly 90 seconds of finished video, about 3 minutes of wall time, and about $0.11 in API costs per run.

Who it is for: a solo creator or small team already comfortable with a terminal and API keys, who publishes short vertical video on a schedule and wants the mechanical stages handled. Who it is not for: anyone who wants a browser based editor. The README lists a Gradio UI as a roadmap item, not a current feature, so the only interface today is `python -m verticals`.

The seven stage data flow, and where the niche profile enters

The README's architecture diagram shows one input box labelled NICHE PROFILE, loaded once, feeding a linear chain: research, script, visuals, voice, captions, assemble, upload. Nothing loops back. Each stage consumes the previous stage's output plus the profile.

Research queries DuckDuckGo and can optionally scrape source URLs for live facts. The README frames this as the anti hallucination gate: the LLM is instructed to use only facts from research data and never its training knowledge. That is a prompt level constraint, not a structural one. Nothing in the described pipeline verifies that a generated sentence actually traces to a scraped page, so treat the claim as a design intent rather than an enforced guarantee.

Script generation runs through your chosen provider (Claude, Gemini, GPT, Ollama, MiniMax, LiteLLM, or the Claude CLI) and emits the voiceover script plus b roll image prompts, a thumbnail prompt, and platform metadata. Visuals generate three b roll frames through Gemini Imagen and auto crop them to 9:16; if image generation fails, the pipeline substitutes fallback frames so assembly can still finish. Voice runs through Edge TTS, ElevenLabs, MiniMax, 60db, or macOS `say`. Captions come from Whisper word level timestamps, exported as both burned in ASS and uploadable SRT. Assembly is ffmpeg with Ken Burns motion, background music, and automatic voice ducking.

The interesting engineering decision is that the niche profile is the only place creative direction lives. Tone, pacing, hook templates, CTA variants, word count, caption fonts, visual vocabulary and music mood all read from one YAML file. Fifteen ship in the `niches/` directory. That keeps prompt engineering out of the code, at the cost of making the YAML schema the real API surface you have to learn.

Installing Verticals v3 and producing a first Short

There is no published install command in the README beyond the module invocation, so installation means fetching the repository and installing the package defined in pyproject.toml. That file declares the distribution name `verticals` at version 3.1.0 and requires Python 3.10 or newer.

git clone https://github.com/rushindrasinha/youtube-shorts-pipeline.git
cd youtube-shorts-pipeline
python -m pip install -e .

The editable install pulls the runtime dependencies listed in pyproject.toml, which include `anthropic`, `google-api-python-client`, `google-auth-oauthlib`, `openai-whisper`, `PyYAML` and `edge-tts`. Whisper and the Google client libraries are the heavy ones. ffmpeg is not a Python dependency, and the assembly stage calls it directly, so it has to be on your PATH separately.

The README's own quickstart is a single command. Run it from the repository root so the `niches/` directory resolves.

python -m verticals run --topic "Sam Altman just mass-fired 200 safety researchers" --niche tech

Expect the stage sequence to appear in order, with the finished video uploaded as private by default. If the run dies partway, the README notes resumable stages, so re-invoking the same command is the documented recovery path rather than starting over.

Niche profiles are plain YAML. The README shows the shape of `niches/tech.yaml` with a `script` block holding `tone`, `pacing`, a `hooks` list of pattern and template pairs, `cta_variants`, and `word_count`. To build your own, copy an existing file and edit those keys.

name: tech
display_name: "Tech & AI News"
script:
  tone: "informed, slightly opinionated, conversational"
  pacing: "fast, dense with facts, no filler"
  word_count: "150 to 170"

If the profile parses and the API keys are present, the run proceeds; a malformed YAML file fails at load time, before any API spend.

Where Verticals v3 breaks or is the wrong tool

The most concrete limitation is documented by the maintainers themselves in the v3.1.0 release notes: edge-tts 6.x is rejected by Microsoft with 403 responses, which is why pyproject.toml pins `edge-tts>=7.0,<8.0`. If your environment resolves an older version, the free default voice path fails. That is an external service changing behaviour under the project, and it will happen again.

Every stage except assembly depends on a third party. Research depends on DuckDuckGo. Script depends on your LLM provider. Visuals depend on Gemini Imagen. Voice depends on Edge TTS, ElevenLabs, MiniMax, 60db, or macOS `say`. Upload depends on the YouTube Data API and an OAuth flow. A quota change, a pricing change or a deprecation anywhere in that list degrades the pipeline, and the README does not document retry semantics or rate limit handling for any of them.

The fallback frame behaviour is a trade-off worth naming. When image generation fails, the pipeline substitutes simple frames so assembly still completes. You get a finished video instead of a crashed run, but you also get a finished video with placeholder visuals, and nothing in the described flow blocks the upload. A pipeline that fails loudly might be the better choice if your channel's visual quality matters more than your publishing cadence.

The wrong tool cases are structural. If you need anything other than YouTube, this is not it yet: TikTok, Reels and X upload are listed as roadmap. If you need a container, Docker and Colab are roadmap. If you want to direct the edit rather than accept a Ken Burns pan and a mood matched music bed, the pipeline has no described manual override for the assembly stage.

One documentation inconsistency to note: the README's upload section says TikTok and Instagram export are coming in v3.1, while the release notes for v3.1.0 describe provider additions and caption fixes instead. Read the shipped feature list as authoritative when the two disagree.

How Verticals v3 differs from assembling the same stack yourself

The realistic alternative is not another single product. It is the same components wired together by hand: Whisper for word level timestamps, ffmpeg for the Ken Burns render and the ASS burn in, Edge TTS or ElevenLabs for voice, a Gemini or OpenAI call for the script, and the YouTube Data API client for upload. Every one of those is a dependency Verticals v3 already declares.

The difference in approach is the niche profile. In a hand built script, the creative direction lives in prompt strings scattered across your code, and changing the tone for a new channel means editing several files. Verticals v3 centralises that into one YAML file per niche that every stage reads. If you publish across multiple channels with different voices, that centralisation is the actual product, and it is the part you would spend the most time rebuilding.

The second difference is the stage contract. Because research feeds script feeds visuals feeds voice feeds captions feeds assembly, each stage has a defined input and output, and the README describes resumable stages on top of that. A hand rolled script usually couples these together, which makes partial reruns awkward. If you only ever generate one video at a time from start to finish, you will not feel the benefit.

What you give up by adopting it: control over the render graph. ffmpeg filter chains are generated for you, and the README describes Ken Burns motion, background music and voice ducking without exposing a documented way to substitute your own filter graph. If your visual style depends on transitions or overlays the pipeline does not generate, a hand built ffmpeg invocation will get you there faster than waiting for a config key.

Maintenance, upgrade cost, and the MIT licence

The last push to the default branch was on 2026-06-09, the same day v3.1.0 was released. The repository is not archived. That is roughly three months before today's date, which is recent enough that the project is not dormant, but the release history shows a single tagged version in the repository, so treat upgrade cadence as unproven rather than established.

Upgrade cost concentrates in three places. First, the provider pins: `anthropic>=0.39.0,<1.0`, `edge-tts>=7.0,<8.0`, `PyYAML>=6.0,<7.0`, `Pillow>=10.0.0,<11.0`. These upper bounds protect you from breaking changes but also mean you cannot take a major version of any of them without the project moving first. Second, the niche YAML schema: if a future release adds or renames keys, your custom profiles are the migration surface, and there is no described schema versioning. Third, the YouTube OAuth client, which is the kind of credential that expires or gets rotated independently of the code.

The licence is MIT, declared in the LICENSE file and referenced from pyproject.toml via `license = {file = "LICENSE"}`. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. What that does not cover is the services the pipeline calls: your LLM provider's terms, Google's Gemini and YouTube API terms, and the voice provider's terms each govern that stage independently of the code licence. If you run this for client work, the code licence is the easy part; the API terms are where the constraints live. This is a summary of the licence text, not legal advice.

Editorial conclusion

Adopt Verticals v3 if you already run Python 3.10 or newer, have ffmpeg on the box, and are willing to hold API keys for Google, an LLM provider, and YouTube upload. Skip it if you want a hosted editor, a Docker image, or non-YouTube distribution, because the README lists Gradio UI, Docker, Colab, TikTok, Reels and X upload as roadmap items rather than current features. Verify first that edge-tts resolves to the 7.x pin, that your niche profile parses under PyYAML, and that the YouTube OAuth flow completes before you point it at a real channel.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rushindrasinha/youtube-shorts-pipeline on GitHub