video-autopilot-kit: a fill-in-your-own-data framework for YouTube and short-form pipelines

What video-autopilot-kit actually solves

Most creator tooling sells you a configuration. The README makes this the explicit contrast: systems on the market either hand you one person's setup, which does not transfer to your channel, or stay so generic that no methodology survives. This kit takes the third position. It ships the skeleton and a questionnaire, and SETUP.md walks through it section by section asking about your channel, your voice and your asset paths. The repository description calls it a fill-in-your-own-data framework, and the README repeats the claim that profiles/ and config.py are gitignored local files, so backend readings and personal profiles never enter the repository.

The intended user is a working editor or a small channel operator who already understands cutting and wants the decision rules written down as code. Three production lines are described: teaching long-form, vertical Shorts, and online interviews. Each one is deliberately built in the same shape, knowledge layer, mechanical gate, one-command driver, so learning one teaches the others. That symmetry is the actual product. The modules are secondary.

Three pipelines, one gate shell, and where the data flows

The README describes a single editor contract, Editkin v4, with the sequence source evidence, plan, audit, atomic apply, render. Python and ffmpeg sit underneath as the cross-platform support layer for asset analysis, normalization and QA. They are not a second editor runtime, and the README is blunt that the older GUI, draft JSON and Path A-E documents survive only as benchmark history rather than a fallback path.

The three gates share a shell, src/longform_maker/gate_core.py, which standardizes the return structure, assert messages and self-test printing. The README notes that gates you write yourself behave identically if they import three functions, while the decision rules stay in each gate's own file so they do not contaminate one another. That is a real design choice, not decoration: shared thresholds across a long-form gate and a Shorts gate would silently apply one format's calibration to another.

Data flow is roughly: knowledge documents explain why a rule exists, a gate blocks output that violates it, and an autopilot script drives the whole thing. For Shorts, src/shorts_autopilot.py runs scan, then you fill in text from looking at frames, then build, which includes automatic QA verification images. For interviews, src/interview_autopilot.py runs invite, then plan producing seven artifacts, then build. The interview gate blocks unsourced guest statistics before recording rather than after.

Installing video-autopilot-kit and running a first example

The README states the requirement plainly: Python 3.9 or higher. Examples 04, 05 and 06 need no ffmpeg, no pip install and no footage at all, which makes them the honest first step. Example 01 needs ffmpeg and ffprobe on PATH. Example 03 additionally needs Pillow and numpy, and requirements-media.txt exists at the repository root for the media-side dependencies.

Start with the vertical Short demo. It synthesizes test footage with ffmpeg and produces a complete 1080x1920 output, so you can confirm the pipeline runs before touching your own files.

python examples/01_vertical_short.py

If you want to see a gate reject something, run the Shorts gate demo. The README describes its sequence as a bad cut being blocked, a fixed version passing, your own thresholds passing, and a different platform passing.

python examples/04_shorts_gate.py

After that, verify the checkout itself. The README gives this command as the clean-install check.

python src/system_health.py --quick

The filter runtime is the other entry point worth trying early, because it is shared across long-form, Shorts and Reels. Listing the registry tells you what presets exist before you apply anything.

python src/filter_runtime.py list
python src/filter_runtime.py inspect torn_paper_vertical

Applying a preset takes an input and output path plus a preset name. The transition subcommand in the README requires a motivation string and a manual approval flag, which is the clearest sign of the project's stance: a transition without a stated editorial reason is not permitted by the tool.

The thresholds are example values, and the README says so

This is the limitation that matters most, and the project states it rather than hiding it. The Shorts duration band, the first-cut timing and the non-white-text cap inside the two gates are described as example calibration values, not universal constants. The README instructs you to recompute them from three to five of your own videos using the Shorts rule calibration section of SETUP.md.

That means a fresh clone will block or pass cuts according to someone else's channel. If your pacing differs from the calibration set, the gate is wrong for you until you recalibrate. This is a deliberate trade: shipping a gate with no numbers at all would make it useless out of the box, and shipping the author's numbers as if they were general would be worse. The v0.12.0 notes make the same argument about borrowed certainty, describing four places where an unmeasured number wore an authoritative label.

The platform awareness is a related constraint. The dead zone in the duration band was measured on YouTube Shorts, and the README notes that applying it to Instagram or Facebook would block normal cuts. The gate now selects the band through spec["platform"], with per-key rules still taking priority. A misspelled platform name is a blocking failure, not a silent fallback. That is the right call, but it means a typo in your config stops the run rather than degrading quietly.

One more boundary: the README states that OCR in src/teardown.py is optional. Without it, subtitle extraction is skipped and the exit code remains 0. If you rely on caption-derived metrics, an environment missing the OCR dependency will produce partial numbers without failing.

How it differs from a general-purpose editing automation stack

The obvious alternative is scripting ffmpeg directly, or driving an editor through its own automation surface. The difference here is not the rendering engine, since ffmpeg does the media work either way. It is that this project ships the editorial rules as executable gates alongside the media operations.

A hand-rolled ffmpeg script encodes your current habits. It has no opinion about whether a transition has an editorial motivation, whether a guest statistic has a source, or whether a Short's duration falls in a dead zone for the target platform. video-autopilot-kit puts those judgements in separate files with a shared return contract, so a failing run tells you which rule tripped. The README's filter runtime makes this concrete: apply, transition and gallery are separate subcommands, and the transition path requires --motivation and --manual-approved rather than accepting any two clips.

The cost of that structure is that you inherit someone else's rule decomposition. The gates are opinionated about what counts as a structural problem in a Short, and the interview gate decides which guest claims need sourcing. If your editorial judgement differs, you are editing gate logic, not adjusting a preference. Compare that with a plain ffmpeg pipeline, where the only thing to disagree with is your own script.

Licence, maintenance and the upgrade path

The repository is MIT licensed, which permits commercial use and modification with attribution. The README notes two named exceptions to the no-private-data rule, both of which it characterizes as public information: author attribution in LICENSE and the READMEs, and third-party public creators named in knowledge/ documents. The stated rule there is citation-first, meaning no number appears without a clickable source. If you redistribute a modified copy, the MIT terms apply to the code while the knowledge documents carry their own citation expectations. That is a description of what the repository says, not legal advice.

The last push was on 2026-08-27, and the most recent release listed is v0.23.0 on the same date, following v0.21.1 and v0.19.0 earlier in August. Releases are frequent and the version numbers move quickly. An install_or_upgrade.py script and a sync-receipt.json sit at the repository root, alongside AUTOPILOT_MANIFEST.json and release-manifest.json, which suggests the intended upgrade path is scripted rather than manual. The README's v0.23.0 note mentions safe automatic updates as part of the public release, though the truncated README does not document rollback behavior, so treat downgrade as unverified until you read the upgrade script yourself.

The upgrade cost is real for anyone who edits the gates. Rapid minor releases mean your local threshold changes and gate modifications can conflict with incoming changes, and the README's insistence that decision rules stay in their own files is partly what makes that manageable.

Editorial conclusion

Adopt it if you already edit video and want the reasoning layer written down as gates you can run: the examples under examples/ run without real footage, and system_health.py --quick tells you whether the checkout is intact. Skip it if you want a one-click editor, since the README states the old GUI and Path A-E documents are benchmark-only history rather than a fallback. Before committing, run the pure-Python examples, then read SETUP.md's Shorts calibration section and check whether you are willing to recompute the duration band, first-cut timing and non-white-text limits from three to five of your own videos.

Frequently asked questions

Official sources

1. Hao0321/video-autopilot-kit on GitHub
2. Issues
3. License: MIT
4. README
5. Releases