What "full spec" actually means
Before the prompt, we wrote down what a passing RSA looks like. Not in our heads — on paper. This is the part most teams skip, and it is the part that does almost all of the work.
| Field | Constraint |
|---|---|
| Headlines | 15 unique, max 30 characters each, no duplicates within an ad group |
| Descriptions | 4 unique, max 90 characters each |
| Case | AP Title Case (Headlines), sentence case (Descriptions) |
| Punctuation | No em-dashes (Google Ads silently strips them). En-dashes allowed in dates only. No double exclamation. One exclamation max per ad, never in Headline 1. |
| Brand mentions | Brand name in at least 2 headlines, not pinned |
| Offer / CTA | At least 3 headlines must contain a CTA verb (Book, Get, Call, Request, Schedule) |
| Diversity | At least 3 of the 15 headlines must be benefit-led (no feature words like "service", "company", "available") |
| Pinning | Headline 1: brand + service. Headline 2: location or differentiator. Headline 3: CTA. Other 12 unpinned. |
| Banned tokens | "#1", "best", "cheapest", "guaranteed" (Google policy + most client compliance lists) |
This table is the spec sheet. It lives in a Markdown file in our skill folder. The prompt does not contain creative direction; it contains references to the spec sheet. That separation is what makes the system stable.
The prompt, in three parts
We use one prompt that has three parts: role, spec, brief. The role and the spec almost never change. Only the brief changes per ad group.
Part 1 — Role
You are a Google Ads RSA copywriter for a high-intent lead-gen
account. You ship Responsive Search Ads that pass the Content
Quality Guard spec without manual rework.
Output only the final RSA in the exact format under "Output
schema". Do not explain, do not list trade-offs, do not ask
clarifying questions until after the first draft.Part 2 — Spec (referenced, not inlined)
Follow CQG-spec.md exactly. Every constraint in the spec sheet
is hard. If a constraint cannot be satisfied with the brief
provided, return the headline as "NEEDS_INPUT: <reason>" and
move on. Do not invent facts.Part 3 — Brief (the only thing that changes)
Client: McMahon Auto Service
Location: Carlsbad, CA
Service: Brake repair (this ad group only)
Offer: Free brake inspection, same-day appointments
Brand voice: Direct, trustworthy, no jargon
Banned: "ASE certified" (cannot substantiate at all locations)That is the entire prompt. Three parts. Two of them are stored as files in the skill, one of them is filled in per ad group. The whole thing fits on one screen.
The validator step (the part that actually saved us)
The prompt alone gets us to about 90% on-spec. Claude is a strong writer, but it cannot count characters perfectly and it has no memory of which words are AP Title Case exceptions ("vs.", "from", "via"). So we run a deterministic validator over its output before anything ships.
The validator is roughly 60 lines of Python. It checks:
- Length per headline (≤30) and per description (≤90), measured the way Google measures (Unicode grapheme clusters, not bytes)
- AP Title Case using a frozen list of 31 lowercase exceptions
- No em-dashes, no double punctuation, no banned tokens
- Brand mention count, CTA verb count, benefit-led count
- Duplicate detection (Levenshtein distance < 4)
If any check fails, the validator returns a structured list of failures and feeds them back into Claude with a single line of instruction:
The following lines failed the Content Quality Guard.
Rewrite only those lines. Keep all other lines exactly as they are.
[failures listed]Two iterations of this loop is enough for 100% of the ad groups we have run it on. Three iterations on edge cases. We have never needed four.
Why the validator matters more than the prompt
This is the part that surprised us. You can write the cleverest prompt in the world; the model will still occasionally produce 31 characters because tokenization and character counting are not the same thing. The validator turns an LLM's "usually right" into "always right" by running a fast, deterministic check that the LLM cannot fool itself on.
It also means we can swap the model. The same prompt and validator work on Claude Sonnet, Claude Opus, and even on an entirely different vendor in a pinch. The spec is the contract; the model is the writer.
The pattern, generalized
For any AI task in PPC where "on-spec" is a binary, write the spec as a file, write a deterministic validator, and put the LLM in a write → validate → rewrite loop. Prompts alone are not enough. Vibes are not a quality system.
What it looks like in practice
A request to ship a new RSA used to take a copywriter 25 to 40 minutes — draft, review, character-count, fix, recheck, copy into the editor. With the Content Quality Guard, the average is now under 4 minutes per ad group, and the senior reviewer's role has shifted from "count characters" to "is this the right offer for this audience?"
Across our 39 client accounts, that is a real number. We ship roughly 60 RSAs a month between net-new ad groups, refreshes, and seasonal swaps. The time saved on counting characters and arguing about Title Case is now spent on the part of the work that actually moves CTR.
What we tell clients
The clients who care about how the sausage is made get the spec sheet on request. The clients who do not care get cleaner ads, shipped faster, with a higher consistency than the previous workflow. The Content Quality Guard is invisible to them; it shows up as fewer policy disapprovals and tighter CTR on day 14.
If you run more than three Google Ads accounts and you find yourself counting characters by hand, you can build this in an afternoon. The spec sheet is the hard part, and you already have one in your head — you just have not written it down yet.