The skill assumed port 4000, but config/dev.exs serves on 8056 (and honours $PORT), so a fresh demo run failed its liveness check and every rodney URL pointed at the wrong port. - demo skill: resolve DEMO_PORT from the app config with `mix run --no-start -e 'Application.get_env(:firehose, FirehoseWeb.Endpoint)[:http][:port]'` (Endpoint.config/1 raises without a started endpoint), derive $DEMO_BASE_URL from it, start the server on that port from app/, and use $DEMO_BASE_URL in every rodney example. The skill also points at .tmp/phx-demo.log and names the assets/node_modules highlight.js failure as a diagnosable cause. - app/Makefile: new `assets` target that runs `npm install` only when node_modules/.package-lock.json is missing, and `deps` now depends on it. A fresh clone gets a working JS bundle from `make deps`/`make test`; later runs never touch the network, so offline runs keep working. Verified: guard skips with node_modules present and installs after moving it aside; the skill's DEMO_PORT command prints 8056 and follows PORT=9999; make check and make test (179 + 162) green.
Demo Skill
Generate living demo documents proving features work, with showboat for Markdown assembly and rodney for browser screenshots.
Prerequisites
Requires two Go CLI tools:
go install github.com/simonw/showboat@latest
go install github.com/simonw/rodney@latest
Verify installation:
showboat --help
rodney --help
Rodney Chrome data directory
Rodney needs write access to the Chrome data directory at ~/.rodney. If you get Permission denied errors when running rodney start, fix it:
mkdir -p ~/.rodney && chmod 755 ~/.rodney
Usage
In pi, invoke via:
/skill:demo <feature-name> [--scenario <description>] [--plan <path>]
Or ask naturally:
- "demo this"
- "show me it works"
- "create a demo"
- "create a demo of the authentication flow"
How It Works
- Checks that showboat and rodney are installed
- Gathers feature context from plan files, recent commits, or your description
- Verifies the dev server is running
- Handles authentication (creates a demo user if needed)
- Captures backend evidence (tests, compilation, database state)
- Takes browser screenshots of UI pages
- Maps evidence to acceptance criteria
- Produces a standalone Markdown demo document in
demos/
Demo Document Structure
- Feature Overview — narrative description
- Test Suite — relevant test output
- Compilation Check —
mix compile --warnings-as-errors - Database State — if relevant
- UI Screenshots — static pages and interactive flows
- Acceptance Criteria Verification — checklist with evidence references