Immutable. This exact content is served forever at /api/v1/blob/1e8214ce0ca60b74.
--- name: ozor-changelog-to-video description: "Convert changelogs, release notes, and version updates into Ozor.ai video prompts. Use this skill whenever the user has a CHANGELOG.md, release notes, GitHub release, version bump summary, or any list of product changes and wants to turn them into a video. Trigger on phrases like 'video from my changelog', 'release notes video', 'make a video from this update', 'announce this release', 'version update video', 'what's new video', 'product update video', 'feature release video', or any request to transform a list of product changes into video format using Ozor." --- # Ozor Changelog-to-Video Converter Transform changelogs, release notes, and version updates into polished, ready-to-paste Ozor.ai video prompts. This skill reads structured change lists and produces scene-by-scene video prompts that announce updates in a visually compelling way. ## Supported Input Types - **CHANGELOG.md** — standard Keep a Changelog format - **GitHub Releases** — release descriptions with tags - **Release notes** — bullet-pointed feature lists - **Version summaries** — "What's New" style documents - **Commit summaries** — grouped commit messages for a release - **Jira/Linear release notes** — exported issue lists ## Workflow ### Phase 1 — Parse the Changelog Read the changelog and extract: 1. **Version number** — the release tag (e.g., v2.4.0) 2. **Release date** — when it shipped 3. **Change categories** — group changes by type: - **New features** — entirely new capabilities - **Improvements** — enhancements to existing features - **Bug fixes** — resolved issues - **Breaking changes** — anything that requires user action - **Deprecations** — features being phased out 4. **Headline change** — the single most impactful or user-requested change 5. **Change count** — total number of changes (used for duration estimation) ### Phase 2 — Prioritize for Video Not every changelog entry deserves a scene. Apply these rules: **Always include:** - The headline feature (biggest or most requested change) - Any new feature that changes the user's workflow - Breaking changes (users need to know) **Include if space allows:** - Significant improvements (performance, UX) - Highly requested bug fixes **Skip for video (mention in notes):** - Minor bug fixes - Internal refactors - Dependency updates - Documentation changes **Scene budget by change count:** - 1–3 changes: 3–4 scenes (intro + 1 per change + CTA) - 4–7 changes: 5–6 scenes (intro + top 3–4 changes + summary + CTA) - 8+ changes: 6–7 scenes (intro + top 4–5 changes + "and more" + CTA) ### Phase 3 — Structure the Video Use this proven structure for release videos: 1. **Intro / Version Badge** — Show the product name and version number with a clean animation. Set the tone: "What's new in [Product] [Version]" 2. **Headline Feature** — The biggest change gets its own scene with the most visual attention. Show what it does, not just what it's called. 3. **Feature Scenes** — One scene per prioritized change. Each scene: feature name as headline, one-sentence description, visual representation of the change. 4. **Summary / "And More"** — If changes were deprioritized, add a scene listing them briefly: "Plus: [fix 1], [fix 2], [improvement 1]" 5. **CTA** — "Update now", "Try it today", or "Read the full release notes at [URL]" ### Phase 4 — Generate the Ozor Prompt Output a complete, copy-pasteable prompt: ``` ## Ozor Video Prompt **Source:** [Product] [Version] changelog **Video type:** Release notes / What's new **Format:** 16:9 landscape **Estimated duration:** [X] seconds **Target audience:** [existing users / developers / team] --- ### Prompt (copy and paste into Ozor) Create a [duration] release notes video for [Product] version [X.X]. [N] scenes: (1) Version Badge — [Product] logo centered on [dark/light] background. Version number "[X.X]" appears with a subtle animation. Subtext: "[Release date] — [tagline or change count summary]". (2) [Headline Feature Name] — [Specific visual direction: what the feature does, shown as a UI animation, diagram, or visual metaphor. Include exact text to display on screen.] (3) [Feature Name] — [Visual direction] [...continue for all scenes...] ([N-1]) And More — Clean list of remaining changes: "[fix 1]", "[improvement 1]", "[fix 2]". Each appears with a check mark animation. ([N]) CTA — "[Update now / Try it today]" with [product URL]. Logo fade-out. Style: [clean / modern / bold]. Background: [dark / light]. Accent color: [brand color]. Tone: [confident / excited / professional]. Audience: [who]. --- ### Notes - [Suggestions for assets to upload] - [Changes that were deprioritized and could become a separate video] - [Tips for iterating] ``` ## Adaptation Rules **If the changelog has only bug fixes:** - Frame as a reliability/quality update - Lead with "We listened" or "Squashed bugs" messaging - Group fixes thematically rather than listing each one - Keep it short: 3–4 scenes max **If the changelog has a breaking change:** - Call it out prominently — users need to see this - Use a visual warning indicator (color shift, icon) - Explain what changed AND what the user needs to do - Place it in scene 2 (right after intro) for visibility **If the changelog spans multiple versions:** - Combine into a "quarterly update" or "year in review" format - Group by theme rather than version number - Lead with the most impactful changes across all versions **If the changelog is from a GitHub Release:** - Extract the release title as the video headline - Use the tag name as the version badge - Parse markdown formatting for bullet points and headers ## Quality Checklist Before presenting the final prompt, verify: - [ ] Version number is prominently displayed in scene 1 - [ ] The headline feature gets the most visual attention - [ ] Breaking changes are clearly called out (if any) - [ ] Each scene has exactly one change or idea - [ ] On-screen text is short — feature names + one-line descriptions - [ ] CTA tells the user exactly what to do - [ ] No critical changes from the source were omitted without mention - [ ] Deprioritized changes are listed in the Notes section ## Rules 1. **Every change that gets a scene must be visually described.** "Show the new dashboard" is not enough — describe what the dashboard looks like, what's animated, what text appears. 2. **Never invent features.** Every change must come from the source changelog. 3. **Prioritize user impact over technical impressiveness.** A small UX fix that users requested is more video-worthy than a large internal refactor. 4. **Keep it punchy.** Release videos should be 30–60 seconds. Users want highlights, not documentation. 5. **Version number must be visible.** It appears in scene 1 and optionally in a persistent badge.