無料GitHub で公開日本語紹介

brightdata-upgrade-migration

Bright DataのSDK、API、製品名、レスポンスヘッダーの変更を、テスト用記録で確かめながら段階的に移行し、切り戻し手順まで整理します。

原文原文の説明を見る

Migrate Bright Data SDK, API, product, or response-header contracts with fixture evidence and a reversible canary. Use when upgrading the Python SDK, moving dataset endpoints, renaming Scraping Browser to Browser API, or removing legacy headers. Trigger with: "upgrade Bright Data", "migrate x-luminati headers", "change a Bright Data API contract".

jeremylongshore/tons-of-skills-marketplaceスター 2,884(GitHub 2,884 + cccskills 0)

実行スコア未検証

インストール方法を見る

こんなときに便利

Python SDKを更新したいとき
データセットのAPIを移行したいとき
古いレスポンスヘッダーを置き換えたいとき
Browser APIへの移行を計画したいとき

日本語での紹介

できること

Bright DataのSDK、APIエンドポイント、製品名、レスポンスヘッダーなど、連携先との取り決めを変更するときに、現状と移行先の差分を整理します。依存関係や設定、アダプター、運用手順を確認し、変更対象を一つずつ切り分けて更新します。成功、認証、ポリシー拒否、制限、処理状態、データ形式、配信に関するテスト用記録を使い、旧方式と新方式の出力を比較します。段階的な試行と切り戻し条件を整え、旧方式を廃止する判断材料もまとめます。

こんなときに便利

Python SDKを更新するとき、データセットの接続先を変更するとき、旧製品名や古いヘッダーへの依存を解消するときに向いています。複数の変更を一度に進めず、原因を追いやすい単位で移行したい開発・運用担当者にも役立ちます。

使い方の例

「旧ヘッダーから現行の x-brd-* への移行計画を作って」
「データセットのAPI変更を、テスト用記録で比較して」
「Browser APIへの移行を切り戻し手順込みで整理して」

注意点

移行先の仕様と固定済みの依存関係、合成データによるテスト用記録が必要です。実環境での試行には承認済みのアカウントと許可された目的が前提です。ローカルテストの実行は、実環境への移行通信や認証情報の変更を許可するものではありません。

この紹介文は、公開されている SKILL.md をもとに AI（OpenAI Codex）が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル（2）

SKILL.md3.6 KB
references/official-docs.md740 B

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Bright Data Contract Migration

Overview

Inventory the exact current behavior before changing dependencies or products. Treat an SDK update, API endpoint change, Browser API rename, and product migration as separate changes with separate rollback boundaries.

Prerequisites

A pinned current dependency or configuration and documented target contract
Golden synthetic fixtures plus representative redacted receipts
A dual-read or feature-flag path and rollback owner

Instructions

Step 1: Build the delta

Read the lockfile, adapter, and runbooks; Grep for x-luminati, old product names, obsolete endpoints, raw vendor response coupling, and undocumented ports.

Step 2: Update one boundary

Write the target dependency, API, or header mapping. Current diagnostics use Proxy-Status and x-brd-*; Browser API replaces the former Scraping Browser name. Do not invent version transitions.

Step 3: Verify compatibility

Edit fixture tests for success, authentication, policy, throttle, lifecycle, schema, and delivery states. Use Bash(python:*) for the pinned type and test suite and compare normalized outputs.

Step 4: Canary and retire

Run an authorized feature-flag canary, compare data and operational receipts, then remove the old path only after rollback expiry and owner signoff.

Tool Discipline

Use Read and Grep for the migration inventory. Use Write and Edit for dependency, adapter, fixture, and runbook changes. Use Bash(python:*) for local tests; it does not authorize live migration traffic or credential changes.

Output

Current-to-target contract matrix
Passing old and new fixture comparison and canary receipt
Rollback path plus explicit old-contract retirement decision

Examples

First replace parsing of x-luminati-error with current x-brd-error and Proxy-Status fixtures. Keep a short dual-read window for retained historical receipts, but require current fields from new live responses.

Error Handling

Failure	Meaning	Response
Migration combines product and SDK changes	Failure attribution is impossible	Split the rollout into independently reversible steps
Golden fixture contains live data	Test evidence is unsafe	Replace it with a synthetic contract fixture
New path changes normalized output	Downstream behavior would drift	Hold promotion and reconcile the schema

Resources

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

同じリポジトリのスキル