FrameCue: building a video workflow that keeps getting more useful

What should remain after a video is finished?

I want AI-assisted video production to leave behind useful assets, animation code, and working methods, as well as a finished video. Changing a title, making a landscape version, or reusing an effect for another event should have a clear starting point.

That led me to consider several questions together: how to separate video projects, how to accumulate reusable effects, where to install the tools, and what will still be available when a project is opened again later.

FrameCue combines a workspace structure, a Skill, and local command wrappers. Codex coordinates existing editing tools while retaining the information needed to continue the work.

Give each tool a clear responsibility

The entry point is $framecue. The user describes the task in natural language, and the agent identifies the project and production stage before choosing tools.

Component	Responsibility	Why it belongs here
FrameCue Skill	Project selection, briefs, tool routing, and delivery records	Keep different tasks within one production workflow
ChatCut Desktop	Asset import, the main timeline, preview, and local export	Inspect editing decisions in a visual editor
HyperFrames	Titles, lower thirds, information graphics, and end cards	Retain HTML, CSS, and JavaScript for later changes
FFmpeg / ffprobe	Conversion, frame extraction, probing, and decoding	Check the actual output files

This division also determines what to test first. A complete Skill document cannot establish whether the editor connection works. Reading a project, editing its timeline, and exporting a short sample need early verification before expanding the workflow.

Install the tools once, organize each video separately

One practical concern was repeated setup. Starting another video should not require downloading another browser, locating FFmpeg again, or reinstalling the same dependencies.

FrameCue keeps tools together under tools/, with separate locations for Node, FFmpeg, HyperFrames, the rendering browser, and ChatCut. A configuration file records their paths, and a common launcher calls them across video projects.

Software, application state, and cache have different roles. Executables provide the runtime; application data holds persistent editor state; downloads, extracted frames, and temporary renders can be rebuilt. Cleaning disk space needs to respect those differences.

This layout does not make the entire workspace automatically portable. Moving it may require updating host connections, shortcuts, and media references. The public repository includes source and dependency manifests; a new computer still needs tool setup.

One project per video, with revisions inside it

Project isolation keeps the context explicit. When the user asks to continue a video, the agent should find its brief, assets, edit plan, and current revision without reconstructing everything from an earlier conversation.

New projects receive an independent ID and a directory containing a date, name, and random identifier. Duplicate names do not overwrite existing work. Before editing, the agent also checks the actual ChatCut project rather than choosing the most recently modified directory.

Isolation should not fragment one video unnecessarily. Caption changes, pacing revisions, aspect-ratio variants, and translations remain in the same project. A different event or independent narrative becomes a new project.

For example, a campus recap could share its material and story between a landscape presentation and a portrait release. Each delivery would still record its own dimensions, frame rate, language, and identifier.

Within the project, originals, caches, motion source, editor references, snapshots, and exports are separate. Large source files can stay in their original location with an explicit reference, avoiding a full copy for every video. Those references must be checked at handoff.

Reuse the method as well as the media

The library is intended to accumulate animation templates, effects, processing recipes, and common functions alongside media. Once a title treatment has been refined, another project should be able to change its parameters and use it again.

That requires keeping more than a rendered clip. Source code, text parameters, fonts, asset references, and tool versions determine whether an animation can be rebuilt. Effects likewise need a recipe, not only a visual preview.

Reuse case	What can be retained	What still needs checking
The same media asset	The existing file	Source, specifications, and permitted use
The same animation with different text or colors	Code and design	Updated parameters and a new render of the affected segment
Identical inputs, parameters, and output specifications	A previously checked render	Matching fonts, tool versions, and other dependencies

Reuse does not automatically remove the need to render. Matching filenames are not evidence of matching content. Automatic cache hits are not implemented, so the agent currently performs these checks.

Library references are versioned. A template already used by a project is not overwritten; an update creates a new version. Older videos retain their original references, preventing an unrelated improvement from changing a later rerender.

Technical reusability also differs from permission to publish. Music, fonts, logos, and event photographs need source and usage records. A file being available to another project does not establish that it belongs in every public video.

Keep the request natural; let the agent maintain the structure

These records could easily become a system that constantly asks users to fill out forms. I want everyday requests to remain simple: use the previous end card, change this title, or continue this video.

The agent therefore maintains directories, asset lists, library versions, and usage records. It should organize information already supplied and ask for missing decisions only when they materially affect production.

The same principle applies to implementation. Search the library before rebuilding an animation and inspect tools/ before rewriting a shared function. Names, dates, and copy specific to a video stay in that project’s parameters.

Make revisions precise and delivery reproducible

“The twelfth second is wrong” is ambiguous once several drafts exist. FrameCue ties feedback to a revision and output timecode. Revision numbers increase, and reviewed files are preserved.

Small changes should have a small scope. Ordinary captions should remain editable text where possible; complex animations can be rendered as video. Once text is baked into a clip, changing it requires returning to its source and rendering again.

Transparency needs its own compatibility check. An animation with alpha can still behave differently in the editor preview and final export. If necessary, it can be composited locally with the target shot while retaining the original source for revisions.

Delivery therefore needs a checklist: the video, required captions and covers, motion source, asset versions, editor references, and recovery instructions. An MP4 alone cannot preserve all of those editing options.

Check what archiving, backup, and local execution actually do

An archive/ directory helps organize finished work, but another folder on the same disk is not an independent backup. Moving files can also break media references. Marking a project as archived in place may be preferable; a real move requires reopening and checking it.

Cache boundaries need similar care. An automatic transcript can be recreated, but a manually corrected subtitle file may be the only authoritative version. It belongs in a retained source directory. Whether a file is disposable depends on recoverability, not simply on which tool produced it.

I also treat local production, account connectivity, and optional cloud features separately. FrameCue prioritizes local media processing and rendering, while cost records distinguish host inference, editing, and optional hosted generation. A file ending up on the computer does not establish a completely offline or free workflow.

Publication follows the same separation. GitHub contains the workflow, Skill, scripts, and empty templates. Actual video, audio, image assets, login state, and editing projects stay local. This article describes the design and progress without hosting those media files.

Current progress and the remaining work

As of September 12, 2026, development records include project creation checks, a two-second local Chinese animation, ChatCut tool discovery, and timeline editing. A roughly 15-second portrait video was exported locally through ChatCut with 1080×1920 video and an audio stream.

The development workspace has also begun registering a portrait motion template, original electronic music, and AI illustrations. The public version provides the empty library structure and registration rules without those project assets.

Area	Current status
Project directories, templates, and Skill	Present, with project creation and isolation checks
Local animation, editor connection, and sample export	Exercised in the development environment
Asset registration, version references, briefs, and state records	Maintained by the agent using the workflow rules
Automatic deduplication, cache hits, and revision allocation	Not implemented
Complete backup, native-project recovery, and broader editing scenarios	Still require implementation or acceptance testing

The next priorities are consistency between production records and the actual editor project, plus verification of targeted changes and reopening. Asset ingestion and caching can then build on that foundation to reduce work on later videos.

Source files and setup instructions are available in the FrameCue repository. Creating a project directory only requires an existing Node.js installation:

node tools/new-project.mjs "Campus recap"

The full media workflow currently targets Windows. Configure the tools and verify availability and Skill discovery in the current environment. No open-source license has been specified for the repository; third-party tools retain their own licensing and service terms.