I got tired of rewriting the same scraper every month — so we open-sourced the tool that writes it once
Hey IH,
Quick story from building BrowserAct — and the thing we just shipped because of it.
For the last year we've been helping teams put AI agents on top of real websites. YouTube research, KOL discovery, competitor monitoring, SaaS dashboards — the mundane repetitive work where an agent should just handle it.
And every single deployment hits the same wall.
Someone asks an agent to "find YouTube videos about X." First day: works great. Three weeks later: YouTube ships a UI update, a selector moves 12 pixels, the entire workflow silently returns empty results. Debug, rewrite, redeploy. Two weeks after that: login session expires mid-run. Rewrite. A month later: a bot-detection layer rolls out, every request 403s. Rewrite.
We kept writing the same script. Different site, same pattern. The "agent" wasn't the bottleneck — the brittle per-site glue was.
So we asked the obvious question: why does the agent regenerate this glue every run? Why doesn't it explore the site once, figure out the cleanest reliable path, and save that as a reusable capability it and anyone else's agent can call later?
That's what we open-sourced. It's called browser-act-skill-forge.
How it works in practice:
You describe a task in plain English:
"I want to find YouTube videos related to OpenClaw."
Skill Forge opens a real stealth browser, explores the site, and prefers API endpoints over DOM selectors. APIs are much more stable. Where no clean API exists, it falls back to DOM patterns. It verifies what actually works against the live site, and then emits a deploy-ready Skill package:
- SKILL.md execution guide
- executable Python scripts
- repeatable workflow logic
- structured output schema
- testing steps to verify the Skill still works later
After that first pass, your agent just calls the installed Skill directly. No re-exploration. Any other agent on the same team can call it too.
The boundary that matters for us:
Forge is intentionally constrained. It only does what the user could manually do in their own browser. Reads data already displayed on the page. Never bypasses auth. We treat it as copy-paste on the user's behalf. That boundary is what makes it shippable inside regulated or trust-sensitive workflows.
The pattern we keep recommending:
For one-off pulls, call browser-act directly. For anything high-volume — hundreds or thousands of records, paginated workflows, multi-keyword research — forge a Skill first, then run it at scale. Bulk scraping without the exploration step is exactly why every bulk scraper eventually breaks.
Install:
npx skills add browser-act/skills --skill browser-act-skill-forge
GitHub: https://github.com/browser-act/skills/tree/main/browser-act-skill-forge
Main repo: https://github.com/browser-act/skills
Curious what workflow you'd turn into a Skill first. Drop it in the comments — happy to pair on it.
— The BrowserAct team
