원클릭으로
browser-use
Browser automation guidance for browser_script and reusable CDP snippets.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Browser automation guidance for browser_script and reusable CDP snippets.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Autonomous multi-round controller for `/autotune`. Reads and updates `loop_state.json`, decides continue or stop, and records completion state when the loop is finished.
One eval-tune round. Applies approved fixes, selects tasks, runs eval, analyzes results, and updates loop state. Standalone use stops for human review; `/autotune-loop` can orchestrate repeated rounds.
Fix Gradle/Kotlin build errors incrementally. No refactoring - just get the build green. Use when build verification fails.
Analyze ClosePaw agent cognition using debug-run traces/replay artifacts and eval results, then propose and implement improvements to prompts, tool definitions, context packing (todo/scratchpad/history), and multi-agent coordination. Use when a debug run feels wrong, when eval metrics regress, when tuning context engineering for generalizable gains, or when reviewing LLM input/output and tool usage; produce both a report and code/doc changes.
Apply prompt, tool description, and app skill changes based on cog-tune diagnosis. Enforces the three-layer ownership model (core prompt → tool descriptions → app skills) to keep changes in the right place.
Run end-to-end Android UX QA from a user perspective through ADB-driven interaction and visual evidence capture. Use when iterating app UX, validating interaction regressions after UI changes, reproducing reported UX bugs, or checking flows in different app states (including Main app and Smart Capsule states such as Takeover/Supplement and text input paths). Prefer this skill when the goal is UX behavior validation rather than internal agent reasoning/debug logs.
| name | browser-use |
| description | Browser automation guidance for browser_script and reusable CDP snippets. |
| allowed-tools | ["browser_script","shell"] |
| metadata | {"bundled":"true"} |
Use browser_script when the task needs Chrome DevTools Protocol control over the user's real Android Chrome profile: navigation, reading page state, screenshots, input, or tab management.
browser_script runs JavaScript in ClosePaw's hidden script host. The only built-in browser primitive is:
await cdp(method, params = {}, options = {})
Prefer raw CDP for simple one-off actions. Read a snippet bundle only when you need repeated page, tab, or input helpers:
{{SKILL_DIR}}/scripts/page.js{{SKILL_DIR}}/scripts/tabs.js{{SKILL_DIR}}/scripts/input.jsUse shell cat to read the bundle you need, then copy or adapt the relevant functions into one browser_script call:
cat {{SKILL_DIR}}/scripts/page.js
cat {{SKILL_DIR}}/scripts/tabs.js
cat {{SKILL_DIR}}/scripts/input.js
Read the current title:
const response = await cdp("Runtime.evaluate", {
expression: "document.title",
returnByValue: true
});
return response.result.value;
Navigate and wait for the load event with raw polling:
await cdp("Page.navigate", { url: "https://example.com" });
for (let i = 0; i < 50; i++) {
const state = await cdp("Runtime.evaluate", {
expression: "document.readyState",
returnByValue: true
});
if (state.result.value === "complete") break;
await new Promise(resolve => setTimeout(resolve, 300));
}
return { loaded: true };
After reading page.js, you can inline the helpers and write:
await navigate("https://example.com");
return await pageInfo();
After reading tabs.js, create a blank tab first, then navigate:
const targetId = await newTab("https://example.com");
return { targetId, info: await currentTab() };
After reading input.js, use CSS pixel coordinates:
await clickAt(120, 340);
await typeText("hello");
return await cdp("Runtime.evaluate", {
expression: "document.activeElement && document.activeElement.value",
returnByValue: true
});
Target.* and Browser.* are browser-level CDP methods. Most page domains route to the active page session unless you pass options.targetId or options.sessionId.window.devicePixelRatio if you measure coordinates from a screenshot.screenshot() from page.js writes the image bytes to a trace artifact and returns metadata plus path — the absolute on-device path of the saved file (or null when tracing is disabled). It does NOT return the raw base64 in the result. If you need to verify visual state, reference the path with shell tools (adb shell run-as ai.closepaw cat <path> from the host, cat/stat on device). Do NOT base64-decode it back and paste it into your tool output — that is exactly the cost this helper exists to avoid (a single screenshot can be 100–500 KB of base64).
If you need the raw base64 for a specific reason (e.g. uploading), call Page.captureScreenshot directly via cdp(...) instead of screenshot().