oxylabs/agent-skills: Oxylabs product skills for Claude Code and other AI agents

What oxylabs/agent-skills actually ships

This is not a scraping framework. It is a set of instruction files that an AI coding agent loads so it knows how to talk to Oxylabs services. The repository description calls them "Official agent skills of Oxylabs products", and the README lists five: Proxies, Web Unblocker, Web Scraper API, Headless Browser and Video Data. Each lives in its own directory under skills/, with a SKILL.md file as the entry point.

The audience is narrow and specific. You need an Oxylabs account with credentials for at least one product, and you need an agent that supports the skills format. The README gives two installation routes: the Claude Code plugin marketplace, and a generic npx command for other agents. If you are building a scraper from scratch and have never used a proxy provider, this repository does not help you choose one; it assumes the choice is already made.

The more interesting part is the product routing table, which maps a need to a product: raw proxy traffic with your own HTTP client goes to Proxies, protected pages without browser interaction go to Web Unblocker, parsed JSON from supported targets goes to Web Scraper API, clicks and screenshots go to Headless Browser, and YouTube metadata or downloads go to Video Data. That table is the closest thing here to a decision procedure, and it is the section worth reading first.

How the skills route a request between five Oxylabs products

There is no runtime, no daemon and no wrapper library. The mechanism is documentation plus environment variables. An agent reads the relevant SKILL.md, follows its instructions, and authenticates with credentials pulled from a .env file in the project. The README states that "All skills authenticate via environment variables defined in a .env file".

The variable names are namespaced per product, which tells you how the authors expect usage to be split. Residential and Mobile proxies use OXY_RES_USERNAME and OXY_RES_PASSWORD. Datacenter and ISP proxies use OXY_DC_USERNAME and OXY_DC_PASSWORD. Web Unblocker uses OXYLABS_USERNAME and OXYLABS_PASSWORD. Web Scraper API and Video Data share OXY_WSA_USERNAME and OXY_WSA_PASSWORD. Headless Browser uses OXY_HB_USERNAME and OXY_HB_PASSWORD, and Video Data also reads OXY_HB_ENDPOINT for a dedicated high-bandwidth proxy endpoint used in video downloads.

That shared-variable design is a real constraint. Web Scraper API and Video Data draw on the same credential pair, so an agent cannot be given access to one and denied the other through the .env file alone. The README's own advice is to start with the most specific product that fits the task, validate one small request, confirm auth and status and expected output, then scale with explicit limits. That sequencing matters more than usual here, because a misrouted request burns paid traffic rather than returning an obvious error.

Installing the plugin in Claude Code and running a first request

Claude Code has the shortest path, because the repository doubles as a plugin marketplace. Inside Claude Code, the README gives two commands: one to add the marketplace, one to install the plugin. The README says this installs all 5 skills as a single plugin.

/plugin marketplace add oxylabs/agent-skills
/plugin install oxylabs@oxylabs-agent-skills

Updating later uses the marketplace update command rather than a reinstall:

/plugin marketplace update oxylabs-agent-skills

For agents outside Claude Code, the README offers a single generic command that adds the skills from the Git URL:

npx skills add https://github.com/oxylabs/agent-skills.git

Before any request works, credentials have to be present. The repository ships a .env.example at the top level. Copy it and fill in only the products you actually use; leaving a product's variables empty is fine as long as you never route to that skill. The file also carries two compatibility fallbacks worth knowing about, OXY_UNBLOCKER_USERNAME and OXY_UNBLOCKER_PASSWORD for Headless Browser, and OXYLABS_HB_ENDPOINT for the video endpoint.

cp .env.example .env

A first real use follows the README's own advice: pick the most specific product for the job, then validate one small request before scaling. If you want parsed output from a supported target, that means Web Scraper API and the OXY_WSA_USERNAME and OXY_WSA_PASSWORD pair. If you want raw traffic through your own HTTP client, it means Proxies and the OXY_RES or OXY_DC pair. The README does not print a sample request, so the concrete call comes from the SKILL.md in the matching directory; read it before the agent does.

Where the credential model and routing advice break down

