What a recipe fixes· structure
One recipe = aspect ratio + duration band + scene grammar + shared components
Each recipe pins the decisions that should be consistent and exposes the few that should vary. A client-promo recipe is locked to 16:9, 45–65s, a fixed scene order (hook → three beats → CTA bumper), and a set of shared Remotion components. The agent supplies the params — client name, the three beats, brand color, logo — and the output is on-brand and fast instead of bespoke and slow.
Starter library· lift these
client-promo · explainer · tribute · readme-walkthrough · b-roll
These are the five I lean on. client-promo (landscape, punchy). explainer (vertical, captions-forward). tribute/testimonial (longer, slower, music-led). readme-walkthrough (screenshot-to-animation for a repo or product). b-roll (short, silent, no VO). Each one fixes its own aspect ratio, duration band, and render defaults so the agent never re-decides them.
Keep it DRY· shared parts
Share components across recipes — lower-thirds, kinetic captions, brand bumpers
Build the reusable pieces once and import them into every recipe: the lower-third, the word-by-word caption component, the intro/outro brand bumper, the render presets. Fix a bug in the caption component and every recipe inherits the fix. This is the whole advantage of video-as-code — you refactor your video library like you refactor a codebase.
Don't re-render· catalog
Catalog every rendered asset so agents reuse instead of regenerate
Log every finished mp4 — its path in storage, the recipe and params that made it, the project it belongs to. Next time an agent needs that promo, it finds the existing render instead of burning compute and a paid VO making it again. Render is the expensive step; a catalog turns it into a cache.