Kimi Webbridge

Kimi WebBridge for Genii Desktop

Use this skill for browser and website tasks, including explicit /webbridge or /kimi-webbridge requests. It handles only the browser portion of a task.

In Genii, OpenClaw, Chrome, and Kimi WebBridge run in the same bot sandbox when desktop is enabled. Use the genii-desktop tools listed below so progress, health checks, and browser actions stay on the configured local path.

Health Check

For slow browser work, first say one concise, user-facing progress sentence, such as "Opening the browser." Do not mention Kimi, WebBridge, or internal browser driver/tool names in routine progress or ordinary blockers unless the user explicitly asks for implementation or debugging details. Then call desktop_progress_notice with driver:"kimi-webbridge" and the same generic message, followed by desktop_session_status.

Proceed only when the result shows:

• a session_id
• webbridge.running: true
• webbridge.extension_connected: true

If the desktop or extension is not healthy, report that browser automation is unavailable, include the user-relevant stage, and stop. Keep raw driver and status names in internal diagnostics unless the user explicitly asks for them. Do not guess fixes. The operator can use the Genii debug UI to restart Desktop or Gateway.

Tools

Standard Flow

1. Emit a progress notice with desktop_progress_notice.
2. Health check with desktop_session_status.
3. If the user says /webbridge ..., treat the remainder as the browser task.
4. Use web_find_tab for pages that may already be open. Otherwise use web_navigate with newTab:false or omit newTab so the active task tab is reused.
5. Use web_snapshot to read page content and locate clickable elements.
6. If web_snapshot is empty or weak, wait briefly and retry once, then use web_evaluate with compact JavaScript.
7. Use web_screenshot only when the visual state matters or DOM reads are insufficient. Prefer small JPEG screenshots or element screenshots.
8. Leave useful user-visible tabs open, but do not accumulate duplicate task tabs or Chrome extension popup tabs. Only call web_close_session or web_close_tab if the user explicitly asks to close/clean up, or if stale tabs block the current task.

Evaluate Rules

• Always return compact data. Prefer JSON.stringify(data) or small arrays.
• Wrap code in an IIFE to avoid re-declaring variables between calls:

(() => {
  const data = Array.from(document.querySelectorAll("article")).slice(0, 3);
  return JSON.stringify(data.map((item) => item.innerText));
})()

• If you need to scroll, use web_evaluate:

(() => {
  window.scrollBy(0, Math.floor(window.innerHeight * 0.8));
  return JSON.stringify({scrolled: true, y: window.scrollY});
})()

X / Twitter Profile Extraction

For requests like "vào X xem karpathy đăng 3 bài gần nhất":

1. web_find_tab for the profile URL, then web_navigate to the profile URL with newTab:false if no matching tab is open.
2. Wait briefly if the first snapshot is sparse.
3. Use web_snapshot first.
4. Use web_evaluate to extract visible post candidates:

(() => {
  const posts = Array.from(document.querySelectorAll("article"))
    .map((article) => {
      const text = article.innerText || "";
      const links = Array.from(article.querySelectorAll("a[href*='/status/']"))
        .map((a) => new URL(a.getAttribute("href"), location.origin).href);
      return { text, links: Array.from(new Set(links)) };
    })
    .filter((post) => post.text.trim() || post.links.length)
    .slice(0, 8);
  return JSON.stringify({ url: location.href, title: document.title, posts });
})()

5. Open the first distinct status URLs one by one with web_navigate using newTab:false unless you explicitly need side-by-side comparison.
6. On each status page, use web_snapshot or web_evaluate to read the main article text.
7. Summarize only content actually read. If X shows a login wall, rate limit, bot check, or empty timeline, say that explicitly with the observed URL and title.

Do not answer "no posts found" after a single empty snapshot. Use the fallback steps above first.

Failure Reporting

When blocked, include the failing stage and observed state:

• desktop health
• current URL/title if known
• whether snapshot was empty
• whether document.querySelectorAll("article").length was zero
• whether X showed login/rate-limit/checkpoint text

This makes local debugging possible from the normal .jsonl transcript.