We made Claude 10x faster at browser tasks. It's just a text file.

This skill is most helpful for non-technical folks. If you see a dotted-underline term you don't recognize, hover over it for a quick explainer.

Ask Claude to pull 500 contacts from a CRM. By default, it does what a person would do: click into contact 1, read the name and email, go back, click contact 2, go back, click contact 3. For 10 items that's fine. For 500 you're waiting two hours.

The thing is, Claude already knows how to intercept APIs, scrape DOMs, batch HTTP requests, and mine client-side state. It knows how to do all of this. The problem is its default instinct. It approaches web apps like a careful human instead of a machine.

So we wrote a skill that changes that instinct. It's a single Markdown file. No dependencies, no build step, no library. It just tells Claude: before you click anything, spend up to 90 seconds figuring out the fastest programmatic path to the data, then use it.

That's the whole trick.

A quick note on Cowork

If you're using Claude in Cowork (the desktop app), browser and computer use already work surprisingly well. You can point it at a web app and say "go through all of these" and it will. The issue is how it does it: slow, sequential clicking at human speed.

This skill is especially powerful in Cowork because you don't need to know how to write a Playwright script or set up a headless browser. You just drop in the file and Claude automatically figures out the fastest programmatic path: MCP first, then hidden APIs, then bulk DOM operations. Same result you were getting before, just dramatically faster on bulk tasks.

What's actually in the file

The skill opens with a quick reference table that ranks every extraction technique by speed, from instant (dedicated MCP) down to minutes (DOM scraping, form filling). Then it gives Claude a decision framework: walk through these in order and stop at the first one that works.

Most of the speed wins actually come from the levels above APIs. Export buttons are the most underrated shortcut. The skill scans for them and common export URLs first. One click often beats everything else.

Window globals are nearly as fast. Next.js dumps its entire dataset into __NEXT_DATA__. Redux SSR apps use __PRELOADED_STATE__. If the data is already in memory, you don't need a network call at all. For apps that don't expose globals but store everything in component state, the skill includes a React fiber tree traversal as the nuclear option: walk the internal data structure and pull what you need directly.

Scroll detection: the silent task-killer

One thing the skill handles that you wouldn't think to worry about: scroll behavior. Before committing to a scroll-and-scrape approach, it detects whether the app uses virtual scrolling (items get replaced as you scroll, you can't go back), infinite append (items get added, scrape after fully loading), or pagination (page controls in the URL). Virtual scrolling is a trap. You scroll down, the top items vanish from the DOM, and your scrape only captures whatever's visible. The skill checks for this before wasting any effort, and routes to export or API instead.

When it doesn't help

This doesn't help on small tasks. Updating 8 rows in Notion? Just click through them. The skill knows this too: under 20 items, it skips recon and clicks directly.

It also won't magically crack apps with heavy server-side rendering and no accessible client-side API. In those cases it falls back to smarter DOM scraping and screenshots, which is better than pure clicking but not the 50x claim. There's a hard stop built in: if nothing works after 10 minutes, it asks you if you have export access or database credentials instead of banging its head against the wall.

When it's great

Bulk tasks on modern web apps. Anything that starts with "go through all of these..." or "pull every..." or "update each..." followed by a list of 50+ items.

We timed this one live. We pointed Claude at our Airtable recruiting pipeline and asked it to pull 100 candidate records.

850x speedup on a real task we actually ran and timed. Similar results on other apps (verified endpoints, estimated timings): Notion bulk status updates (~8 min clicking down to ~3 sec via /api/v3/saveTransactions), Stripe invoice downloads (~45 min clicking down to ~12 sec via /v1/invoices batch fetch).

It also writes back

Most browser automation stops at extraction. You pull 500 records out and then... do what? The skill also maps write endpoints during recon. Same network tab that reveals GET /api/candidates will show PATCH /api/candidates/:id when you click a button in the UI. For GraphQL apps, it introspects mutations alongside queries.

This means the full loop works: extract 500 candidates, filter in Python, then write the decisions back via the same API. Bulk status changes, tagging, pipeline advancement, decline/shortlist actions. All programmatic, all in parallel.

