showboat-rodney-demo

name	showboat-rodney-demo
description	Build reproducible feature demos as markdown documents using showboat and Rodney browser automation. Use when the user asks for a demo, walkthrough, proof the UI works, screenshots of a feature flow, or an executable markdown artifact showing what was built.
compatibility	Requires showboat, uvx, and a local Chrome/Chromium-capable environment for uvx rodney. Intended for OpenCode or similar agent clients with shell access.
metadata	{"author":"OpenCode","last-reviewed":"2026-04-04T00:00:00.000Z"}

Showboat And Rodney Demo Workflow

Use this skill to create a reusable, verifiable demo document for a feature.

Default output location:

• In a repository: ./demos/
• Outside a repository or when explicitly requested: a user-provided path

Create the smallest useful artifact:

• one markdown demo document
• one clear happy-path walkthrough
• screenshots only where they add proof or clarity

When To Use

Use this skill when the user asks for any of the following:

• a demo of a feature
• a walkthrough of newly built UI
• proof that a page or flow works
• an executable markdown demo
• screenshots captured as part of a documented run-through
• a browser-driven feature demonstration or accessibility walk-through

Core Rules

1. Do not hand-edit the demo markdown when showboat can append the entry instead.
2. Use showboat note, showboat exec, and showboat image to build the document incrementally.
3. Prefer uvx rodney --local so the browser session is isolated to the current working directory.
4. Use showboat pop immediately after any failed or noisy step that should not remain in the final demo.
5. End by running showboat verify if the workflow is stable enough to replay.

Recommended Flow

1. Choose the demo file

Pick a descriptive file name, for example:

showboat init demos/module-27-4-demo.md "Module 27.4 Relationship Dashboards Demo"

Then add a short intro note explaining what the demo proves.

2. Start a local Rodney session

Use a directory-scoped Rodney session so the demo is self-contained.

showboat note demos/module-27-4-demo.md "Start a local Rodney browser session for the demo."
showboat exec demos/module-27-4-demo.md bash "uvx rodney start --local"

If the browser must be visible for debugging, use --show.

3. Navigate and interact

Use small, explicit Rodney steps:

showboat exec demo.md bash "uvx rodney --local open https://localhost:3000/network/suppliers"
showboat exec demo.md bash "uvx rodney --local waitidle"
showboat exec demo.md bash "uvx rodney --local title"
showboat exec demo.md bash "uvx rodney --local screenshot demos/module-27-4-suppliers.png"
showboat image demo.md '![Suppliers relationship dashboard](demos/module-27-4-suppliers.png)'

Useful Rodney commands:

• uvx rodney --local open <url>
• uvx rodney --local click <selector>
• uvx rodney --local input <selector> <text>
• uvx rodney --local wait <selector>
• uvx rodney --local waitidle
• uvx rodney --local text <selector>
• uvx rodney --local js <expression>
• uvx rodney --local screenshot <file>
• uvx rodney --local screenshot-el <selector> <file>

4. Mix browser proof with shell proof

Use showboat exec for non-browser evidence too:

• local curl calls
• targeted test commands
• route or page titles
• grep output showing relevant code paths when useful

Keep the commands directly relevant to the feature being demonstrated.

5. Stop Rodney cleanly

showboat exec demo.md bash "uvx rodney --local stop"

6. Verify the demo

If the steps should be replayable, verify the document:

showboat exec demo.md bash "showboat verify demo.md"

If verification changes outputs in a meaningful way, inspect the diff and decide whether the demo should be regenerated.

Good Demo Structure

A strong demo usually has this shape:

• brief intro note
• setup step
• one note per major section of the workflow
• small executable commands with captured output
• screenshots at key UI states
• a short closing note summarising what was proven

Rodney Tips

• Prefer waitidle after navigation-heavy steps.
• Use js for quick inspection when selectors are awkward.
• Use screenshot-el when a full-page screenshot adds noise.
• If a selector is unstable, confirm it first with exists, count, or html.
• Keep all screenshot files near the demo document so the artifact is portable.

Showboat Tips

• Use showboat note for context the output alone will not explain.
• Use showboat pop right away if a command fails or produces misleading output.
• Keep one command per showboat exec unless the commands are tightly coupled.
• Prefer concise notes that explain intent, not obvious shell mechanics.

Example Pattern

showboat init demos/feature-demo.md "Feature Demo"
showboat note demos/feature-demo.md "Open the page and confirm the new dashboard loads."
showboat exec demos/feature-demo.md bash "uvx rodney start --local"
showboat exec demos/feature-demo.md bash "uvx rodney --local open https://localhost:3000/dashboard"
showboat exec demos/feature-demo.md bash "uvx rodney --local waitidle"
showboat exec demos/feature-demo.md bash "uvx rodney --local screenshot demos/dashboard.png"
showboat image demos/feature-demo.md '![Dashboard](demos/dashboard.png)'
showboat exec demos/feature-demo.md bash "uvx rodney --local stop"
showboat verify demos/feature-demo.md

If Rodney Is Unavailable

First try:

uvx rodney --help

If that fails, say so clearly and either:

• fall back to a showboat-only shell demo, or
• ask the user to install Rodney / make browser automation available

Maintenance Note

Before making major revisions to this skill, re-check the live Agent Skills docs at https://agentskills.io/ and confirm the showboat and rodney CLI help text still match the workflow here.