I Built a Remotion AI Skill, Then Found Out They Already Had One (And Why I Kept Mine Anyway)
with tags remotion ai coding open-source -
Photo by Duc Anh Nguyen from Pexels
I was watching a YouTube video from Average Tech Bro where he mentioned Remotion—you know, that framework that lets you make videos using React. As a developer, the idea of “coding” a video instead of dragging clips around in Premiere Pro just clicks for me. It’s declarative, version-controllable, and frankly, just cool.
Naturally, my first thought wasn’t “I should make a video.” It was: “I should make an AI skill so my coding assistant can make videos for me.”
So I did. I spent a weekend building remotion-skill, teaching the AI how to use useCurrentFrame, how to interpolate values, how to structure compositions, and most importantly, how to not break the render with CSS transitions. I added a CLI, some programmatic rendering scripts, and a workflow for embedding the player. I was feeling pretty good about it.
Then, I did what I probably should have done five minutes in: I checked the Remotion monorepo.
The Discovery
Lo and behold, hidden deep within packages/skills, there it was: Remotion’s official skill.
My heart sank a little. They had everything. Thirty-plus markdown files covering every edge case imaginable—Three.js integration, advanced sequencing, audio trimming, Lottie support. It was written by the people who built the framework. Of course it was better than mine.
My first instinct was to deprecate my project. “Well, wheel reinvented. Time to pack up.”
But then I actually read their skill.
The Gap
While their skill was an incredible technical reference, it was missing the “Assistant” part.
It was a library of rules, but it didn’t tell the AI how to behave. It didn’t have:
- A verification workflow: AI assistants are notorious for generating code that looks right but doesn’t compile. My skill forced a “render-and-fix” loop.
- Forbidden Patterns: Remotion has specific gotchas (like
setTimeoutor Tailwindanimate-spin) that break renders. Their skill implied these; mine screamed them in big bold letters. - Operational Tooling: I had built a CLI to install the skill and scripts for batch rendering and web embedding. Theirs was just a folder of markdown files.
I realized I didn’t have a competitor; I had a backend.
Why Not Both?
I decided to pivot. Instead of competing with the official docs, I restructured my skill to wrap around them.
I created a hybrid architecture:
- The Brain (My Skill): Handles the workflow, the CLI, the error checking, and the “how-to” of being a Remotion developer.
- The Library (Their Skill): Provides the deep technical truth.
I even added a --deep flag to my CLI. If you’re online, the AI fetches their rules from GitHub on demand. If you’re offline (or on a plane, because why not code videos at 30,000 feet?), --deep downloads their entire rulebook locally.
# Best of both worlds
remotion-skill init --ai claude --deep
The Lesson
It’s easy to feel discouraged when you realize someone “beat you to it.” But often, what you’ve built has a different perspective. They built a documentation engine; I built a pilot.
By combining them, I ended up with something better than either of us started with: a skill that knows what to do (thanks to them) and how to ensure it actually works (thanks to me).
So, if you want to generate videos with Claude or Cursor, give it a spin. It’s got the official knowledge of the creators, with the safety rails of a paranoid engineer.
Happy rendering!
