comment-checker
Use when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.
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,
$ npx -y skills add code-yeongyu/lazycodex --skill browser --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/browserContext preview
The summary Claude sees to decide when to auto-load this skill.
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,
name: browser description: "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."
One library, two engines. omowright ships inside this skill; choose the engine before you act:
| You need | Engine | Entry point | |---|---|---| | A site the user is signed into, their open tabs, a form, a click-through, a screenshot, web QA, an extension popup | **attached** — the user's own browser through BrowserSkill | `connectBrowserSkill()` | | A throwaway profile, bot-scoring evasion, a CAPTCHA, network interception, a QA flight trace, coordinate control, headless runs | **owned** — a browser your code launches | `connectPipe()` / `connectCloakProfile()` — [references/owned-engine/README.md](references/owned-engine/README.md) | | Text out of a URL, a 403 bypass, a platform that blocks fetchers | neither | the `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.
const { loadOmowright } = await import("<skill-root>/scripts/omowright.mjs")
const { omowright } = await loadOmowright() // { connectBrowserSkill, bskSnapshot, connectPipe, ... }node "<skill-root>/scripts/browser-doctor.mjs" --json
| State | Meaning | Next | |---|---|---| | `ready` | CLI, daemon and a connected browser | start a session | | `no-cli` / `no-daemon` / `no-extension` | something is missing | `node "<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-browser` | the 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-support` | no Chromium-family profile on this machine | say 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.
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](references/commands.md).
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.
cookie or recovery code. The value of the attached engine is that the browser is already signed in.
out everywhere. No flow here needs it.
The one and only agent harness for complex codebases. Project memory, planning, execution, and verified completion inside Codex.
Repo: code-yeongyu/lazycodex
Use when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.
Contribute a verified bug fix for LazyCodex, lazycodex-ai, omo-codex, bundled Codex skills, or upstream Codex CLI bugs. Opens a fork PR only for upstream…
Diagnose LazyCodex and Codex CLI installation health against the latest sources. Use whenever the user asks for a doctor or health check, says LazyCodex,…
Create a high-signal bug issue or PR in the repo that owns the defect. Use this whenever the user asks to report, file, open, or triage a LazyCodex,…
Use when Codex needs language-server diagnostics, definitions, references, symbols, or rename safety checks in the current workspace.
Use when the user asks about Codex Rules behavior, injected project rules, supported rule file locations, matching, or environment configuration.