DemoForge
Localhost → Playwright → shareable demo

Show what your app does.
Explain what matters.

Tell Codex what to show in your running local app. The Demo Forge skill turns that workflow into a checked recording, with explanation cards and steps you can rerun.

If an expectation fails, the run fails. A previous successful video is kept in history instead of appearing as the latest output.

Codex skill: local setup required · Browser Studio: no signup or upload

Cutroom / real local workflowRecorded + explained

49 seconds of footage → an 8.1-second cut. Cutroom selects a transcript cue and exports video with audio and subtitles. Demo Forge records that real workflow and adds Japanese explanations. Synthetic source; 8.88-second silent demo, including a four-second final-frame hold. Reproduce this workflow ↗

01 / DEFINE

Bring your running app

Give Codex a localhost URL and the result to show. The skill prepares the operation JSON; you can also write it yourself.

02 / CHECK

Run the same workflow again

Playwright performs the steps in a separate Chromium session and checks the expected UI state.

03 / EXPORT

Keep media with its report

Successful checks and conversions produce MP4, GIF, WebM, a cover and a JSON report.

Portable Codex skill · v0.3.0

Use it inside your own app project.

The ZIP includes the recorder, sample app and skill instructions. You do not need a second repository checkout. Codex inspects your local app to prepare its selectors and expected result.

Install once, then ask for a demo

  1. Download the v0.3.0 skill ZIP and review the included files.
  2. Extract the whole demo-forge folder into your app's .agents/skills/ directory. Keep scripts/ and references/ together with SKILL.md. Preserve any existing skill with the same name.
  3. Open that app project in Codex and start your local app. Recording needs Python 3.11+, Playwright/Chromium, FFmpeg and ffprobe; the ZIP does not install them. Setup and dependency checks ↗
  4. Explicitly ask Codex to use demo-forge. Replace the sample URL and reading-note task below with your app's real workflow.

Release, checksum and verification notes ↗ · Read the skill source ↗

A concrete request to adapt

Use the demo-forge skill.
My app is running at http://127.0.0.1:3000/.
Record adding a reading note: title Dune, note Remember desert ecology.
Show the saved title and note at the end, with short explanation cards.
Return the MP4, GIF and operation JSON so I can rerun it after UI changes.

Review the new run report and final frame before sharing. Chapter text is an authored explanation, not generated speech. The recorder uses a fresh Chromium session on one local HTTP port; external APIs and logged-in browser sessions are outside its scope.

Prefer direct commands? Use the CLI example below. Already have footage? Open Browser Studio to annotate it; that editor does not run the recorder's UI checks.

A demo needs context

Put your explanation beside the evidence.

After recording the included app below, write a few short captions and their times. Demo Forge places them above the original footage without cropping or changing its speed. It runs locally with no API key.

python3 experiments/demo-forge/present.py \
  --run-dir .demo-forge-output/brief-url \
  --story experiments/demo-forge/story.example.json \
  --output .demo-forge-output/explained

Also requires ffprobe. Caption times are manual: review them against each new recording. Captions are your explanation, not additional facts checked by the app. Caption format and local instructions ↗

The rerun matters

A failed run should not look successful.

An older version left the last successful MP4 beside a failed report when reusing an output directory. The v0.1.1 preview moves prior output into history before a new run and publishes fresh media only after checks and conversion finish.

SUCCESS

The expected text is present

output/
├── run.json        status: success
├── demo-forge.mp4
├── demo-forge.gif
├── demo-forge.webm
└── cover.png
FAILED RERUN

The next expectation is wrong

output/
├── run.json        status: failed
└── previous-runs/
    └── run-.../
        ├── run.json
        └── previous media

Verified locally: success → failure → success; injected GIF-conversion failure; previous media preserved. Inspect the fix · Recording and verification files

Try it locally

Start with the included release-brief app.

Use Python 3.11+, Playwright with Chromium, and FFmpeg on your PATH. No API key or logged-in browser profile is needed. Run the commands from the repository root.

git clone https://github.com/aichance/business-ai-recipes.git
cd business-ai-recipes
python3 experiments/demo-forge/forge.py --doctor
Need the Python browser dependency?

Create a project environment, install Playwright, then install its Chromium browser. Install FFmpeg separately with your usual package manager if the doctor reports it missing.

python3 -m venv .demo-forge-venv
.demo-forge-venv/bin/python -m pip install playwright
.demo-forge-venv/bin/python -m playwright install chromium

Then use .demo-forge-venv/bin/python in place of python3 for the runner below.

Terminal 1 — start the sample app

python3 experiments/demo-forge/examples/brief-app/server.py \
  --port 3000

Keep it running while recording. Press Ctrl-C when finished.

Terminal 2 — record and check it

python3 experiments/demo-forge/forge.py \
  --url http://127.0.0.1:3000/ \
  --operation experiments/demo-forge/examples/brief-app/operation.json \
  --output .demo-forge-output/brief-url \
  --tail-seconds 8

Open .demo-forge-output/brief-url/run.json and confirm status: success, then view the MP4 or GIF in the same folder. Adapting this to your app requires your actual selectors and expected outcome.

Full guide, operation example and troubleshooting ↗

A useful fit

  • Repeatable README demos for a local web app.
  • Recording a known interaction after a UI change.
  • Keeping a result report alongside media you share.

Know the limits

  • Localhost only. Assets must use the same port.
  • Redirects, WebSockets and service workers are unsupported.
  • UI text checks do not prove backend persistence.
  • Use separate output directories for concurrent runs.
Inspect it. Run it. Adapt it.
Preview software with a reproducible included example.
Open the repository ↗