Open, inspect, interact with, and verify websites or local web apps in Poracode's isolated browser. Use for visible page state, navigation, screenshots, console or network evidence, and end-to-end UI testing; do not use it for semantic service operations when a purpose-built connector is available.
Scanned 9/2/2026
Install to Claude Code
npx -y skills add SDSLeon/lightcode --skill browser-control --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Browser Control?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sdsleon-browser-control)More formats (shields.io, HTML) on the badges page.
---
name: browser-control
description: Open, inspect, interact with, and verify websites or local web apps in Poracode's isolated browser. Use for visible page state, navigation, screenshots, console or network evidence, and end-to-end UI testing; do not use it for semantic service operations when a purpose-built connector is available.
---
# Browser Control
Use Poracode's `browser` MCP when the task depends on a rendered page, visible interaction, or local web app. If the request is really about structured data or a service operation and a purpose-built connector is available, use that connector instead. An explicit request for Poracode's browser wins.
## Workflow
1. Call `browser.api` when you need the current API map, then call `browser.enable` once before the first browser action.
2. Reuse a relevant tab from `browser.list_tabs`; otherwise open the exact URL the user supplied or the known local target. Do not guess a remote site or substitute web search when authentication blocks the requested page.
3. Establish the baseline with the current URL plus `browser.snapshot` or `browser.find`. Prefer accessible roles, names, and returned element refs over brittle selectors or coordinates.
4. Perform the smallest meaningful action. Use `fill` when replacing a field and `type` only when appending is intended.
5. After every navigation or state-changing action, wait for the expected URL, text, or element and inspect the resulting state. For web-app verification, also check relevant console errors and failed network requests.
6. Capture a screenshot when visual layout or appearance is part of the requirement.
7. Call `browser.disable` before asking the user for input, waiting on an external event, or finishing.
## Boundaries
- The in-app browser is isolated from the user's personal Chrome profile. Do not assume it contains existing logins, cookies, or extensions.
- Never inspect cookies or storage unless the task requires it and the user authorized that data access.
- A successful click is not proof of success. Verify the user-visible or application state it was meant to produce.
- Pause before purchases, submissions, messages, deletions, or other irreversible external actions unless the user explicitly authorized that exact action.
## Output
Report the tested URL and flow, the final observed state, and the evidence used. Separate visual, console, and network findings, and state any step that could not be verified.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!