[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71DE18AWAS5W9TYVW2NM6VR":3,"skill-same:01M71DE18AWAS5W9TYVW2NM6VR":133},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":16,"sourceHtmlUrl":17,"categories":18,"keywords":32,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":68,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M71DE18AWAS5W9TYVW2NM6VR","ui-test",null,"AI-powered adversarial UI testing via the browse CLI. Analyzes git diffs to test only what changed, or explores the full app to find bugs. Tests functional correctness, accessibility, responsive layout, and UX heuristics. Use when the user asks to test UI changes, QA a pull request, audit accessibility, or run exploratory testing. Supports local browser (localhost) and remote Browserbase (deployed sites).","x402agent\u002Fopenclawd-main","x402agent","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F243432990?v=4","01M71D6NTS5STS5KG360KMCGNJ","ClawdBot 🦞","01M71D6NVEWQSFGXWT7QDCXEM7",0,"MIT","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002FSKILL.md",[19,24,27],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":28,"categoryName":29,"taxonomyType":30,"taxonomyTypeDesc":31},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"ui test","test","ui","sites","for","browse","full","responsive","ui testing","responsive layout","git","read","run","functional","remote","diffs","local","testing","cookie","app","2026-11-10 10:12:30",false,"---\nname: ui-test\ndescription: \"AI-powered adversarial UI testing via the browse CLI. Analyzes git diffs to test only what changed, or explores the full app to find bugs. Tests functional correctness, accessibility, responsive layout, and UX heuristics. Use when the user asks to test UI changes, QA a pull request, audit accessibility, or run exploratory testing. Supports local browser (localhost) and remote Browserbase (deployed sites).\"\nlicense: MIT\nmetadata:\n  author: browserbase\n  version: \"0.4.0\"\nallowed-tools: Bash Read Glob Grep Agent\ncompatibility: \"Requires the browse CLI (`npm install -g @browserbasehq\u002Fbrowse-cli`). For remote testing: BROWSERBASE_API_KEY and cookie-sync skill.\"\n---\n\n# UI Test — Agentic UI Testing Skill\n\nTest UI changes in a real browser. Your job is to **try to break things**, not confirm they work.\n\nThree workflows:\n- **Diff-driven** — analyze a git diff, test only what changed\n- **Exploratory** — navigate the app, find bugs the developer didn't think about\n- **Parallel** — fan out independent test groups across multiple Browserbase browsers\n\n## How Testing Works\n\nThe main agent **coordinates** — it plans test strategy, delegates to sub-agents, and merges results. Sub-agents do the actual browser testing.\n\n### Planning: multiple angles, then execute once\n\n**You MUST complete all three planning rounds yourself and output them before launching any sub-agents.** Planning happens in your own response — it is NOT delegated to sub-agents. Do not skip ahead to execution.\n\n**Round 1 — Functional:** What are the core user flows? What should work? Write out each test as: action → expected result.\n\n**Round 2 — Adversarial:** Re-read Round 1. What did you miss? Think about: different user types\u002Froles, error paths, empty states, race conditions, edge inputs (empty, huge, special chars, rapid clicks).\n\n**Round 3 — Coverage gaps:** Re-read Rounds 1–2. What about: accessibility (axe-core, keyboard-only), mobile viewports, console errors, visual consistency with the rest of the app?\n\n**Deduplicate:** Merge all three rounds into one numbered list of tests. Remove overlaps. Assign each test to a group (e.g. Group A, Group B).\n\n**Then execute once** — launch one sub-agent per group. Each sub-agent receives its specific list of tests to run, nothing more. Sub-agents do not explore or plan — they execute assigned tests and report results.\n\nOutput the three rounds, the merged plan, and the group assignments in your response before calling any Agent tool.\n\n### Principles for splitting work\n\n- **Sub-agents run assigned tests, not open exploration.** The main agent hands each sub-agent a specific numbered list of tests. Sub-agents do not plan, explore, or decide what to test — they execute the list and stop.\n- **The bottleneck is the slowest agent** — split work so no single agent has a disproportionate share. Many small agents > few large ones.\n- **Size the effort to the change** — a single component fix doesn't need many agents or many steps. A full-page redesign does. Let the scope of the diff drive the plan.\n- **No early stopping on failures** — find as many bugs as possible within the assigned tests.\n\n### Giving sub-agents a step budget\n\n**The main agent MUST include an explicit browse step limit in every sub-agent prompt.** Sub-agents do not self-limit — they will run until done unless told otherwise.\n\nAs a rough heuristic: ~25 steps for a few targeted checks, ~40 for a full page with functional + adversarial + a11y, ~75 for multiple pages or a broad category. **Adjust based on what the assigned tests actually require** — these are starting points, not rules.\n\nAs a rough heuristic: ~25 steps for a few targeted checks, ~40 for a full page with functional + adversarial + a11y, ~75 for multiple pages or a broad category. **Adjust based on what the assigned tests actually require** — these are starting points, not rules.\n\nEvery sub-agent prompt must include:\n```\nYou have a budget of N browse steps (each `browse` command = 1 step). Count your steps as you go. When you reach N, stop immediately and report:\n- STEP_PASS\u002FSTEP_FAIL for every test you completed\n- STEP_SKIP|\u003Ctest-id>|budget reached for every test you didn't get to\n\nDo not retry or continue after hitting the budget.\nRun only these tests: [numbered list from the merged plan]\nDo not explore beyond the assigned tests.\nDo NOT generate an HTML report or write any files. Return only step markers and your findings as text.\n```\n\nThe main agent should NOT run `browse` commands itself (except to verify the dev server is up). All testing happens in sub-agents.\n\n**When a sub-agent hits its budget, the main agent accepts the partial results as-is.** Do not re-run or retry the sub-agent. Include SKIPPED tests in the final report so the developer knows what wasn't covered.\n\n### Reporting\n\n**Every sub-agent reports back with:**\n```\nTests: 8 | Passed: 5 | Failed: 2 | Skipped: 1 | Pages visited: 2\n```\n\n**The main agent merges into a final report with:**\n```\nTests: 20 | Passed: 14 | Failed: 4 | Skipped: 2 | Agents: 3 | Pass rate: 70%\n```\n\nDo not report \"steps used\" — browse command counts are implementation plumbing, not a meaningful metric for reviewers.\n\n## Testing Philosophy\n\n**You are an adversarial tester.** Your goal is to find bugs, not prove correctness.\n\n- **Try to break every feature you test.** Don't just check \"does the button exist?\" — click it twice rapidly, submit empty forms, paste 500 characters, press Escape mid-flow.\n- **Test what the developer didn't think about.** Empty states, error recovery, keyboard-only navigation, mobile overflow.\n- **Every assertion must be evidence-based.** Compare before\u002Fafter snapshots. Check specific elements by ref. Never report PASS without concrete evidence from the accessibility tree or a deterministic check.\n- **Report failures with enough detail to reproduce.** Include the exact action, what you expected, what you got, and a suggested fix.\n\n## Assertion Protocol\n\nEvery test step MUST produce a structured assertion. Do not write freeform \"this looks good.\"\n\n### Step markers\n\nFor each test step, emit exactly one marker:\n\n```\nSTEP_PASS|\u003Cstep-id>|\u003Cevidence>\n```\nor\n```\nSTEP_FAIL|\u003Cstep-id>|\u003Cexpected> → \u003Cactual>|\u003Cscreenshot-path>\n```\n\n- `step-id`: short identifier like `homepage-cta`, `form-validation-error`, `modal-cancel`\n- `evidence`: what you observed that proves the step passed (element ref, text content, URL, eval result)\n- `expected → actual`: what you expected vs what you got\n- `screenshot-path`: path to the saved screenshot (failures only — see Screenshot Capture below)\n\n### Screenshot Capture for Failures\n\n**Every STEP_FAIL MUST have an accompanying screenshot** so the developer can see what went wrong visually.\n\nWhen a test step fails:\n\n```bash\n# 1. Take a screenshot immediately after observing the failure\nbrowse screenshot --path .context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png\n\n# If --path is not supported, take the screenshot and save manually:\nbrowse screenshot\n# The browse CLI will output the screenshot path — move\u002Fcopy it:\ncp \u002Ftmp\u002Fbrowse-screenshot-*.png .context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png\n```\n\nSetup the screenshot directory at the start of any test run:\n\n```bash\nmkdir -p .context\u002Fui-test-screenshots\n```\n\n**Rules:**\n- File name = step-id (e.g., `double-submit.png`, `axe-audit.png`, `modal-focus-trap.png`)\n- Store in `.context\u002Fui-test-screenshots\u002F` — this directory is gitignored and accessible to the developer and other agents\n- For parallel runs, include the session name: `\u003Csession>-\u003Cstep-id>.png` (e.g., `signup-double-submit.png`)\n- Take the screenshot at the moment of failure — capture the broken state, not after recovery\n- For visual\u002Flayout bugs, also screenshot the baseline (working state) for comparison: `\u003Cstep-id>-baseline.png`\n\n### How to verify (in order of rigor)\n\n1. **Deterministic check** (strongest) — `browse eval` returns structured data you can inspect. Examples: axe-core violation count, `document.title`, form field value, console error array, element count.\n2. **Snapshot element match** — a specific element with a specific role and text exists in the accessibility tree. Check by ref: `@0-12 button \"Save\"`. An element either exists in the tree or it doesn't.\n3. **Before\u002Fafter comparison** — snapshot before action, act, snapshot after. Verify the tree changed in the expected way (element appeared, disappeared, text changed).\n4. **Screenshot + visual judgment** (weakest) — only for visual-only properties (color, spacing, layout) that the accessibility tree cannot capture. Always accompany with what specifically you're evaluating.\n\n### Before\u002Fafter comparison pattern\n\nThis is the core verification loop. Use it for every interaction:\n\n```bash\n# 1. BEFORE: capture state\nbrowse snapshot\n# Record: what elements exist, their text, their refs\n\n# 2. ACT: perform the interaction\nbrowse click @0-12\n\n# 3. AFTER: capture new state\nbrowse snapshot\n# Compare: what changed? What appeared? What disappeared?\n\n# 4. ASSERT: emit marker based on comparison\n# If dialog appeared: STEP_PASS|modal-open|dialog \"Confirm\" appeared at @0-20\n# If nothing changed:\nbrowse screenshot --path .context\u002Fui-test-screenshots\u002Fmodal-open.png\n# STEP_FAIL|modal-open|expected dialog to appear → snapshot unchanged|.context\u002Fui-test-screenshots\u002Fmodal-open.png\n```\n\n## Setup\n\n```bash\nwhich browse || npm install -g @browserbasehq\u002Fbrowse-cli\n```\n\n### Avoid permission fatigue\n\nThis skill runs many `browse` commands (snapshots, clicks, evals). To avoid approving each one, add `browse` to your allowed commands:\n\nAdd both patterns to `.claude\u002Fsettings.json` (project-level) or `~\u002F.claude\u002Fsettings.json` (user-level):\n```json\n{\n  \"permissions\": {\n    \"allow\": [\n      \"Bash(browse:*)\",\n      \"Bash(BROWSE_SESSION=*)\"\n    ]\n  }\n}\n```\n\nThe first pattern covers plain `browse` commands. The second covers parallel sessions (`BROWSE_SESSION=signup browse open ...`). Both are needed to avoid approval prompts.\n\n## Mode Selection\n\n| Target | Mode | Command | Auth |\n|--------|------|---------|------|\n| `localhost` \u002F `127.0.0.1` | Local | `browse env local` | None needed (clean isolated local browser by default) |\n| Deployed\u002Fstaging site | Remote | `browse env remote` | cookie-sync → `--context-id` |\n\n**Rule: If the target URL contains `localhost` or `127.0.0.1`, always use `browse env local`.**\n\n### Local Mode (default for localhost)\n\n```bash\nbrowse env local\nbrowse open http:\u002F\u002Flocalhost:3000\n```\n\n`browse env local` uses a clean isolated local browser by default, which is best for reproducible localhost QA runs.\n\nUse local-mode variants only when needed:\n\n- `browse env local --auto-connect` — auto-discover existing local Chrome, fallback to isolated. Use this only when the test explicitly needs existing local login\u002Fcookies\u002Fstate.\n- `browse env local \u003Cport|url>` — attach to a specific CDP target (explicit local browser attach).\n\n### Remote Mode (deployed sites via cookie-sync)\n\n```bash\n# Step 1: Sync cookies from local Chrome to Browserbase\nnode .claude\u002Fskills\u002Fcookie-sync\u002Fscripts\u002Fcookie-sync.mjs --domains your-app.com\n# Output: Context ID: ctx_abc123\n\n# Step 2: Switch to remote mode\nbrowse env remote\nbrowse open https:\u002F\u002Fstaging.your-app.com --context-id ctx_abc123 --persist\nbrowse snapshot\n# ... run tests ...\nbrowse stop\n```\n\nCookie-sync flags: `--domains`, `--context`, `--stealth`, `--proxy \"City,ST,US\"`\n\n## Workflow A: Diff-Driven Testing\n\n### Phase 1: Analyze the diff\n\n```bash\ngit diff --name-only HEAD~1          # or: git diff --name-only \u002F git diff --name-only main...HEAD\ngit diff HEAD~1 -- \u003Cfile>            # read actual changes\n```\n\nCategorize changed files:\n\n| File pattern | UI impact | What to test |\n|-------------|-----------|--------------|\n| `*.tsx`, `*.jsx`, `*.vue`, `*.svelte` | Component | Render, interaction, state, edge cases |\n| `pages\u002F**`, `app\u002F**`, `src\u002Froutes\u002F**` | Route\u002Fpage | Navigation, page load, content, 404 handling |\n| `*.css`, `*.scss`, `*.module.css` | Style | Visual appearance (screenshot), responsive |\n| `*form*`, `*input*`, `*field*` | Form | Validation, submission, empty input, long input, special chars |\n| `*modal*`, `*dialog*`, `*dropdown*` | Interactive | Open\u002Fclose, escape, focus trap, cancel vs confirm |\n| `*nav*`, `*menu*`, `*header*` | Navigation | Links, active states, routing, keyboard nav |\n| Non-UI files only | None | Skip — report \"no UI tests needed\" |\n\n### Phase 2: Map files to URLs\n\nDetect framework: `cat package.json | grep -E '\"(next|react|vue|nuxt|svelte|@sveltejs|angular|vite)\"'`\n\n| Framework | Default port | File → URL pattern |\n|-----------|-------------|-----|\n| Next.js App Router | 3000 | `app\u002Fdashboard\u002Fpage.tsx` → `\u002Fdashboard` |\n| Next.js Pages Router | 3000 | `pages\u002Fabout.tsx` → `\u002Fabout` |\n| Vite | 5173 | Check router config |\n| Nuxt | 3000 | `pages\u002Findex.vue` → `\u002F` |\n| SvelteKit | 5173 | `src\u002Froutes\u002F+page.svelte` → `\u002F` |\n| Angular | 4200 | Check routing module |\n\n### Phase 3: Ensure the right code is running\n\nBefore testing, verify the dev server is serving the code from the diff — not a stale branch.\n\n**If testing a PR or specific branch:**\n```bash\n# Check what branch is currently checked out\ngit branch --show-current\n\n# If it's not the PR branch, switch to it\ngit fetch origin \u003Cbranch> && git checkout \u003Cbranch>\n\n# Install deps — the lockfile may differ between branches\nyarn install  # or npm install \u002F pnpm install\n```\n\nIf the dev server was already running on a different branch, restart it after checkout.\n\n**Find a running dev server:**\n```bash\nfor port in 3000 3001 5173 4200 8080 8000 5000; do\n  s=$(curl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" \"http:\u002F\u002Flocalhost:$port\" 2>\u002Fdev\u002Fnull)\n  if [ \"$s\" != \"000\" ]; then echo \"Dev server on port $port (HTTP $s)\"; fi\ndone\n```\n\nIf nothing found: tell the user to start their dev server.\n\n**Verify it actually renders:**\nAfter `browse open` + `browse snapshot`, check that the accessibility tree contains real page content (navigation, headings, interactive elements) — not just an error overlay or empty body. Next.js dev servers can return HTTP 200 while showing a full-screen build error dialog. If the snapshot is empty or dominated by an error dialog, the server is broken — fix the build before testing.\n\n### Phase 4: Generate test plan\n\nFor each changed area, plan **both happy path AND adversarial tests**:\n\n```\nTest Plan (based on git diff)\n=============================\nChanged: src\u002Fcomponents\u002FSignupForm.tsx (added email validation)\n\n1. [happy] Valid email submits successfully\n   URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n   Steps: fill valid email → submit → verify success message appears\n\n2. [adversarial] Invalid email shows error\n   Steps: fill \"not-an-email\" → submit → verify error message appears\n\n3. [adversarial] Empty form submission\n   Steps: click submit without filling anything → verify error, no crash\n\n4. [adversarial] XSS in email field\n   Steps: fill \"\u003Cscript>alert(1)\u003C\u002Fscript>\" → submit → verify sanitized\u002Frejected\n\n5. [adversarial] Rapid double-submit\n   Steps: click submit twice quickly → verify no duplicate submission\n\n6. [adversarial] Keyboard-only flow\n   Steps: Tab to email → type → Tab to submit → Enter → verify success\n```\n\n### Phase 5: Execute tests\n\n```bash\nbrowse stop 2>\u002Fdev\u002Fnull\nmkdir -p .context\u002Fui-test-screenshots\n# localhost\u002Fdefault QA → clean, reproducible local run\nbrowse env local\n```\n\nFor each test, follow the **before\u002Fafter pattern**:\n\n```bash\n# Navigate\nbrowse open http:\u002F\u002Flocalhost:3000\u002Fpath\nbrowse wait load\n\n# BEFORE snapshot\nbrowse snapshot\n# Note the current state: elements, refs, text\n\n# ACT\nbrowse click @0-ref\n# or: browse fill \"selector\" \"value\"\n# or: browse type \"text\"\n# or: browse press Enter\n\n# AFTER snapshot\nbrowse snapshot\n# Compare against BEFORE: what changed?\n\n# ASSERT with marker\n# STEP_PASS|step-id|evidence  OR  STEP_FAIL|step-id|expected → actual\n```\n\n### Phase 6: Report results\n\n```\n## UI Test Results\n\n### STEP_PASS|valid-email-submit|status \"Thanks!\" appeared at @0-42 after submit\n- URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n- Before: form with email input @0-3, submit button @0-7\n- Action: filled \"user@test.com\", clicked @0-7\n- After: form replaced by status element with \"Thanks! We'll be in touch.\"\n\n### STEP_FAIL|double-submit|expected single submission → form submitted twice|.context\u002Fui-test-screenshots\u002Fdouble-submit.png\n- URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n- Before: form with submit button @0-7\n- Action: clicked @0-7 twice rapidly\n- After: two success toasts appeared, suggesting duplicate submission\n- Screenshot: .context\u002Fui-test-screenshots\u002Fdouble-submit.png\n- Suggestion: disable submit button after first click, or debounce the handler\n\n---\n**Summary: 4\u002F6 passed, 2 failed**\nFailed: double-submit, xss-sanitization\n\nScreenshots saved to `.context\u002Fui-test-screenshots\u002F` — open any failed step's screenshot to see the broken state.\n```\n\nAlways `browse stop` when done.\n\n### Phase 7: Generate HTML report\n\nAfter producing the text report, generate a standalone HTML report that a reviewer can open in a browser. The report embeds screenshots inline (base64) so it works as a single file — no external dependencies.\n\n**Why:** Text reports are good for the agent conversation, but reviewers (PMs, designers, other engineers) want a visual artifact they can open, scan, and share. Screenshots inline make failures immediately obvious.\n\n#### How to generate\n\n1. Read the HTML template at [references\u002Freport-template.html](references\u002Freport-template.html)\n2. Build the report by replacing the template placeholders with actual test data:\n\n| Placeholder | Value |\n|-------------|-------|\n| `{{TITLE}}` | Report title for `\u003Ctitle>` tag (e.g., \"UI Test: PR #1234 — OAuth Settings\") |\n| `{{TITLE_HTML}}` | Report title for the visible `\u003Ch1>`. If a PR URL is available, wrap the PR reference in an `\u003Ca>` tag so it's clickable (e.g., `UI Test: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F1234\">PR #1234\u003C\u002Fa> — OAuth Settings`). If no URL, use plain text same as `{{TITLE}}`. |\n| `{{META}}` | One-line context: date, app URL, user, branch |\n| `{{TOTAL_TESTS}}` | Total STEP_PASS + STEP_FAIL count |\n| `{{AGENT_COUNT}}` | Number of sub-agents that ran |\n| `{{PASS_COUNT}}` | Number of STEP_PASS |\n| `{{FAIL_COUNT}}` | Number of STEP_FAIL |\n| `{{PASS_RATE}}` | Integer percentage (e.g., \"92\") |\n| `{{RATE_CLASS}}` | `good` (≥90%), `warn` (70–89%), `bad` (\u003C70%) |\n| `{{FAILURES_SECTION}}` | HTML for failed test cards (see below) |\n| `{{PASSES_SECTION}}` | HTML for passed test cards (see below) |\n\n3. For each test result, generate a `\u003Cdetails>` card. Failed tests should be **open by default** so reviewers see them immediately:\n\n```html\n\u003C!-- Failed test card (open by default) -->\n\u003Cdiv class=\"section\">\n  \u003Ch2>Failures \u003Cspan class=\"count\">{{FAIL_COUNT}}\u003C\u002Fspan>\u003C\u002Fh2>\n  \u003Cdetails class=\"test-card fail\" open>\n    \u003Csummary>\n      \u003Cspan class=\"badge fail\">FAIL\u003C\u002Fspan>\n      \u003Cspan class=\"step-id\">step-id-here\u003C\u002Fspan>\n      \u003Cspan class=\"evidence\">expected → actual\u003C\u002Fspan>\n    \u003C\u002Fsummary>\n    \u003Cdiv class=\"body\">\n      \u003Cdl>\n        \u003Cdt>URL\u003C\u002Fdt>\u003Cdd>http:\u002F\u002Flocalhost:3000\u002Fpath\u003C\u002Fdd>\n        \u003Cdt>Action\u003C\u002Fdt>\u003Cdd>What was done\u003C\u002Fdd>\n        \u003Cdt>Expected\u003C\u002Fdt>\u003Cdd>What should have happened\u003C\u002Fdd>\n        \u003Cdt>Actual\u003C\u002Fdt>\u003Cdd>What happened instead\u003C\u002Fdd>\n      \u003C\u002Fdl>\n      \u003Cdiv class=\"suggestion\">Fix: description of suggested fix\u003C\u002Fdiv>\n      \u003Cdiv class=\"screenshot\">\n        \u003Cimg src=\"data:image\u002Fpng;base64,...\" alt=\"Screenshot of failure\">\n        \u003Cdiv class=\"caption\">step-id.png — captured at moment of failure\u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n    \u003C\u002Fdiv>\n  \u003C\u002Fdetails>\n\u003C\u002Fdiv>\n\n\u003C!-- Passed test card (collapsed by default) -->\n\u003Cdiv class=\"section\">\n  \u003Ch2>Passed \u003Cspan class=\"count\">{{PASS_COUNT}}\u003C\u002Fspan>\u003C\u002Fh2>\n  \u003Cdetails class=\"test-card pass\">\n    \u003Csummary>\n      \u003Cspan class=\"badge pass\">PASS\u003C\u002Fspan>\n      \u003Cspan class=\"step-id\">step-id-here\u003C\u002Fspan>\n      \u003Cspan class=\"evidence\">evidence summary\u003C\u002Fspan>\n    \u003C\u002Fsummary>\n    \u003Cdiv class=\"body\">\n      \u003Cdl>\n        \u003Cdt>URL\u003C\u002Fdt>\u003Cdd>http:\u002F\u002Flocalhost:3000\u002Fpath\u003C\u002Fdd>\n        \u003Cdt>Evidence\u003C\u002Fdt>\u003Cdd>What was observed\u003C\u002Fdd>\n      \u003C\u002Fdl>\n    \u003C\u002Fdiv>\n  \u003C\u002Fdetails>\n\u003C\u002Fdiv>\n```\n\n4. **Embed screenshots as base64** so the HTML is fully self-contained:\n\n```bash\n# Convert screenshot to base64 data URI\nbase64 -i .context\u002Fui-test-screenshots\u002Fstep-id.png | tr -d '\\n'\n# Use as: src=\"data:image\u002Fpng;base64,\u003Coutput>\"\n```\n\nRead each screenshot file referenced in STEP_FAIL markers, base64-encode it, and embed it as an `\u003Cimg src=\"data:image\u002Fpng;base64,...\">` in the corresponding test card. For STEP_PASS, only embed a screenshot if one was explicitly taken (e.g., baseline screenshots).\n\n5. Write the final HTML to `.context\u002Fui-test-report.html`:\n\n```bash\n# Write the generated HTML\ncat > .context\u002Fui-test-report.html \u003C\u003C 'REPORT_EOF'\n\u003C!DOCTYPE html>\n...generated report...\nREPORT_EOF\n\n# Open it for the reviewer\nopen .context\u002Fui-test-report.html  # macOS\n# xdg-open .context\u002Fui-test-report.html  # Linux\n```\n\n6. Tell the user: `Report saved to .context\u002Fui-test-report.html` and offer to open it.\n\n**Rules:**\n- Failures section comes before passes — reviewers care about what's broken first\n- Failed cards are `open` by default; passed cards are collapsed\n- Every STEP_FAIL card MUST have an embedded screenshot — if the screenshot file is missing, note it in the card\n- Include the suggestion\u002Ffix in each failure card if one was provided\n- The report must work offline — no CDN links, no external assets\n- Keep the HTML under 5MB — if screenshots push it over, reduce image quality or skip baseline screenshots for passes\n\n## Adversarial Test Patterns\n\nApply these to every interactive element you test. Read [references\u002Fadversarial-patterns.md](references\u002Fadversarial-patterns.md) for the full pattern library (forms, modals, navigation, error states, keyboard accessibility).\n\n## Deterministic Checks\n\nThese produce structured data, not judgment calls. Use them as the strongest form of assertion.\n\n| Check | What it catches | Assertion |\n|-------|----------------|-----------|\n| axe-core | WCAG violations | `violations.length === 0` |\n| Console errors | Runtime exceptions, failed requests | empty error array |\n| Broken images | Missing\u002Ffailed image loads | no images with `naturalWidth === 0` |\n| Form labels | Inputs without accessible labels | every input has `hasLabel: true` |\n\nFor the exact `browse eval` recipes, read [references\u002Fbrowser-recipes.md](references\u002Fbrowser-recipes.md).\n\n## Workflow B: Exploratory Testing\n\nNo diff, no plan — just open the app and try to break it. Use this when the user says \"test my app\", \"find bugs\", or \"QA this site.\"\n\n### Approach\n\n1. **Discover the app** — read `package.json` to detect the framework, then open the root URL and snapshot to see what's there\n2. **Navigate everything** — click through nav links, visit every reachable page, note what exists\n3. **Test what you find** — for each page, apply the adversarial patterns below (forms, modals, navigation, keyboard, error states)\n4. **Run deterministic checks** — axe-core, console errors, broken images, form labels on every page\n5. **Report findings** — use STEP_PASS\u002FSTEP_FAIL markers, include reproduction steps for failures\n\nDon't try to be systematic about coverage. Just explore like a user would, but with the intent to break things. The agent is good at this — let it roam.\n\n### Tips for exploratory runs\n\n- Start with the homepage, then follow the navigation naturally\n- Try the 404 page (`\u002Fdoes-not-exist`) — is it custom or default?\n- Look for empty states (pages with no data)\n- Test forms with garbage input before valid input\n- Check mobile viewport (375px) on every page — does it overflow?\n- If the app has auth, use cookie-sync first\n\n## Workflow C: Parallel Testing\n\nRun independent test groups concurrently using named `browse` sessions (`BROWSE_SESSION=\u003Cname>`). Each session gets its own browser. Works with both local and remote mode.\n\nUse when testing multiple pages or categories and you want faster wall clock time.\n\nRead [references\u002Fparallel-testing.md](references\u002Fparallel-testing.md) for the full workflow: session setup, agent fan-out, cookie-sync for auth, and result merging.\n\n## Design Consistency\n\nCheck whether changed UI matches the rest of the app visually. Read [references\u002Fdesign-consistency.md](references\u002Fdesign-consistency.md) when doing visual or design checks.\n\n## Test Categories\n\n| Category | How | Assertion type |\n|----------|-----|---------------|\n| Accessibility | axe-core + keyboard nav | Deterministic (violation count) |\n| Visual Quality | Screenshot + heuristic evaluation | Visual judgment (weakest — note specifics) |\n| Responsive | Viewport sweep + screenshots | Visual + deterministic (overflow check) |\n| Console Health | Console capture eval | Deterministic (error count) |\n| UX Heuristics | Snapshot + Laws of UX + Nielsen's | Structured judgment (cite specific heuristic) |\n| Error States | Navigate to empty\u002Ferror states | Before\u002Fafter comparison |\n| Data Display | Snapshot on tables\u002Fdashboards | Element match (column count, formatting) |\n| Design Consistency | Screenshot baseline + changed page comparison | Visual judgment (cite specific property) |\n| Exploratory | Free navigation + adversarial testing | Before\u002Fafter + judgment |\n\nReference guides (load on demand):\n- **Adversarial patterns** — [references\u002Fadversarial-patterns.md](references\u002Fadversarial-patterns.md) — load when testing forms, modals, navigation, or keyboard a11y\n- **Browser recipes** — [references\u002Fbrowser-recipes.md](references\u002Fbrowser-recipes.md) — load when running deterministic checks (axe-core, console, images, form labels)\n- **Exploratory testing** — [references\u002Fexploratory-testing.md](references\u002Fexploratory-testing.md) — load for Workflow B (no diff, open exploration)\n- **UX heuristics** — [references\u002Fux-heuristics.md](references\u002Fux-heuristics.md) — load when evaluating UX quality or citing specific heuristics\n- **Design system** — [references\u002Fdesign-system.example.md](references\u002Fdesign-system.example.md) — template for users to customize\n- **Design consistency** — [references\u002Fdesign-consistency.md](references\u002Fdesign-consistency.md) — load when doing visual consistency checks\n- **Parallel testing** — [references\u002Fparallel-testing.md](references\u002Fparallel-testing.md) — load for Workflow C (concurrent sessions)\n- **Report template** — [references\u002Freport-template.html](references\u002Freport-template.html) — HTML template for Phase 7 report generation\n\nFor worked examples with exact commands, read [EXAMPLES.md](EXAMPLES.md) if you need to see the assertion protocol in action.\n\n## Best Practices\n\n1. **Be adversarial** — try to break things, don't just confirm they work\n2. **Every assertion needs evidence** — snapshot ref, eval result, or before\u002Fafter diff\n3. **Before\u002Fafter for every interaction** — snapshot, act, snapshot, compare\n4. **Screenshot every failure** — `browse screenshot` immediately on STEP_FAIL, save to `.context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png`\n5. **Deterministic checks first** — axe-core, console errors, form labels before visual judgment\n6. **For localhost, start with clean local mode** — use `browse env local` first for reproducible runs; use `--auto-connect` only when existing local state is required\n7. **Always `browse stop` when done** — for parallel runs, stop every named session\n8. **Report failures with reproduction steps** — action, expected, actual, screenshot path, suggestion\n9. **Parallelize independent tests** — use Workflow C with named sessions when testing multiple pages or categories on a deployed site\n\n## Troubleshooting\n\n- **\"No active page\"**: `browse stop`, retry. For zombies: `pkill -f \"browse.*daemon\"`\n- **Dev server not responding**: `curl http:\u002F\u002Flocalhost:\u003Cport>` — ask user to start it\n- **`browse eval` with `await` fails**: Use `.then()` instead — `browse eval` doesn't support top-level await\n- **Element ref not found**: `browse snapshot` again — refs change on page update\n- **Blank snapshot**: `browse wait load` or `browse wait selector \".expected\"` before snapshotting\n- **SPA deep links 404**: Navigate to `\u002F` first, then click through\n- **Remote auth fails**: Re-run cookie-sync with `--context \u003Cid>`, try `--stealth`\n- **Parallel session conflicts**: Ensure every `browse` command uses `BROWSE_SESSION=\u003Cname>` — without it, commands go to the default session\n- **Session not stopping**: `BROWSE_SESSION=\u003Cname> browse stop`. For zombies: `pkill -f \"browse.*\u003Cname>.*daemon\"`\n","# UI Test — Agentic UI Testing Skill\n\nTest UI changes in a real browser. Your job is to **try to break things**, not confirm they work.\n\nThree workflows:\n- **Diff-driven** — analyze a git diff, test only what changed\n- **Exploratory** — navigate the app, find bugs the developer didn't think about\n- **Parallel** — fan out independent test groups across multiple Browserbase browsers\n\n## How Testing Works\n\nThe main agent **coordinates** — it plans test strategy, delegates to sub-agents, and merges results. Sub-agents do the actual browser testing.\n\n### Planning: multiple angles, then execute once\n\n**You MUST complete all three planning rounds yourself and output them before launching any sub-agents.** Planning happens in your own response — it is NOT delegated to sub-agents. Do not skip ahead to execution.\n\n**Round 1 — Functional:** What are the core user flows? What should work? Write out each test as: action → expected result.\n\n**Round 2 — Adversarial:** Re-read Round 1. What did you miss? Think about: different user types\u002Froles, error paths, empty states, race conditions, edge inputs (empty, huge, special chars, rapid clicks).\n\n**Round 3 — Coverage gaps:** Re-read Rounds 1–2. What about: accessibility (axe-core, keyboard-only), mobile viewports, console errors, visual consistency with the rest of the app?\n\n**Deduplicate:** Merge all three rounds into one numbered list of tests. Remove overlaps. Assign each test to a group (e.g. Group A, Group B).\n\n**Then execute once** — launch one sub-agent per group. Each sub-agent receives its specific list of tests to run, nothing more. Sub-agents do not explore or plan — they execute assigned tests and report results.\n\nOutput the three rounds, the merged plan, and the group assignments in your response before calling any Agent tool.\n\n### Principles for splitting work\n\n- **Sub-agents run assigned tests, not open exploration.** The main agent hands each sub-agent a specific numbered list of tests. Sub-agents do not plan, explore, or decide what to test — they execute the list and stop.\n- **The bottleneck is the slowest agent** — split work so no single agent has a disproportionate share. Many small agents > few large ones.\n- **Size the effort to the change** — a single component fix doesn't need many agents or many steps. A full-page redesign does. Let the scope of the diff drive the plan.\n- **No early stopping on failures** — find as many bugs as possible within the assigned tests.\n\n### Giving sub-agents a step budget\n\n**The main agent MUST include an explicit browse step limit in every sub-agent prompt.** Sub-agents do not self-limit — they will run until done unless told otherwise.\n\nAs a rough heuristic: ~25 steps for a few targeted checks, ~40 for a full page with functional + adversarial + a11y, ~75 for multiple pages or a broad category. **Adjust based on what the assigned tests actually require** — these are starting points, not rules.\n\nAs a rough heuristic: ~25 steps for a few targeted checks, ~40 for a full page with functional + adversarial + a11y, ~75 for multiple pages or a broad category. **Adjust based on what the assigned tests actually require** — these are starting points, not rules.\n\nEvery sub-agent prompt must include:\n```\nYou have a budget of N browse steps (each `browse` command = 1 step). Count your steps as you go. When you reach N, stop immediately and report:\n- STEP_PASS\u002FSTEP_FAIL for every test you completed\n- STEP_SKIP|\u003Ctest-id>|budget reached for every test you didn't get to\n\nDo not retry or continue after hitting the budget.\nRun only these tests: [numbered list from the merged plan]\nDo not explore beyond the assigned tests.\nDo NOT generate an HTML report or write any files. Return only step markers and your findings as text.\n```\n\nThe main agent should NOT run `browse` commands itself (except to verify the dev server is up). All testing happens in sub-agents.\n\n**When a sub-agent hits its budget, the main agent accepts the partial results as-is.** Do not re-run or retry the sub-agent. Include SKIPPED tests in the final report so the developer knows what wasn't covered.\n\n### Reporting\n\n**Every sub-agent reports back with:**\n```\nTests: 8 | Passed: 5 | Failed: 2 | Skipped: 1 | Pages visited: 2\n```\n\n**The main agent merges into a final report with:**\n```\nTests: 20 | Passed: 14 | Failed: 4 | Skipped: 2 | Agents: 3 | Pass rate: 70%\n```\n\nDo not report \"steps used\" — browse command counts are implementation plumbing, not a meaningful metric for reviewers.\n\n## Testing Philosophy\n\n**You are an adversarial tester.** Your goal is to find bugs, not prove correctness.\n\n- **Try to break every feature you test.** Don't just check \"does the button exist?\" — click it twice rapidly, submit empty forms, paste 500 characters, press Escape mid-flow.\n- **Test what the developer didn't think about.** Empty states, error recovery, keyboard-only navigation, mobile overflow.\n- **Every assertion must be evidence-based.** Compare before\u002Fafter snapshots. Check specific elements by ref. Never report PASS without concrete evidence from the accessibility tree or a deterministic check.\n- **Report failures with enough detail to reproduce.** Include the exact action, what you expected, what you got, and a suggested fix.\n\n## Assertion Protocol\n\nEvery test step MUST produce a structured assertion. Do not write freeform \"this looks good.\"\n\n### Step markers\n\nFor each test step, emit exactly one marker:\n\n```\nSTEP_PASS|\u003Cstep-id>|\u003Cevidence>\n```\nor\n```\nSTEP_FAIL|\u003Cstep-id>|\u003Cexpected> → \u003Cactual>|\u003Cscreenshot-path>\n```\n\n- `step-id`: short identifier like `homepage-cta`, `form-validation-error`, `modal-cancel`\n- `evidence`: what you observed that proves the step passed (element ref, text content, URL, eval result)\n- `expected → actual`: what you expected vs what you got\n- `screenshot-path`: path to the saved screenshot (failures only — see Screenshot Capture below)\n\n### Screenshot Capture for Failures\n\n**Every STEP_FAIL MUST have an accompanying screenshot** so the developer can see what went wrong visually.\n\nWhen a test step fails:\n\n```bash\n# 1. Take a screenshot immediately after observing the failure\nbrowse screenshot --path .context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png\n\n# If --path is not supported, take the screenshot and save manually:\nbrowse screenshot\n# The browse CLI will output the screenshot path — move\u002Fcopy it:\ncp \u002Ftmp\u002Fbrowse-screenshot-*.png .context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png\n```\n\nSetup the screenshot directory at the start of any test run:\n\n```bash\nmkdir -p .context\u002Fui-test-screenshots\n```\n\n**Rules:**\n- File name = step-id (e.g., `double-submit.png`, `axe-audit.png`, `modal-focus-trap.png`)\n- Store in `.context\u002Fui-test-screenshots\u002F` — this directory is gitignored and accessible to the developer and other agents\n- For parallel runs, include the session name: `\u003Csession>-\u003Cstep-id>.png` (e.g., `signup-double-submit.png`)\n- Take the screenshot at the moment of failure — capture the broken state, not after recovery\n- For visual\u002Flayout bugs, also screenshot the baseline (working state) for comparison: `\u003Cstep-id>-baseline.png`\n\n### How to verify (in order of rigor)\n\n1. **Deterministic check** (strongest) — `browse eval` returns structured data you can inspect. Examples: axe-core violation count, `document.title`, form field value, console error array, element count.\n2. **Snapshot element match** — a specific element with a specific role and text exists in the accessibility tree. Check by ref: `@0-12 button \"Save\"`. An element either exists in the tree or it doesn't.\n3. **Before\u002Fafter comparison** — snapshot before action, act, snapshot after. Verify the tree changed in the expected way (element appeared, disappeared, text changed).\n4. **Screenshot + visual judgment** (weakest) — only for visual-only properties (color, spacing, layout) that the accessibility tree cannot capture. Always accompany with what specifically you're evaluating.\n\n### Before\u002Fafter comparison pattern\n\nThis is the core verification loop. Use it for every interaction:\n\n```bash\n# 1. BEFORE: capture state\nbrowse snapshot\n# Record: what elements exist, their text, their refs\n\n# 2. ACT: perform the interaction\nbrowse click @0-12\n\n# 3. AFTER: capture new state\nbrowse snapshot\n# Compare: what changed? What appeared? What disappeared?\n\n# 4. ASSERT: emit marker based on comparison\n# If dialog appeared: STEP_PASS|modal-open|dialog \"Confirm\" appeared at @0-20\n# If nothing changed:\nbrowse screenshot --path .context\u002Fui-test-screenshots\u002Fmodal-open.png\n# STEP_FAIL|modal-open|expected dialog to appear → snapshot unchanged|.context\u002Fui-test-screenshots\u002Fmodal-open.png\n```\n\n## Setup\n\n```bash\nwhich browse || npm install -g @browserbasehq\u002Fbrowse-cli\n```\n\n### Avoid permission fatigue\n\nThis skill runs many `browse` commands (snapshots, clicks, evals). To avoid approving each one, add `browse` to your allowed commands:\n\nAdd both patterns to `.claude\u002Fsettings.json` (project-level) or `~\u002F.claude\u002Fsettings.json` (user-level):\n```json\n{\n  \"permissions\": {\n    \"allow\": [\n      \"Bash(browse:*)\",\n      \"Bash(BROWSE_SESSION=*)\"\n    ]\n  }\n}\n```\n\nThe first pattern covers plain `browse` commands. The second covers parallel sessions (`BROWSE_SESSION=signup browse open ...`). Both are needed to avoid approval prompts.\n\n## Mode Selection\n\n| Target | Mode | Command | Auth |\n|--------|------|---------|------|\n| `localhost` \u002F `127.0.0.1` | Local | `browse env local` | None needed (clean isolated local browser by default) |\n| Deployed\u002Fstaging site | Remote | `browse env remote` | cookie-sync → `--context-id` |\n\n**Rule: If the target URL contains `localhost` or `127.0.0.1`, always use `browse env local`.**\n\n### Local Mode (default for localhost)\n\n```bash\nbrowse env local\nbrowse open http:\u002F\u002Flocalhost:3000\n```\n\n`browse env local` uses a clean isolated local browser by default, which is best for reproducible localhost QA runs.\n\nUse local-mode variants only when needed:\n\n- `browse env local --auto-connect` — auto-discover existing local Chrome, fallback to isolated. Use this only when the test explicitly needs existing local login\u002Fcookies\u002Fstate.\n- `browse env local \u003Cport|url>` — attach to a specific CDP target (explicit local browser attach).\n\n### Remote Mode (deployed sites via cookie-sync)\n\n```bash\n# Step 1: Sync cookies from local Chrome to Browserbase\nnode .claude\u002Fskills\u002Fcookie-sync\u002Fscripts\u002Fcookie-sync.mjs --domains your-app.com\n# Output: Context ID: ctx_abc123\n\n# Step 2: Switch to remote mode\nbrowse env remote\nbrowse open https:\u002F\u002Fstaging.your-app.com --context-id ctx_abc123 --persist\nbrowse snapshot\n# ... run tests ...\nbrowse stop\n```\n\nCookie-sync flags: `--domains`, `--context`, `--stealth`, `--proxy \"City,ST,US\"`\n\n## Workflow A: Diff-Driven Testing\n\n### Phase 1: Analyze the diff\n\n```bash\ngit diff --name-only HEAD~1          # or: git diff --name-only \u002F git diff --name-only main...HEAD\ngit diff HEAD~1 -- \u003Cfile>            # read actual changes\n```\n\nCategorize changed files:\n\n| File pattern | UI impact | What to test |\n|-------------|-----------|--------------|\n| `*.tsx`, `*.jsx`, `*.vue`, `*.svelte` | Component | Render, interaction, state, edge cases |\n| `pages\u002F**`, `app\u002F**`, `src\u002Froutes\u002F**` | Route\u002Fpage | Navigation, page load, content, 404 handling |\n| `*.css`, `*.scss`, `*.module.css` | Style | Visual appearance (screenshot), responsive |\n| `*form*`, `*input*`, `*field*` | Form | Validation, submission, empty input, long input, special chars |\n| `*modal*`, `*dialog*`, `*dropdown*` | Interactive | Open\u002Fclose, escape, focus trap, cancel vs confirm |\n| `*nav*`, `*menu*`, `*header*` | Navigation | Links, active states, routing, keyboard nav |\n| Non-UI files only | None | Skip — report \"no UI tests needed\" |\n\n### Phase 2: Map files to URLs\n\nDetect framework: `cat package.json | grep -E '\"(next|react|vue|nuxt|svelte|@sveltejs|angular|vite)\"'`\n\n| Framework | Default port | File → URL pattern |\n|-----------|-------------|-----|\n| Next.js App Router | 3000 | `app\u002Fdashboard\u002Fpage.tsx` → `\u002Fdashboard` |\n| Next.js Pages Router | 3000 | `pages\u002Fabout.tsx` → `\u002Fabout` |\n| Vite | 5173 | Check router config |\n| Nuxt | 3000 | `pages\u002Findex.vue` → `\u002F` |\n| SvelteKit | 5173 | `src\u002Froutes\u002F+page.svelte` → `\u002F` |\n| Angular | 4200 | Check routing module |\n\n### Phase 3: Ensure the right code is running\n\nBefore testing, verify the dev server is serving the code from the diff — not a stale branch.\n\n**If testing a PR or specific branch:**\n```bash\n# Check what branch is currently checked out\ngit branch --show-current\n\n# If it's not the PR branch, switch to it\ngit fetch origin \u003Cbranch> && git checkout \u003Cbranch>\n\n# Install deps — the lockfile may differ between branches\nyarn install  # or npm install \u002F pnpm install\n```\n\nIf the dev server was already running on a different branch, restart it after checkout.\n\n**Find a running dev server:**\n```bash\nfor port in 3000 3001 5173 4200 8080 8000 5000; do\n  s=$(curl -s -o \u002Fdev\u002Fnull -w \"%{http_code}\" \"http:\u002F\u002Flocalhost:$port\" 2>\u002Fdev\u002Fnull)\n  if [ \"$s\" != \"000\" ]; then echo \"Dev server on port $port (HTTP $s)\"; fi\ndone\n```\n\nIf nothing found: tell the user to start their dev server.\n\n**Verify it actually renders:**\nAfter `browse open` + `browse snapshot`, check that the accessibility tree contains real page content (navigation, headings, interactive elements) — not just an error overlay or empty body. Next.js dev servers can return HTTP 200 while showing a full-screen build error dialog. If the snapshot is empty or dominated by an error dialog, the server is broken — fix the build before testing.\n\n### Phase 4: Generate test plan\n\nFor each changed area, plan **both happy path AND adversarial tests**:\n\n```\nTest Plan (based on git diff)\n=============================\nChanged: src\u002Fcomponents\u002FSignupForm.tsx (added email validation)\n\n1. [happy] Valid email submits successfully\n   URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n   Steps: fill valid email → submit → verify success message appears\n\n2. [adversarial] Invalid email shows error\n   Steps: fill \"not-an-email\" → submit → verify error message appears\n\n3. [adversarial] Empty form submission\n   Steps: click submit without filling anything → verify error, no crash\n\n4. [adversarial] XSS in email field\n   Steps: fill \"\u003Cscript>alert(1)\u003C\u002Fscript>\" → submit → verify sanitized\u002Frejected\n\n5. [adversarial] Rapid double-submit\n   Steps: click submit twice quickly → verify no duplicate submission\n\n6. [adversarial] Keyboard-only flow\n   Steps: Tab to email → type → Tab to submit → Enter → verify success\n```\n\n### Phase 5: Execute tests\n\n```bash\nbrowse stop 2>\u002Fdev\u002Fnull\nmkdir -p .context\u002Fui-test-screenshots\n# localhost\u002Fdefault QA → clean, reproducible local run\nbrowse env local\n```\n\nFor each test, follow the **before\u002Fafter pattern**:\n\n```bash\n# Navigate\nbrowse open http:\u002F\u002Flocalhost:3000\u002Fpath\nbrowse wait load\n\n# BEFORE snapshot\nbrowse snapshot\n# Note the current state: elements, refs, text\n\n# ACT\nbrowse click @0-ref\n# or: browse fill \"selector\" \"value\"\n# or: browse type \"text\"\n# or: browse press Enter\n\n# AFTER snapshot\nbrowse snapshot\n# Compare against BEFORE: what changed?\n\n# ASSERT with marker\n# STEP_PASS|step-id|evidence  OR  STEP_FAIL|step-id|expected → actual\n```\n\n### Phase 6: Report results\n\n```\n## UI Test Results\n\n### STEP_PASS|valid-email-submit|status \"Thanks!\" appeared at @0-42 after submit\n- URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n- Before: form with email input @0-3, submit button @0-7\n- Action: filled \"user@test.com\", clicked @0-7\n- After: form replaced by status element with \"Thanks! We'll be in touch.\"\n\n### STEP_FAIL|double-submit|expected single submission → form submitted twice|.context\u002Fui-test-screenshots\u002Fdouble-submit.png\n- URL: http:\u002F\u002Flocalhost:3000\u002Fsignup\n- Before: form with submit button @0-7\n- Action: clicked @0-7 twice rapidly\n- After: two success toasts appeared, suggesting duplicate submission\n- Screenshot: .context\u002Fui-test-screenshots\u002Fdouble-submit.png\n- Suggestion: disable submit button after first click, or debounce the handler\n\n---\n**Summary: 4\u002F6 passed, 2 failed**\nFailed: double-submit, xss-sanitization\n\nScreenshots saved to `.context\u002Fui-test-screenshots\u002F` — open any failed step's screenshot to see the broken state.\n```\n\nAlways `browse stop` when done.\n\n### Phase 7: Generate HTML report\n\nAfter producing the text report, generate a standalone HTML report that a reviewer can open in a browser. The report embeds screenshots inline (base64) so it works as a single file — no external dependencies.\n\n**Why:** Text reports are good for the agent conversation, but reviewers (PMs, designers, other engineers) want a visual artifact they can open, scan, and share. Screenshots inline make failures immediately obvious.\n\n#### How to generate\n\n1. Read the HTML template at [references\u002Freport-template.html](references\u002Freport-template.html)\n2. Build the report by replacing the template placeholders with actual test data:\n\n| Placeholder | Value |\n|-------------|-------|\n| `{{TITLE}}` | Report title for `\u003Ctitle>` tag (e.g., \"UI Test: PR #1234 — OAuth Settings\") |\n| `{{TITLE_HTML}}` | Report title for the visible `\u003Ch1>`. If a PR URL is available, wrap the PR reference in an `\u003Ca>` tag so it's clickable (e.g., `UI Test: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F1234\">PR #1234\u003C\u002Fa> — OAuth Settings`). If no URL, use plain text same as `{{TITLE}}`. |\n| `{{META}}` | One-line context: date, app URL, user, branch |\n| `{{TOTAL_TESTS}}` | Total STEP_PASS + STEP_FAIL count |\n| `{{AGENT_COUNT}}` | Number of sub-agents that ran |\n| `{{PASS_COUNT}}` | Number of STEP_PASS |\n| `{{FAIL_COUNT}}` | Number of STEP_FAIL |\n| `{{PASS_RATE}}` | Integer percentage (e.g., \"92\") |\n| `{{RATE_CLASS}}` | `good` (≥90%), `warn` (70–89%), `bad` (\u003C70%) |\n| `{{FAILURES_SECTION}}` | HTML for failed test cards (see below) |\n| `{{PASSES_SECTION}}` | HTML for passed test cards (see below) |\n\n3. For each test result, generate a `\u003Cdetails>` card. Failed tests should be **open by default** so reviewers see them immediately:\n\n```html\n\u003C!-- Failed test card (open by default) -->\n\u003Cdiv class=\"section\">\n  \u003Ch2>Failures \u003Cspan class=\"count\">{{FAIL_COUNT}}\u003C\u002Fspan>\u003C\u002Fh2>\n  \u003Cdetails class=\"test-card fail\" open>\n    \u003Csummary>\n      \u003Cspan class=\"badge fail\">FAIL\u003C\u002Fspan>\n      \u003Cspan class=\"step-id\">step-id-here\u003C\u002Fspan>\n      \u003Cspan class=\"evidence\">expected → actual\u003C\u002Fspan>\n    \u003C\u002Fsummary>\n    \u003Cdiv class=\"body\">\n      \u003Cdl>\n        \u003Cdt>URL\u003C\u002Fdt>\u003Cdd>http:\u002F\u002Flocalhost:3000\u002Fpath\u003C\u002Fdd>\n        \u003Cdt>Action\u003C\u002Fdt>\u003Cdd>What was done\u003C\u002Fdd>\n        \u003Cdt>Expected\u003C\u002Fdt>\u003Cdd>What should have happened\u003C\u002Fdd>\n        \u003Cdt>Actual\u003C\u002Fdt>\u003Cdd>What happened instead\u003C\u002Fdd>\n      \u003C\u002Fdl>\n      \u003Cdiv class=\"suggestion\">Fix: description of suggested fix\u003C\u002Fdiv>\n      \u003Cdiv class=\"screenshot\">\n        \u003Cimg src=\"data:image\u002Fpng;base64,...\" alt=\"Screenshot of failure\">\n        \u003Cdiv class=\"caption\">step-id.png — captured at moment of failure\u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n    \u003C\u002Fdiv>\n  \u003C\u002Fdetails>\n\u003C\u002Fdiv>\n\n\u003C!-- Passed test card (collapsed by default) -->\n\u003Cdiv class=\"section\">\n  \u003Ch2>Passed \u003Cspan class=\"count\">{{PASS_COUNT}}\u003C\u002Fspan>\u003C\u002Fh2>\n  \u003Cdetails class=\"test-card pass\">\n    \u003Csummary>\n      \u003Cspan class=\"badge pass\">PASS\u003C\u002Fspan>\n      \u003Cspan class=\"step-id\">step-id-here\u003C\u002Fspan>\n      \u003Cspan class=\"evidence\">evidence summary\u003C\u002Fspan>\n    \u003C\u002Fsummary>\n    \u003Cdiv class=\"body\">\n      \u003Cdl>\n        \u003Cdt>URL\u003C\u002Fdt>\u003Cdd>http:\u002F\u002Flocalhost:3000\u002Fpath\u003C\u002Fdd>\n        \u003Cdt>Evidence\u003C\u002Fdt>\u003Cdd>What was observed\u003C\u002Fdd>\n      \u003C\u002Fdl>\n    \u003C\u002Fdiv>\n  \u003C\u002Fdetails>\n\u003C\u002Fdiv>\n```\n\n4. **Embed screenshots as base64** so the HTML is fully self-contained:\n\n```bash\n# Convert screenshot to base64 data URI\nbase64 -i .context\u002Fui-test-screenshots\u002Fstep-id.png | tr -d '\\n'\n# Use as: src=\"data:image\u002Fpng;base64,\u003Coutput>\"\n```\n\nRead each screenshot file referenced in STEP_FAIL markers, base64-encode it, and embed it as an `\u003Cimg src=\"data:image\u002Fpng;base64,...\">` in the corresponding test card. For STEP_PASS, only embed a screenshot if one was explicitly taken (e.g., baseline screenshots).\n\n5. Write the final HTML to `.context\u002Fui-test-report.html`:\n\n```bash\n# Write the generated HTML\ncat > .context\u002Fui-test-report.html \u003C\u003C 'REPORT_EOF'\n\u003C!DOCTYPE html>\n...generated report...\nREPORT_EOF\n\n# Open it for the reviewer\nopen .context\u002Fui-test-report.html  # macOS\n# xdg-open .context\u002Fui-test-report.html  # Linux\n```\n\n6. Tell the user: `Report saved to .context\u002Fui-test-report.html` and offer to open it.\n\n**Rules:**\n- Failures section comes before passes — reviewers care about what's broken first\n- Failed cards are `open` by default; passed cards are collapsed\n- Every STEP_FAIL card MUST have an embedded screenshot — if the screenshot file is missing, note it in the card\n- Include the suggestion\u002Ffix in each failure card if one was provided\n- The report must work offline — no CDN links, no external assets\n- Keep the HTML under 5MB — if screenshots push it over, reduce image quality or skip baseline screenshots for passes\n\n## Adversarial Test Patterns\n\nApply these to every interactive element you test. Read [references\u002Fadversarial-patterns.md](references\u002Fadversarial-patterns.md) for the full pattern library (forms, modals, navigation, error states, keyboard accessibility).\n\n## Deterministic Checks\n\nThese produce structured data, not judgment calls. Use them as the strongest form of assertion.\n\n| Check | What it catches | Assertion |\n|-------|----------------|-----------|\n| axe-core | WCAG violations | `violations.length === 0` |\n| Console errors | Runtime exceptions, failed requests | empty error array |\n| Broken images | Missing\u002Ffailed image loads | no images with `naturalWidth === 0` |\n| Form labels | Inputs without accessible labels | every input has `hasLabel: true` |\n\nFor the exact `browse eval` recipes, read [references\u002Fbrowser-recipes.md](references\u002Fbrowser-recipes.md).\n\n## Workflow B: Exploratory Testing\n\nNo diff, no plan — just open the app and try to break it. Use this when the user says \"test my app\", \"find bugs\", or \"QA this site.\"\n\n### Approach\n\n1. **Discover the app** — read `package.json` to detect the framework, then open the root URL and snapshot to see what's there\n2. **Navigate everything** — click through nav links, visit every reachable page, note what exists\n3. **Test what you find** — for each page, apply the adversarial patterns below (forms, modals, navigation, keyboard, error states)\n4. **Run deterministic checks** — axe-core, console errors, broken images, form labels on every page\n5. **Report findings** — use STEP_PASS\u002FSTEP_FAIL markers, include reproduction steps for failures\n\nDon't try to be systematic about coverage. Just explore like a user would, but with the intent to break things. The agent is good at this — let it roam.\n\n### Tips for exploratory runs\n\n- Start with the homepage, then follow the navigation naturally\n- Try the 404 page (`\u002Fdoes-not-exist`) — is it custom or default?\n- Look for empty states (pages with no data)\n- Test forms with garbage input before valid input\n- Check mobile viewport (375px) on every page — does it overflow?\n- If the app has auth, use cookie-sync first\n\n## Workflow C: Parallel Testing\n\nRun independent test groups concurrently using named `browse` sessions (`BROWSE_SESSION=\u003Cname>`). Each session gets its own browser. Works with both local and remote mode.\n\nUse when testing multiple pages or categories and you want faster wall clock time.\n\nRead [references\u002Fparallel-testing.md](references\u002Fparallel-testing.md) for the full workflow: session setup, agent fan-out, cookie-sync for auth, and result merging.\n\n## Design Consistency\n\nCheck whether changed UI matches the rest of the app visually. Read [references\u002Fdesign-consistency.md](references\u002Fdesign-consistency.md) when doing visual or design checks.\n\n## Test Categories\n\n| Category | How | Assertion type |\n|----------|-----|---------------|\n| Accessibility | axe-core + keyboard nav | Deterministic (violation count) |\n| Visual Quality | Screenshot + heuristic evaluation | Visual judgment (weakest — note specifics) |\n| Responsive | Viewport sweep + screenshots | Visual + deterministic (overflow check) |\n| Console Health | Console capture eval | Deterministic (error count) |\n| UX Heuristics | Snapshot + Laws of UX + Nielsen's | Structured judgment (cite specific heuristic) |\n| Error States | Navigate to empty\u002Ferror states | Before\u002Fafter comparison |\n| Data Display | Snapshot on tables\u002Fdashboards | Element match (column count, formatting) |\n| Design Consistency | Screenshot baseline + changed page comparison | Visual judgment (cite specific property) |\n| Exploratory | Free navigation + adversarial testing | Before\u002Fafter + judgment |\n\nReference guides (load on demand):\n- **Adversarial patterns** — [references\u002Fadversarial-patterns.md](references\u002Fadversarial-patterns.md) — load when testing forms, modals, navigation, or keyboard a11y\n- **Browser recipes** — [references\u002Fbrowser-recipes.md](references\u002Fbrowser-recipes.md) — load when running deterministic checks (axe-core, console, images, form labels)\n- **Exploratory testing** — [references\u002Fexploratory-testing.md](references\u002Fexploratory-testing.md) — load for Workflow B (no diff, open exploration)\n- **UX heuristics** — [references\u002Fux-heuristics.md](references\u002Fux-heuristics.md) — load when evaluating UX quality or citing specific heuristics\n- **Design system** — [references\u002Fdesign-system.example.md](references\u002Fdesign-system.example.md) — template for users to customize\n- **Design consistency** — [references\u002Fdesign-consistency.md](references\u002Fdesign-consistency.md) — load when doing visual consistency checks\n- **Parallel testing** — [references\u002Fparallel-testing.md](references\u002Fparallel-testing.md) — load for Workflow C (concurrent sessions)\n- **Report template** — [references\u002Freport-template.html](references\u002Freport-template.html) — HTML template for Phase 7 report generation\n\nFor worked examples with exact commands, read [EXAMPLES.md](EXAMPLES.md) if you need to see the assertion protocol in action.\n\n## Best Practices\n\n1. **Be adversarial** — try to break things, don't just confirm they work\n2. **Every assertion needs evidence** — snapshot ref, eval result, or before\u002Fafter diff\n3. **Before\u002Fafter for every interaction** — snapshot, act, snapshot, compare\n4. **Screenshot every failure** — `browse screenshot` immediately on STEP_FAIL, save to `.context\u002Fui-test-screenshots\u002F\u003Cstep-id>.png`\n5. **Deterministic checks first** — axe-core, console errors, form labels before visual judgment\n6. **For localhost, start with clean local mode** — use `browse env local` first for reproducible runs; use `--auto-connect` only when existing local state is required\n7. **Always `browse stop` when done** — for parallel runs, stop every named session\n8. **Report failures with reproduction steps** — action, expected, actual, screenshot path, suggestion\n9. **Parallelize independent tests** — use Workflow C with named sessions when testing multiple pages or categories on a deployed site\n\n## Troubleshooting\n\n- **\"No active page\"**: `browse stop`, retry. For zombies: `pkill -f \"browse.*daemon\"`\n- **Dev server not responding**: `curl http:\u002F\u002Flocalhost:\u003Cport>` — ask user to start it\n- **`browse eval` with `await` fails**: Use `.then()` instead — `browse eval` doesn't support top-level await\n- **Element ref not found**: `browse snapshot` again — refs change on page update\n- **Blank snapshot**: `browse wait load` or `browse wait selector \".expected\"` before snapshotting\n- **SPA deep links 404**: Navigate to `\u002F` first, then click through\n- **Remote auth fails**: Re-run cookie-sync with `--context \u003Cid>`, try `--stealth`\n- **Parallel session conflicts**: Ensure every `browse` command uses `BROWSE_SESSION=\u003Cname>` — without it, commands go to the default session\n- **Session not stopping**: `BROWSE_SESSION=\u003Cname> browse stop`. For zombies: `pkill -f \"browse.*\u003Cname>.*daemon\"`\n",{"name":5,"license":15,"metadata":58,"description":7,"allowed-tools":61,"compatibility":62},{"author":59,"version":60},"browserbase","0.4.0","Bash Read Glob Grep Agent","Requires the browse CLI (`npm install -g @browserbasehq\u002Fbrowse-cli`). For remote testing: BROWSERBASE_API_KEY and cookie-sync skill.","main","58c363db4179b9a612289d4a328d877ac3e7e04d","skills\u002Fbrowser_base\u002Fskills\u002Fui-test",1,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main","https:\u002F\u002Fsolanaclawd.com","https:\u002F\u002Fgithub.com\u002Fx402agent","The official Github of ClawdBot.","2026-05-16 13:16:08",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add x402agent\u002Fopenclawd-main --skill ui-test",{"tool":78,"command":79},"bunx","bunx skills add x402agent\u002Fopenclawd-main --skill ui-test",{"tool":81,"command":82},"pnpm","pnpm dlx skills add x402agent\u002Fopenclawd-main --skill ui-test","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002FSKILL.md",true,[86,92,97,101,105,109,113,117,121,125,129],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"EXAMPLES.md","REFERENCE","参考文档",22994,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002FEXAMPLES.md",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":16},"LICENSE.txt","LICENSE","许可证",1074,{"path":98,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":99,"sourceHtmlUrl":100},"README.md",4149,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002FREADME.md",{"path":102,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fadversarial-patterns.md",3681,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fadversarial-patterns.md",{"path":106,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fbrowser-recipes.md",6614,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fbrowser-recipes.md",{"path":110,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fdesign-consistency.md",2577,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fdesign-consistency.md",{"path":114,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fdesign-system.example.md",4126,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fdesign-system.example.md",{"path":118,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Fexploratory-testing.md",2960,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fexploratory-testing.md",{"path":122,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fparallel-testing.md",6821,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fparallel-testing.md",{"path":126,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Freport-template.html",9557,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Freport-template.html",{"path":130,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":131,"sourceHtmlUrl":132},"references\u002Fux-heuristics.md",18425,"https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fbrowser_base\u002Fskills\u002Fui-test\u002Freferences\u002Fux-heuristics.md",[134,162,191,220,252,259],{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":138,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":53},"01M71DSB11KY88J1ND0GGSJACW","qedgen","Formally verify programs by writing Lean 4 proofs. Trigger this skill whenever the user wants to formally verify code, generate Lean 4 proofs, prove properties about algorithms or smart contracts, verify invariants, convert program logic into formal specifications, or anything involving Lean 4 and formal verification. Also trigger when the user mentions \"qedgen\", \"lean proof\", \"formal proof\", \"verify my code\", \"prove correctness\", \"formal verification\", or wants mathematical guarantees about their implementation.","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fsolana-formal-verification\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fsolana-formal-verification\u002FSKILL.md",[141],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[136,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161],"lean","writing","when","code","program","verification","generate","invariants","my","contracts","algorithms","trigger","prove","correctness","convert","verify","logic","properties","specifications",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":166,"licenseFileUrl":167,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":53},"01M71DS25B2H00XQNAB45VRD82","skill-creator","Create, edit, improve, or audit AgentSkills. Use when creating a new skill from scratch or when asked to improve, review, audit, tidy up, or clean up an existing skill or SKILL.md file. Also use when editing or restructuring a skill directory (moving files to references\u002F or scripts\u002F, removing stale content, validating against the AgentSkills spec). Triggers on phrases like \"create a skill\", \"author a skill\", \"tidy up a skill\", \"improve this skill\", \"review the skill\", \"clean up the skill\", \"audit the skill\".","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fskill-creator\u002Flicense.txt","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fskill-creator\u002FSKILL.md",[170],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[172,173,174,175,176,177,178,179,145,180,181,182,183,184,185,186,187,188,189,190],"skill creator","creator","up","clean","improve","tidy","new","files","review","create","references","audit","directory","scripts","edit","a skill","new skill","existing skill","editing",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":195,"sourceHtmlUrl":196,"categories":197,"keywords":202,"publishedAt":53},"01M71DMZWVVYEN2RXNW32VTFBT","clawd-code-skill","Control Clawd via MCP protocol. Trigger with \"plan\" to write a precise execution plan then feed it to Clawd. Also supports direct commands, persistent sessions, agent teams, and advanced tool control.","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fclawd-code-skill-main\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002Fskills\u002Fclawd-code-skill-main\u002FSKILL.md",[198,199],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":200,"categoryName":201,"taxonomyType":30,"taxonomyTypeDesc":31},"01JBSEEDCAT000000000000030","开发工程师",[146,203,204,205,206,207,49,208,209,210,211,212,213,214,154,215,216,217,218,219],"clawd","code skill","clawd code skill","agent teams","advanced","MCP","plan","write","node","commands","direct","execution plan","tool","sessions","teams","execution","use",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":224,"sourceHtmlUrl":225,"categories":226,"keywords":235,"publishedAt":53},"01M71DM1RK8B85JEQNDY6D8G62","solana-clawd","solana-clawd — an open-source Solana AI agent framework built from Clawd Code's leaked agentic engine and the SolanaOS operator runtime. TypeScript MCP server for Clawd Desktop, Cursor, VS Code, or headless node. 31+ tools for Solana trading, on-chain intelligence, wallet management, Pump.fun scanning, MawdBot trading agents, Honcho v3 memory, Privy agentic wallets, and multi-venue perp execution (Hyperliquid + Aster). Use when asked about Solana trading, memecoin analysis, Pump.fun launches, MawdBot operations, OODA loops, wallet management, token research, agentic wallets, or any SolanaOS\u002Fsolana-clawd surface.","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fsolana-clawd\u002FSKILL.md",[227,230,233,234],{"categoryNo":228,"categoryName":229,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":231,"categoryName":232,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},{"categoryNo":200,"categoryName":201,"taxonomyType":30,"taxonomyTypeDesc":31},[203,236,237,238,239,240,241,242,243,244,245,208,246,247,248,145,249,250,251,146],"solana clawd","solana","solanaos","Wallet","headless","chain","memory","fun","privy","open","token research","agent framework","ai agent","agentic","mcp server","analysis",{"skillNo":253,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":254,"sourceHtmlUrl":255,"categories":256,"keywords":258,"publishedAt":53},"01M71DJZVSXC21XA2CM4FG6VYW","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fsolana-formal-verification\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fsolana-formal-verification\u002FSKILL.md",[257],{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},[136,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161],{"skillNo":260,"name":261,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":262,"sourceHtmlUrl":263,"categories":264,"keywords":265,"publishedAt":53},"01M71DJV1FZRP9ZMK9GQ5F9WBQ","solana-dev-skill-main","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fsolana-dev-skill-main\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fx402agent\u002Fopenclawd-main\u002Fblob\u002Fmain\u002Fskills\u002Fsolana-dev-skill-main\u002FSKILL.md",[],[266,267,63,237,268,269],"dev","solana dev skill main","solana dev","solana dev skill"]