
Ce Demo Reel
Capture key UI states in the browser and stitch them into a demo GIF for READMEs, changelogs, and launch posts without manual screen recording.
Overview
ce-demo-reel is an agent skill most often used in Ship (also Build, Launch) that captures 3–5 browser screenshots at key UI states and stitches them into a demo GIF via agent-browser and ffmpeg.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-demo-reelWhat is this skill?
- Tiered browser reel: 3–5 screenshots stitched via ffmpeg two-pass palette into one GIF
- Detects dev/start commands from package.json, Procfile, Gemfile, and common ports (3000, 5000, 8080)
- Connects via agent-browser to localhost or CDP; falls back to static screenshots if agent-browser is missing
- Headless mode can auto-start the server in the background with cleanup after capture (max 30s port poll)
- Labels output as Demo; requires agent-browser and ffmpeg—or `/ce-setup` for dependencies
- 3–5 browser screenshots per reel
- GIF output via ffmpeg two-pass palette
- 30s max port poll when auto-starting dev server
Adoption & trust: 1.5k installs on skills.sh; 20.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a working UI but no fast, repeatable way to produce a lightweight demo reel for READMEs or release notes.
Who is it for?
Indie developers documenting SaaS or local web UIs who already use agent-browser in a compound-engineering workflow.
Skip if: Native mobile-only apps with no browser surface, teams that cannot run shell/ffmpeg, or flows that need full video with audio narration.
When should I use this skill?
You need a Browser Reel tier demo (GIF from keyed UI states) for a web or CDP-accessible app and have or can install agent-browser and ffmpeg.
What do I get? / Deliverables
You get a labeled Demo GIF from real browser states, with optional server startup and cleanup handled in one scripted pass.
- Animated Demo GIF (PNG frames stitched)
- Captured PNG screenshots per key UI state
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Demo reels are produced when the product is runnable and you are packaging evidence for release—canonical shelf is Ship because the workflow assumes a dev server and polished UI moments. Launch prep under Ship is where maintainers attach visual proof to PRs, docs, and distribution assets; this skill automates that capture pass.
Where it fits
Refresh README hero GIF after a dashboard redesign without re-recording a full video.
Attach a Demo-labeled GIF to the release PR showing onboarding, empty state, and success state.
Export the same GIF for a Product Hunt or social post highlighting three UI beats.
How it compares
Use instead of manual QuickTime or Loom captures when you only need a few keyed frames as a shareable GIF.
Common Questions / FAQ
Who is ce-demo-reel for?
Solo and indie builders using Claude Code-style agents who ship web apps and want automated demo GIFs tied to their repo’s real start commands and ports.
When should I use ce-demo-reel?
During Ship launch prep to attach a Demo GIF to a PR or changelog; during Build when updating docs with fresh UI shots; during Launch when you need distribution-ready visuals without a video editor.
Is ce-demo-reel safe to install?
It needs browser automation, shell, and ffmpeg, which can start local servers and touch the filesystem—review the Security Audits panel on this page before running in production repos.
SKILL.md
READMESKILL.md - Ce Demo Reel
# Tier: Browser Reel Capture 3-5 browser screenshots at key UI states and stitch into an animated GIF. **Best for:** Web apps, desktop apps accessible via localhost or CDP. **Output:** GIF (PNG screenshots stitched via ffmpeg two-pass palette) **Label:** "Demo" **Required tools:** agent-browser, ffmpeg If `agent-browser` is not installed, inform the user: "`agent-browser` is not installed. Run `/ce-setup` to install required dependencies." Then fall back to a lower tier (static screenshots or skip). ## Step 1: Connect to the Application **For web apps** -- verify the dev server is accessible: - Read `package.json` `scripts` for `dev`, `start`, `serve` commands - Check `Procfile`, `Procfile.dev`, or `bin/dev` if they exist - Check `Gemfile` for Rails (`bin/rails server`) or Sinatra - Check for running processes on common ports (3000, 5000, 8080) If the server is not running: - **Headless / background mode** (no blocking question tool available): try starting the server automatically using the detected start command in a background process. For Rails apps, run `bin/dev` or `bin/rails server` in the background. Poll until port 3000 (or the detected port) is accepting connections (max 30s). If it doesn't come up, fall back to static screenshots tier. Track the server PID so you can stop it in Step 4 cleanup. - **Interactive mode**: tell the user what start command was detected and ask them to start it. Do not start it automatically (it may require environment variables, database setup, etc.). If the server cannot be reached after the user confirms it should be running, fall back to static screenshots tier. Once accessible, note the base URL (e.g., `http://localhost:3000`). **For Electron/desktop apps** -- connect via Chrome DevTools Protocol (CDP): 1. Check if the app is already running with CDP enabled by probing common ports: ```bash curl -s http://localhost:9222/json/version ``` If that returns a JSON response, the app is ready -- connect agent-browser to it: ```bash agent-browser connect 9222 ``` 2. If not running, the app needs to be launched with `--remote-debugging-port`. Detect the entry point from `package.json` (look for the `main` field or `electron` in scripts), then ask the user to launch it with: ``` your-electron-app --remote-debugging-port=9222 ``` If port 9222 is busy, try 9223-9230. 3. Poll until CDP is ready (timeout after 30 seconds): ```bash curl -s http://localhost:9222/json/version ``` 4. Connect agent-browser: ```bash agent-browser connect 9222 ``` **CDP advantages:** Screenshots come from the renderer's frame buffer, not macOS screen capture -- no Accessibility or Screen Recording permissions needed. **If CDP connection fails:** Fall back to static screenshots tier. Tell the user: "Could not connect to the app via CDP. Falling back to static screenshots." ## Step 2: Capture Screenshots Navigate to the relevant pages and capture 3-5 screenshots at key UI states: 1. **Initial/empty state** -- Before the feature is used 2. **Navigation** -- How the user reaches the feature (if not the landing page) 3. **Feature in action** -- The hero shot showing the feature working 4. **Result state** -- After interaction (data present, items created, success message) 5. **Detail view** (optional) -- Expanded item, settings panel, modal For each screenshot, write to the concrete `RUN_DIR` created by the parent skill: ```bash agent-browser open [URL] ``` ```bash agent-browser wait --load networkidle ``` ```bash agent-browser wait 1000 ``` ```bash agent-browser screenshot [RUN_DIR]/frame-01-initial.png ``` **Capture tips:** - Use URL navigation (`agent-browser open URL`) rather than clicking SPA elements (clicks often fail on React/Vue/Svelte SPAs) - Wait for `--load networkidle` after navigation, then a short fixed buffer for any post-fetch render. A fixed `wait 2000` alone is not enough on SPAs that fetch data after paint -- screenshots will captur