agentleFS
loglylogly/mureo/skills/search-term-cleanup/SKILL.md

search-term-cleanup

Skill64 starsChanged 7 months agoApache-2.0View on GitHub

Audit and clean up search terms (negative keywords, intent classification, query hygiene). Use when the user asks to clean up search queries, add negative keywords, review search term reports, or improve match quality. Cross-references Search Console, GA4, and ad platform data. Also use when the user asks in Japanese (検索語句のクリーンアップ / 除外キーワードを追加して / 無駄な検索クエリを止めたい).

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before you start: Run the Diagnostic preamble from ../_mureo-shared/SKILL.md — load learning insights (mureo_learning_insights_get) and …

    line 21
  2. Very specific:

    Load context: Read STRATEGY.md (Persona, USP, Target Audience, Data Sources) and STATE.json (the same mureo_state_get response from step 0 …

    line 26
  3. Very specific:

    Check pending observations: Before executing, check action_log for this campaign.

    line 59
  4. Distinctive:

    Execute: Use each platform's keyword management tools to apply approved changes (add negative keywords, add positive keywords, adjust bids).

    line 63
  5. Very specific:

    Close the batch: call mureo_batch_end and report the returned batch_id and member count to the operator, so undoing this pass later is …

    line 67

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Search Term Cleanup

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.

Review and clean up search terms and keywords across all platforms.

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.

  1. 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 11, and every "is a previous action still inside its observation window?" check in step 9, are 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".
  2. Load context: Read STRATEGY.md (Persona, USP, Target Audience, Data Sources) and STATE.json (the same mureo_state_get response from step 0 on MCP hosts).
  3. Discover platforms: Identify all configured platforms that support search term data from STATE.json platforms. Also include any hosted official-MCP connector present in the session (e.g. TikTok, key tiktok_ads) where it exposes search-term data — drive it via its own tools and skip mureo-only value-adds; see ../_mureo-shared/SKILL.md → Hosted-connector platforms.
  4. Review search terms: For each ad platform that supports search term data:
    • Google Ads: prefer mureo native — call google_ads_search_terms_report for the raw query rows, then google_ads_search_terms_review (rule-based scoring) and google_ads_search_terms_analyze (intent classification) per campaign. These tools work in both Live API and BYOD mode. In BYOD they read from ~/.mureo/byod/google_ads/search_terms.csv (the Apps Script bundle output) — do not look for raw CSVs in the project directory; 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. 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's search-terms report tool for the raw rows, then skip the mureo-only rule-based scoring and intent-classification tools (google_ads_search_terms_review, google_ads_search_terms_analyze) and do the scoring/classification yourself using the rules described in step 6 below; note to the user that mureo's automated scoring is only available with the native MCP (install or re-enable via mureo setup claude-code).
    • Meta Ads: Skip — Meta is interest/audience-targeted and has no search-query data (this applies to both mureo native and the official Meta MCP).
    • Analyze N-gram patterns and user intent across the returned rows.
  5. Paid/organic cross-reference (if Search Console is available):
    • Pull top organic queries for the site
    • Cross-reference with paid search terms to identify overlap
    • For terms ranking well organically (position 1-3), consider reducing paid bids or pausing paid keywords
    • For terms with strong paid performance but weak organic ranking, flag as SEO opportunity
    • Present a paid/organic overlap matrix
  6. Landing page quality check (if GA4 is available): Check landing page performance for key search terms. Terms driving traffic to high-bounce-rate pages may need LP improvements rather than keyword changes.
  7. Score candidates against strategy:

    • Exclude candidates: Terms with 0 conversions + high cost, informational-only queries, terms misaligned with Persona
    • Add candidates: High-converting terms not yet added as keywords, terms matching USP themes
    • Reduce candidates: Terms well-covered by organic rankings

    Negative keywords are a marginal decision, not an average ranking. Distinguish systematic waste — an n-gram or intent pattern that is wrong for the Persona at any volume, where a negative genuinely removes future spend — from a low-volume term with a bad average, where a handful of clicks and zero conversions is a sample-size fact, not evidence of waste. Excluding the long tail one term at a time mostly narrows match reach without saving meaningful spend. Prefer pattern-level negatives with a stated marginal saving; leave thin terms to accumulate. See ../_mureo-pro-diagnosis/SKILL.md → Allocation & Learning-State Discipline.

  8. Present recommendations in a table:

    TermPlatformActionReasonScoreCampaign

    Group by platform and campaign. Show estimated cost savings from exclusions.

  9. Ask for approval: Let me select which recommendations to apply.
  10. Check pending observations: Before executing, check action_log for this campaign. If a previous action is still within its observation window, warn that stacking changes will make outcome evaluation difficult. Recommend waiting if possible.
  11. Open a batch: call mureo_batch_begin with a label naming this pass (e.g. "search-term cleanup 2026-08-07"). A cleanup changes many entities across possibly several platforms, and the batch is what makes it one reviewable, plannable unit instead of a set of entries nobody can re-identify later. See ../_mureo-shared/SKILL.md → Bulk changes are one revertible unit.
  12. Execute: Use each platform's keyword management tools to apply approved changes (add negative keywords, add positive keywords, adjust bids).
  13. Record outcome context: For each campaign modified, log to action_log with observation_due (14 days from server_now's date); omit metrics_at_action and mureo fills it from the campaign's snapshot. This enables evidence-based evaluation later. Keyword and negative-keyword changes are not auto-recorded, so this step is what puts them in the batch at all — an entry you do not append is invisible to any later revert.
  14. Close the batch: call mureo_batch_end and report the returned batch_id and member count to the operator, so undoing this pass later is rollback_plan_get with that id rather than a reconstruction from memory.
  15. Update STATE.json with notes about the cleanup.

IMPORTANT: Always explain WHY a term should be excluded/added, referencing the Persona or USP from STRATEGY.md. Consult past action_log entries — if a similar cleanup was previously evaluated, reference whether it was effective.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.