/Catalogue/Prompt/code-yeongyu/code-yeongyu-oh-my-openagent-browser

Origin: github

browser

Drives a real browser through the omowright library from the js eval kernel: sites the user is already signed into, forms and clicks, JS-rendered pages, screenshots, web QA, extension popups, a human handoff for login, CAPTCHA or OTP, and a browser you own for scraping, bot-scored targets, network capture and QA traces. Use for any interactive browser task; not for a plain search or an unblocked static fetch.

by code-yeongyu · updated 15h ago · imported from GitHub

Installs0+0/7d
Security score73/100
Retention 14d0%
GitHub stars69.4K

Skill logic

Execution graph
User message
Prompt rewrites behaviour
Response

SKILL.md

View on GitHub ↗

Browser

One library, two engines. omowright ships inside this skill; choose the engine before you act:

You needEngineEntry point
A site the user is signed into, their open tabs, a form, a click-through, a screenshot, web QA, an extension popupattached — the user's own browser through BrowserSkillconnectBrowserSkill()
A throwaway profile, bot-scoring evasion, a CAPTCHA, network interception, a QA flight trace, coordinate control, headless runsowned — a browser your code launchesconnectPipe() / connectCloakProfile() — references/owned-engine/README.md
Text out of a URL, a 403 bypass, a platform that blocks fetchersneitherthe ultimate-browsing skill

Attached is the default, because it is the only engine carrying the user's logins and the only one where a human is a single call away. Never substitute one engine for the other silently: if the attached engine is not set up, run the onboarding script and tell the user its one remaining step.

Step 0 — load omowright and prove the stack

const { loadOmowright } = await import("<skill-root>/scripts/omowright.mjs")
const { omowright } = await loadOmowright()          // { connectBrowserSkill, bskSnapshot, connectPipe, ... }
node "<skill-root>/scripts/browser-doctor.mjs" --json
StateMeaningNext
readyCLI, daemon and a connected browserstart a session
no-cli / no-daemon / no-extensionsomething is missingnode "<skill-root>/scripts/browser-install.mjs" [--browser=<id>] prepares everything it can for the browser the user uses, then prints the single step only the user can do (relaunch that browser and click Enable); relay it verbatim, wait, re-run the doctor
choose-browserthe signals do not single out one browser (Safari/Firefox default, an idle default while another browser runs, several in use)nothing was installed; take the browser from memory or ask the user, then browser-install.mjs --browser=<id>
no-browser-supportno Chromium-family profile on this machinesay so and stop

Install into the browser the user actually uses, never into whatever happens to be on disk. Before installing, check your memory for the user's browser; otherwise read the doctor's browser (picked from the OS default browser, running apps and recent use — candidates shows the evidence). If memory and the doctor disagree, or the doctor says choose-browser, ask the user. Pass the answer as --browser=<id> and record it in memory. A Chrome that is merely installed is not their browser.

Never launch a headless browser because the attached one is missing. It has none of the user's sessions, so every login turns into a ladder you should not be climbing. Say which state you hit and ask.

The loop (attached)

const session = await omowright.connectBrowserSkill({ name: "<task>", focused: false })
try {
  await session.navigate("https://example.com/", { waitUntil: "load" })
  const { tree, refs, css } = await omowright.bskSnapshot(session, { interactive: true })  // OmOWright tree + refs, no trace in the page
  await session.click({ selector: css.e3 })                                                 // css[ref] is null inside shadow roots:
  const vom = await session.observe({ maxTokens: 4000 })                                    //   then read the daemon's own tree ...
  await session.click("@e7")                                                                //   ... and click its @eN ref
  await session.fill(css.e5, "hello")
  await session.press("Enter")
  await session.waitForNavigation({ waitUntil: "load" })
  const shot = await session.screenshot()                                                   // { buffer, width, height, captureId }
} finally {
  await session.stop()                                                                      // success AND failure; returns borrowed tabs
}
  1. Read before every action. bskSnapshot refs and observe @eN refs are reissued on each call; use a ref in the same cycle you read it.
  2. Navigation and large DOM changes stale every ref. Read again rather than reusing.
  3. Two identical failures mean change approach, not retry. A third identical attempt is a defect.
  4. Borrow a user tab explicitly (tabList({ scope: "user" }), tabBorrow(id), tabReturn(id)). Borrowing prompts the user; never invent tab ids and never repeat a denied borrow.
  5. Always stop() the session, on success and on failure.

Every method, its options, and the failure codes are in references/commands.md.

When a human is the only way through

Login, CAPTCHA, OTP, a payment confirmation, a consent dialog:

const outcome = await session.requestHelp({ prompt: "<what you need done>", targets: ["@e4"], timeoutMs: 300_000 })

Then read the page again. Respect a cancelled or timed_out outcome; do not work around it by changing the extension's automation settings.

Rules

  • Never read credentials through the page. No evaluate that extracts a password, token, cookie or recovery code. The value of the attached engine is that the browser is already signed in.
  • Never clear cookies, cache or site data. It is the user's real profile; clearing it logs them out everywhere. No flow here needs it.
  • focused: false by default. The browser belongs to someone who is probably using it.
  • One short, named session per task, always stopped.
  • Bot-scored or WAF targets go to the owned engine. The attached engine's daemon enables console capture on every tab it drives, which is a known automation signal; CloakBrowser through connectCloakProfile() is the stealth path.

Where the rest lives

TopicRead
Session methods, targets, options, error codesreferences/commands.md
Installing: CLI, daemon, extension, the one human step, blocklisted extensionreferences/install.md
Agent on one machine, browser on anotherreferences/remote.md
Owned engine: launch, snapshot ladder, network, frames, human handoffreferences/owned-engine/README.md
Reading a 1Password vault the user has unlockedreferences/recipes/1password.md

Discussion

No comments yet — start the thread.

Sign in to join the discussion.

/More from code-yeongyu/oh-my-openagent

code-yeongyu· 15h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
hyperplan

Prompts · TypeScript · v0.1.0

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', 'adversarial plan', 'hostile planning', 'cross-critique plan', '하이퍼플랜', '적대적 계획', '교차 비평'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
pre-publish-review

Prompts · TypeScript · v0.1.0

Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release synthesis. Runs ONLY when the user explicitly asks for a pre-publish review — a plain publish/release request MUST NOT trigger this; /publish ships directly. Triggers: 'pre-publish review', 'review before publish', 'release review', 'pre-release review', 'ready to publish?', 'can I publish?', 'pre-publish', 'safe to publish', 'publishing review', 'pre-publish check'.

#ai#ai-agents#anthropic

0 69.4K
code-yeongyu· 15h agoSandbox
codex-qa

Prompts · TypeScript · v0.1.0

QA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.

#ai#ai-agents#anthropic

0 69.4K