Rescue

PREREQUISITE: Read ../_mureo-shared/SKILL.md for auth, security rules, output format, and Tool Selection (Read/Write on Code, mureo_strategy_* / mureo_state_* MCP on Desktop / Cowork).

Tool names below refer to the built-in platforms; a namespaced variant (see _mureo-shared → Namespaced built-in variants) is used with its prefix substituted.

Run an emergency performance rescue workflow for underperforming campaigns.

Prerequisites

• STRATEGY.md and STATE.json must exist (run the onboard skill first)

Steps

Before you start: Run the Diagnostic preamble from ../_mureo-shared/SKILL.md — load learning insights (mureo_learning_insights_get) and consult advisors (mureo_consult_advisor) before drawing conclusions.

0. Establish today: call mureo_state_get first, on every host (including Claude Code, where you would otherwise Read the file) and take server_now from its response — ISO 8601 with UTC offset, e.g. 2026-07-28T10:12:33+09:00. Its date is the only source of the current date for this run: the observation_due you write in step 10 is server_now's date + 7 or 14 days, and "how long has this been going on?" is measured from it. Do not shell out (this skill must run in Bash-less headless hosts) and do not read the date off STATE.json — last_synced_at, reports.*.period and action_log timestamps are history, never evidence of what day it is now. Never write server_now into STATE.json: it is a response field, and a persisted copy becomes tomorrow's stale "today".

1. Load context: Read STRATEGY.md (including Goal sections and Data Sources) and STATE.json (the same mureo_state_get response from step 0 on MCP hosts). Set Operation Mode to TURNAROUND_RESCUE in STRATEGY.md.

2. Discover platforms: Identify all configured ad platforms from STATE.json platforms. Also include any hosted official-MCP connector present in the session (e.g. TikTok, key tiktok_ads) — drive it via its own tools and skip mureo-only value-adds; see ../_mureo-shared/SKILL.md → Hosted-connector platforms.

3. Diagnose: platform-side or site-side? (if GA4 is available): Before making ad changes, check if the performance problem is platform-side or site-side. If LP conversion rates dropped in GA4 too, the issue may be the landing page, not the ads. Recommend LP investigation before ad changes.

