1---2name: demo3description: The demo skill owns turning a product concept, release artifact, checklist, or named demo into a convincing, self-contained local try-it experience. It stages only missing product context with deterministic, visibly simulated behavior; builds or revises the focal interaction; serves it on loopback; and verifies the exact preview, restart path, and QA result. It triggers when a user asks to build, revise, activate, or use /demo for a realistic local demo or artifact experience. It does not own feature integration into an existing app router, testing an already-running localhost or dist build, comparing prototype directions or state models, converting Markdown into durable HTML, making demo videos, writing sales scripts, explaining mock design, or reviewing bugs without edits.4---56# Demo78## Recipe9101. Resolve the target and `DEMO_DIR` inside the provided demo state root, or expanded `~/.demo` otherwise: revise a named demo in place, demonstrate a named artifact, or identify plausible targets whose differences would materially change the result.112. Present any required target question directly—never through `AskUserQuestion`—as a clear bold question, necessary context below it, then numbered options whose first option is the recommendation and ends with `(Recommended)`.123. Inspect the source and choose its smallest convincing focal experience; use host tools directly, stage missing product or service behavior with deterministic synthetic state, and keep `Demo` or `Simulated` visible without credentials, destructive action, or claims of a live backend, model, extension, auth flow, integration, or third party.134. Build or revise the one descriptive lowercase-hyphen directory as an accessible responsive local experience, preferring one self-contained `index.html` and adding only assets or files the focal path requires.145. Start a long-lived server for `DEMO_DIR` on `127.0.0.1` using a free non-common port, record its PID, and record the exact restart command with the same binding, port, and directory.156. Verify the exact preview URL and focal path with browser interaction at relevant viewports when available, or a clearly identified HTTP/source fallback otherwise, and keep the verified server alive through handoff.167. On success reply with exactly five lines labeled `Demo path`, `Preview`, `Restart`, `Real vs staged`, and `QA`; after bounded serve or verification failure reply with `Not ready`, omit every link, and give the path, restart command, concrete failure, next fix, and QA limitation.1718## Details1920- Run the server as the foreground command of a long-running tool session; do not background or detach it from a shell that will exit, and treat loss of that session as a serving failure rather than reporting its URL.
eliasstravik