A Skill That Makes the PhantomBuster MCP Launch Instructions More Efficient

Why this skill exists

Launching a Phantom is an outward-facing action. It acts on your connected account (your real LinkedIn session, for example), consumes execution credits, and, if mis-scheduled, can repeat unwanted runs or trip platform rate limits.

The most common failure mode isn't a broken Phantom. It's launching with assumed settings: guessing results-per-launch, defaulting the frequency to one-off, or skipping output options that actually mattered. The Phantom Launch Pre-flight skill exists to stop that. Before any launch, the AI runs a short structured interview, and the questions are built from the Phantom's actual configurable fields: pulled from its manifest, not from memory or assumption.

The golden rule: never invent a launch value. If the AI doesn't know whether you want daily or one-off, 50 results or 1000, dedup on or off, it asks. The manifest says which fields exist; you say what they should be.

How the skill is structured

Step 1 — Identify the Phantom and load its manifest

You can't ask the right questions until you know which Phantom is being launched and what it actually accepts. The skill finds the target agent and reads its real schema (agents_fetch_all, agents_fetch with withManifest: true, or scripts_fetch). The ,argumentSchema.properties, and argumentForm.steps are the source of truth for which behavior and output fields exist, and which are required.

Field names differ per Phantom (the LinkedIn Search Export uses numberOfResultsPerLaunch, while the LinkedIn Profile Scraper uses numberOfAddsPerLaunch), so the skill maps your intent to the real field via the manifest's labels instead of assuming. It also confirms a connected identity (session cookie) is attached, because a Phantom with no identity cannot run.

Step 2 — Run the structured pre-launch interview

One structured batch of questions, covering three areas. Manifest defaults are shown as reference, but an explicit answer is required; silence is never treated as acceptance.

• Launch frequency / schedule — one-off, once at a specific time, or repeating, mapped to the agent's launchType and schedule fields, with timezone confirmed. "Launch it now" is not assumed to mean one-off.
• Behavior & output settings — only the fields this Phantom actually exposes: volume, deduplication, enrichment toggles, email discovery, CRM push, watcher mode, output file name and filters, notifications. The input itself (search URL, lead list, keywords) is also confirmed, because a launch with the wrong input wastes the whole run.
• Rate-limit safety — for account-driven Phantoms, safe daily ceilings are surfaced before you pick volume × frequency (e.g. ~1000 results/day for LinkedIn Search Export on a standard account, ~1500 profiles/day for the Profile Scraper, up to ~2500/day on Sales Navigator), and any combination that would exceed them gets flagged.

Step 3 — Confirm, then launch

The full resolved configuration (input, schedule, and every behavior/output setting) is echoed back in a compact summary for an explicit go-ahead. Only then does the skill persist the settings (agents_save), launch if a run-now was requested (agents_launch), and report back the container ID, the applied settings (old → new), and the next scheduled run.

What "never guess" means in practice

• Don't pick a results-per-launch number because it "seems safe": ask.
• Don't default launchType to manual: ask whether it should be scheduled.
• Don't assume dedup, enrichment, email-discovery, or CRM preferences: ask.
• Don't trust a constructed search URL or geo mapping without the user confirming it.
• "Use the Phantom's defaults" is a valid answer, but the defaults are stated explicitly so the choice is informed.

Get the skill

The full skill script is shared as a markdown file (,SKILL.md,) alongside this post. Drop it into your Claude skills folder to use it. The complete script is also included below for reference.

Full skill script (copy from here)

# Phantom Launch Pre-flight

Launching a Phantom is an outward-facing action: it acts on the user's connected account (e.g. their real LinkedIn session), consumes execution credits, and, if mis-scheduled, can repeat unwanted runs or trip platform rate limits. The most common failure mode is launching with assumed settings: guessing results-per-launch, defaulting frequency to one-off, or skipping output options the user actually cared about. This skill exists to stop that. Every launch goes through a short interview first, and the questions are built from the Phantom's actual configurable fields, not from memory or assumption. The golden rule: never invent a launch value. If you don't know whether the user wants daily or one-off, 50 results or 1000, dedup on or off: ask. The manifest tells you which fields exist; the user tells you what they should be.

## Step 1 - Identify the Phantom and load its manifest

You cannot ask the right questions until you know which Phantom this is and what it actually accepts. Find the target agent and read its real schema:

- Find the agent: ,agents_fetch_all, (use ,withArgument: true, to see any already-saved settings), or ,agents_fetch, by id.
- Load the field definitions: ,agents_fetch, with ,withManifest: true,, or ,scripts_fetch, on the Phantom's script id. The ,argumentSchema.properties, and ,argumentForm.steps, are your source of truth for which behavior/output fields exist and which are required (,ui-required,). The ,manifest.defaultArgument, shows the platform's defaults: useful to show the user, never to silently apply. Field names differ per Phantom: confirm them, don't assume. For example, the LinkedIn Search Export uses ,numberOfResultsPerLaunch, + ,enrichLeadsWithAdditionalInformation,, while the LinkedIn Profile Scraper uses ,numberOfAddsPerLaunch, ("Profiles to update per launch") + ,enrichWithCompanyData,. Map the user's intent to the real field via the manifest's labels. If no agent for this Phantom exists yet, set it up first (see the project's PhantomBuster setup flow), then return here before launching. If the Phantom requires a connected identity (LinkedIn session cookie, etc.), confirm one is attached: check the agent's saved ,argument, for an ,identities, or ,sessionCookie, value. A Phantom with no identity cannot run.

## Step 2 - Run the structured pre-launch interview

Ask the user about both areas below before launching, in a single structured batch (use the question UI if available). Present the manifest defaults as reference so the user can make an informed choice, but require an explicit answer: do not treat silence or "looks good" as acceptance of a value you picked. If the user already stated some values in their request, treat those as answered (don't re-ask them); only ask about what's genuinely still open.

### A. Launch frequency / schedule (always resolve)

Map the answer to the agent's ,launchType,:

- One-off / manual → ,launchType: "manually",, launch once now.
- Once at a specific time → ,launchType: "once", + ,launchOnceAt,.
- Repeating → ,launchType: "repeatedly", + a ,repeatedLaunchPreset, (e.g. "Once per day", "Twice per day", "Once per working hour, excluding weekends") or explicit ,repeatedLaunchTimes,. Confirm the timezone (the org has one, e.g. Europe/Paris, but confirm it's the intended one for scheduling). Ask which of these they want, and for repeating/scheduled, get the specific cadence and time. Don't assume one-off just because they said "launch it now." When the user sets up a recurring schedule, also clarify whether they want a first run to start immediately or only at the next scheduled slot.

### B. Behavior & output settings (always resolve)

Enumerate the behavior/output fields that this Phantom actually exposes (from ,argumentSchema.properties, + the "Behavior" / "Results file settings" steps in ,argumentForm,). Only ask about fields that exist for this Phantom. Common ones:

- Volume: ,numberOfResultsPerLaunch, / ,numberOfAddsPerLaunch, / ,numberOfResultsPerSearch, / ,numberOfLinesPerLaunch,.
- Deduplication: ,removeDuplicateProfiles,.
- Enrichment: ,enrichLeadsWithAdditionalInformation, / ,enrichWithCompanyData, (and other ,enrichWith*, toggles).
- Email discovery: ,emailChooser,.
- CRM push: ,pushResultToCRM, and field mappings.
- Watcher mode + notifications: ,watcherMode,, ,newLeadsNotificationEnabled,.
- Output file: ,csvName,, ,filters, (fields to keep).
- Notifications: success/error email or Slack (,notifications,).

Also confirm the input/target itself (search URL, keywords, lead list, spreadsheet, profile list): a launch with the wrong input wastes the whole run. If you constructed an input (e.g. a search URL with a ,geoUrn,), show it and have the user confirm or replace it; don't assume a geo/keyword mapping is correct.

### C. Rate-limit safety (include when relevant)

For account-driven Phantoms (LinkedIn, Sales Navigator, Instagram, etc.), surface PhantomBuster's safe daily limits before the user sets volume and frequency, so their choices stay safe:

- LinkedIn Search Export (standard account): ~1000 results/working day.
- LinkedIn Profile Scraper: ~1500 profiles/day.
- Sales Navigator: up to ~2500/day.
- The manifest's ,rateLimitsRecommendations, plugin or the "Behavior" step ,helpers, often carry the exact per-Phantom guidance: prefer them when present.

Flag it when volume × frequency would exceed the recommended daily ceiling, and let the user decide.

## Step 3 - Confirm, then launch

Echo back the full resolved configuration (input, frequency/schedule, and every behavior/output setting, old → new when editing) in a compact summary, and get an explicit go-ahead. Launching/scheduling consumes credits and acts on the user's account, so this confirmation is required, not optional. Then:

1. Persist settings: ,agents_save, with the resolved ,argument,, ,launchType,, and any schedule fields (,repeatedLaunchPreset, / ,repeatedLaunchTimes, / ,launchOnceAt,). When editing, send the full ,argument, with only the intended fields changed so you don't drop existing config (input, identities, CRM map).
2. Launch (if a run-now was requested): ,agents_launch, with the agent ,id,.
3. Report back the ,containerId,, the settings that were applied (old → new), and, for scheduled/repeating launches, when the next run will occur. Offer to check status or pull results once the run finishes.

## What "never guess" means in practice

- Don't pick a results/profiles-per-launch number because it "seems safe": ask.
- Don't default ,launchType, to manual: ask whether they want it scheduled.
- Don't assume dedup / enrichment / email-discovery / CRM preferences: ask.
- Don't trust a search URL or geo mapping you built without the user confirming it.
- If the user explicitly says "use the Phantom's defaults," that's a valid answer: apply ,manifest.defaultArgument, and tell them exactly what those values are so the choice is informed.