Agent skill · software engineering · jeremylongshore
brightdata-sdk-patterns
Wrap the official Bright Data Python SDK and REST contracts behind a typed, testable client boundary. Use when adding SDK calls, isolating provider upgrades, or normalizing scraper and Browser API results. Trigger with: "wrap the Bright Data SDK", "design a Bright Data client", "pin Bright Data Python dependencies".
Why this skill is useful
Adds production-ready TypeScript and Python SDK patterns for Bright Data integrations, including retry logic and session management scripts.
What it needs
Requires axios, node-fetch installed locally. About 2k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Bright Data Typed Client Boundary Overview Use the official Python SDK where it matches the workload, but keep product choice, authorization, retry policy, and domain schemas outside vendor objects. Pin the dependency and expose a small application-owned interface. Prerequisites A Python project with a lockfile and supported runtime An approved Bright Data product and credential mode Synthetic contract fixtures for every exposed operation Instructions Step 1: Pin and inspect Read the lockfile and Grep for direct Bright Data imports. Pin the reviewed SDK release through the repository dependency workflow rather than embedding a version in this skill. Step 2: Define the port Write an application interface that returns normalized records and provider receipts, not raw SDK response objects. Step 3: Implement adapters Keep API-key, proxy-zone, and Browser API adapters separate. Map documented terminal states and current x-brd- errors into stable application failure classes. Step 4: Verify the seam Use Bash(python:) to run type checks and fixture tests. Compare the locked SDK behavior with the current official SDK docs before any upgrade. Tool Discipline Use Read and Grep to locate dependency and transport boundaries. Use Write and Edit for the typed port, provider adapters, and tests. Use Bash(python:) only for local type/test commands; live SDK calls require a separate authorized workflow. Output Pinned SDK dependency and application-owned port Separate credential/product adapters Normalized receipts and fixture-backed failure mapping Examples Expose triggercollection, getprogress, and downloadsnapshot through your own protocol. Keep a vendor response fixture at the boundary, map it once, and let downstream code depend only on CollectionReceipt. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/brightdata-sdk-patterns