How the full workflow works

The skill treats the browser as extraction only. Once you have raw data, it gets it out as fast as possible (file download, clipboard, or redacted JSON) and moves processing to Python or Bash where you have pandas and real compute power. The pattern is always: extract in the browser, transfer out, transform in Python (filter, cross-reference, enrich), then load back into the app via API or MCP. JavaScript in the browser is constrained by output filtering and execution time limits. Python and Bash aren't.

For large datasets (1000+ items), the skill splits processing across multiple subagents running in parallel. One agent extracts 500 contact IDs, then four subagents each process 125 contacts at the same time: web research, profile lookups, cross-referencing against existing databases. Results merge at the end. This only helps when there's per-item work to do. If it's a single export click, subagents just add overhead.

It also handles native desktop apps with AppleScript, JXA, and SQLite on app databases (many macOS apps store data in ~/Library/Application Support/). And it caches what worked: which app, which method, what auth pattern. Next time you point Claude at the same app, it checks its notes and skips recon entirely.

The core technique: monkey-patching fetch()

The most useful trick in the skill is API discovery via monkey-patching. It works on virtually any web app, regardless of framework. You override window.fetch to log every request the app makes, click one item in the UI, then read what endpoint it hit:

const originalFetch = window.fetch;
window.__API_LOG__ = [];
window.fetch = async function(...args) {
  const url = typeof args[0] === 'string' ? args[0] : args[0]?.url;
  const response = await originalFetch.apply(this, args);
  window.__API_LOG__.push({ url, status: response.status });
  return response;
};
// Click one item in the UI, then read window.__API_LOG__
// You now know the exact endpoint. Reproduce it at scale.

One sequencing detail that matters more than it sounds: start your network monitor before the page loads, not after. The most valuable API calls happen on initial page load, when the app fetches the full dataset to render. Navigate first and monitor second, and you miss them entirely. The skill makes this an explicit numbered step so Claude doesn't skip it.

Once you have the endpoint, you reproduce the call with {credentials: 'include'} to carry the session cookie, crank the limit parameter up, and paginate through everything. Most apps don't aggressively rate-limit their own internal APIs because they're designed for their own frontend, which already fetches in large batches. Cranking limit from 20 to 500 often just works.

The PII filter problem (and six workarounds)

The skill includes six ranked workarounds for the Chrome MCP PII filter, because that filter is one of the most annoying problems people hit. The javascript_tool blocks any output containing email addresses or phone numbers. You write a perfectly good scraper, it returns the data, and Chrome MCP redacts it. Most people just give up. Here's what to do instead:

1. DOM overlay + screenshot. Inject an HTML table with the data directly onto the page, then take a screenshot. The PII filter only applies to text output from javascript_tool, not to what's visible on screen. This is the most reliable method for large datasets. Paginate 30-50 rows at a time.

2. Redacted JSON. Strip emails and phone numbers from the output, return everything else as JSON. Recover the PII separately via the overlay method. Works well when you need structured data and only a few fields are blocked.

3. Console output. Write to console.log instead of returning from the function. Read it back with read_console_messages. Bypasses some filters.

4. File download. Create a Blob with the data and trigger a download. The CSV lands in the user's downloads folder with all fields intact.

5. Clipboard write. Write the data to navigator.clipboard and read it back with read_clipboard.

6. Window variable chunking. Store the full dataset in window.__EXTRACTED__ and read it back in small, filter-safe chunks.

Most people never get past the first PII block. Having these six options ranked means Claude can fall through them quickly instead of getting stuck.

What this tells us about skills in general

The interesting thing about this skill isn't the browser stuff specifically. It's that a plain text file can change how an AI agent behaves on a whole class of tasks. The skill doesn't add capabilities Claude doesn't have. It just points existing ones in the right direction.

Think of it as the difference between a junior engineer who knows the syntax and a senior engineer who knows which approach to reach for first. Same knowledge, different instincts. The skill is the instinct.