Einsia/Browser-BC: Recording Browser Tasks and Distilling Them into Claude Skills

The problem Browser-BC addresses: browser work that never becomes reusable

Most browser automation starts from a written script. Someone watches a login flow, a signup form or a dashboard export, then translates it into selectors and clicks. The translation is where the time goes, and it breaks whenever the page changes. Browser-BC inverts the order. You perform the task in a normal Chrome window with a recorder extension running, and the tool derives the reusable artifact from what you actually did. The README describes the output as a bucket of capabilities per website, for example github.com/{login-with-credentials, signup-with-email, …}, with each capability distilling into one skill.

The intended user is a single person working locally, not a team platform. The README states this plainly: a single-user, local product, you bring your own LLM API key, pure Python at runtime. It is also explicit that this is not a benchmark, which matters because the repository is the productized companion to an arXiv paper (2606.32014) on distilling reusable browser skills from human interaction traces. The paper supplies the method; the repository supplies the local pipeline around it.

The scope is narrower than the phrase behaviour cloning suggests. The recorder in this repository is a product fork that points at localhost and accepts free-form tasks only. There is no dataset harness, no scoring loop, and no leaderboard. If you came looking for a research rig, the README points you at the paper instead.

How a recording becomes a skill: the atomize, classify, bucket, distill pipeline

The data path is short and visible in the README diagram. The extension records a free-form task and posts it to a localhost server on port 8099 through /v1/traces/init, then chunks, then finalize. The server assembles the pieces into data/traces/<id>/trace.json, which holds the intent plus the event stream.

From there a background harness pipeline runs four stages. Atomize splits the trace into segments. Classify assigns each segment to a capability. Bucket pools segments of the same capability, keyed by domain and capability. Distill turns one bucket into two files, SKILL.md and TRACE_GUIDE.md, and install places them. The install target depends on the client: for Claude Code the skill lands at ~/.claude/skills/<domain>-<capability>/SKILL.md automatically, while for Claude Desktop the pipeline produces a .zip that you upload yourself through Settings, Skills.

State is inspectable rather than hidden in a database. Everything lives under data/harness/: buckets.json, registry.json, and per-skill folders at skills/<domain>/<capability>/ containing SKILL.md, TRACE_GUIDE.md, meta.json and evidence.jsonl. The evidence file is the interesting one. It keeps the trace segments that justified the skill, so you can check what the distiller saw instead of trusting the summary.

The control API exposes /api/buckets, which returns the per-site capability buckets and the skills derived from them. The harness CLI in harness/main.py offers ingest, distill, status, consolidate and query. The README does not document what consolidate or query do in detail, and it does not describe a rollback path for a skill that distills badly. That is a real gap: if a distillation produces a wrong SKILL.md for a domain, the documented recovery is to look at the files under data/harness/ and deal with them yourself.

Installing Journey Forge Local and recording your first task

The runtime is Python, and the README says no Node is needed for the server. Install the dependencies listed in requirements.txt, which are fastapi, uvicorn and tomli, then copy the example environment file and set your key. The variable name is SF_LLM_KEY, and the README shows an Anthropic-style value.

pip install -r requirements.txt
cp config.example.env .env.local      # then set SF_LLM_KEY=sk-ant-...
./scripts/start.sh                     # or: python entry/main.py  (native window)

After the server starts, the control panel is served at http://127.0.0.1:8099/. The README notes that the server seeds a default key, jfl-local-dev-key, which the extension ships with, so the extension connects without extra configuration. The panel is a zero-build page at app/dist/index.html served by the server itself.

The recorder is a Chrome extension built from the extension directory. The README uses pnpm, and the unpacked build target is extension/dist/chrome-mv3.

cd extension && pnpm install && pnpm build

Load it through chrome://extensions with Developer mode enabled, then Load unpacked and select extension/dist/chrome-mv3. It is pre-pointed at the local server.

Now record something small. The README's instruction is to record a short task with the extension, stop, label, upload. With auto-distill enabled, it says a skill appears within roughly one to three minutes. For Claude Code, the skill is already installed under your skills root. For Claude Desktop, download the .zip from the panel's Trajectories view and upload it under Settings, Skills, following docs/claude-desktop-setup.md. If you want Claude Desktop to actually click and type rather than just read instructions, the panel has a Browser execution section with a Configure Playwright MCP action; restart Claude Desktop afterwards.

