hyperframes-studio
Use when building or editing a HyperFrames project that people open in Studio: how the timeline should be laid out so it reads well (one caption track, one element kind per track, every scene a sub-composition) and where captions and key content may sit (safe zones). Don't use for how to perform an individual edit (split, trim, retime, volume, copy, swap): that is `creator-editing-recipes.md` in `/hyperframes-core`.
1How It Works & Mechanism
The causal starting point of the entire document is Studio's rendering model: the timeline draws one row for each top-level element. Therefore, 'how hierarchies are sliced' directly determines whether users can edit inside Studio, rather than being an aesthetic preference.
Studio draws one timeline row per top-level element. A project that follows the rules below opens as a short, readable timeline; one that does not opens as a wall of unlabeled rows the user cannot edit.
Rule 1: The root composition only holds top-level hosts, media, and audio; any scene with a nested structure must be split into a standalone file and mounted via data-composition-src—nested markup left in the root will not become separate rows.
The root composition holds only timed hosts, media and audio.
Rule 2: All captions occupy only a single track—a single sub-composition host with data-track-kind="captions" carries all caption groups sequentially; caption groups are never allowed to have one row each, nor mixed with other track kinds.
- All captions live on one track: a single sub-composition host (one `data-track-index`)
Rule 3: Each track contains only one element type, annotated via data-track-kind (video/graphics/captions/audio), and data-track-index is only a display sequence that does not dictate stacking order—stacking order is determined by CSS.
Give each kind its own `data-track-index`; the number is display only; it never changes what renders on top.
Rule 4: Safe zones are rendered only in the preview panel and must never be written into compositions; portrait and landscape formats share the same safe frame standards (Adobe Premiere defaults: Action Safe 90%, Title Safe 80%), with captions and key content strictly positioned within the Title Safe frame.
Safe margins: everything visible stays inside the action-safe box (90%), and captions and key content stay inside the title-safe box (80%).
Wrap up with dual-evidence verification: First run hyperframes lint to resolve all findings, then visually verify the timeline structure inside Studio (one base row + one row per scene host + one caption row + audio rows).
Run `hyperframes lint` and fix every finding.
Clear boundaries: This skill strictly covers 'what shape should be constructed'; specific clip modifications (split/trim/retime/volume/copy/swap) must defer to creator-editing-recipes.md in /hyperframes-core, with no improvised redundant patterns permitted.
For how to change a clip, follow `/hyperframes-core` `references/creator-editing-recipes.md` and never invent a different form of the same edit.
2Core Capabilities
3External Dependencies
| Kind | Dependency / Endpoint |
|---|---|
| cli | hyperframes lint(唯一被本 skill 点名的外部命令,作为结构正确性的静态门禁) |
4Recommended Governance & Evidence
- SKILL.md: Pure prompt instructions and rule text; no script execution or external impact
5Second-Pass Verification
- [ok] 安全区百分比与宿主源码常量是否一致(文档唯一可被代码验证的声明) — SKILL.md 给出 Action-safe 90%(每边 5%)、Title-safe 80%(每边 10%),并指明来源 packages/studio/src/utils/previewSafeMargins.ts。打开该文件实测:`export const ACTION_SAFE_PERCENT = 90;` 与 `export const TITLE_SAFE_PERCENT = 80;`,注释亦写明「Adobe Premiere default: action-safe and title-safe margins are 10% and 20% total (5% and 10% per edge)」——文档与代码一致。
- [ok] 是否遗漏网络调用 / 脚本 / 凭证(绿档判定的关键反例检查) — 全域扫描 URL、fetch、process.env、child_process、writeFile、credential 关键词均为 0 命中;目录内只有 1 个 md 文件,无 scripts/、references/、资产。因此不存在隐藏执行面。
- [ok] 「轨类型 / 字幕单轨」等约定是否与仓库 lint 规则对得上(避免文档与实现脱节) — 文档自述「Author as if a structure lint rejects any violation」,并把词级时间规则交给 /embedded-captions 与 caption_* lint 规则;同仓 /embedded-captions 与 /hyperframes-core 的 lint 域存在对应规则,故约定不是孤例自说。本 skill 自身不实现 lint,属声明面。
- [ok] 是否存在夸大(把宿主能力说成自己的) — 文档通篇用祈使式约定(该建出什么形状)与指向(去看某文件),没有声称自己执行检查或渲染;收尾要求跑的是 hyperframes lint(宿主命令)。与同批 hyperframes-keyframes 同型:纯约定文档,能力来自宿主。
6Verdict & Scenarios
e1afb0832db4ac26…