mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-07 18:26:17 +00:00
* feat(skills): anchored-connector rule + source-traceable visuals doctrine Two advisory rules absorbed from a community-skill comparison study (4-cell sandbox replay vs geekjourneyx/hyperframes-motion-director; ideas only — no upstream text, the repo is AGPL-3.0): - Connector lines earn their place: any beam/rail/scan/underline must name both anchors and its job (reveal/route/validate) or be cut. Lands in motion-principles (composition) + svg-path-draw (constraints). - Visuals point back to the source: when a video derives from concrete material, each frame's key visual should trace to a specific source line — real filenames/numbers over stock props. Lands as story-spine rule 4; the four SKILL.md index lines that enumerate story-spine's rules are synced. Both are self-checks, not hard gates. lint:skills + skill-mirror green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(skills): regen stale manifest + add emphasize to connector job list Review 4975048154 follow-ups: - skills-manifest.json was hashed mid-commit before oxfmt renormalized the four SKILL.md tables (lefthook pre-commit runs format and skills-manifest in parallel — they raced). Regenerated at head; second regen is a no-op. - The connector rule's job list read literally would cut lines this same doctrine prescribes (dividers, hairlines, underline_sweep): emphasis was a missing job, not a forbidden one. Added 'emphasize' to both motion-principles and svg-path-draw. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
44 lines
4.0 KiB
Markdown
44 lines
4.0 KiB
Markdown
# Story spine — value-first narrative doctrine
|
|
|
|
Applies to the narrated, story-driven creation workflows — `/product-launch-video`, `/pr-to-video`, `/faceless-explainer`, and `/general-video` when the piece tells a story. It does **not** apply to `/music-to-video` (the track drives the arc), `/motion-graphics` (no narration — motion is the message), `/embedded-captions` and `/talking-head-recut` (the footage's story is already fixed), or `/slideshow` (the presenter owns the story). Do not force these rules onto an exempt workflow.
|
|
|
|
Each workflow's own story-design reference owns its archetypes, beat sequences, and frame vocabulary. This file owns four cross-workflow rules about **order** and **justification** — the reverse iceberg: lead with why it's valuable, not with what it is or how it was made.
|
|
|
|
## 1. The hook speaks the viewer's language
|
|
|
|
The first beat answers "why should I care" in **outcome language** — what the viewer gains, avoids, or finally understands. Subject-internal vocabulary is banned in the hook: file / function / API names for a code change; a feature list for a product; the source article's section headings for an explainer. Numbers are welcome only when they carry stakes ("40% faster cold starts"), never inventory ("23 files changed").
|
|
|
|
## 2. Reverse iceberg — value before evidence
|
|
|
|
The value claim (the brief's `message`) lands **by the second beat**. Everything after it is evidence in service of that claim — the diff, the mechanism, the feature demo, the site's screenshots. Implementation is the footnote of the story, not the spine.
|
|
|
|
Self-check on the finished beat list:
|
|
|
|
- Delete every evidence beat — the remaining beats must still state the value on their own.
|
|
- Delete the value beats — if the video still seems to work, it was a feature tour / diff readout, not a story.
|
|
|
|
Structure is value-first; the **voice** stays whatever the workflow prescribes (a PR video keeps its plain, no-hype developer voice — leading with value is an ordering decision, not a marketing register).
|
|
|
|
## 3. The storyboard is a proposal, not a listing
|
|
|
|
When Step 3 presents the plan (a checkpoint gate — `hyperframes-core/references/brief-contract.md` § 1):
|
|
|
|
- Open by echoing the strategy line: **"This video tells [audience] that [message]."**
|
|
- Present the frames as a markdown table, one row per frame:
|
|
|
|
| Frame | Beat | On screen | Why |
|
|
| ---------------- | --------- | ------------------------------------------------------- | ------------------------------- |
|
|
| 01 — Not anymore | hook · 9s | States the old pain and resolves it in the same breath. | Lands the value claim in beat 1 |
|
|
|
|
**Why** is the frame's job in the story (from its `narrativeRole`), traced back to the message — a frame whose why cannot be traced to the message is a frame to cut, not to decorate.
|
|
|
|
- Recommendations keep their receipts (brief-contract § 3): the archetype choice, the beat count, and any beat the user might question each state their basis.
|
|
|
|
The proposal shape — echo line → frame table → style / duration footer → "approve or adjust" — is the cheapest place to iterate: a frame change here costs 30 seconds; the same change after build costs minutes.
|
|
|
|
## 4. Visuals point back to the source
|
|
|
|
When the piece derives from concrete source material — a PR, a repo, an article, a product page — mine that material for the visual vocabulary before inventing any: its phrases, entities, verbs, and recurring motifs are the props. Each frame's key visual should be traceable to a specific line of the source, the same way its **Why** traces to the message: real filenames over generic file icons, the product's own numbers over invented ones, the article's own metaphor over a stock one.
|
|
|
|
Self-check per visual: if the prop could appear unchanged in another product's video, it didn't come from the source. Swap it for something only this subject could produce before decorating it.
|