Change plan builder
12 free, installable Google Ads skills for Claude and other coding agents.
npx -y skills add kelpi-ai/google-ads-skills --skill change-plan-builderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.0 KB, 573 tokens by cl100k_base, as published. Nobody here has run it
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.