browser-preview▌
starchild-ai-agent/official-skills · updated Apr 8, 2026
MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.
Browser preview panel for rendering and managing iframe-based service previews in the right sidebar.
- ›Automatically opens a Browser tab when preview_serve returns a URL; each service gets one tab accessible via the ⋮ menu showing running services
- ›Preview URLs use reverse proxy format /preview/{id}/ — users cannot access localhost or 127.0.0.1 directly; always direct them to the preview URL or Browser panel
- ›Static assets must use relative paths ( ./static/app.js , ./api/data ) instead
Browser Preview
You already know preview_serve and preview_stop. This skill fills the gap: what happens after preview_serve returns a URL — how the user actually sees it.
What is Browser
The frontend has a right-side panel with two tabs: Workspace and Browser. Browser renders preview URLs inside an iframe. When you call preview_serve, the frontend automatically opens a Browser tab loading that URL.
Key facts:
- Each
preview_servecall creates one Browser tab - URL format:
https://<host>/preview/{id}/ - Browser panel has a ⋮ menu (top-right) showing "RUNNING SERVICES" list
- Browser tab can be closed by the user without stopping the backend service
- Backend service stopping → Browser tab shows an error page
⚠️ CRITICAL: Never Tell Users to Access localhost
The user's browser CANNOT access localhost or 127.0.0.1. These addresses point to the server container, not the user's machine. The preview architecture uses a reverse proxy:
User's Browser → https://<host>/preview/{id}/path → (reverse proxy) → 127.0.0.1:{port}/path
Rules:
- NEVER tell the user to visit
http://localhost:{port}orhttp://127.0.0.1:{port}— they cannot reach it - ALWAYS direct users to the preview URL:
/preview/{id}/(or the full URLhttps://<host>/preview/{id}/) curl http://localhost:{port}is for your own server-side diagnostics only — never suggest it to the user as a way to "test" the preview- When a preview is running, tell the user: "Check the Browser panel, or refresh the Browser panel"
- If you need to give the user a URL, use the
urlfield returned bypreview_serve(format:/preview/{id}/)
⚠️ Static Assets Must Use Relative Paths
Because previews are served under /preview/{id}/, absolute paths in HTML/JS/CSS will break. The reverse proxy strips the /preview/{id} prefix before forwarding to the backend, but the browser resolves absolute paths from the domain root.
Example of the problem:
<!-- ❌ BROKEN: browser requests https://host/static/app.js → 404 (bypasses preview proxy) -->
<script src="/static/app.js"></script>
<!-- ✅ WORKS: browser requests https://host/preview/{id}/static/app.js → proxied correctly -->
<script src="static/app.js"></script>
<script src="./static/app.js"></script>
Common patterns to fix:
| Broken (absolute) | Fixed (relative) |
|---|---|
"/static/app.js" |
"static/app.js" or "./static/app.js" |
"/api/users" |
"api/users" or "./api/users" |
"/images/logo.png" |
"images/logo.png" or "./images/logo.png" |
url('/fonts/x.woff') |
url('./fonts/x.woff') |
fetch('/data.json') |
fetch('data.json') |
Check ALL places where paths appear:
- HTML
src,hrefattributes - JavaScript
fetch(),XMLHttpRequest, dynamic imports - CSS
url()references - JavaScript string literals (e.g.,
'/static/'in template strings or concatenation) - Framework config files (e.g.,
publicPath,base,assetPrefix)
⚠️ Be thorough — it's common to fix CSS url() but miss JS string literals like '/static/' (with single quotes). Search for ALL occurrences of absolute paths across all file types.
⚠️ Do NOT Browse Filesystem to Debug Previews
Never look at workspace directories like preview/, output/, or random folders to understand preview state. Those are user data, not preview service state.
The only sources of truth:
- Registry file:
/data/previews.json(running services) - History file:
/data/preview_history.json(all past services) preview_serve/preview_stoptools- Port checks via
curl(server-side only, for your diagnostics)
Do NOT use ls/find on workspace directories to diagnose preview issues. Do NOT call unrelated tools like list_scheduled_tasks. Stay focused.
Step-by-Step: Diagnosing Browser Issues
When a user reports any Browser problem, follow this exact sequence:
Step 1: Read the registry (running services)
cat /data/previews.json 2>/dev/null || echo "NO_REGISTRY"
⚠️ Your bash CWD is /data/workspace/. The registry is at /data/previews.json (absolute path, one level up). Always use the absolute path.
JSON structure:
{
"previews": [
{"id": "f343befc", "title": "My App", "dir": "/data/workspace/my-project", "command": "npm run dev", "port": 9080, "is_builtin": false}
]
}
Step 2: Branch based on registry state
If registry has entries → Go to Step 3 (verify services) If registry is empty or missing → Go to Step 4 (check history)
Step 3: Registry has entries — verify and fix
For each preview in the registry, check if the port is responding server-side (this is your diagnostic, not for the user):
curl -s -o /dev/null -w "%{http_code}" http://localhost:{port}
If port responds (200):
- The service IS running. Tell the user:
- "You have a running service: {title}"
- "Click the ⋮ menu at the top-right of the Browser panel, then click it in the RUNNING SERVICES list to reopen"
- Preview URL:
/preview/{id}/
- If user says the ⋮ menu is empty or doesn't show the service → frontend lost sync. Fix by recreating:
preview_stop(id)thenpreview_serve(dir, title, command)using the info from the registry. This forces the frontend to re-register the tab.
If port does NOT respond:
- Process crashed but registry entry remains. Recreate:
preview_stop(id="{id}") preview_serve(dir="{dir}", title="{title}", command="{command}")
Step 4: No running services — check history first, then scan workspace
When there are no running services, use a two-tier lookup to find projects the user can preview:
Tier 1: Read preview history (preferred — fast and accurate)
cat /data/preview_history.json 2>/dev/null || echo "NO_HISTORY"
JSON structure:
{
"history": [
{
"id": "f343befc",
"title": "Trading System",
"dir": "/data/workspace/my-project",
"command": "python main.py",
"port": 8000,
"is_builtin": false,
"created_at": 1709100000.0,
"last_started_at": 1709200000.0
}
]
}
History entries are never removed by preview_stop — they persist across restarts. Entries are automatically pruned only when the project directory no longer exists.
If history has entries:
- List all history entries to the user with title, directory, and last started time
- Ask which one they want to restart
- Call
preview_servewith thedir,title, andcommandfrom the history entry
If user says a project is missing from history → fall through to Tier 2.
Tier 2: Scan workspace (fallback — when history is empty or incomplete)
find /data/workspace -maxdepth 2 \( -name "package.json" -o -name "index.html" -o -name "*.html" -o -name "app.py" -o -name "main.py" -o -name "vite.config.*" \) -not -path "*/node_modules/*" -not -path "*/skills/*" -not -path "*/memory/*" -not -path "*/prompt/*" -not -path "*/.git/*" 2>/dev/null
Then:
- List discovered projects with brief descriptions
- Ask the user which one to preview
- Call
preview_servewith the appropriate directory
Don't just say "no services running" and stop. Always check history first, then scan, and offer options.
Quick Reference
| User says | You do |
|---|---|
| "tab disappeared" / "tab 不见了" | Step 1 → 2 → 3 or 4 |
| "blank page" / "白屏" | Check port (server-side), if dead → recreate; if alive → check for absolute path issues |
| "not updating" / "内容没更新" | Suggest refresh button in Browser tab, or recreate preview |
| "port conflict" / "端口冲突" | preview_stop old → preview_serve new |
| "can't see service" / "⋮ menu empty" | preview_stop + preview_serve to force re-register |
| "where's my project" / "what did I build" | Read /data/preview_history.json and list entries |
| "resource load failed" / "JS/CSS 404" | Check for absolute paths (/static/, /api/), fix to relative paths |
What You Cannot Do
- Cannot directly open/close/refresh Browser tabs (frontend UI)
- Cannot force-refresh the iframe
- Cannot read what the iframe displays
When you can't do something, tell the user the manual action (e.g., "click refresh in Browser tab"). If manual action doesn't work, recreate the preview with preview_stop + preview_serve.
Common Mistakes to Avoid
- ❌ Telling user to "visit http://localhost:18791/" — user cannot access localhost
- ❌ Saying "refresh the page at localhost" — meaningless to the user
- ❌ Only fixing CSS
url()paths but missing JS string literals with absolute paths - ❌ Forgetting to check ALL file types (HTML, JS, CSS, config) for absolute paths
- ✅ Always use
/preview/{id}/as the user-facing URL - ✅ Always use
curl localhost:{port}only for your own server-side diagnostics - ✅ After fixing paths, call
preview_stop+preview_serveto restart, then tell user to check Browser panel
How to use browser-preview on Cursor
AI-first code editor with Composer
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
- ›Cursor installed and configured on your development machine
- ›Node.js version 16.0+ with npm package manager (verify with
node --version) - ›Active project directory or workspace where you want to add browser-preview
Execute installation command
Execute the skills CLI command in your project's root directory to begin installation:
The skills CLI fetches browser-preview from GitHub repository starchild-ai-agent/official-skills and configures it for Cursor.
Select Cursor when prompted
The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:
Verify installation
Confirm successful installation by checking the skill directory location:
Reload or restart Cursor to activate browser-preview. Access the skill through slash commands (e.g., /browser-preview) or your agent's skill management interface.
Security & Verification Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.
List & Monetize Your Skill
Submit your Claude Code skill and start earning
Use Cases▌
User Story & Requirements Generation
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Competitive Analysis
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Roadmap Prioritization
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Implementation Guide▌
Prerequisites
- ›Claude Desktop or compatible AI client
- ›Access to product documentation and roadmap tools (Jira, Notion, etc.)
- ›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
- ›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Installation Steps
- 1.Install product management skill
- 2.Start with user story generation for known feature
- 3.Progress to competitive analysis: research 2-3 competitors
- 4.Use for roadmap prioritization: apply RICE/ICE scoring
- 5.Draft stakeholder communications and refine based on feedback
- 6.Build template library for recurring PM tasks
- 7.Share effective prompts with product team
Common Pitfalls
- ⚠Not validating competitive research—verify facts before sharing
- ⚠Accepting user stories without involving engineering team
- ⚠Over-relying on frameworks without qualitative judgment
- ⚠Not customizing outputs to company culture and communication style
- ⚠Skipping stakeholder validation of generated requirements
Best Practices▌
✓ Do
- +Validate research and competitive analysis with real data
- +Collaborate with engineering when generating technical requirements
- +Customize frameworks and templates to your company context
- +Use skill for first drafts, refine with stakeholder input
- +Document successful prompt patterns for PM tasks
- +Combine AI efficiency with human judgment and intuition
✗ Don't
- −Don't publish competitive analysis without fact-checking
- −Don't finalize user stories without engineering review
- −Don't make prioritization decisions solely on AI scoring
- −Don't skip customer validation of generated requirements
- −Don't ignore company-specific context and culture
💡 Pro Tips
- ★Provide context: company goals, constraints, customer feedback
- ★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
- ★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
- ★Use skill for 70% generation + 30% customization to company needs
When to Use This▌
✓ Use When
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid When
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path▌
- 1Basic: user stories, feature specs, status updates
- 2Intermediate: competitive analysis, prioritization frameworks, PRDs
- 3Advanced: product strategy, go-to-market planning, OKR setting
- 4Expert: product vision, market positioning, business model innovation
Discussion
Product Hunt–style comments (not star reviews)- No comments yet — start the thread.
Ratings
4.6★★★★★60 reviews- ★★★★★Ava Abbas· Dec 28, 2024
browser-preview fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- ★★★★★Sofia Ndlovu· Dec 28, 2024
browser-preview has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Diego Yang· Dec 20, 2024
Useful defaults in browser-preview — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Diego Mensah· Dec 16, 2024
We added browser-preview from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Ren Harris· Dec 8, 2024
I recommend browser-preview for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Kiara Khan· Dec 4, 2024
Solid pick for teams standardizing on skills: browser-preview is focused, and the summary matches what you get after install.
- ★★★★★Daniel Khanna· Nov 27, 2024
Solid pick for teams standardizing on skills: browser-preview is focused, and the summary matches what you get after install.
- ★★★★★Ava Rahman· Nov 23, 2024
I recommend browser-preview for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Kaira Bansal· Nov 19, 2024
Useful defaults in browser-preview — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Carlos Srinivasan· Nov 11, 2024
browser-preview has been reliable in day-to-day use. Documentation quality is above average for community skills.
showing 1-10 of 60