/ce-demo-reel

name: ce-demo-reel
description: "Capture a visual demo reel (GIF, terminal recording, screenshots) for PR descriptions. Use when shipping UI changes, CLI features, or any work with observable behavior that benefits from visual proof. Also use when asked to add a demo, record a GIF, screenshot a feature, show what changed visually, create a demo reel, capture evidence, add proof to a PR, or create a before/after comparison."
argument-hint: "[what to capture, e.g. 'the new settings page' or 'CLI output of the migrate command']"

Demo Reel

Detect project type, recommend a capture tier, record visual evidence, upload to a public URL, and return markdown for PR inclusion.

**Evidence means USING THE PRODUCT, not running tests.** "I ran npm test" is test evidence. Evidence capture is running the actual CLI command, opening the web app, making the API call, or triggering the feature. The distinction is absolute -- test output is never labeled "Demo" or "Screenshots."

If real product usage is impractical (requires API keys, cloud deploy, paid services, bot tokens), say so explicitly: "Real evidence would require [X]. Recommending [fallback approach] instead." Do not silently skip to "no evidence needed" or substitute test output.

Never generate fake or placeholder image/GIF URLs. If upload fails, report the failure.

Arguments

Parse `$ARGUMENTS`:

• **What to capture**: A description of the feature or behavior to demonstrate. If provided, use it to guide which pages to visit, commands to run, or states to capture.
• If blank, infer what to capture from recoverable branch or PR context. If the target remains ambiguous after that, ask the user what they want to demonstrate before proceeding.

Step 0: Discover Capture Target

Treat target discovery as stateless and branch-aware. The agent may be invoked in a fresh session after the work was already done, so do not rely on conversation history or assume the caller knows the right artifact.

If invoked by another skill, treat the caller-provided target as a hint, not proof. Rerun target discovery and validation before capturing anything.

Use the lightest available context to identify the best evidence target:

• Current branch name
• Open PR title and description, if one exists
• Changed files and diff against the base branch
• Recent commits
• A plan file only when it is obviously referenced by the branch, PR, arguments, or caller context

Form a capture hypothesis: "The best evidence appears to be [behavior]."

Proceed without asking only when there is exactly one high-confidence observable behavior and a plausible way to exercise it from the workspace. Ask the user what to demonstrate when multiple behaviors are plausible, the diff does not reveal how to exercise the behavior, or the requested target cannot be mapped to a product surface.

Skip evidence with a clear reason when the diff is docs-only, markdown-only, config-only, CI-only, test-only, or a pure internal refactor with no observable output change.

Step 1: Exercise the Feature

Before capturing anything, verify the feature works by actually using it:

• **CLI tool**: Run the new/changed command and confirm the output is correct
• **Web app**: Navigate to the new/changed page and confirm it renders correctly
• **Library**: Run example code using the new/changed API
• **Bug fix**: Reproduce the original bug scenario and confirm it's fixed

Use the workspace where the feature was built. Do not reinstall from scratch. If setup requires credentials or services, use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini) to ask the user.

Step 2: Detect Project Type

Use the capture target from Step 0 to decide which directory to classify. If the diff touches a specific subdirectory with its own package manifest (e.g., `packages/cli/`, `apps/web/`), pass that as the root. Otherwise use the repo root.

python3 scripts/capture-demo.py detect --repo-root [TARGET_DIR]

This outputs JSON with `type` and `reason`. The result is a signal, not a gate. If the agent's understanding from Step 0 contradicts the script's classification (e.g., the diff clearly changes CLI behavior but the repo root classifies as `web-app` because of a sibling Next.js app), the agent's judgment wins.

Step 3: Assess Change Type

Step 0 already handled the "no observable behavior" early exit. This step classifies changes that DO have observable behavior into `motion` or `states` to guide tier selection.

If arguments describe what to capture, classify based on the description. Otherwise, use the diff context from Step 0.

**Change classification:**

1. **Involves motion or interaction?** (animations, typing flows, drag-and-drop, real-time updates, continuous CLI output) -> classify as `motion`. 2. **Involves discrete states?** (before/after UI, new page, command with output, API response) -> classify as `states`.

| Change characteristic | Classification | |---|---| | Animations, typing, drag-and-drop, streaming output | `motion` | | New UI, before/after, command output, API responses | `states` |

**Feature vs bug fix -- what to demonstrate:**

• **New feature (`feat`)**: Demonstrate the feature working. Show the hero moment -- the feature doing its thing.
• **Bug fix (`fix`)**: Show before AND after. Reproduce the original broken state (if possible) then show the fix. If the broken state can't be reproduced (already fixed in the workspace), capture the fixed state and describe what was broken.

Infer feat vs fix from commit messages, branch name, or plan file frontmatter (`type: feat` or `type: fix`). If unclear, ask.

Step 4: Tool Preflight

Run the preflight check:

python3 scripts/capture-demo.py preflight

This outputs JSON with boolean availability for each tool: `agent_browser`, `vhs`, `silicon`, `ffmpeg`, `ffprobe`. Print a human-readable summary for the user based on the result, noting insta