Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/jinning6/noosphere/browser-actionability-debugnpx skills add JinNing6/Noosphere --skill browser-actionability-debuggit clone --depth 1 https://github.com/JinNing6/NoosphereWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00072 | $0.00697 |
| Opus 5 | $0.00036 | $0.00349 |
| Sonnet 5 | $0.00014 | $0.00139 |
| Haiku 4.5 | $0.00007 | $0.00070 |
Grade A, and why
browser-actionability-debug scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser Actionability Debug
Workflow
-
Reproduce the failure with a real browser action, not only DOM existence.
- Prefer normal
locator.click()first so the browser reports what intercepts the pointer. - Read the full call log. If it names an intercepting element, treat that as evidence.
- Prefer normal
-
Separate visibility from actionability.
visiblecan still be blocked by an overlay,opacity: 0, parentpointer-events: none, a splash screen, or an element with higher stacking order.- Inspect
elementFromPoint()at the target center and compare it to the intended button/input. - Capture computed
opacity,visibility,display,pointerEvents, and bounding boxes for the target and its stable ancestors.
-
Check lifecycle gates before changing CSS.
- If a splash/loading/transition component exists, wait for the lifecycle signal that makes the app interactive, such as overlay detached or app shell
pointer-events: auto. - Do not fix a test by using
force: trueunless the user specifically needs to bypass hit testing. It can hide real UX bugs.
- If a splash/loading/transition component exists, wait for the lifecycle signal that makes the app interactive, such as overlay detached or app shell
-
Fix at the correct layer.
- If the overlay should still be active, update the test to wait for the overlay to detach.
- If a decorative canvas or visual layer should never capture input, set
pointer-events: noneon that visual layer. - If app content is intentionally disabled until boot, do not make underlying controls clickable before boot unless that is a product decision.
-
Verify clipboard behavior cross-platform.
- On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize
\r\nto\nfor semantic multi-line copy assertions. - Still assert exact command text after line-ending normalization.
- On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize
Diagnostic Snippet
Use this inside page.evaluate() when a click target exists but is not actionable:
const target = document.querySelector('[aria-label="Copy Noosphere share post"]');
const rect = target?.getBoundingClientRect();
const top = rect
? document.elementFromPoint(rect.left + rect.width / 2, rect.top + rect.height / 2)
: null;
return {
target: target ? getComputedStyle(target).cssText : null,
topTag: top?.tagName,
topClass: String(top?.className || ''),
topAria: top?.getAttribute?.('aria-label') || null,
targetRect: rect ? {
x: rect.x,
y: rect.y,
width: rect.width,
height: rect.height,
} : null,
};
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 64 lines · 72 tokens per session scan A 80d7dad158de
browser-actionability-debug is a skill published in the GitHub repository JinNing6/Noosphere (18 stars, last pushed 9d ago), licensed Apache-2.0. It adds 72 tokens to every session and 697 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
notte
Deploy browser automations as scheduled, API-callable serverless Functions — plus stealth sessions, vault-backed login, captcha solving, and natural-language agent runs via the Notte CLI. Turns any browser flow into a deterministic Bitterbot-callable endpoint, ideal for crystallized skills + dream-engine cron…
browser-use
Control a real browser to navigate pages, click, type, fill forms, inspect rendered UI, take screenshots, or record video. Load only when the user asks to open or automate a browser, interact with or test rendered page UI, scrape a site that needs browser execution, or capture a browser screenshot or video. Do not…
node-inspect-debugger
Debug Node.js via --inspect + Chrome DevTools Protocol.
agent-browser
Use Vercel agent-browser for browser automation through a persistent visible Chrome or Chromium CDP session. Trigger when the user asks to use agent-browser, Vercel agent browser, real Chrome, non-headless browser automation, CDP, Hotbox, LinkedIn profile browser work, or authenticated browser workflows.
e2e-setup
Set up Playwright e2e automation tailored to this team and app. Probes the running app (auth mechanism, API surface, spec availability), interviews with recommendations instead of open questions, scaffolds the playwright/ folder, and records every decision in playwright/AUTOMATION.md for the other e2e skills to read.…
verify-fix
Re-test a bug fix after a developer resolves it. Pulls the original bug from Jira, re-executes the repro steps in the browser, checks for regressions, and updates the bug status. The final step in the SDT workflow before a ticket moves to Done. Use when: "verify fix", "retest", "is this fixed?", "check BUG-123"…