Skills are instructions, not an execution engine

The most important limitation is stated in the README's own notes: skills don't grant tools. A SKILL.md is injected instructions. To execute its steps in a browser you must configure a browser MCP, and the README names Playwright for that role. Nothing in the recording pipeline clicks anything on your behalf. If you install a distilled skill and expect the agent to drive Chrome, you will be disappointed until the MCP is configured and Claude Desktop is restarted.

The second constraint is the LLM. Distillation calls an external model. The README says the distiller speaks the Anthropic Messages API natively with a default of claude-opus-4-8, and that you can point SF_LLM_BASE at an OpenAI-compatible gateway instead. It also states the privacy boundary directly: data lives under data/ (git-ignored), and nothing leaves your machine except the distillation calls to your configured LLM. That is a meaningful carve-out. Your traces stay local, but the content the distiller sends does not.

The third issue is classification. Bucketing depends on the classify stage deciding which capability a segment belongs to. The README gives no accuracy figure and no fallback behaviour when a segment is misclassified. A segment that lands in the wrong bucket pollutes a skill you may later rely on, and the only documented way to notice is to read evidence.jsonl in the skill folder. Treat the first few recordings as calibration, not production.

Finally, this is the wrong tool if you need unattended, headless operation on a schedule. There is no documented scheduler, no server deployment story, and the whole design assumes one person at one machine with a browser open.

Browser-BC compared with writing Playwright scripts directly

The obvious alternative is Playwright itself, or any of the agent frameworks built on it. The difference is where the knowledge lives. A Playwright script encodes the steps a developer wrote, and it fails loudly when a selector moves. Browser-BC encodes the steps you performed, then asks a model to compress them into prose instructions plus a trace guide. The artifact is a document a Claude client reads, not a program a runtime executes.

That changes the failure mode. A broken Playwright selector throws. A stale SKILL.md does not throw; it produces an agent that confidently does the wrong thing, because the instructions are advisory text. The evidence.jsonl file next to each skill is the only built-in way to audit that, and it is a manual step.

The trade-off is worth naming. Playwright gives you deterministic replay and a test runner. Browser-BC gives you coverage of tasks you never got around to scripting, at the cost of determinism and at the cost of an LLM call per distillation. If your task is high-frequency and stable, script it. If your task is occasional, site-specific and annoying to automate, recording it once and distilling a skill is the cheaper path.

Maintenance, versioning and what the repository does not state

The repository is not archived, and the last push was on 2026-07-13. The most recent release listed is v0.1.9 (Journey Forge Local v0.1.9) from 2026-06-28, preceded by v0.1.8 and v0.1.7 the previous day. The version line is still in 0.1.x, and the release cadence visible here is a burst in late June rather than a steady stream.

Upgrade cost is mostly the Python dependency set in requirements.txt, which is three packages with lower bounds, plus the extension build if you rebuild the recorder. There is an optional native window path: pywebview is commented out in requirements.txt, and the README says to enable it with JFL_USE_PYWEBVIEW=1 after installing it, noting that on macOS it pulls the pyobjc Cocoa/WebKit backend and can be slow or fragile to install. The default is the system browser, which avoids that entirely.

The licence is the open question. The repository metadata carries no licence identifier, and the README does not name one. The README does ask that you cite the arXiv paper if you use the project or its ideas. Without a licence file, the terms under which you may redistribute or embed this code are not stated in the repository, and that is something to resolve with the authors before shipping it inside anything. The paper's citation request is a norm, not a licence grant.

Editorial conclusion

Adopt Browser-BC if you already use Claude Code or Claude Desktop, you are willing to supply an Anthropic-compatible API key, and you want a local library of per-site skills built from your own browser sessions. Skip it if you need unattended, headless execution, if you cannot install a browser MCP, or if you need a documented retention or rollback policy, because the README does not describe one. Before committing, run the quick start end to end on one short recording and confirm that a skill appears under data/harness/skills/<domain>/<capability>/ and that the Claude Desktop zip uploads through Settings, Skills.

Frequently asked questions

Official sources

1. Einsia/Browser-BC on GitHub
2. Issues
3. README
4. Releases