While reading the codebase I noticed the notes already discuss calling
hyperframes render via child_process.spawn as the intended render path,
but it hasn't been implemented yet. Raising this as a feature request.
Benefits
-
HTML generation via HF skills — hyperframes-animation / hyperframes-creative
encode the full authoring contract (data-* attributes, single paused timeline,
seek-safe constraints) and 24+ validated animation recipes. Using them directly
produces output that passes hyperframes lint by construction, which a
hand-rolled prompt cannot guarantee.
-
No need to reimplement or maintain the render pipeline — the current
adapter reimplements font loading, GSAP pause/seek/resume, multi-composition
inlining, duration probing, and ffmpeg transcoding. Calling hyperframes render
returns all of that to upstream.
Is this on the roadmap? Would a PR be welcome?
While reading the codebase I noticed the notes already discuss calling
hyperframes renderviachild_process.spawnas the intended render path,but it hasn't been implemented yet. Raising this as a feature request.
Benefits
HTML generation via HF skills —
hyperframes-animation/hyperframes-creativeencode the full authoring contract (
data-*attributes, single paused timeline,seek-safe constraints) and 24+ validated animation recipes. Using them directly
produces output that passes
hyperframes lintby construction, which ahand-rolled prompt cannot guarantee.
No need to reimplement or maintain the render pipeline — the current
adapter reimplements font loading, GSAP pause/seek/resume, multi-composition
inlining, duration probing, and ffmpeg transcoding. Calling
hyperframes renderreturns all of that to upstream.
Is this on the roadmap? Would a PR be welcome?