chengfeng-videocut-skills: the Codex Plugin entry point for a video editing agent

What chengfeng-videocut-skills actually is, and who it is for

This repository is not the video editor. The README describes it as the public Codex Plugin installation entry for chengfeng-videocut, and states plainly that the Runtime and Studio source and release artifacts live in a separate repository, chengfeng-videocut. The README also draws a line worth repeating: installing the plugin, preparing the Runtime, and finishing a video are three different things. Nothing here edits footage.

What it does provide is a set of agent-facing methods and confirmation tools. The default set is seven entry points: cutting spoken-word video, subtitles, visuals, export, bug reporting, update checking, and the newly added workbench operations skill. The README notes that the first six are the entries retained in the current release and should not be read as a final product list. That is an unusually honest framing, and it tells you the intended audience: people already running a Codex CLI with plugin support who want an agent to drive editing operations through a fixed, auditable install rather than a floating one.

Pinned identities: how the install avoids drifting with main

The mechanism here is pinning, not fetching. installer-manifest.json fixes both marketplaceRef and pluginRef, and the README states that installation does not follow main or stable drift and does not rewrite published tags or same-version content. The release table fixes the plugin at 0.10.11, the plugin content commit at d4580d8a0cef4fa34558b068945575d03e4c63ee, the install snapshot with provenance receipt at 6d798efb9940946c994d1f3e59f8ff2ea7446c31, and the workbench methods at v0.1.0-beta.1 / e9e78e0f3aefca1c38a1157817cc411e9757bb12.

One distinction the README stresses is easy to get wrong: the bootstrap's own commit and the plugin snapshot are not the same object, and the full SHA for the bootstrap revision comes from the v0.10.11 pre-release receipt rather than the table. The stable branch is described as a mutable discovery entry that cannot substitute for the install identities above. The workbench methods themselves are not rewritten inside this plugin; the README says they come from a fixed version in a separate repository, chengfeng-videocut-workbench. That is a sensible separation, though it adds a second place to check when something does not load.

Installing and running the first check with Node 18+ and Git

The prerequisites are Node.js 18+, Git, and a Codex CLI that is logged in and supports the codex plugin command. The README asks you to review the pinned source first, then run the installer from that directory. The dry run comes first so you can see what the installer intends to do before it does it. The README gives these three commands, and the third is the one whose output you should actually read.

node bin/install.cjs install --dry-run
node bin/install.cjs install
node bin/install.cjs doctor

The dry run should list the intended actions without changing anything. The install then calls the host's plugin commands and reads back the source, the cloned commit and the install status. doctor is the verification step: it reports what is installed and where it came from, so if the source line is not the pinned commit you expected, stop there rather than editing the installation by hand.

The installer's refusal behavior, and the Arborist failure

The installer only calls plugin commands the host supports, and it reads back the source, the cloned commit, and the install status. It refuses to overwrite an existing install of the same name or of unknown origin. The README explicitly warns against deleting the install directory to get around that check, which is good guidance: the refusal is the feature.

There is a known bootstrap failure worth knowing before you start. The README reports that npm 10.9.2 can fail with GitFetcher requires an Arborist constructor when packing from a full commit over Git. That is a fetch failure, not an installed plugin. The suggested path is to obtain the source at the full commit named in the release, verify HEAD, and then run the Node commands above. The README is explicit that you should not switch to an unpinned main or stable to work around it, and should not treat the plugin snapshot in the table as the bootstrap fix commit.

One more boundary: this installer does not prepare or start the Runtime. Whether a new task discovers the skills and MCP is verified separately, and an existing session may need to be reopened.

The workbench skill needs Runtime >=0.5.9, and the public download is v0.4.11

This is the limitation that decides whether the release is useful to you right now. The new default workbench operations skill covers locating words and sentences, covering or removing visuals, deleting clear segments, splitting, trimming and moving existing segments, canvas fitting, and read-back. It requires Runtime >=0.5.9 with matching actual workbench capability. The README states that the current public download is still v0.4.11, which does not satisfy the new command requirements. When capability is missing, the plugin reports and stops. It does not auto-install, upgrade, or modify your project.

The README is direct that this release ships methods and a default entry, not a new Runtime. The workbench skill is selectable via $chengfeng-videocut:chengfeng-videocut-workbench, but the README notes that install and new-task discovery are verified separately, and that default availability does not guarantee hot loading into an existing desktop session. There is also a separate compatibility boundary around chengfeng-videocut-xiaohei, an independently maintained animation method and ChatCut adapter. Its new Runtime route requires >=0.5.9 plus interfaces such as workbench commands/connect, module publish/get, and workbench visuals-put. Neither Runtime 0.4.10 nor the 0.4.11 install fix meets that contract, and the README says installing this plugin alone does not mean xiaohei is connected. If a user only wants standalone animation, HTML or SVG can be delivered without claiming it entered an editing project.

Where the Runtime preparation path sits, and what it reuses

For the six existing entry points, the README points to references/runtime-and-product-contract.md and scripts/ensure-runtime.cjs inside the package, and says to confirm version, capability and missing dependencies from actual output. A missing Runtime download is pinned to v0.4.11. That CLI installer still needs Node or an existing Bun to start, after which macOS arm64 can prepare a product-private Bun from the pinned official asset and SHA-256, reused by the persistent entry point without changing global Bun or shell configuration. An existing healthy Runtime at 0.4.10+ with sufficient capability can keep being reused; nothing auto-overwrites or upgrades it.

The README is clear that the new workbench operations do not use this older preparation path. They precheck their own >=0.5.9 and actual capability, and stop when it is missing. Media dependencies, host loading, the long-running service, and the actual edit are each verified separately, and this release ships no new Runtime, DMG or EXE.

Licence, maintenance and upgrade cost

The repository is Apache-2.0, and the package.json for the bootstrap declares the same license. The README asks that LICENSE, NOTICE.md and CITATION.cff be retained. Apache-2.0 permits commercial use and modification with the usual notice and patent terms; if you redistribute a modified plugin, the NOTICE file is the thing to read rather than guess at. This is a description of the repository's own statements, not legal advice.

The last push was on 2026-09-20, and the most recent release is v0.10.11 from the same day, marked as a pre-release. The upgrade cost is mostly version bookkeeping. Because installs are pinned to commits and snapshots rather than branches, moving forward means moving to a new pinned release deliberately, and the README states that this round does not advance stable, does not move old tags, and does not replace an already installed plugin or Runtime. The practical consequence is that the new workbench skill will sit unusable until a Runtime meeting >=0.5.9 is released and verified, and the README does not say when that will be.

Editorial conclusion

Adopt chengfeng-videocut-skills if you already run a Codex CLI with plugin support and want the six existing entry points (cutting spoken-word video, subtitles, visuals, export, bug reporting, update checks) plus the new workbench operations skill, and you accept that the workbench skill will stop until a matching Runtime ships. Do not adopt it if you need a working end-to-end editing pipeline today, or if you expect this repository to contain the editor itself: the Runtime and Studio live in chengfeng-videocut. Before installing, verify three things: that your Codex CLI actually supports the codex plugin command, that node bin/install.cjs doctor reports the install source and status you expect, and which Runtime version you already have, because the public download is v0.4.11 and the new skill requires >=0.5.9.

Frequently asked questions

Official sources

1. Agentchengfeng/chengfeng-videocut-skills on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases