browser-actionability-debug

A debugging workflow for browser tests in which an element looks visible but cannot actually be clicked, copied, hovered over, or focused. It applies to tools such as Playwright that control a real browser.

In plain words
What is it for?
Use it to inspect pointer interception, stacking order, visibility, opacity, pointer events, and application lifecycle conditions in browser checks.
Why use it?
It helps find hidden overlays, loading screens, transitions, or CSS settings that block interaction, instead of masking the problem with a forced click.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/jinning6/noosphere/browser-actionability-debug
Any agent
npx skills add JinNing6/Noosphere --skill browser-actionability-debug
Clone the repo
git clone --depth 1 https://github.com/JinNing6/Noosphere

Made for: Claude Code, Codex.

Per session 72 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 697 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What 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.

ModelPer sessionOnce 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

Measured 2d ago against content hash 80d7dad158de, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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.

shared_skills/active/browser-actionability-debug/SKILL.md · 64 lines

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

  1. 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.
  2. Separate visibility from actionability.

    • visible can still be blocked by an overlay, opacity: 0, parent pointer-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.
  3. 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: true unless the user specifically needs to bypass hit testing. It can hide real UX bugs.
  4. 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: none on 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.
  5. Verify clipboard behavior cross-platform.

    • On Windows, browser clipboard reads may normalize line endings to CRLF. Normalize \r\n to \n for semantic multi-line copy assertions.
    • Still assert exact command text after line-ending normalization.

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,
};

Read the full file on GitHub · 64 lines

Changes

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.

  1. 2d ago First seen · 64 lines · 72 tokens per session scan A 80d7dad158de

Subscribe to this mod's changes

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.

Related

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…

Bitterbot-AI/bitterbot-desktop · 63 tokens

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…

letta-ai/letta-code · 97 tokens

node-inspect-debugger

Debug Node.js via --inspect + Chrome DevTools Protocol.

HezaoHezao/poirot · 18 tokens

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.

TheSmokeDev/taskchad-os · 65 tokens

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.…

TimothyHan/qa-buddy-skills · 152 tokens

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"…

TimothyHan/qa-buddy-skills · 116 tokens