agentleFS
kelpi-aikelpi-ai/google-ads-skills/skills/change-plan-builder/SKILL.md

change-plan-builder

Skill2 starsChanged 4 months agoMITView on GitHub

Turn Google Ads findings into an ordered, approval-ready change plan with dependencies, evidence, rollback, and measurement. Use when the analysis is done and the next move needs to be clear.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After one or more Google Ads skills have produced findings.

    line 14
  2. Distinctive:

    Before making account changes, especially goals, negatives, ads, bids, budgets, or structure.

    line 15
  3. Distinctive:

    Use a connected Google Ads MCP for a fresh read, or paste findings with exact entity names, IDs, current settings, recent changes, and …

    line 16
  4. Distinctive:

    Never delete or demote a conversion action from a similarity in names or totals alone.

    line 40
  5. Distinctive:

    Never turn a few bad queries into broad one-word negatives without match-type, scope, and collision checks.

    line 41
  6. Distinctive:

    Every executable item needs exact current and proposed state, approval, rollback, and measurement.

    line 43
  7. Distinctive:

    Do not bundle unrelated changes into one test.

    line 44

≈ “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

Change Plan Builder

Doctrine

A good change list is not a pile of recommendations. It respects dependencies, names the exact entity and current state, separates investigation from execution, and tells you how to undo each move. Tracking comes before bidding, query evidence comes before negatives, and a low CPA does not make every extra dollar profitable.

When to use

  • After one or more Google Ads skills have produced findings.
  • Before making account changes, especially goals, negatives, ads, bids, budgets, or structure.
  • Use a connected Google Ads MCP for a fresh read, or paste findings with exact entity names, IDs, current settings, recent changes, and business constraints.

Run it

Build a READ-ONLY Google Ads change plan. Use live account data for current state if connected; otherwise use what I paste. Execute nothing.

1. Confirm the scope, exact entities and IDs, current settings, primary business goal, approval policy, and recent change history.
2. Convert each finding into one label: keep, investigate, exclude, rewrite, restructure, or test.
3. For every item show: priority, entity, current state, proposed state, evidence, expected direction, confidence, risk, dependency, preflight check, approval required, rollback, success measure, and review date.
4. Order dependencies before impact:
   - verify conversion integrity before bid, target, budget, or scaling changes;
   - run negative-keyword collision checks before exclusions;
   - verify page claims and URLs before ad rewrites;
   - stabilize serving before judging efficiency.
5. Use directional expectations unless the user supplies a validated model. Do not invent CTR lifts, CPC savings, conversion counts, or monthly forecasts.
6. Keep investigations separate from mutations. "May be duplicated" becomes a verification step, not "delete the duplicate".
7. Require item-level approval and a fresh preflight read before any later execution. Grouping items in one plan is not blanket approval.

Return: do first, do next, hold, and keep. End with "Plan only. No changes were made."

Guardrails

  • Never delete or demote a conversion action from a similarity in names or totals alone.
  • Never turn a few bad queries into broad one-word negatives without match-type, scope, and collision checks.
  • A campaign below target and limited by budget is a candidate for investigation, not an automatic budget increase.
  • Every executable item needs exact current and proposed state, approval, rollback, and measurement.
  • Do not bundle unrelated changes into one test. If the result would be impossible to attribute, split the plan.

Good output looks like

An ordered dry run where the safest dependency comes first, every proposed change is inspectable and reversible, forecasts stay honest, and nothing happens without item-level approval.

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.