Communitygithub.com

josueh04/product-video-skills

Turn a product's real frontend code into 1:1 rebuild specs for a video, one read-only subagent per screen, each returning static HTML, CSS with every variable resolved to its literal value and cited (role/path:line@sha), every state, transitions with exact durations and easings, icons from the code's own icon sets, and the exact i18n strings; plus resolve_tokens.py to write the product's design tokens to kit/tokens.css. Use it whenever a screen of the product has to appear in a video, when writing or fixing video/src/app.css or the template markup, when someone asks for exact sizes, colors, fonts, paddings, animations or icons of a screen, when a rebuilt screen "looks off" next to the real app, and when the design tokens or theme of a product need extracting. Framework adapters cover Angular with PrimeNG (proven), React, Vue, Tailwind and plain HTML (unproven).

Qu'est-ce que product-video-skills ?

product-video-skills is a Claude Code agent skill that turn a product's real frontend code into 1:1 rebuild specs for a video, one read-only subagent per screen, each returning static HTML, CSS with every variable resolved to its literal value and cited (role/path:line@sha), every state, transitions with exact durations and easings, icons from the code's own icon sets, and the exact i18n strings; plus resolve_tokens.py to write the product's design tokens to kit/tokens.css. Use it whenever a screen of the product has to appear in a video, when writing or fixing video/src/app.css or the template markup, when someone asks for exact sizes, colors, fonts, paddings, animations or icons of a screen, when a rebuilt screen "looks off" next to the real app, and when the design tokens or theme of a product need extracting. Framework adapters cover Angular with PrimeNG (proven), React, Vue, Tailwind and plain HTML (unproven).

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/josueh04/product-video-skills/tree/HEAD/skills/ui-spec-from-code
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

UI spec from code

The video rebuilds the product's interface in HTML and CSS instead of recording it, so the interface is only as true as the spec it is built from. Approximations get caught: in the production these skills come from, a reviewer rejected hand-drawn icons and logos on the first review, and a hand-built badge with the wrong size and name made him furious. The fixes came from reading the code, and the code hid traps nobody sees by eye: the root font size was set at runtime by the app shell (14 px, not the 10 px the stylesheet declared), several CSS variables did not exist in production and painted their fallback, a component lost its accent bar in a commit two months earlier, and two "dialogs" were custom pop-ups, not the library's dialog.

So every value in a spec is literal and cited, and a value you cannot cite is flagged, never guessed.

Inputs

  • videos/<video>/SOURCES.md from source-recon: each screen, its route, components and state. If it is missing, run source-recon first.
  • sources/<role>/ and sources.lock. Every citation uses the locked sha.
  • product.yaml: app_canvas.logical (the viewport the UI is rebuilt at), app_canvas.theme, app_canvas.rem_px, sources[].framework.
  • The adapter for the framework: references/adapters/<framework>.md. Read it before writing the subagent prompts; it says where values hide in that stack.
framework in product.yamladapterstatus
angular-primengreferences/adapters/angular-primeng.mdproven in production
reactreferences/adapters/react.mdunproven
vuereferences/adapters/vue.mdunproven
any stack using Tailwindreferences/adapters/tailwind.md (with the framework's own)unproven
html, other, server templatesreferences/adapters/html.mdunproven

For an unproven adapter, tell the user it is unproven, follow it, and add what you learn to it at the end (a short "Learned on " section), so the next product starts further ahead.

1. Global render facts (once per product)

Before any screen, establish the facts every screen depends on and write them to kit/render-facts.md with citations:

  • Root font size at runtime (search the app shell for code that sets it, not only the CSS), so rem converts right. Update app_canvas.rem_px in product.yaml if it differs.
  • Theme: which selector turns the video's theme on, and whether it is on by default.
  • Token files, the CSS layer or import order (which rules win), and the component library with its exact version from the lockfile and its theme preset.
  • Fonts actually loaded (link tags, @font-face, font packages), not just named in CSS. A font that is declared but never loaded renders as the fallback in production.
  • The desktop breakpoint, to confirm app_canvas.logical shows the desktop layout.

Then write the tokens, resolved to literals for the video's theme:

PVS_HOME="$(cd "$(cd "${CLAUDE_SKILL_DIR}" && pwd -P)/../.." && pwd)"
"$PVS_HOME/bin/pvs-py" "$PVS_HOME/skills/ui-spec-from-code/scripts/resolve_tokens.py" <product_dir> \
  [--role frontend] [--theme-selector "html.dark"] [--files src/styles/tokens.css ...]

It reads CSS custom properties, top-level SCSS variables and a Tailwind v3 theme (statically) from sources/<role>/, resolves every var() and $variable, and writes kit/tokens.css with a /* role/path:line@sha */ citation on each line. Lines flagged UNDEFINED are variables production does not define (a likely glitch); needs a Sass compile marks values built with Sass functions, which the subagent must resolve by hand from the function and its inputs. Use --files when the export holds unrelated stylesheets (docs sites, email templates, vendored CSS).

2. One subagent per screen

Launch one read-only subagent per screen (or per panel of a large screen), all in parallel, with references/ui-spec-prompt.md filled in and the adapter's "where values hide" list appended. Point each at sources/<role>/ (not the user's checkout) and give it the rendering context: logical canvas size, theme, rem, render facts, tokens, and the CSS of pieces already rebuilt so the new piece matches.

