Agent skill · software engineering · remotion-dev
studio-config-option-lifecycle
Classify and wire Remotion Studio config options as either startup-fixed or reloadable while preventing mixed lifecycle behavior across consumers. Use when adding, changing, or reviewing a Config setter or CLI option consumed by Studio, its preview server, compiler, HTML bootstrap, public-folder watcher, or render queue.
Why this skill is useful
Provides specific patterns for managing configuration lifecycles in Remotion Studio that the AI wouldn't reliably generate on its own.
What it needs
About 3k tokens when loaded. Last updated 2026-08-06. 55,698 stars on the source repository.
What this skill does
Studio Config Option Lifecycle Make reload behavior explicit for every Studio-facing option. A config file is reset and re-executed when it changes, but a consumer only observes the new value if its code reads the option again. Classify the whole option Inspect every Studio consumer, then assign one lifecycle to the whole option: Startup-fixed: Changing the value requires recreating a server, compiler, watcher, directory mapping, or other initialized resource. Reloadable: Every Studio consumer can safely use the new value after the browser reload or at another deliberate request boundary. If any consumer must be startup-fixed, make the option startup-fixed for all Studio consumers. Do not implement mixed lifecycle behavior. Do not infer reloadability from Config.set() state being updated. Config re-execution updates module state regardless of whether an already-created consumer observes it. Wire startup-fixed values Resolve the option once in packages/cli/src/studio.ts before calling startStudio(): Pass the value, not a getter, through startStudio(), startServer(), and the consumer. Keep new internal parameters required; use T null when absence is valid. Capture startup-fixed render settings in StudioRenderJobFixedConfig at the Studio queue boundary and thread that object into the job processor. Do not call option.getValue() from the processor, because config state may have changed since Studio startup. Typical startup-fixed consumers include the Studio port, entry point, active compiler choice and override, polling mode, public directory and watcher, network binding, and cross-site-isolation headers. Wire reloadable values Read reloadable options through a getter that retains CLI precedence: Pass the getter as a required internal callback and invoke it only at the boundary that should observe config changes, such as generating Studio HTML after the config-file-changed browser reload. Do not evaluate the getter earlier and pass its result onward. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills remotion-dev/studio-config-option-lifecycle