What it does
remocn is a copy-paste component registry for Remotion — animations, transitions, backgrounds, and full UI primitives you pull in with npx shadcn add and own outright. No runtime package, no black box: the source lands in your repo.
Why I starred it
I reviewed this repo back when it lived under kapishdima/remocn and had 64 components. GitHub silently redirects that URL to Remocn/remocn now — the project moved to an org — which is why it shows up twice in my stars export. Rather than write the same post again, I went back in to see what changed. A lot did: the registry now spans three separate namespaces — remocn (136 items: animations, transitions, backgrounds, full compositions), remocn-ui (45 items: timeline-driven shadcn primitives like dialog, command-menu, dropdown), and remocn-icons (101 icons). That's ~280 installable pieces, up from 64.
The part that made me open the source again wasn't the component count. It's skills/remocn/SKILL.md — an agent skill the maintainers ship so Claude Code, Codex, and friends can build Remotion videos with the registry. Most projects that ship an "AI skill" bundle a snapshot of their docs into the skill file and let it rot. This one refuses to.
How it works
The skill's opening move, straight from skills/remocn/SKILL.md:16-19:
## The catalog lives at remocn.dev
This skill does not carry a copy of the component catalog. There are ~240 components and they
change; a bundled copy goes stale silently. Read the live docs instead.Every agent session fetches https://remocn.dev/llms-components.txt fresh, gets one table per category with Use for / Avoid for / vibe / tier / dependencies per component, shortlists, then fetches only the .md page for the components it picked. If the network's down, the skill tells the agent to stop and say so — not to invent a prop name from memory. That's a real design decision: they traded "fast, offline, occasionally wrong" for "always correct, requires a fetch." For a registry that ships new components on a near-daily commit cadence (I counted commits from 2026-08-12 through 2026-08-17 alone adding kinetic-warp, lens-zoom, gooey-morph, perspective-squeeze, chromatic-wave), a cached catalog would be wrong within a week.
The machinery behind that live catalog is enforced by tests, not convention. lib/docs-meta.test.ts walks every registry.json across the three namespaces and every MDX page under content/docs/**, then asserts every installable component has exactly one docs page declaring it via a component: frontmatter field — and flags any page that claims a component name that doesn't exist in a registry. There's a small UNDOCUMENTED allowlist for internal-only primitives (brush, stop-motion, icons-core), and the test also fails if that allowlist goes stale. This is what makes the "fetch instead of cache" strategy safe: the docs can't silently drift from the registry, because CI won't let them.
I also went looking at how individual components are built, since that's usually where a "growing fast" registry starts cutting corners. registry/remocn/confetti/index.tsx is a good sample: physics-driven particles (vx, vy, gravity, drift) seeded through a hand-rolled mulberry32 PRNG so a given seed renders an identical burst on every render pass — a real requirement for Remotion, where frames get rendered out of order and non-determinism shows up as flicker. The pure helpers (mulberry32, makeParticles, particleOpacity) are separated from the component and unit-tested in confetti.test.ts with bun:test — checking determinism across seeds, palette fallback, and the fade envelope at the boundaries. Not every component in the tree has a __tests__ folder, but the ones with real math do.
The registry-to-CLI pipeline is also tighter than I expected. bun run registry:build runs shadcn build into registry-artifacts/, which gets committed — then registry:check reruns the build and diffs it against what's committed, failing CI if they don't match. app/r/[file]/route.ts serves those committed artifacts directly off disk (export const dynamic = "force-dynamic" — never cached, because an install only counts if the request actually lands) and fires an analytics beacon via Next's after() on every real install.
Using it
npx create-video@latest # Remotion is a prerequisite, not bootstrapped
npx shadcn@latest add @remocn/confettiTransitions use a lowercase factory instead of a component — whipPan() in registry/remocn/whip-pan/index.tsx returns a TransitionPresentation you hand to TransitionSeries.Transition:
const travel = interpolate(p, [0, 1], [0, 1], { ...clampOpts, easing: Easing.bezier(0.7, 0, 0.2, 1) });
const velocity = Math.sin(Math.PI * travel);
const offset = entering ? (travel - 1) * 110 * sign : travel * 110 * sign;
const stretch = 1 + velocity * 0.12;velocity peaks mid-transition and drives both the motion blur (filter: blur(...)) and a squash-stretch scale — one derived value feeding two visual effects, which is a cleaner trick than tuning them separately.
Rough edges
The animation tier and the UI-primitives tier have genuinely different prop conventions (speed multiplier vs. state string), and the skill has to spell that out explicitly because nothing in the type system stops you from passing speed to a remocn-ui component and having it silently do nothing. Not every component ships a test — the coverage is concentrated where there's real math (physics, PRNGs, timing curves), and thin everywhere else, which the maintainers seem to accept rather than hide. And the live-fetch strategy means the skill is useless offline; that's a stated tradeoff, not an oversight, but it's worth knowing before you rely on it mid-flight with no connection.
Bottom line
If you're generating Remotion videos programmatically — product demos, changelogs, launch clips — install what you need and read skills/remocn/SKILL.md even if you're not using an AI agent; it's the clearest explanation of the two-tier prop system in the repo. The catalog-freshness problem it solves is one every fast-moving component library with an AI skill will eventually hit.