Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add tough-tongue/toughtongue-skills --skill browser-demo-buildergit clone --depth 1 https://github.com/tough-tongue/toughtongue-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tough-tongue/toughtongue-skills/browser-demo-builder)<a href="https://agentmods.dev/skills/tough-tongue/toughtongue-skills/browser-demo-builder"><img src="https://agentmods.dev/badge/skills/tough-tongue/toughtongue-skills/browser-demo-builder/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/tough-tongue/toughtongue-skills/browser-demo-builder"><img src="https://agentmods.dev/badge/skills/tough-tongue/toughtongue-skills/browser-demo-builder.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00110 | $0.01797 |
| Opus 5 | $0.00055 | $0.00898 |
| Sonnet 5 | $0.00022 | $0.00359 |
| Haiku 4.5 | $0.00011 | $0.00180 |
Grade A, and why
browser-demo-builder scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser Demo Builder
Interview → walk the flow → harvest selectors → write steps via
ttai:update_scenario → verify with a live session. One run produces a
deterministic demo flow the voice agent replays instantly, with zero AI
processing per click.
How steps execute (context you must respect): each recorded action
replays through the replay engine using its exact selector — no AI calls. If
a selector breaks, ONE AI-driven retry is attempted using the action's
description + method + arguments. A step aborts at the first action
that fails both, and the agent is told which action broke. So: selectors
must be stable, and every description must work as a standalone retry
prompt.
Reference files (load on demand):
- references/steps-format.md — field guide,
JSON payload,
ai_instructionstemplates - references/selector-guide.md — selector rules, forbidden XPath patterns, verification snippets
- references/ttai-library-demo-example.md — complete worked example
Prerequisites
Load ttai-agent (features/mcp) before any ttai: call (prefix ttai:;
some clients show mcp__ttai__update_scenario).
- A way to inspect the demo app's pages: your agent's browser automation if available, or the user's own browser DevTools console using the snippets in references/selector-guide.md.
Workflow
Phase 1 — Interview
Ask the user (one round; skip anything already stated):
- Target app — the product URL the demo walks through.
- Login — does the demo need an authenticated session? If yes, plan the auth setup in Phase 4. Sandbox/demo credentials only if any values get typed by steps — they are stored in plaintext scenario config.
- The flow, screen by screen — have the user narrate the demo exactly as a salesperson would click through it. Each screen transition is a candidate step boundary.
- Demo data — names, amounts, dates. Push hard to FIX every value and
bake it into the actions.
%placeholders%(substituted from the step command'svariablesparam) add a failure mode — use them only when a value genuinely varies per session. - Simplify — flag anything state-dependent or flaky (date pickers, auto-assigned resources, optional fields) and propose dropping it. A shorter deterministic demo beats a longer brittle one.
- Target scenario — an existing scenario (find the ID via
ttai:list_scenarios) or a new one viattai:create_scenariowith the browser tool enabled. Also decide where capture milestones belong (max ~3 per demo).
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago Changed · +7 lines 80402fa83703
- 12d ago First seen · 150 lines · 110 tokens per session scan A 6092223c310d
browser-demo-builder is a skill published in the GitHub repository tough-tongue/toughtongue-skills (7 stars, last pushed today), licensed MIT. It adds 110 tokens to every session and 1,797 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
e2e-testing-patterns
Master end-to-end testing with Playwright and Cypress to build reliable test suites that catch bugs, improve confidence, and enable fast deployment. Use when implementing E2E tests, debugging flaky tests, or establishing testing standards.
browser-testing-with-devtools
Tests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be…
playwright-recording
Record browser interactions as video using Playwright. Use for capturing demo videos, app walkthroughs, and UI flows for Remotion videos. Triggers include recording a demo, capturing browser video, screen recording a website, or creating walkthrough footage.
website-to-video
Capture a general website/URL and turn it into a HyperFrames video (site tour, showcase, or social clip from the site's own visuals). Uses headless Chrome screenshots + brand assets. Use when intent is general — portfolio/blog/landing-page showcase or social clip from the site. NOT for: product/SaaS launch or promo (→…
ai-web-scraping-scrapegraph
AI-powered web scraping - extract data using natural language prompts.
browser-automation-notte
Browser automation - control browser sessions, scrape pages, and run AI agents.