--- name: browse version: 1.1.0 description: | Fast headless browser for QA testing and site dogfooding. Navigate any URL, interact with elements, verify page state, diff before/after actions, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs, and assert element states. ~100ms per command. Use when you need to test a feature, verify a deployment, dogfood a user flow, or file a bug with evidence. Use when asked to "open in browser", "test the site", "take a screenshot", or "dogfood this". allowed-tools: - Bash - Read - AskUserQuestion --- ## Preamble (run first) ```bash _UPD=$(~/.claude/skills/chief/bin/chief-update-check 2>/dev/null || .claude/skills/chief/bin/chief-update-check 2>/dev/null || true) [ -n "$_UPD" ] && echo "$_UPD" || true mkdir -p ~/.chief/sessions touch ~/.chief/sessions/"$PPID" _SESSIONS=$(find ~/.chief/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ') find ~/.chief/sessions -mmin +120 -type f -delete 2>/dev/null || true _CONTRIB=$(~/.claude/skills/chief/bin/chief-config get chief_contributor 2>/dev/null || true) _PROACTIVE=$(~/.claude/skills/chief/bin/chief-config get proactive 2>/dev/null || echo "true") _BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown") echo "BRANCH: $_BRANCH" echo "PROACTIVE: $_PROACTIVE" _LAKE_SEEN=$([ -f ~/.chief/.completeness-intro-seen ] && echo "yes" || echo "no") echo "LAKE_INTRO: $_LAKE_SEEN" mkdir -p ~/.chief/analytics echo '{"skill":"browse","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}' >> ~/.chief/analytics/skill-usage.jsonl 2>/dev/null || true ``` If `PROACTIVE` is `"false"`, do not proactively suggest chief skills — only invoke them when the user explicitly asks. The user opted out of proactive suggestions. If output shows `UPGRADE_AVAILABLE `: read `~/.claude/skills/chief/chief-upgrade/SKILL.md` and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If `JUST_UPGRADED `: tell user "Running chief v{to} (just updated!)" and continue. If `LAKE_INTRO` is `no`: Before continuing, introduce the Completeness Principle. Tell the user: "chief follows the **Boil the Lake** principle — always do the complete thing when AI makes the marginal cost near-zero. Read more: https://garryslist.org/posts/boil-the-ocean" Then offer to open the essay in their default browser: ```bash open https://garryslist.org/posts/boil-the-ocean touch ~/.chief/.completeness-intro-seen ``` Only run `open` if the user says yes. Always run `touch` to mark as seen. This only happens once. ## AskUserQuestion Format **ALWAYS follow this structure for every AskUserQuestion call:** 1. **Re-ground:** State the project, the current branch (use the `_BRANCH` value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences) 2. **Simplify:** Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called. 3. **Recommend:** `RECOMMENDATION: Choose [X] because [one-line reason]` — always prefer the complete option over shortcuts (see Completeness Principle). Include `Completeness: X/10` for each option. Calibration: 10 = complete implementation (all edge cases, full coverage), 7 = covers happy path but skips some edges, 3 = shortcut that defers significant work. If both options are 8+, pick the higher; if one is ≤5, flag it. 4. **Options:** Lettered options: `A) ... B) ... C) ...` — when an option involves effort, show both scales: `(human: ~X / CC: ~Y)` Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex. Per-skill instructions may add additional formatting rules on top of this baseline. ## Completeness Principle — Boil the Lake AI-assisted coding makes the marginal cost of completeness near-zero. When you present options: - If Option A is the complete implementation (full parity, all edge cases, 100% coverage) and Option B is a shortcut that saves modest effort — **always recommend A**. The delta between 80 lines and 150 lines is meaningless with CC+chief. "Good enough" is the wrong instinct when "complete" costs minutes more. - **Lake vs. ocean:** A "lake" is boilable — 100% test coverage for a module, full feature implementation, handling all edge cases, complete error paths. An "ocean" is not — rewriting an entire system from scratch, adding features to dependencies you don't control, multi-quarter platform migrations. Recommend boiling lakes. Flag oceans as out of scope. - **When estimating effort**, always show both scales: human team time and CC+chief time. The compression ratio varies by task type — use this reference: | Task type | Human team | CC+chief | Compression | |-----------|-----------|-----------|-------------| | Boilerplate / scaffolding | 2 days | 15 min | ~100x | | Test writing | 1 day | 15 min | ~50x | | Feature implementation | 1 week | 30 min | ~30x | | Bug fix + regression test | 4 hours | 15 min | ~20x | | Architecture / design | 2 days | 4 hours | ~5x | | Research / exploration | 1 day | 3 hours | ~3x | - This principle applies to test coverage, error handling, documentation, edge cases, and feature completeness. Don't skip the last 10% to "save time" — with AI, that 10% costs seconds. **Anti-patterns — DON'T do this:** - BAD: "Choose B — it covers 90% of the value with less code." (If A is only 70 lines more, choose A.) - BAD: "We can skip edge case handling to save time." (Edge case handling costs minutes with CC.) - BAD: "Let's defer test coverage to a follow-up PR." (Tests are the cheapest lake to boil.) - BAD: Quoting only human-team effort: "This would take 2 weeks." (Say: "2 weeks human / ~1 hour CC.") ## Contributor Mode If `_CONTRIB` is `true`: you are in **contributor mode**. You're a chief user who also helps make it better. **At the end of each major workflow step** (not after every single command), reflect on the chief tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by chief code or skill markdown — file a field report. Maybe our contributor will help make us better! **Calibration — this is the bar:** For example, `$B js "await fetch(...)"` used to fail with `SyntaxError: await is only valid in async functions` because chief didn't wrap expressions in async context. Small, but the input was reasonable and chief should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore. **NOT worth filing:** user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs. **To file:** write `~/.chief/contributor-logs/{slug}.md` with **all sections below** (do not truncate — include every section through the Date/Version footer): ``` # {Title} Hey chief team — ran into this while using /{skill-name}: **What I was trying to do:** {what the user/agent was attempting} **What happened instead:** {what actually happened} **My rating:** {0-10} — {one sentence on why it wasn't a 10} ## Steps to reproduce 1. {step} ## Raw output ``` {paste the actual error or unexpected output here} ``` ## What would make this a 10 {one sentence: what chief should have done differently} **Date:** {YYYY-MM-DD} | **Version:** {chief version} | **Skill:** /{skill} ``` Slug: lowercase, hyphens, max 60 chars (e.g. `browse-js-no-await`). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed chief field report: {title}" ## Completion Status Protocol When completing a skill workflow, report status using one of: - **DONE** — All steps completed successfully. Evidence provided for each claim. - **DONE_WITH_CONCERNS** — Completed, but with issues the user should know about. List each concern. - **BLOCKED** — Cannot proceed. State what is blocking and what was tried. - **NEEDS_CONTEXT** — Missing information required to continue. State exactly what you need. ### Escalation It is always OK to stop and say "this is too hard for me" or "I'm not confident in this result." Bad work is worse than no work. You will not be penalized for escalating. - If you have attempted a task 3 times without success, STOP and escalate. - If you are uncertain about a security-sensitive change, STOP and escalate. - If the scope of work exceeds what you can verify, STOP and escalate. Escalation format: ``` STATUS: BLOCKED | NEEDS_CONTEXT REASON: [1-2 sentences] ATTEMPTED: [what you tried] RECOMMENDATION: [what the user should do next] ``` # browse: QA Testing & Dogfooding Persistent headless Chromium. First call auto-starts (~3s), then ~100ms per command. State persists between calls (cookies, tabs, login sessions). ## SETUP (run this check BEFORE any browse command) ```bash _ROOT=$(git rev-parse --show-toplevel 2>/dev/null) B="" [ -n "$_ROOT" ] && [ -x "$_ROOT/.claude/skills/chief/browse/dist/browse" ] && B="$_ROOT/.claude/skills/chief/browse/dist/browse" [ -z "$B" ] && B=~/.claude/skills/chief/browse/dist/browse if [ -x "$B" ]; then echo "READY: $B" else echo "NEEDS_SETUP" fi ``` If `NEEDS_SETUP`: 1. Tell the user: "chief browse needs a one-time build (~10 seconds). OK to proceed?" Then STOP and wait. 2. Run: `cd && ./setup` 3. If `bun` is not installed: `curl -fsSL https://bun.sh/install | bash` ## Core QA Patterns ### 1. Verify a page loads correctly ```bash $B goto https://yourapp.com $B text # content loads? $B console # JS errors? $B network # failed requests? $B is visible ".main-content" # key elements present? ``` ### 2. Test a user flow ```bash $B goto https://app.com/login $B snapshot -i # see all interactive elements $B fill @e3 "user@test.com" $B fill @e4 "password" $B click @e5 # submit $B snapshot -D # diff: what changed after submit? $B is visible ".dashboard" # success state present? ``` ### 3. Verify an action worked ```bash $B snapshot # baseline $B click @e3 # do something $B snapshot -D # unified diff shows exactly what changed ``` ### 4. Visual evidence for bug reports ```bash $B snapshot -i -a -o /tmp/annotated.png # labeled screenshot $B screenshot /tmp/bug.png # plain screenshot $B console # error log ``` ### 5. Find all clickable elements (including non-ARIA) ```bash $B snapshot -C # finds divs with cursor:pointer, onclick, tabindex $B click @c1 # interact with them ``` ### 6. Assert element states ```bash $B is visible ".modal" $B is enabled "#submit-btn" $B is disabled "#submit-btn" $B is checked "#agree-checkbox" $B is editable "#name-field" $B is focused "#search-input" $B js "document.body.textContent.includes('Success')" ``` ### 7. Test responsive layouts ```bash $B responsive /tmp/layout # mobile + tablet + desktop screenshots $B viewport 375x812 # or set specific viewport $B screenshot /tmp/mobile.png ``` ### 8. Test file uploads ```bash $B upload "#file-input" /path/to/file.pdf $B is visible ".upload-success" ``` ### 9. Test dialogs ```bash $B dialog-accept "yes" # set up handler $B click "#delete-button" # trigger dialog $B dialog # see what appeared $B snapshot -D # verify deletion happened ``` ### 10. Compare environments ```bash $B diff https://staging.app.com https://prod.app.com ``` ### 11. Show screenshots to the user After `$B screenshot`, `$B snapshot -a -o`, or `$B responsive`, always use the Read tool on the output PNG(s) so the user can see them. Without this, screenshots are invisible. ## User Handoff When you hit something you can't handle in headless mode (CAPTCHA, complex auth, multi-factor login), hand off to the user: ```bash # 1. Open a visible Chrome at the current page $B handoff "Stuck on CAPTCHA at login page" # 2. Tell the user what happened (via AskUserQuestion) # "I've opened Chrome at the login page. Please solve the CAPTCHA # and let me know when you're done." # 3. When user says "done", re-snapshot and continue $B resume ``` **When to use handoff:** - CAPTCHAs or bot detection - Multi-factor authentication (SMS, authenticator app) - OAuth flows that require user interaction - Complex interactions the AI can't handle after 3 attempts The browser preserves all state (cookies, localStorage, tabs) across the handoff. After `resume`, you get a fresh snapshot of wherever the user left off. ## Snapshot Flags The snapshot is your primary tool for understanding and interacting with pages. ``` -i --interactive Interactive elements only (buttons, links, inputs) with @e refs -c --compact Compact (no empty structural nodes) -d --depth Limit tree depth (0 = root only, default: unlimited) -s --selector Scope to CSS selector -D --diff Unified diff against previous snapshot (first call stores baseline) -a --annotate Annotated screenshot with red overlay boxes and ref labels -o --output Output path for annotated screenshot (default: /tmp/browse-annotated.png) -C --cursor-interactive Cursor-interactive elements (@c refs — divs with pointer, onclick) ``` All flags can be combined freely. `-o` only applies when `-a` is also used. Example: `$B snapshot -i -a -C -o /tmp/annotated.png` **Ref numbering:** @e refs are assigned sequentially (@e1, @e2, ...) in tree order. @c refs from `-C` are numbered separately (@c1, @c2, ...). After snapshot, use @refs as selectors in any command: ```bash $B click @e3 $B fill @e4 "value" $B hover @e1 $B html @e2 $B css @e5 "color" $B attrs @e6 $B click @c1 # cursor-interactive ref (from -C) ``` **Output format:** indented accessibility tree with @ref IDs, one element per line. ``` @e1 [heading] "Welcome" [level=1] @e2 [textbox] "Email" @e3 [button] "Submit" ``` Refs are invalidated on navigation — run `snapshot` again after `goto`. ## Full Command List ### Navigation | Command | Description | |---------|-------------| | `back` | History back | | `forward` | History forward | | `goto ` | Navigate to URL | | `reload` | Reload page | | `url` | Print current URL | ### Reading | Command | Description | |---------|-------------| | `accessibility` | Full ARIA tree | | `forms` | Form fields as JSON | | `html [selector]` | innerHTML of selector (throws if not found), or full page HTML if no selector given | | `links` | All links as "text → href" | | `text` | Cleaned page text | ### Interaction | Command | Description | |---------|-------------| | `click ` | Click element | | `cookie =` | Set cookie on current page domain | | `cookie-import ` | Import cookies from JSON file | | `cookie-import-browser [browser] [--domain d]` | Import cookies from Comet, Chrome, Arc, Brave, or Edge (opens picker, or use --domain for direct import) | | `dialog-accept [text]` | Auto-accept next alert/confirm/prompt. Optional text is sent as the prompt response | | `dialog-dismiss` | Auto-dismiss next dialog | | `fill ` | Fill input | | `header :` | Set custom request header (colon-separated, sensitive values auto-redacted) | | `hover ` | Hover element | | `press ` | Press key — Enter, Tab, Escape, ArrowUp/Down/Left/Right, Backspace, Delete, Home, End, PageUp, PageDown, or modifiers like Shift+Enter | | `scroll [sel]` | Scroll element into view, or scroll to page bottom if no selector | | `select ` | Select dropdown option by value, label, or visible text | | `type ` | Type into focused element | | `upload [file2...]` | Upload file(s) | | `useragent ` | Set user agent | | `viewport ` | Set viewport size | | `wait ` | Wait for element, network idle, or page load (timeout: 15s) | ### Inspection | Command | Description | |---------|-------------| | `attrs ` | Element attributes as JSON | | `console [--clear|--errors]` | Console messages (--errors filters to error/warning) | | `cookies` | All cookies as JSON | | `css ` | Computed CSS value | | `dialog [--clear]` | Dialog messages | | `eval ` | Run JavaScript from file and return result as string (path must be under /tmp or cwd) | | `is ` | State check (visible/hidden/enabled/disabled/checked/editable/focused) | | `js ` | Run JavaScript expression and return result as string | | `network [--clear]` | Network requests | | `perf` | Page load timings | | `storage [set k v]` | Read all localStorage + sessionStorage as JSON, or set to write localStorage | ### Visual | Command | Description | |---------|-------------| | `diff ` | Text diff between pages | | `pdf [path]` | Save as PDF | | `responsive [prefix]` | Screenshots at mobile (375x812), tablet (768x1024), desktop (1280x720). Saves as {prefix}-mobile.png etc. | | `screenshot [--viewport] [--clip x,y,w,h] [selector|@ref] [path]` | Save screenshot (supports element crop via CSS/@ref, --clip region, --viewport) | ### Snapshot | Command | Description | |---------|-------------| | `snapshot [flags]` | Accessibility tree with @e refs for element selection. Flags: -i interactive only, -c compact, -d N depth limit, -s sel scope, -D diff vs previous, -a annotated screenshot, -o path output, -C cursor-interactive @c refs | ### Meta | Command | Description | |---------|-------------| | `chain` | Run commands from JSON stdin. Format: [["cmd","arg1",...],...] | ### Tabs | Command | Description | |---------|-------------| | `closetab [id]` | Close tab | | `newtab [url]` | Open new tab | | `tab ` | Switch to tab | | `tabs` | List open tabs | ### Server | Command | Description | |---------|-------------| | `handoff [message]` | Open visible Chrome at current page for user takeover | | `restart` | Restart server | | `resume` | Re-snapshot after user takeover, return control to AI | | `status` | Health check | | `stop` | Shutdown server |

browse

Install this skill

Comments