Oxylabs Agent Skills: SKILL.md Files That Route an Agent to the Right Proxy Product

The Routing Problem These Skills Actually Solve

An agent asked to pull data from a website has a bad default: reach for one tool and apply it to every page. Oxylabs sells several distinct products, and they are not interchangeable. Residential and mobile proxies hand you raw geo-targeted traffic and expect your own HTTP client on the other end. Web Unblocker sits in front of protected pages and handles fingerprinting, JavaScript rendering and CAPTCHAs. Web Scraper API returns parsed JSON for a fixed list of supported targets. Headless Browser gives you remote CDP sessions for clicks, forms and screenshots. Video Data covers metadata, subtitles, search, channel data and high-bandwidth downloads. The repository's contribution is a routing table that maps a stated need to one of those five, plus a SKILL.md per product containing the instructions an agent reads before it acts. The intended audience is narrow: teams running Claude Code or another skill-aware agent who already hold Oxylabs credentials and want the agent to pick the correct endpoint on the first attempt rather than the third.

What Is Actually in the Repository

The README lists five skills, each in its own directory with a SKILL.md entry point: skills/proxies, skills/web-unblocker, skills/web-scraper-api, skills/headless-browser and skills/video-data. The description calls them structured instructions for AI agents, and that phrasing is literal. Nothing in the supplied material describes executable code, a client library, a CLI or a test suite. The repository is prose that an agent loads as context. That design choice has a consequence worth stating plainly: the skills cannot be unit tested, and their correctness depends on the agent interpreting English instructions the way Oxylabs intended. The topics list includes claude-skills and agent-skill, which confirms the intended host environment. The primary language field came back unknown, which is consistent with a repository whose payload is markdown. The licence is MIT, so the instruction files can be copied into your own skill directory or forked and edited without asking permission, though the MIT grant covers the repository contents and says nothing about the Oxylabs services the skills call.

Product Routing Is the Part Worth Reading

The routing table is the densest piece of engineering judgement in the README, and it is the section to read first even if you never install the plugin. It pairs a need with a product: bring your own HTTP client, proxy auth, IP rotation, sticky sessions or raw geo-targeted traffic goes to Proxies. Fetching protected pages without browser interaction goes to Web Unblocker. Structured data from supported targets, search results, e-commerce pages or parsed JSON goes to Web Scraper API. Clicks, forms, screenshots, browser state or Playwright and Puppeteer automation goes to Headless Browser. YouTube metadata, subtitles, search, channel data or video and audio downloads goes to Video Data. The README adds an ordering rule: start with the most specific product that fits the task, validate one small request first, confirm auth, status and expected output, then scale with explicit limits. That last clause matters more than it looks. An agent that discovers a working credential and no stated ceiling will happily fan out requests, and the README's instruction to set explicit limits is the only guardrail the material offers against that.

Credentials Are Split Five Ways, and That Is Deliberate

Configuration runs entirely through environment variables in a .env file, and the split is finer than most integrations bother with. Residential and mobile proxies read OXY_RES_USERNAME and OXY_RES_PASSWORD. Datacenter and ISP proxies read OXY_DC_USERNAME and OXY_DC_PASSWORD. Web Unblocker reads OXYLABS_USERNAME and OXYLABS_PASSWORD. Web Scraper API and Video Data share OXY_WSA_USERNAME and OXY_WSA_PASSWORD. Headless Browser reads OXY_HB_USERNAME and OXY_HB_PASSWORD. Video Data additionally reads OXY_HB_ENDPOINT, described as a dedicated high-bandwidth proxy endpoint for video downloads, which is the one variable in the table that is an endpoint rather than a credential pair. The practical effect is that a single .env can serve all five skills without a shared account name, and revoking one product's access does not disturb the others. The cost is bookkeeping. Five pairs plus one endpoint is six things to populate correctly, and a typo in OXY_WSA_PASSWORD will surface as an authentication failure inside whichever skill needed it, not as a configuration error at load time.

Installing It in Claude Code Versus Anywhere Else