The README's configuration table and the repository's .env.example do not agree on every name, and that is the first thing to check before trusting an agent to run unattended. The README lists OXYLABS_USERNAME and OXYLABS_PASSWORD for Web Unblocker. The .env.example includes those, plus OXY_UNBLOCKER_USERNAME and OXY_UNBLOCKER_PASSWORD under a comment that says "Compatibility fallback", then repeats OXY_HB_USERNAME and OXY_HB_PASSWORD with the same label. Which pair a given skill actually reads is not settled by the README alone. An agent that picks the wrong one will fail authentication, and the failure will look like a bad credential rather than a naming mismatch.

The .env.example also contains variables the README table does not document at all: OXY_RESI_USERNAME, OXY_RESI_PASSWORD, OXY_MOBILE_USERNAME, OXY_MOBILE_PASSWORD, OXY_DC_IPS_API_LINK and OXY_DC_IPS_LIST. The README collapses residential and mobile into a single OXY_RES pair; the example file separates them. Anyone wiring credentials from the README alone may end up with a .env that the Proxies skill does not fully recognize.

There is a second limitation that is structural rather than documentary. Every skill here authenticates against a commercial Oxylabs product. There is no offline mode, no mock server and no free tier described in the README. An agent loaded with these skills and no valid subscription will produce authentication errors on every attempt, and the skills themselves cannot tell you whether a failure came from your credentials, your routing choice or the target site. That makes it a poor fit for evaluation, teaching or CI pipelines where credentials cannot be embedded.

oxylabs/agent-skills against a general-purpose skill library

The natural comparison is a broad community skill collection, the kind that gathers hundreds of unrelated skills for code review, testing, documentation and deployment. Those libraries optimize for breadth: you install one thing and get a wide surface of agent behaviours. This repository does the opposite. It is five skills, all from one vendor, all pointing at one paid platform, and it is maintained by that vendor. The README routes you to developers.oxylabs.io for further documentation.

The difference in approach shows up in what each is good at. A general library gives an agent opinions about how to write code. oxylabs/agent-skills gives an agent knowledge of specific endpoints, authentication variables and product boundaries, which is exactly the knowledge a general model lacks and tends to hallucinate. If your task is scraping YouTube metadata, no general skill library will tell you that Video Data reads OXY_WSA_USERNAME for extraction and OXY_HB_ENDPOINT for the high-bandwidth download path. That split is the kind of detail only a vendor-authored skill carries.

The trade-off is lock-in. Installing this plugin commits your agent's scraping vocabulary to Oxylabs product names and variable names. Swapping proxy providers later means replacing the skills, not editing a config value, because the routing logic lives inside the SKILL.md files rather than in your code.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-21, which is recent enough that the skill files should still match the current product surface. No releases are listed, so there is no versioned changelog to read before upgrading. Upgrades for Claude Code users go through the marketplace update command, which pulls the current state of the default branch. That means an update can change skill instructions without a version number to pin against, and the only record of what changed is the commit history.

The licence is MIT, which is permissive and places few obligations on reuse of the skill files themselves. That licence covers the repository contents, not the Oxylabs services the skills call. Those are governed by your Oxylabs account terms, and nothing in this repository grants access to them. Do not read the MIT licence as permission to use the APIs; it is not, and the README's own link to the developer documentation is where service terms live. This is a description of what the licence file covers, not legal advice.

The practical maintenance cost is small but not zero. Credentials rotate, and the .env file is the only place they live, so a rotation touches one file. The larger cost is verification after each update, since an unversioned skill change could alter which variables a skill reads.

Editorial conclusion

Adopt it if you already hold Oxylabs credentials and want an agent to route between proxies, Web Unblocker, Web Scraper API, Headless Browser and Video Data without you pasting endpoint details into every prompt. Do not adopt it if you have no Oxylabs account, since every skill authenticates against a paid service, or if you need a general-purpose skill library, because this repository contains only Oxylabs product instructions. Before relying on it, read skills/web-unblocker/SKILL.md and confirm which variables that skill actually reads, because the README table names OXYLABS_USERNAME while .env.example also lists OXY_UNBLOCKER_USERNAME as a compatibility fallback.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. oxylabs/agent-skills on GitHub
4. README