Each returns: geometry inside the canvas, static HTML per state (no framework syntax), one CSS block with literal values and a citation per value, hover/focus/active/disabled/loading states as extra classes, transitions and keyframes with exact durations and easings, icons by library and name (or inline SVG verbatim), every visible string, and an explicit "not verified" list.

The coordinator (you) does not extract specs itself: one screen of a real app can take tens of kilobytes of findings, and a coordinator whose context fills up mid-video loses track of the whole build.

3. Icons and images

Icons come from the product's own icon sets and assets, never drawn and never from a browser profile or extension folder. Run references/icon-extraction-prompt.md once per product (and again for new screens) to map every icon a video needs to its library and name, then hand the names to product-kit's collect_icons.py, which copies the SVGs into kit/icons/ with citations. For icon fonts with no SVG files, the build writes the codepoints from the library's own CSS and must fail on an unknown name rather than render an empty box.

4. Write the specs

For each screen, videos/<video>/specs/<screen>.md and specs/<screen>.html:

# Spec: <screen>
Source: frontend@1a2b3c4 (see SOURCES.md). Canvas 1440x810, theme light, rem 16.

## Geometry
| element | x | y | w | h | citation |

## States
S1 <name>: <what is shown, fictional data>. HTML in <screen>.html, section S1.

## CSS
<one block, literal values, each line with /* role/path:line@sha */>

## Motion
| what | property | from | to | duration | easing | delay | citation |

## Icons
| key | library | name | file in kit/icons | citation |

## Strings
| key | text | citation |

## Fixes (production glitches fixed in the video)
| what | production does | video does | why |

## Not verified
- <value or behaviour, why, and the best available reference>

Keep the look, fix the glitches

Rebuild layout, tokens and behaviour 1:1, including the animations, hovers, typing and loading states that make it feel like the real product. But fix visible production defects, because the video shows the product at its best and a reviewer will ask why a bug is on screen: missing padding, overflow, clipped text, a native browser control (a grey default audio player) where the product means a designed one, an undefined variable painting a fallback, a focus ring left after a click. List every fix in the spec's Fixes table and in the BRIEF notes. Keep oddities that are design decisions (a sticky footer covering a field, a sidebar that scrolls with its content); changing those is redesign, not a fix.

Two more transformations the spec applies and records:

  • Canonical names. Replace legacy strings from product.yaml names with the canonical name even when the live UI still shows the old one, and keep everything else about that element.
  • Banned terms. If a real screen shows a vendor or a term in banned_terms (a model picker, an integration card), leave that part out of frame. It must not look empty or broken; choose a framing or a state where it is naturally absent.

Data

Specs carry fictional data only, from product.yaml cast. Fixtures, seeds and screenshots in the repo can hold real names; use their shape, never their values.