4. Identify problem campaigns across all platforms: For each configured ad platform:

   • Analytics-module check (external integrations only): For every external-integration platform (plugin or official MCP), call mureo_analytics_modules_list first. When the platform's module advertises detect_anomalies, run it via mureo_analytics_run (capability: detect_anomalies, with window_days) and fold the structured result into the rescue summary; a non-ok status means treat it as unavailable. Otherwise emit analytics_not_available_for_<platform> in the rescue summary rather than fabricating heuristics from the integration's tool schemas (Issue #120).
   • Google Ads: prefer mureo native — call google_ads_health_check_all (eligibility / serving issues — meaningful only with Live API; returns [] in BYOD), then iterate campaigns from google_ads_campaigns_list and call google_ads_monitoring_zero_conversions and google_ads_cost_increase_investigate per campaign_id, plus google_ads_campaigns_diagnose for structural issues. If mureo's Google Ads tools are unavailable (e.g. MUREO_DISABLE_GOOGLE_ADS=1 after mureo providers add google-ads-official), fall back to the official google-ads-official MCP for the campaign list and performance numbers, then skip the mureo-only anomaly-detection tools (google_ads_health_check_all, google_ads_monitoring_zero_conversions, google_ads_cost_increase_investigate, google_ads_campaigns_diagnose) with a note: "anomaly detection and structural diagnostics require mureo's native MCP — install or re-enable via mureo setup claude-code for full rescue coverage." Identify zero-conversion / high-spend campaigns manually from the raw performance numbers in that case.
   • Meta Ads: prefer mureo native meta_ads_insights_report and inspect each campaign's result_indicator (PR #61): a link_click-optimized campaign with high "results" but zero pixel_lead is a tracking issue, not a creative one — flag for measurement fix before any rescue action. If mureo's Meta Ads tools are unavailable, fall back to the official meta-ads-official hosted MCP for raw insights; note that result_indicator-based CV-definition analysis is a mureo-specific value-add and will not be present — manually inspect the insights actions list for link_click vs offsite_conversion.fb_pixel_lead mismatches.
   • mureo BYOD data is centralized in the workspace byod/ directory (or ~/.mureo/byod/ for legacy CLI users) and is only accessible through mureo MCP tools — do not look for raw CSVs in the project directory.

4b. Delivery collapse — when a campaign stopped serving rather than got worse. Use this branch when impressions or spend went to (or near) zero while the campaign's status still says ENABLED / ACTIVE. It is a different problem from a CPA spike and needs a different path: there is nothing to optimise, something is blocking delivery.

1. Confirm it. Run the detector rather than eyeballing a chart: mureo_analytics_run with capability="detect_delivery_collapse" on Google Ads / Meta Ads, or analysis_delivery_collapse_check with day-grain rows for any other platform (see /daily-check step 4 for the row shape). It reports the cliff date and the baseline the campaign fell from — you need both. If it reports no collapse, this is an efficiency problem, not a delivery one: go back to step 4.

2. Build the change × metric timeline. Gather what changed in the days before the cliff — google_ads_change_history_list for Google Ads, action_log entries for the campaign on every platform, and any change feed the platform itself offers — then call analysis_delivery_collapse_diagnose with the same rows, the campaign_id, and those changes. The tool treats the 3 days before the cliff as "immediately before"; widen change_lookback_days when you suspect a cause with a delayed effect (a billing hold or a policy review can stop delivery days after the change that caused it). Changes outside the window still appear on the timeline — only the changes_before_cliff shortlist narrows.

3. Walk the elimination ladder and feed each result back in as evidence. The tool's next_checks names the mureo tool for each open step (Google Ads: google_ads_ads_policy_details, google_ads_budget_get, google_ads_auction_insights_get, google_ads_campaigns_diagnose, google_ads_campaigns_get; Meta: meta_ads_ads_list, meta_ads_campaigns_get, meta_ads_ad_sets_get). An empty tool string means mureo has no tool for that step — check it in the platform UI and supply the answer, or record it as unavailable. Report each step as implicated / ruled_out / unavailable / inconclusive, with the evidence in detail. Only report what you actually checked: a step you did not run comes back as an open question, which is the honest state.

4. Report the cause AND the open questions. Take the tool's verdict as given. confidence: undetermined with most_likely_cause: null means nobody knows yet — say that, list the unresolved items and the limitations, and do NOT nominate a cause the evidence does not support. This is the common outcome, not a failure of the workflow: a real week-long, two-campaign outage was worked with full API access and never closed. Several things no read API on any platform exposes — serving-side suppression, billing state, learning-phase internals — are in limitations for exactly this reason.

5. Then act. Fix an implicated cause directly. When nothing is implicated, escalate to platform support with the timeline and the ruled-out list attached, and treat a rebuild as the last resort — it destroys the evidence and the learning history along with the problem. Log whatever you do to action_log per step 10 so the next collapse has a change axis to read.

6. Evaluate severity against Goals: For each problem campaign, reference Goal targets from STRATEGY.md:

   • Calculate how far off the campaign is from the Goal
   • Prioritize rescue actions by impact on Goal achievement
   • Flag campaigns that are the biggest blockers to reaching Goals

7. Search term cleanup (for platforms that support search term data):

   • Review search terms for waste on each problem campaign
   • Cross-reference with Persona from STRATEGY.md — flag terms that don't match target audience
   • If Search Console is available, identify terms better served by organic
   • Suggest negative keywords to add
   • Ask for my approval before adding any negative keywords

8. Budget efficiency: Analyze budget efficiency across all platforms. Identify campaigns wasting budget (high spend, low/zero conversions). Suggest budget reallocation from wasteful to efficient campaigns.

   • Ask for my approval before changing any budgets

9. Platform-specific optimizations: For each platform, run the platform's specialized analysis (device performance, placement analysis, audience analysis, etc.) on problem campaigns. Suggest specific optimizations.

   • Ask for my approval before making changes

10. Execute approved actions: Only after I approve each recommendation, execute the changes using each platform's update tools.

11. Record outcome context: For each campaign modified, log to action_log with observation_due (from server_now's date: 7 days for budget changes, 14 days for keyword/creative changes); omit metrics_at_action and mureo fills it from the campaign's snapshot.

12. Update STATE.json: Record all changes made in campaign notes with timestamps. Log all rescue actions to the action_log with platform, action type, and expected impact.

13. Summary: List all changes made per platform with expected impact on Goal metrics.

IMPORTANT: Never make changes without explicit approval. Present each action as a recommendation first. Do NOT trigger rescue based on a single bad day — at least 7 consecutive days of critical metrics (>30% off target) before recommending rescue actions.