@autoaiai/aicut 0.1.11 → 0.1.13

package/skills/cyxj-remotion-evolve-vibe-motion/SKILL.md

@@ -1,123 +0,0 @@
----
-name: cyxj-remotion-evolve-vibe-motion
-description: "AICUT 文档进化引擎。把一次制作 / 对话里学到的东西(纠正、新决策、新手法、被推翻的旧规则、过时描述)路由到正确的真源文件并回写,保持路由链单一真源、指针不断、不重复。用户说\"进化 / 更新文档 / 把这次学到的写进规则 / 回写规则 / 文档该改了\"时使用。这不是复盘 QA,是让规则越长越准、视频越做越好的活文档机制。 Runs in AICUT: the film is film.html, a page per shot, drawn by `aicut look` and `aicut render`."
-license: MIT
-source: "vibe-motion/remotion-starter"
----
-
-# cyxj-remotion-evolve(文档进化引擎)
-
-## Running it in AICUT
-
-AICUT's film is `film.html`: it cuts pages, footage, pictures and sound together on tracks. A page is a web page that
-sets `window.film = { frame(t) }` and draws that moment — no framework, no build step, no composition object, no
-`registerRoot`. Five shots are five pages cut together, not one page that changes scene, so each shot stays trimmable
-and replaceable in Studio.
-
-```sh
-npx -y @autoaiai/aicut@latest          # the manual: the format and the commands, always current
-npx -y @autoaiai/aicut@latest open .   # make this folder a film and print Studio's address
-npx -y @autoaiai/aicut@latest look     # a contact sheet of the whole film, its sound, and a determinism check
-npx -y @autoaiai/aicut@latest look 4.5 # one frame, full size — look at the PNG, not at the code
-npx -y @autoaiai/aicut@latest render   # the MP4, beside film.html
-```
-
-Run the manual before the first film: it is authoritative for the format, and this skill is about the method above it.
-
-Where the words below name another program's part, it becomes this:
-
-| elsewhere | in AICUT |
-|---|---|
-| composition, timeline, project file | `film.html`; tracks and clips inside it |
-| a scene, a sequence, a slide | a page (`pages/<name>.html`) cut onto a track |
-| `useCurrentFrame()`, `interpolate()` | `frame(t)` — the picture depends only on `t`, never on state or `Date.now()` |
-| a still, a screengrab | `aicut look <t>` |
-| `render` / `build` / `export` | `aicut render` (the person can also export from Studio) |
-| a dev server, a preview window | `aicut open` and the Studio address it prints |
-
-Hard rules that hold whatever the method says: the picture depends only on `t`; every value in the person's prompt is
-binding; look at the frames `look` writes before saying a film is done.
-
-
-Remotion 工作台的"活文档"机制。目标:**规则文档每次都跟着进化,不靠人记得改。** 学到一条东西 → 路由到正确的真源文件 → 回写 → 保持整条路由链一致。
-
-> ⚠️ 这不是复盘 / QA(那是查"做对没做对")。这是**进化**:把"学到的"沉淀成"下次的起点",让视频越做越好。
-> ⚠️ 也不替代官方核查或硬规则——它只负责"把规则本身改对、改全、放对地方"。
-
-## 什么时候触发
-
-- **手动**:用户说"进化 / 更新文档 / 回写规则 / 把这次学到的写进规则"。
-- **自动**:收工"文档进化闸"hook(`.claude/hooks/evolve-on-stop.mjs`,Stop 时机;搭档 `record-evolve-touch.mjs` 记本轮改动)检测到本轮动过镜头/出片代码而规则文档未动 → 拦一次提醒跑本 skill,再次收工放行。
-- **主动**:对话里出现"纠正 / 新决策 / 新手法 / 旧规则被推翻"时,主动提议跑一次。
-
-## 铁律(先记住,再动手)
-
-1. **绝不静默改文档。** 一律先出 diff 提案、按文件分组、说清"为什么写这个文件"、**用户批准才写**。规则文档是你的宪法。
-2. **单一真源。** 每条事实只在一个真源里写全,别处只放指针。**禁止把同一条规则复制进多个文件**——发现重复要合并、留指针。
-3. **CLAUDE.md 是路由器,不是仓库。** 具体规则进对应真源文件,CLAUDE.md 只留一行指过去;不要把内容堆进 CLAUDE.md 正文。
-4. **改视觉值走单一真源。** 视觉【值】(色 / 字号 / 动效 token)改 `kit/theme.ts`(或你为它建的生成器),别在组件里到处内联硬编码色值。
-5. **移动规则要补指针。** 一条规则从 A 文件挪到 B 文件,必须同步改掉所有指向它的路由行,别留断链。
-
-## 执行分工(防上下文污染)
-
-**主对话只做两件事**:① 采集信号(从本会话对话/diff 里捞,压缩成一段简报——只有主对话知道这轮发生了什么);② 按铁律 1 向用户出提案、拿批准。
-**批准后派子代理执行**(general-purpose,把简报 + 下方路由表 + 目标文件路径喂给它):读真源 → 一致性查重(四步之3)→ 回写 → 记沿革 → 返回 diff 摘要,主对话转达即可。
-**为什么**:路由/查重要读大量真源文件,全在主对话做会吃掉主上下文;子代理烧自己的窗口,主对话只留结论。
-**边界**:批准环节不许下放——子代理不能与用户对话,「用户批准才写」必须发生在主对话;子代理只执行已批准的内容,超出提案范围的发现带回主对话再议。
-
-## 路由链地图(锚点 = 仓库根)
-
-```
-CLAUDE.md                根路由 + 三层真源索引
-kit/CLAUDE.md            共享层(kit)索引 + 组件晋升规则
-template/CLAUDE.md       出片层(各工程自己的禁区)
-docs/HARD_RULES.md       工程红线唯一真源(frame 驱动 / clamp / 确定性 / public…)
-```
-
-## 进化四步
-
-### 1. 采集(找进化信号)
-从本会话对话 + `git diff` / `git log`(动过的工程)里捞:
-- **纠正**:用户说过"不对 / 我没说过 / 应该是 X / 你理解错了"。
-- **新决策**:定了新做法 / 新默认 / 新边界。
-- **新手法 / 新能力**:造出了好用且会跨片重复的手法,或验证了某引擎用法(3D / anime / 原生武器…)。
-- **旧规则被推翻 / 过时描述**:文档说 X,现实或代码是 Y。
-- **创造 vs 复用事件**:这次是真创造,还是又反射式复用了?(给"创作姿态闸"攒账)
-
-### 2. 分类 + 路由(查路由表)
-每条信号落到唯一真源:
-
-| 学到什么 | 写进哪个真源(锚点 = 仓库根) | CLAUDE.md |
-|---|---|---|
-| 操作纪律 / 流程 | 对应层 `CLAUDE.md` 正文(根 / kit / 出片层) | 它本身就是 |
-| 踩坑 / 框架红线 / 战疤 | `docs/HARD_RULES.md` | 留指针 |
-| 视觉【值】(色 / 字号 / 动效 token) | `kit/theme.ts`(或你建的生成器) | — |
-| 视觉意图 / 构图 / 色彩语义 | 你自己的设计说明书(本仓不含,建议自建) | 留指针 |
-| 动效手法 / 节奏 / spring 手感 | 你自己的动效笔记(本仓不含,建议自建) | 留指针 |
-| 引擎能力 / 用法(3D·anime·原生武器) | 你自己的引擎笔记(本仓不含,建议自建) | 留指针 |
-| **创作姿态(创造 vs 复用判断)** | `.claude/skills/cyxj-remotion-overlay/SKILL.md` | — |
-
-> 判不准放哪 → 问用户,别硬塞。一条信号可能要落两处(真源写全 + 上层留指针),但**内容只在真源那一份**。
->
-> 作者的完整真源体系还有设计说明书 / 动效笔记 / 引擎能力手册 / 字幕与后期 SOP / 沿革档案等多份文件(私有沉淀,**本仓不含**)。上表把它们标成"建议自建"——按同样的"单一真源 + 留指针"机制沉淀你自己的。
-
-### 3. 一致性检查(写之前必做)
-- 目标真源里**有没有已经写过的相近条目**?有 → 合并 / 改写,不新增重复。
-- 这条规则原来在别的文件吗?是 → 这是"移动":删旧处 + 改所有指向它的指针。
-- 写完后路由链**还连得上吗**?(CLAUDE.md 里的指针指向的文件 / 小节真实存在)
-
-### 4. 提案 → 批准 → 写
-- 按文件分组出 diff 提案,每组配一句"为什么是这个文件"。
-- 用户批准后才写入。
-
-## 跑完自检
-- [ ] 有没有把内容堆进了 CLAUDE.md 正文(本该进真源 + 留指针)?
-- [ ] 有没有制造重复(同一条话两个文件都写全)?
-- [ ] 有没有在组件里内联硬编码色值(本该改 `kit/theme.ts`)?
-
-## Source
-
-Rewritten for AICUT from [`vibe-motion/remotion-starter`](https://github.com/vibe-motion/remotion-starter)
-(MIT), .claude/skills/cyxj-remotion-evolve/SKILL.md. The method is that skill's own; the way it runs is AICUT's.
-
-The repository holds 3 skills; this is the one its entry stands for.

package/skills/demo-video-creation-skill/SKILL.md

@@ -1,152 +0,0 @@
----
-name: demo-video-creation-skill
-description: "Creates high-quality SaaS and product demo videos from a company website, screenshots, app flow, or launch brief. Use whenever the user asks for product demo videos, SaaS promo videos, app walkthroughs, website-to-video conversion, launch videos, AICUT or FFmpeg video production, browser screenshots for video, or 1080p/4K demo videos, even if the only input is a URL. Runs in AICUT: the film is film.html, a page per shot, drawn by `aicut look` and `aicut render`."
-license: MIT
-source: "derrickgong87/demo-video-creation-skill"
----
-
-# Demo Video Creation Skill
-
-## Running it in AICUT
-
-AICUT's film is `film.html`: it cuts pages, footage, pictures and sound together on tracks. A page is a web page that
-sets `window.film = { frame(t) }` and draws that moment — no framework, no build step, no composition object, no
-`registerRoot`. Five shots are five pages cut together, not one page that changes scene, so each shot stays trimmable
-and replaceable in Studio.
-
-```sh
-npx -y @autoaiai/aicut@latest          # the manual: the format and the commands, always current
-npx -y @autoaiai/aicut@latest open .   # make this folder a film and print Studio's address
-npx -y @autoaiai/aicut@latest look     # a contact sheet of the whole film, its sound, and a determinism check
-npx -y @autoaiai/aicut@latest look 4.5 # one frame, full size — look at the PNG, not at the code
-npx -y @autoaiai/aicut@latest render   # the MP4, beside film.html
-```
-
-Run the manual before the first film: it is authoritative for the format, and this skill is about the method above it.
-
-Where the words below name another program's part, it becomes this:
-
-| elsewhere | in AICUT |
-|---|---|
-| composition, timeline, project file | `film.html`; tracks and clips inside it |
-| a scene, a sequence, a slide | a page (`pages/<name>.html`) cut onto a track |
-| `useCurrentFrame()`, `interpolate()` | `frame(t)` — the picture depends only on `t`, never on state or `Date.now()` |
-| a still, a screengrab | `aicut look <t>` |
-| `render` / `build` / `export` | `aicut render` (the person can also export from Studio) |
-| a dev server, a preview window | `aicut open` and the Studio address it prints |
-
-Hard rules that hold whatever the method says: the picture depends only on `t`; every value in the person's prompt is
-binding; look at the frames `look` writes before saying a film is done.
-
-
-Create a polished product demo video from a company URL or product assets. The default output is a 60-90 second 1080p+ video; render 4K when the machine, assets, and delivery target support it.
-
-## Operating Standard
-
-- Base the video on the real product surface: website pages, app screens, logged-in workflows, screenshots, user-provided assets, or verified public demos.
-- Treat URL-only input as enough to start. Infer the product, audience, core workflow, and brand system from the site, then ask only for missing access or high-impact preferences.
-- Prefer product-manager storytelling over generic marketing. Show what problem the user has, what they do inside the product, what changes on screen, and why the outcome matters.
-- Use Remotion for motion composition when practical and FFmpeg for inspection, encoding, contact sheets, audio handling, and delivery conversion.
-- Keep claims defensible. Do not invent metrics, customer logos, detector results, integrations, compliance status, or pricing unless verified from source material.
-- Avoid overfitting to a prior client. Reuse the workflow, quality gates, and motion patterns; do not reuse client-specific screenshots, copy, colors, pricing, personas, or version-by-version fixes.
-
-## Inputs
-
-If the user provides only a website URL:
-
-1. Open the site in a browser, map the nav, value proposition, product pages, pricing, help docs, and visible interactive states.
-2. Capture high-resolution screenshots of the pages and UI surfaces that best explain the product.
-3. Build a narrative around the strongest product loop discovered from the site.
-4. State any access boundary if a logged-in product area is required.
-
-If the user provides more context, use it to raise quality:
-
-- Target audience, campaign platform, aspect ratio, preferred duration, CTA, launch goal.
-- Product workflow steps, demo account access, sample inputs, or expected before/after output.
-- Brand assets, screenshots, video references, fonts, music direction, prohibited claims, and legal notes.
-
-## Reference Routing
-
-- Read `references/capture-workflow.md` before browser research, logged-in capture, or screenshot work.
-- Read `references/storytelling.md` before writing the script, storyboard, shot list, or product narrative.
-- Read `references/visual-system.md` before choosing motion language, typography, transitions, layout, or music.
-- Read `references/remotion-ffmpeg.md` before implementing the video project or rendering files.
-- Read `references/qc-checklist.md` before calling the video complete.
-
-## Production Workflow
-
-1. **Scope the deliverable**
-   - Confirm target duration, aspect ratio, resolution, language, and delivery platform when available.
-   - Default to 16:9, 60-90 seconds, 30fps, H.264 MP4, 1080p minimum.
-   - Use 4K when requested or when the video will be used for launch, investor, conference, or paid ad distribution.
-
-2. **Research the product**
-   - Browse the website and product pages deeply enough to identify the core loop, not only the homepage promise.
-   - Build a quick feature map: main user, pain point, primary action, visible product output, proof, CTA.
-   - If the product is behind login, use the user's active browser session or ask them to log in, then continue from the authenticated UI.
-
-3. **Capture product evidence**
-   - Capture desktop screenshots at 2x or higher device scale when possible.
-   - Capture filled and empty states if they explain the transformation.
-   - Name assets by scene and state, such as `dashboard-empty.png`, `workflow-result.png`, `pricing.png`.
-   - Keep a manifest with URL, page title, capture time, viewport, file name, and notes.
-
-4. **Write the product story**
-   - Open with the user's problem or desired outcome in plain language.
-   - Move through the product loop in this order: setup, action, transformation, review/proof, broader workflow, CTA.
-   - Keep text short enough for a moving video. Use captions as anchors, not paragraphs.
-   - Use native-sounding copy for the audience; avoid generic AI phrases such as "unlock productivity" unless the product genuinely says that.
-
-5. **Design the motion system**
-   - Use the brand's real colors and typography as the base, then add one restrained display font or accent face if it improves hierarchy.
-   - Use product screenshots as the hero assets. Add browser frames, cursor paths, zooms, masks, scan lines, comparison panels, or kinetic typography only when they clarify the workflow.
-   - Choose transitions that match the product: liquid/ripple for fluid transformation, scan wipe for analysis, spotlight reveal for proof, spatial push for navigation, split comparison for before/after.
-   - Keep motion continuous. Scene changes should feel like the camera or interface is moving through one product story, not separate slides.
-
-6. **Build and render**
-   - Use the starter template in `assets/remotion-starter/` when a project scaffold is useful.
-   - Render review stills or a contact sheet before rendering the final video.
-   - Render 1080p first for QA, then 4K final if requested.
-   - Use FFmpeg or ffprobe to verify duration, resolution, codec, frame rate, and audio stream.
-
-7. **QA before delivery**
-   - Check that no text overlaps, crops awkwardly, or becomes unreadable on fast cuts.
-   - Check that buttons, cursors, callouts, and masks align with the underlying UI.
-   - Check that all screenshots are crisp enough at final scale.
-   - Check that music is instrumental, rights-safe, and balanced under any voiceover or SFX.
-   - Provide the final MP4 plus useful production artifacts: storyboard, asset manifest, contact sheet, and source project when relevant.
-
-## Reusable Scripts
-
-- `scripts/create_demo_brief.py` creates a structured brief from a URL and optional product context.
-- `scripts/qc_video.py` inspects final video metadata with ffprobe and flags resolution, duration, codec, and audio issues.
-- `scripts/make_contact_sheet.py` creates a visual contact sheet with FFmpeg for quick review.
-
-Run scripts from a project folder or with absolute paths. They are helpers, not a replacement for visual judgment.
-
-## Starter Template
-
-Copy `assets/remotion-starter/` into the working project when starting a new video. Replace the placeholder config in `src/demoConfig.ts`, add screenshots to `public/` or Remotion static assets, and adapt scenes to the product narrative.
-
-The starter is intentionally generic:
-
-- It includes a product-story composition with opening, workflow, proof, and CTA scenes.
-- It uses real screenshot slots but falls back to clean UI placeholders.
-- It includes motion primitives for fades, zooms, rail movement, cursor emphasis, and comparison panels.
-- It avoids client-specific copy, colors, or assets.
-
-## Completion Bar
-
-Do not call the video finished until these are true:
-
-- The product story is derived from real product evidence.
-- Final render is at least 1080p, or the user explicitly accepted a lower target.
-- The video has been inspected visually through stills, preview render, or contact sheet.
-- FFmpeg/ffprobe metadata confirms resolution, duration, video codec, and audio state.
-- Any licensing or source boundary for music, fonts, stock footage, or third-party pages is documented.
-- The user receives a concrete video file, not only a plan or script.
-
-## Source
-
-Rewritten for AICUT from [`derrickgong87/demo-video-creation-skill`](https://github.com/derrickgong87/demo-video-creation-skill)
-(MIT), demo-video-creation-skill/SKILL.md. The method is that skill's own; the way it runs is AICUT's.

package/skills/demo-video-creation-skill/references/capture-workflow.md

@@ -1,74 +0,0 @@
-# Capture Workflow
-
-Use this guide when researching a product website, logged-in app, or live workflow for a demo video.
-
-## Research Pass
-
-Start broad, then narrow:
-
-1. Homepage: identify category, audience, promise, CTA, and visual language.
-2. Product pages: identify the real workflow, not just benefits.
-3. Pricing or plans: understand buyer segment and feature emphasis.
-4. Docs, changelog, blog, or templates: find concrete use cases and language the company already uses.
-5. Logged-in product, if available: capture the actual surface users will trust most.
-
-Create a short product map:
-
-- Product name
-- Primary user
-- Main job-to-be-done
-- Core loop
-- 3-5 features worth showing
-- Proof source, if any
-- CTA
-- Claims that must not be made without verification
-
-## Browser Capture Standards
-
-Prefer crisp source assets over fixing blur later.
-
-- Use desktop screenshots at 1920x1080 minimum; 2560x1440 or higher is better.
-- Use device scale factor 2 when browser tooling supports it.
-- Capture mobile separately for vertical/social variants; do not crop desktop into mobile unless the product is desktop-only and the user accepts it.
-- Capture full-page screenshots for research, but use viewport screenshots for video composition.
-- Capture interaction states: empty state, filled input, processing, output, result, settings, and CTA.
-- Keep scrollbars and browser chrome only if they help orient the viewer; otherwise crop or frame the UI cleanly in composition.
-
-## Logged-In Products
-
-If the product requires login:
-
-- Ask the user to log in through the available browser surface.
-- Do not store credentials in files, manifests, or comments.
-- If access fails, make a video from public evidence and clearly mark the access boundary.
-- Avoid changing production data unless the user explicitly authorizes it.
-- Use demo data or reversible test inputs whenever possible.
-
-## Screenshot Manifest
-
-Track every important screenshot:
-
-```json
-{
-  "captured_at": "2026-07-01T12:00:00Z",
-  "viewport": "2560x1440",
-  "device_scale_factor": 2,
-  "pages": [
-    {
-      "name": "dashboard-filled",
-      "url": "https://example.com/app",
-      "title": "Dashboard",
-      "file": "dashboard-filled.png",
-      "notes": "Primary workflow result state"
-    }
-  ]
-}
-```
-
-## Capture Quality Checks
-
-- Text must remain legible after the planned zoom/crop.
-- Repeated feature screenshots should share the same aspect ratio and visual scale.
-- Before/after screenshots should have matching width, height, zoom, and alignment.
-- Cursor paths and button highlights must be based on actual UI coordinates.
-- Remove accidental overlays, OS notifications, browser download bars, or capture tool UI.

package/skills/demo-video-creation-skill/references/qc-checklist.md

@@ -1,61 +0,0 @@
-# QC Checklist
-
-Use this checklist before delivery.
-
-## Product Accuracy
-
-- Product name, URL, screenshots, and UI states are real.
-- Claims are source-backed or clearly framed as generic benefits.
-- No customer logos, numbers, detector scores, or integrations are invented.
-- Any third-party website or proof shot is current enough and used with appropriate caution.
-
-## Visual Quality
-
-- Resolution is at least 1920x1080 unless the user explicitly asked otherwise.
-- 4K render exists when requested.
-- Screenshots remain sharp at the largest zoom.
-- Text is readable after compression.
-- No text, screenshots, buttons, cursors, or callouts overlap incorrectly.
-- Before/after panels share the same visual scale.
-- Scene transitions are smooth and logically motivated.
-- First five seconds communicate audience and value.
-
-## Motion Quality
-
-- Cursor movements land on actual UI targets.
-- Button highlights and click effects align with real coordinates.
-- Transitions do not obscure important UI at the wrong moment.
-- No long dead pauses unless the pause is deliberate.
-- Pacing matches platform: faster for social, calmer for enterprise or investor demos.
-
-## Audio Quality
-
-- Music is instrumental and rights-safe.
-- Source, author, URL, and license are documented.
-- Music volume does not overpower voiceover, if present.
-- SFX are subtle and tied to visible actions.
-- Start and end fades are clean.
-
-## Technical Verification
-
-Run `scripts/qc_video.py` or equivalent ffprobe inspection.
-
-Minimum evidence:
-
-- File exists and is non-empty.
-- Duration roughly matches brief.
-- Width and height meet target.
-- Video stream codec is usable for the delivery channel.
-- Audio stream is present when music, SFX, or voiceover was requested.
-- Contact sheet or still review was created.
-
-## Delivery Package
-
-For a full handoff, provide:
-
-- Final MP4
-- Contact sheet or preview stills
-- Storyboard or shot list
-- Screenshot manifest
-- Source project, if user needs iteration
-- Music license note, if music is included

package/skills/demo-video-creation-skill/references/remotion-ffmpeg.md

@@ -1,94 +0,0 @@
-# Remotion and FFmpeg Guide
-
-Use this guide when implementing and rendering the demo video.
-
-## Recommended Stack
-
-- Remotion for scene composition, product screenshot motion, captions, and programmatic animation.
-- FFmpeg for metadata inspection, contact sheets, audio conversion, compression, and final transcodes.
-- Browser automation or the in-app browser for product research and screenshots.
-
-## Project Setup
-
-When no existing video project exists, copy the starter:
-
-```bash
-cp -r demo-video-creation-skill/assets/remotion-starter ./demo-video
-cd demo-video
-npm install
-npm run studio
-```
-
-On Windows PowerShell:
-
-```powershell
-Copy-Item -Recurse demo-video-creation-skill\assets\remotion-starter .\demo-video
-Set-Location .\demo-video
-npm install
-npm run studio
-```
-
-Add screenshots to `public/` or adapt the template's `src/demoConfig.ts`.
-
-## Render Targets
-
-Use a review render first:
-
-```bash
-npx remotion render src/index.ts ProductDemo out/product-demo-1080p.mp4 \
-  --codec=h264 --audio-codec=aac --pixel-format=yuv420p
-```
-
-Use 4K for high-stakes delivery:
-
-```bash
-npx remotion render src/index.ts ProductDemo4K out/product-demo-4k.mp4 \
-  --codec=h264 --audio-codec=aac --pixel-format=yuv420p
-```
-
-Prefer H.264 MP4 for broad sharing. Use ProRes or high-bitrate mezzanine files only if the user asks for editing handoff.
-
-## FFmpeg Verification
-
-Inspect final metadata:
-
-```bash
-ffprobe -v error -show_streams -show_format -of json out/product-demo-4k.mp4
-```
-
-Create a contact sheet:
-
-```bash
-ffmpeg -y -i out/product-demo-4k.mp4 \
-  -vf "fps=1/6,scale=480:-1,tile=4x4" out/contact-sheet.jpg
-```
-
-Compress for social upload if needed:
-
-```bash
-ffmpeg -y -i out/product-demo-4k.mp4 \
-  -c:v libx264 -pix_fmt yuv420p -crf 18 -preset slow \
-  -c:a aac -b:a 192k out/product-demo-upload.mp4
-```
-
-## Implementation Notes
-
-- Keep all timings in seconds or named frame helpers.
-- Keep scenes data-driven where possible: screenshot path, headline, subline, focus area, transition type.
-- Use `interpolate`, `spring`, and easing curves consistently.
-- Use static dimensions for browser frames, comparison panels, buttons, and callouts to prevent layout jumps.
-- Render stills around transitions and dense UI moments before full render.
-
-## Music and Licensing
-
-Store music in `public/audio/` or another explicit asset path. Add a license note in the project output:
-
-```text
-Track: [title]
-Author: [author]
-Source: [URL]
-License: [license]
-Usage notes: instrumental background music for product demo video
-```
-
-If a license is unclear, do not use the track.

package/skills/demo-video-creation-skill/references/storytelling.md

@@ -1,86 +0,0 @@
-# Storytelling Guide
-
-Use this guide to turn product research into a clear demo video narrative.
-
-## Core Narrative Shape
-
-A strong product demo video usually follows this order:
-
-1. **Hook**: Name the user's real problem or desired outcome.
-2. **Context**: Show the product surface where the work begins.
-3. **Action**: Show the user doing the primary action.
-4. **Transformation**: Show what changes because the product works.
-5. **Review or proof**: Show the result, signal, dashboard, comparison, or external evidence.
-6. **Expansion**: Show adjacent features only after the core loop is clear.
-7. **CTA**: End with product name, URL, and a concrete next step.
-
-For a 60-90 second video, keep the core loop in the first 35-45 seconds. Secondary features should support the loop, not compete with it.
-
-## Scene Timing
-
-Use this as a starting point:
-
-- 0-6s: Hook and product promise
-- 6-18s: Product surface and setup
-- 18-34s: Primary action
-- 34-48s: Result or transformation
-- 48-62s: Proof, review, or comparison
-- 62-78s: Feature suite or workflow breadth
-- 78-90s: CTA
-
-Shorter social variants can compress to:
-
-- 0-3s hook
-- 3-15s workflow
-- 15-25s result
-- 25-35s proof
-- 35-45s CTA
-
-## Copy Rules
-
-- Write for the target user, not for an abstract buyer.
-- Use short lines. Moving video text should be understood in one glance.
-- Prefer active, concrete copy: "Paste the draft. Review the changes. Submit with confidence."
-- Avoid inflated AI language: "revolutionary", "unlock", "seamless", "next-gen", "supercharge", unless the brand already uses it and it fits.
-- Do not put paragraphs on screen. Use voiceover or subtitles if the content needs more detail.
-
-## Product Manager Lens
-
-Decide what the user needs to believe after watching:
-
-- I understand what this product does.
-- I can imagine myself using it.
-- I saw the actual interface.
-- I saw the before/after or proof.
-- I know what to do next.
-
-Every scene should serve one of those beliefs.
-
-## Shot List Template
-
-```json
-[
-  {
-    "time": "0-6s",
-    "scene": "Hook",
-    "visual": "Product surface enters behind concise headline",
-    "copy": "One sentence describing the user outcome",
-    "evidence": "Homepage or product screenshot"
-  },
-  {
-    "time": "6-18s",
-    "scene": "Setup",
-    "visual": "Browser frame with cursor and focused input",
-    "copy": "Start from the real workflow",
-    "evidence": "Logged-in or product page screenshot"
-  }
-]
-```
-
-## Common Story Mistakes
-
-- Showing too many pages before the viewer understands the core loop.
-- Opening with company boilerplate instead of user relevance.
-- Treating each scene like a separate slide instead of one continuous journey.
-- Showing proof before showing what was done.
-- Making the product look fake by using generic mockups when real UI is available.

package/skills/demo-video-creation-skill/references/visual-system.md

@@ -1,83 +0,0 @@
-# Visual System Guide
-
-Use this guide when selecting art direction, motion, typography, transitions, and music.
-
-## Brand Extraction
-
-Extract these from the website before designing:
-
-- Primary and secondary colors
-- Background treatment
-- Border radius and card density
-- Typography style: geometric, editorial, utilitarian, playful, technical
-- Icon style
-- Product UI density
-- Existing motion cues, if any
-
-Use the brand system as the base. Add polish, not a disconnected theme.
-
-## Typography
-
-Use at most three text roles:
-
-- Product or UI text: the product's own font or a close system match.
-- Display title: one strong face for major headlines.
-- Utility labels and metrics: a clean sans or numeric face.
-
-Variation should create hierarchy, not novelty. A good pattern for AI/SaaS videos:
-
-- Clean sans for labels and body.
-- A confident display serif or slightly editorial face for one or two major moments.
-- Monospace or tabular numeric styling only for metrics, code, logs, or data.
-
-Check that every text block remains readable at final video scale and platform compression.
-
-## Motion Language
-
-Choose transitions based on meaning:
-
-- Liquid or ripple reveal: transformation, rewriting, generation, creative flow.
-- Scan wipe: detection, analysis, review, security, verification.
-- Spatial push: moving through product navigation or workflow stages.
-- Spotlight reveal: proof, score, key metric, final output.
-- Split comparison: before/after, manual/automated, old/new.
-- Rail or carousel movement: suite breadth, multiple tools, feature families.
-
-Do not use complex transitions as decoration. The transition should explain why the next scene follows.
-
-## Layout
-
-- Keep product screenshots large enough to inspect.
-- Use callouts near the relevant UI, but never on top of important text.
-- Match before/after panels by size and scale.
-- Leave breathing room around browser frames; avoid stacking cards inside cards.
-- Use a consistent safe margin for platform crops.
-
-## Music and Audio
-
-Use instrumental, rights-safe music. Good search terms:
-
-- "royalty free ambient tech instrumental"
-- "royalty free minimal future bass instrumental"
-- "royalty free corporate technology background"
-- "CC0 electronic instrumental"
-- "YouTube Audio Library ambient technology"
-
-Document the source, license, track title, author, and URL when music is included.
-
-Audio mix targets:
-
-- Music should support pace without feeling rushed.
-- Lower music during voiceover or dense subtitles.
-- Add soft UI clicks, whooshes, or scan sounds only when they align with visible action.
-- Fade in and out cleanly; avoid abrupt starts.
-
-## Design QA
-
-Check several still frames:
-
-- First frame, first hook, primary action, result, proof, feature suite, CTA.
-- No overlapping captions, masks, screenshots, or UI.
-- No blurry screenshots at the moment the viewer needs to read.
-- No brand color overuse that turns the video into one flat hue.
-- No accidental capture tool UI, notifications, or browser chrome artifacts.