There are two documented installation paths and they differ in scope. Inside Claude Code, the plugin marketplace commands are /plugin marketplace add oxylabs/agent-skills followed by /plugin install oxylabs@oxylabs-agent-skills. The README states this installs all five skills as a single plugin, so you cannot take Web Scraper API alone through that route. Updating later is /plugin marketplace update oxylabs-agent-skills. For other agents the generic path is npx skills add https://github.com/oxylabs/agent-skills.git, which pulls from the git URL directly and is the option to consider if your agent is not Claude Code. Neither command appears with a version pin, and the repository has no releases retrieved, so there is no tagged version to lock to. If reproducibility matters to you, clone the repository and vendor the SKILL.md files at a commit you chose, rather than tracking main through the marketplace. That is a real trade-off: you give up the update command and take on the job of re-reading the skill files when Oxylabs changes them.

Where This Is the Wrong Tool

The repository is instructions for services you must already be paying for. There is no free tier described, no local emulation, and no fallback path if a credential is missing. If your task is scraping a handful of pages from a site that does not defend itself, adding five skills and six environment variables is more configuration than writing a direct HTTP request. If you use a different proxy vendor, the skills are close to useless to you, because every instruction resolves to an Oxylabs endpoint and an Oxylabs account name. The Web Scraper API skill is also bounded by its target list: the README says structured JSON parsing for 40+ targets, which means the product handles a defined set rather than arbitrary pages, and a site outside that set is a job for Web Unblocker or Headless Browser instead. Finally, an instructions-only repository carries no verification surface. You cannot run a test to confirm the agent followed the routing rule correctly. You can only watch what it does and correct it, which is the same loop you would run without the skills, just starting from better-written instructions.

The Alternative: Writing Your Own SKILL.md

The closest alternative is not a competing product but a competing approach: write your own skill file describing your proxy and scraping setup. The difference is specificity. A self-written skill can encode your internal conventions, your rate limits, the exact targets you scrape, and the credential names your secret manager already uses. The Oxylabs skills encode Oxylabs' product boundaries and a routing table that assumes you want to choose among five Oxylabs services. If you already use Oxylabs, the vendor-authored version has one advantage you cannot easily replicate: it reflects the vendor's own view of which product fits which task, which is exactly the knowledge that is hard to acquire from outside. If you use two vendors, or you want one skill that covers both, the vendor file is a poor fit and you are better off writing a thin wrapper that calls whichever service your routing logic selects. The MIT licence makes that practical: fork the repository, keep the routing table, and rewrite the product sections around your own endpoints.

Maintenance Cost and What to Check Before Adopting

Maintenance here is documentation maintenance, not dependency maintenance. There is no package to upgrade and no transitive dependency to audit. The cost is that the skills describe a moving product surface: proxy network types, the Web Scraper API target count, and the endpoint variables are all things Oxylabs can change, and a stale SKILL.md will instruct your agent to use a product name or parameter that no longer matches the service. The update command handles the Claude Code path; the git path means you re-pull manually. The MIT licence lets you modify and redistribute the files, and it comes with no warranty, which for an instructions-only repository is the honest description of what you get. The licence does not extend to the Oxylabs services themselves, and nothing in the supplied material describes how the services are licensed or billed, so treat that as a separate commercial question to settle with Oxylabs rather than something the repository answers. The one concrete pre-adoption check the README itself suggests is to validate a single small request and confirm auth, status and expected output before scaling. Do that once per skill you intend to use, with the matching credential pair, and you will know within a few minutes whether the routing table's assumptions hold for your workload.

Editorial conclusion

Adopt this if you already pay for Oxylabs products and want an agent to stop guessing which endpoint handles a protected page versus a structured scrape. Skip it if you have no Oxylabs account, since every skill resolves to a credentialed Oxylabs service and the repository contains no fallback implementation. Before wiring it into anything, read skills/web-scraper-api/SKILL.md and confirm whether your target appears among the 40+ supported ones, then check that your .env separates OXY_WSA_USERNAME from OXYLABS_USERNAME, because the routing table's advice to start with the most specific product only works if the agent can tell which credential belongs to which service.

Official sources

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