[Feature Request] Support for Reusable Components and Global Design Systems

[abbnv]

Problem

Hi there!

I'm very impressed with the Hyperframes concept. As a creator and developer, I'm looking for a way to maintain a consistent visual identity across multiple videos without hardcoding styles every time.

The Problem:
Currently, if I want to create a series of videos with a specific "brand voice" (e.g., minimalist dark theme, specific typography, and custom UI elements), I have to define these parameters repeatedly.

Proposed solution

I would like to see a way to implement Reusable Components or a Global Design System within Hyperframes. Specifically:

Global Styles: The ability to define a theme.json or similar config for colors, fonts, and spacing.

Custom Templates/Components: Creating wrappers (like ) that can be imported and reused across different .hfr (or equivalent) files.

Style Inheritance: A way to ensure all video assets automatically follow the brand's design system.

Question:
Is this currently possible within the existing architecture, or is it on your roadmap? If not, I'd love to discuss how we might implement a "Design System for Video" approach here.

Alternatives considered

No response

Additional context

No response

[philippaz272006-commits]

Hi! Really appreciate you taking the time to share this you’ve articulated a real pain point clearly, and it aligns with feedback we’ve been hearing from other creators as well.

You’re absolutely right: maintaining a consistent visual identity across multiple videos shouldn’t require redefining styles each time. The idea of a reusable design system for video is a strong direction, and your breakdown (global styles, reusable components, and inheritance) maps closely to how we’ve been thinking about scalability within Hyperframes.

To answer your question directly: a full “design system for video” with global theming and component reuse isn’t fully implemented in the current architecture yet. However, it is very much in line with where we want to go. We’re actively exploring ways to introduce more modularity including shared style configurations and reusable building blocks without sacrificing flexibility.

In the meantime, some users are approximating this by duplicating base projects or creating internal templates, but we recognize that’s not a true solution.

Your suggestion around a theme.json-style configuration and importable components is especially compelling. If you’re open to it, I’d love to hear more about how you’d structure this in practice particularly how you’d balance flexibility vs. enforceable consistency across projects.

Thanks again for the thoughtful input this is exactly the kind of insight that helps shape the product in a meaningful way.

[jrusso1020]

Thanks for the thoughtful writeup!

Note on the prior comment: that reply is from a drive-by account (no project association) and doesn't reflect how we actually think about this. Treat this comment as the official response.

Here's our current take:

Brand identity → DESIGN.md

Our recommended pattern for a consistent visual identity is a plain-markdown DESIGN.md at the project root — colors, typography rules, components, do/don'ts. This gives the AI (Claude, Cursor, etc.) and the human a single brand contract to write every composition against, without locking you into a hardcoded theme schema. Think of it the same way Google's new Stitch approach treats UI design: a written design system that downstream tooling consumes.

Rather than inventing theme.json ourselves, we leaned into this because:

1. It composes naturally with how coding agents already work (they read your repo; DESIGN.md is just another file).
2. It's expressive enough to capture the subjective brand stuff a JSON schema can't — tone of motion, what you don't do, narrative rules.
3. You can version, diff, and fork it like any other doc.

To make starting one less tedious, we ship the /website-to-hyperframes skill, which captures an existing site and scaffolds a DESIGN.md from it — colors, fonts, components, the lot. Stitch itself (and a few other AI design tools) are also reasonable starting points if you don't have a reference site.

Reusable components

We maintain a public catalog in the docs under docs/catalog/blocks and docs/catalog/components — callouts, title cards, transitions, etc. Beyond that, you can absolutely build your own private catalog for reuse across your projects. A personal ~/brand-components/ directory (or a small npm package if you work across teams) that individual projects copy from is the pattern we'd suggest today.

TL;DR recommendation

• For brand identity → try /website-to-hyperframes against a reference site (your own landing page, a brand guideline doc, whatever most represents the voice) to bootstrap DESIGN.md, then hand-edit from there.
• For reusable components → use the public catalog + build your own personal catalog alongside it.

That said — if this pain point keeps coming up from others, we'd take a harder look at first-class theming primitives. Would love to hear from anyone else landing on this issue with the same need, and specifically where DESIGN.md + catalog falls short for your workflow. Leaving this open for more signal.

[jrusso1020]

Also @philippaz272006-commits is not a core maintainer, so I would not rely on their response @abbnv

They have no current influence or impact on this project

[Hamzaa6296]

Hey!
I've been thinking about this exact problem and have opened a PR that proposes a foundational Design System layer for Hyperframes. Here's what it adds:
templates/theme.json , A single config file for brand colors, typography, and spacing. Change your accent color once, every video updates.
templates/components/ , Pre-built reusable HTML components (LowerThird, Outro) that automatically inherit from theme.json via CSS variables (--hf-color-accent, --hf-font-family, etc.)
docs/design-system.md , Full documentation covering how theme tokens cascade and how to use components.
The inheritance order is: theme.json → composition → inline styles, which mirrors how CSS cascade works , so it'll feel natural to web developers.
PR link: (paste your PR URL here)
Would love feedback from the maintainers on whether this fits the architecture direction. Happy to extend it further , e.g. adding CLI support for npx hyperframes add theme 🙌