Checklist before handing specs to the build

  • Locked commit cited; render facts written; tokens resolved for the video's theme
  • Canvas size above the desktop breakpoint; rem matches runtime
  • Every var() resolved; undefined ones listed with their fallback (or fixed as a glitch)
  • Every string from the i18n file or template; canonical names applied
  • Every icon from the app's libraries; the build fails on a missing glyph
  • Logos and images from the repo assets
  • Default states (tabs, accordions, toggles) match the code
  • Overlay, pop-up and transition timings with exact easings
  • Scroll ranges within real content; no text cut at an edge
  • No vendor, banned term, internal id or real customer data in frame
  • Fixes and kept oddities listed; unverified values listed for the reviewer

Individual skills in this repo

This repo contains 14 individual skills — each has its own dedicated page.

josueh04/product-video-skills

Extract, once per product, everything every video of it reuses and write it to kit/ and product.yaml (design tokens, font subsets as woff2, icon subsets as SVG from the product's own icon packages, logos in light, dark and app-tile variants from the repo, a fictional cast proposed once for veto and then frozen, the canonical-names map, pronunciations, banned terms and the read-only tool list). Use it when a product is set up or its kit is missing or incomplete, when a video needs an icon, font or logo that is not in kit/ yet, when someone asks for demo names, fake customers, phone numbers or emails, when a brand word is mispronounced or an old product name shows up, and when checking that demo data is fictional.

josueh04/product-video-skills

Interview the user about a product, then create products/<slug>/ with its own git history, a filled product.yaml and linked skills, fetch its sources and build its kit. Run only when the user types /product-new.

josueh04/product-video-skills

Back every sentence of a video's narration (audio/lines.tsv) and every screen it shows with a citation into the pinned source code (role/path:line@sha) or a docs URL, mark what is visible in the UI versus backend-only, flag restricted or unreleased features, and cut or rewrite anything unbacked; writes the video's TRUTH.md and checks it with truth_check.py. Use it whenever a script or narration is drafted or edited, before voice is generated, before a build, when someone asks "can we say this?", "is this true?", "does the product really do X?", when a reviewer asks for a feature or a claim the product may not support, and when a source document (pitch deck, PRD, marketing page) makes claims the video wants to repeat.

josueh04/product-video-skills

Check a rendered product video before anyone else sees it: worker-pattern flicker, black frames, loudness and true peak, clipping, clicks at clip edges, overlapping narration, speech to text against the script, banned terms and legacy names, camera zoom, contact sheets, frame strips at transitions and parity against the approved version; then write qa/REPORT.json, the only thing deliver.py accepts. Use it after every HyperFrames render, whenever someone asks "is the render clean", "QA this", "check the video", "check the audio", "why does it flicker", "there is a click", "compare v3 with v2", "did the approved part change", or before showing, sending, uploading or delivering any MP4, even when the request does not say QA. Also use it to triage a defect a reviewer reported in a render.

josueh04/product-video-skills

Write a product video's narration and turn it into voice clips with word timings, pronunciation fixes, sound effects and even loudness. The script becomes a table of moments and then audio/lines.tsv (one clip per sentence, with role and speed columns); tts.py voices it with ElevenLabs or the free macOS say voice, maps brand respellings back to the on-screen spelling, normalizes every clip and writes audio/timings.json for the composer; make_sfx.py builds typing tracks from real keystrokes and places recorded click and pop sounds. Use it whenever a video needs a script, narration, voice-over, lines.tsv, timings.json, TTS, a new take, a voice or casting choice, a pronunciation fix ("it says the name wrong"), a changed sentence, a tone note ("too hype", "sounds cut off"), audio levels, a click at the end of a clip, typing or click sounds, or when the build stage asks for the voice. Also use it for silent loops, which still need a moment table and SFX.

josueh04/product-video-skills

The animation rules that keep HyperFrames' parallel render workers from dropping, flashing or flickering elements, plus a static lint (lint_motion.py) that finds the violations in a video's template before it costs a render. Use it whenever you write or edit GSAP tweens, timelines, cursors, camera moves, typing, scrolls or pop-ups in a HyperFrames composition or a video's src/template.tpl, whenever a render shows flicker, stutter, an element that vanishes on some frames, a title that flashes, or a "WORKER PATTERN" line from scan_render.py or qa.py, and whenever the preview looks right but the MP4 does not. Also use it to review someone else's timeline code before rendering.

josueh04/product-video-skills

Pin a product's source code (read-only exports in sources/ plus sources.lock), confirm that the pinned commit is what runs in production, and map every screen of a video brief to its route, components, i18n strings and state, written to the video's SOURCES.md. Use it whenever a video needs to know where a screen lives in the code, when sources/ is missing or stale, before ui-spec-from-code or product-truth start on a video, after the product's frontend changed ("what changed", "which videos are affected", "refresh the sources", "is this checkout current", "which commit is in prod"), and when there is no code and you need an inventory of the no-code references (recordings, recovered captures, docs) a screen can be rebuilt from.

josueh04/product-video-skills

Compose a narrated product demo in HyperFrames: the stage (the product UI rebuilt at its real viewport and scaled to 1080p, camera, rack focus with veil, chapter titles, cursor and clicks, typing, streaming text, pop-ups, toasts, scrolls, end screen and lockup) and the build.py that anchors every beat to a word of the narration. Use it whenever you write or edit a video's video/build.py, src/template.tpl or src/app.css, place a beat on a word, add a chapter, a click, a pop-up or a push-in, frame a screen, build the end screen or lockup, snapshot setup beats, or render a draft or delivery MP4 of a product video in this workbench. Also use it when someone says "the cursor is off", "too zoomed in", "too fast", "it feels chaotic", "the title flashes", "sync the UI to the voice", or asks for a walkthrough, demo or pitch video of a UI.

josueh04/product-video-skills

Gather pixel references for UI that the code cannot show, or to check a rebuild against the real thing, using frames and timed OCR text from screen recordings, captures recovered from past Claude Code session transcripts, a local instance of the app built like production, and web research for third-party apps, plus side-by-side parity images and contact sheets. Use it whenever someone hands over a screen recording (.mov or .mp4) of the product, when a screen has no usable source code (a stale checkout, another company's UI such as a sign-in page, calendar or CRM, runtime output from a backend not in the repos), when asked "what does it really look like", "match the recording", "how long does that animation take in the app", "compare our render to the real app", or when screenshots from an earlier session might already exist. Never uses the reviewer's personal browser.

josueh04/product-video-skills

Say where this session stands in the Product Video Skills workbench (setup state, which product and video the current folder belongs to, the stage of every video) and the exact next command to type. Also answers "how do I..." questions about the workbench from its docs.

josueh04/product-video-skills

Coordinate the build of one or more signed videos of the current product with subagents (source recon, product truth, UI specs, voice, one builder per video), re-run QA itself, then deliver. A light coordinator that never builds itself. Run only when the user types /video-build.

josueh04/product-video-skills

Start a new video of the current product - create videos/<video>/, write BRIEF.md, the feature coverage matrix (COVERAGE.md) and the claims sheet (CLAIMS.md), propose chapters, then stop for the reviewer's sign-off. Never builds. Run only when the user types /video-new.

josueh04/product-video-skills

Turn a batch of reviewer feedback on the product's videos into one table per video, fix every video that got notes in parallel (one subagent each) while keeping approved parts, re-run QA and parity, bump versions and deliver. Run only when the user types /video-review.

josueh04/product-video-skills

Check this machine and install the pinned video toolchain of the Product Video Skills workbench (HyperFrames CLI, its rendering Chrome and its agent skills from the same release, the Python environment, the speech model for QA), then run the self-check. Safe to run again. `/video-setup check` only reports.

Skills associés

steipete/video-frames

Extract frames or short clips from videos using ffmpeg.

community

steipete/summarize

Summarize or transcribe URLs, YouTube/videos, podcasts, articles, transcripts, PDFs, and local files.

community

openclaw/openclaw

Use when testing, fixing, or extending the OpenClaw Control UI GUI with Vitest + Playwright end-to-end checks, mocked Gateway WebSocket flows, mocked dashboard runs, screenshots/videos, or agent-verifiable browser proof.

community

obra/superpowers

Obra superpowers agent skills.

community

finishing-a-development-branch

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

community

writing-plans

Use when you have a spec or requirements for a multi-step task, before touching code

community