Migrate To Parallel

Migrate to Parallel

Replace the provider boundary end to end. Treat a successful HTTP response as the midpoint, not completion: migrate request construction, response consumers, dependencies, configuration, tests, and operational behavior.

Resolve <skill-root> to the directory containing this SKILL.md. Resolve every bundled reference and script from that directory, regardless of the current working directory. The scanner uses only the Python standard library. If Python 3.9 or newer is unavailable, perform equivalent repository searches with the harness's file-search tools and state that the bundled scan was not run.

Load the right references

1. Read references/exa.md when the repository contains Exa.
2. Read references/tavily.md when the repository contains Tavily.
3. Read references/perplexity.md when the repository contains Perplexity Search, Sonar, Agent API web tools, or a Perplexity search wrapper.
4. Read references/firecrawl.md when the repository contains Firecrawl Search, Scrape, Batch Scrape, Extract, Agent, Research Index, Crawl, Map, Parse, Browser, Interact, Monitor, or MCP usage.
5. Read references/parallel-search.md when any call may route to Search or needs query, filter, freshness, mode, or result-list migration.
6. Read references/parallel-products.md when any call may route to Extract, Chat, Task, or entity discovery, or needs streaming, structured output, or citations.
7. Read references/integration-patterns.md when queries are generated dynamically, the provider is exposed as a model tool, provider response types escape into multiple modules, or the application needs full content or synthesized answers.
8. Open current official documentation for any detected SDK, wrapper, parameter, or response field not covered by those references. Do not guess at provider behavior.

Preserve these invariants

• Preserve caller-visible behavior unless the user explicitly authorizes a change.
• Never silently drop a filter, content field, synthesized answer, image, safety control, or score-based decision.
• Never print API keys or secret values. Check only whether a key is present.
• Do not add a hidden LLM call merely to manufacture search_queries.
• Do not treat an arbitrary user prompt as a keyword query merely because it fits an API length limit.
• Keep web-research intent, hard filters, handler policy, and answer-synthesis instructions in their separate contracts.
• Treat omitted provider parameters as behavior too: inspect their defaults before omitting a Parallel setting.
• Do not recreate the entire legacy provider SDK behind a compatibility shim. Normalize only the contract the application actually uses.
• Do not remove credentials from external secret managers or provider dashboards unless the user explicitly asks. Remove obsolete code references and update checked-in templates.
• Treat mode mappings as starting points. Verify latency, quality, and output behavior with the application's real queries.
• Stop before destructive edits when a required behavior has no supported Parallel equivalent and no in-scope substitute. Report the exact gap and the smallest decision needed.
• Stop when the Perplexity boundary requires embeddings; they are not a Parallel Search replacement. Route finance_search through Parallel's general index using Search, Chat, or Task according to the consumed contract, and stop only when a hard market-data coverage, freshness, or raw-result requirement remains unpreserved. Keep Agent API model routing, sandbox, MCP, and existing custom-function capabilities separate unless the user explicitly expands the migration scope.
• Stop when the Firecrawl boundary requires complete crawling or URL mapping, local/private file parsing, browser actions or sessions, screenshots or other rich scrape formats, change tracking, or Firecrawl-specific privacy/security controls without an approved replacement. Search and Extract do not reproduce those contracts.
• Follow repository-local instructions such as AGENTS.md, CLAUDE.md, and CONTRIBUTING.md. Preserve unrelated work and never reset or discard user changes.
• Complete safe repository-local migration work without stopping after an inventory or plan. Do not commit, push, change hosted secrets, or alter provider accounts unless the user asks.

1. Inventory the real migration surface

Record the current branch and working-tree state before editing. Run the bundled scanner from the target repository:

python3 <skill-root>/scripts/scan_provider_usage.py .

Use --format json for machine-readable output. The scanner intentionally skips dependency/generated directories, binaries, unreadable files, and oversized files; it cannot identify provider-neutral consumers from field names alone. Treat it as an inventory aid, not proof of completeness. Inspect the results and then trace each provider response to its consumers. Also inspect:

• package manifests and lockfiles;
• direct REST endpoints and auth headers;
• SDK clients, async clients, wrappers, and model-tool definitions;
• environment schemas, examples, deployment config, and docs;
• request builders, retries, timeouts, caches, observability, and error handling;
• response fields used for rendering, ranking, thresholds, citations, or model context;
• Firecrawl crawl, batch, extract, browser, interaction, webhook, and job-lifecycle consumers;
• tests, mocks, fixtures, and snapshots.

Run the existing focused tests before editing when feasible. Record which behavior is currently covered, which failures are pre-existing, and which behavior must be verified manually.

Before editing, write a decision row for every provider call site:

Choose exactly one action before changing the call:

• migrate only when the proposed route preserves the consumed contract or the user has already approved the named difference;
• retain when the call is outside the migration boundary or is the smallest safe way to preserve an unsupported capability;
• block when the requested boundary cannot be completed without a user decision. Name the smallest decision, and continue any independent migrate rows.

Do not use a broader Parallel product merely to eliminate a provider import. A plausible result shape is not evidence that source scope, spend controls, model behavior, lifecycle, or privacy policy remains equivalent.

2. Choose the migration boundary

Consider both designs before editing:

• Direct replacement: Use when provider calls are few, nearby, and provider-specific response types do not escape. Replace each call and its consumers atomically.
• Application-owned web-data module: Use when calls are scattered, several Parallel products are needed, or provider fields escape into the application. Put request construction, response normalization, retries, and telemetry behind one small caller-facing interface. Make this a deep module that hides provider details; do not add a pass-through wrapper.

Prefer the design that localizes future search-provider changes and minimizes edits to unrelated callers. If the application publishes the old provider's raw response, either preserve only the documented application contract through a normalizer or update all consumers together.

3. Migrate requests intentionally

Build every Parallel Search API request around these facts: