/launch-meta-ad-campaign

name: launch-meta-ad-campaign
description: Take someone from a business goal to a verified, paused-then-live Meta/Facebook/Instagram campaign without making them learn Meta's hierarchy. Use automatically for requests to launch, run, create, publish, set up, or plan Meta ads; use reporting skills for analysis-only requests.

Launch Meta Ad Campaign

**What this is for.** Someone says "I want more signups". They should not have to learn what a campaign objective is, what an ad set does, what a pixel is, or which of Meta's fourteen optimization goals fits — and they should not be asked to choose any of them. They tell you about their business; you do the rest and explain it back in their words.

The skill is agent-neutral: choose the best available adapter, but keep one journey and one approval boundary.

Choose one mode

Use the first available mode:

1. **GooseWorks adapter** when all GooseWorks launch tools are callable. Read [references/gooseworks-adapter.md](references/gooseworks-adapter.md). 2. **Direct Meta adapter** when a valid Meta token and ad-account access are available. Read [references/direct-meta-adapter.md](references/direct-meta-adapter.md) and use the bundled `tools/meta_marketing_api.js`. 3. **Planning-only fallback** when neither write adapter is available. Read [references/planning-only.md](references/planning-only.md). Produce a useful plan; do not present missing write access as a failed planning task.

If both write adapters are available, prefer GooseWorks because its approval page, creative links, and recovery records are already integrated. Never mix adapters within one launch.

**Before Stage 1, resume rather than restart.** If a launch record or push already exists, resume it. Inspect existing campaigns, ad sets, ads and creative before recommending anything new, and say whether the intent fits reuse. Never duplicate a partially completed launch, and never build a second context system when the adapter already provides one.

<!-- shared:launch-journey start -->

How to talk to the user

The user talks about their business. Talk back about their business.

Campaign ids, ad-set ids, pixel ids, objectives, optimization goals, placements and bid strategies are **your** working vocabulary, not theirs. Work them out, use them, and translate them back. Surface a raw id only when the user asks for one, or when they need it to do something in Meta themselves.

| What you are dealing with | What you say | |---|---| | Campaign objective | "what we're asking Meta to go after" | | Ad set | the audience and the budget — usually no need to name it at all | | `LANDING_PAGE_VIEWS` | "we pay for people who actually load your page, not just tap the ad" | | `LINK_CLICKS` | "we pay for taps — cheaper, but some of them never arrive" | | `OFFSITE_CONVERSIONS` | "we pay for the action itself — signups, purchases" | | Pixel / conversion event | "the tracking on your site" / "the action we're counting" | | Creative | "the ad" | | Learning phase | "Meta needs roughly 50 of these a week before it can steer well" | | `effective_status: IN_PROCESS` | "Meta is reviewing it — normal, usually within a day" | | Account balance / funding source | "the card Meta bills" | | Lifetime budget + `end_time` | "it spends at most $X and stops itself on the 30th" |

Three rules sit on top of that vocabulary:

• **Frame every launch as a test worth running**, never as "your ads are live". Say what this

money can and cannot answer *before* it is spent. A budget that cannot measure cost per sale should never be reported as if it did.

• **Never say an ad is live until Meta says so.** A successful write is not a live ad.
• **Own the errors.** Translate Meta's failures into what happened and what happens next. Never

hand back a raw API error and leave the user to decode it.

Workflow

Seven stages. Stages 1 to 5 run before a single object exists in Meta.

Stage 1 — Start with the goal

Open here. Do not open with Meta settings, and **never ask the user to pick an objective, an optimization goal, a budget type or a structure** — those are yours to derive.

Ask for six things, in the user's own language:

1. **The goal** — what should this money produce? Sales, leads, signups, traffic, awareness, or "I want to find out whether this works at all". 2. **The offer** — what is being promoted, and what does someone actually get? 3. **The audience** — who is it for, and where are they? 4. **Budget and run time** — the total and how long, e.g. "$300 over two weeks". If they give a daily number, ask for the total and duration anyway: "£20 a day" and "£140 for the week" build different things. 5. **Success metric** — what number would make this a good fortnight? If they have none, say so and propose one. 6. **Destination** — where should someone land after tapping?

Everything else you derive:

| You derive | From | |---|---| | Campaign objective | the goal plus the destination — a purchase on a site with tracking → sales; a form or signup → leads; "does this work at all" → traffic | | Optimization goal | whether the destination carries tracking, and how many of the target event the account already produces per week (Stage 2) | | Structure — one campaign, one audience, 2–3 ads | the budget | | Budget type | a total + duration → a lifetime budget with an end date, which hard-caps itself; an open-ended daily figure → a daily budget | | Placements, bid strategy, billing event | sensible defaults, unless something in the brief argues otherwise | | Schedule | the ad account's own timezone, never yours |

**When something is missing, explain why you need it** — one sentence, in business terms, then ask. Never ask for a fact you could look up, and never ask twice for something already answered.

> "I need a rough sense of what a signup is worth to you, because that decides whether we can > afford to chase signups directly or should buy traffic first and learn from it."

Take silence as a