ad_angle_engine v1.0.0

name: "ad_angle_engine" description: "Turns one product into a full ad campaign: expands 7 angle families (pain, desire, proof, contrarian, mechanism, identity, urgency) into written ad variants, screens every line against platform policy, and ships a ranked test plan with kill and scale criteria. Triggers when someone needs ad copy, ad concepts, or a creative testing plan for Meta, Google, LinkedIn, or TikTok." metadata: { "includeInPrompt": true }

Ad Angle Engine

Purpose

One strong offer, seven different reasons to care. This skill takes a product (or an offer) and produces a campaign's worth of ad copy built on a real angle system: each angle attacks a different buyer motivation, gets a written hook line, survives policy screening, and enters a ranked test plan with clear decision rules. The point is not variety for its own sake. It is a calibrated set of testable bets, so the account learns which motivation actually moves buyers.

Workflow

1. Extract the grounded offer. Before writing a single word, pin down: product, core promise, target buyer, platform, ad format, landing page. If the core promise is fuzzy, stop and say so. Twelve angles on a fuzzy offer produce twelve fuzzy ads. Nothing proceeds on assumptions: every number, testimonial, and result quoted must come from the user or a source they provide. Unverifiable claims get cut, not softened.

1. Expand the angle families. Build at least one angle per family in references/angle-families.md (pain, desire, proof, contrarian, mechanism, identity, urgency). Each angle gets:

• A one-line angle statement: the specific reason a buyer would care.
• A written hook line: the actual first line a person would see, in the platform's format (ad headline, primary text opener, search ad headline). An angle without a hook line is not testable and does not ship.
• A distinctness check: if you deleted the other six, could this one stand as its own ad? Synonym swaps fail the check. Rewrite until it is genuinely different.
• Skip a family only with a written reason (e.g. urgency does not fit an evergreen subscription). Note it in the output.

1. Flesh out full variants. For each surviving angle, write the full ad: headline(s), body/primary text, CTA, visual concept. Keep to the platform's character and format constraints; verify current official limits before shipping exact compliance (the reference values in references/policy-checklist.md are starting points, not gospel).

1. Screen every line for policy. Run each variant through references/policy-checklist.md. The big ones: Meta's personal-attributes rule (no direct or indirect assertion about age, health, finances, religion, identity, or any of the protected categories), no appearance-inferiority copy, no unqualified time-boxed outcome promises, evidence qualifiers on every result claim. Rewrite or drop anything that fails. A rejected ad costs more than a cut angle.

1. Validate with the checker. Put the variants into a CSV bank (angle, platform, element, copy, claim_source) and run python3 bin/bank_check.py bank.csv. Fix every FAIL before continuing. This is mechanical hygiene, not a substitute for the policy read in step 4.

1. Build the ranked test plan. Rank the variants and lay out the test per references/test-plan-rubric.md: which variants run first, the budget per variant, the minimum data before any read, the kill and scale criteria, and the review cadence. One meaningful variable per test cell: angle changes, offer and landing page stay fixed. Ship the plan as part of the output, not as an afterthought.

1. Iterate from data (when performance data exists). Compare against the decision metrics in the rubric. Name winners by the agreed metric, keep losers paused (not deleted; a loser for one audience can win for another), and brief the next wave from what won: variants of winners, not new random ideas.

Output Contract

Deliverables, in this order:

1. Angle bank (markdown or CSV): angle family, angle statement, hook line, full copy with character counts, policy status per variant, claim sources.
2. Test plan: ranked variant order, budget per variant, minimum-data thresholds, kill/scale criteria, review dates.
3. Iteration report (only when performance data exists): evidence, hypotheses, pause/scale/test recommendations.

Table format for the bank:

| Angle | Platform | Element | Copy | Chars | Policy | Claim source | |---|---|---|---|---|---|---|

Every factual claim in every row must have a claim source, or the claim is cut.

Operating Rules

1. No invented numbers, dates, quotes, or events, ever. A stat without a source does not exist.
2. Result promises always carry an evidence qualifier: "on average", "based on", "up to". Never promise what the landing page cannot fulfill.
3. No empty superlatives, no all-caps, no fake scarcity, no rhetorical questions aimed at personal attributes ("Still struggling with your weight?" is a policy failure, not a hook).
4. Every search-ad headline must stand alone and combine safely with any other headline.
5. One variable per test cell. Never test a new angle and a new offer in the same cell.
6. Never call a winner below the rubric's minimum data. Variance at small samples looks like signal and is not.
7. Keep SKILL.md tight; family recipes live in references/angle-families.md, policy in references/policy-checklist.md, test discipline in references/test-plan-rubric.md.