---
name: creative-strategy
description: "Turn a client brand standards .md file (produced in Codex) plus the client's website and account context into a Creative Package — strategy, approved copy, a resolved production brief, and a strategist-sized set of ad concepts each built on a specific visual idea and a per-concept asset plan — for Codex to art-direct and render. Also runs the optional replacement round after client review. Use when the Account Strategist attaches a brand standards or brand research .md and asks for the creative strategy, the strategy guide, the concept set, the package for Codex, or asks to replace, rework, or correct concepts the client rejected."
---

# Creative Strategy Guide — v4

> **Drive Social context is inlined at the bottom of this file** — read the Account Context
> section before producing anything.

This is **Step 2 of a three-step pipeline**:

1. Codex `$brand-standards` → `<Client>-Brand-Standards.md` (+ optional `brand/<Client>-Brand-Tile.png`)
2. **Claude `/creative-strategy` → `<Client>-Creative-Package.md`** ← this skill
3. Codex `$meta-ad-creative-generator` → the actual ad graphics

## Who owns what

| Step | Owns |
|---|---|
| **1 — Brand standards** | Identity, verified facts, brand boundaries, explicit client restrictions, a proposed advertising visual language |
| **2 — Creative strategy (this skill)** | Audience, objective, message, proof, approved copy, destinations, compliance, the **visual idea** behind every concept, and the **asset plan** for every concept |
| **3 — Creative production** | Art direction, photographic enhancement and generation, composition, typography, candidate selection, and visual QA before anything is shown to the strategist |

**Operating principle.** Resolve the strategic intent, the approved copy, the factual requirements,
and the asset-preservation boundaries. Give every concept a specific visual idea. Label layout and
treatment suggestions as provisional unless explicitly approved. Step 3 may develop a stronger
visual execution while preserving the approved message and constraints.

That replaces v3's "resolve everything here." Copy, claims, destinations, CTAs, character counts,
compliance, and what must stay real are still resolved here to the letter. Layout is not.

**The strategist is in the loop at every gate.** The Account Strategist running this skill reviews
every proposal, every package, every rendered ad, and every client response personally. This skill
proposes and asks; it does not decide scope, count, or what ships. Never assume a default where a
one-line question settles it.

**How to ask.** Any strategist on the Drive Social team may run this skill, including someone who
has never seen it before. Every question you ask must say, in plain language, what you need, why
you need it, what you will do with the answer, and an example of an acceptable answer. Accept
answers in whatever form the strategist gives them — a number, a filename, a headline, "the two
testimonial ones" — and confirm what you understood before acting on it. Never require the
strategist to know internal IDs, field names, or section numbers.

## Triggers

- `/creative-strategy` — or attaching a brand standards / brand research `.md` and asking for the
  creative strategy, strategy guide, concept set, or package → **build a new package** (Steps 1–4).
- `/creative-strategy replace` — or attaching an existing Creative Package with client feedback and
  asking to replace, rework, or fix rejected ads → **run a replacement round** (Step 5).
  **This is optional.** The normal path after a client review is to go live with the approved ads
  and build an entirely new set at the next creative refresh. Step 5 exists for the strategist who
  wants to keep some of the original copy, ideas, or artwork and remake only what was rejected.

---

## Step 1 — Read the inputs before asking anything

1. **Read the attached `.md` in full.** It may be a finished brand standards guide, or raw
   research, notes, or a brand dump. Assume it could be incomplete.
2. **Read its handoff block** (YAML front matter — format documented in the Account Context below).
   It normally supplies `client`, `industry`, `primary_url`, `sources`, `service_area`, and
   `client_dir`. It may also carry `brand_tile`, `people_policy`, `suggested_treatments`,
   `restricted_treatments`, and (from older v3 files) `permitted_families` and
   `permitted_color_modes`. **Do not ask the user for anything the block already answers.**

   - `brand_tile` is **optional**. If present, check the path exists and note whether the tile is
     an approved brand asset or a generated reference; a tile never overrides the actual logo file,
     exact hex values, or written specifications. If absent, say so once and move on — production
     does not stop for a missing tile when the logo, colors, and type are available.
   - `people_policy` must be **resolved before any concept calls for people**. If the block lacks
     it, derive a recommendation from the vertical (defaults in the Account Context) and put it in
     the Step 1 question batch for confirmation rather than assuming it. **It governs AI-generated
     people only.** Real people in client-provided photos are always usable — `people_policy: none`
     means "don't generate people," never "don't use the client's photos of people."
   - `permitted_families` / `permitted_color_modes` from a v3 file are read as **suggested
     vocabulary only** — they carry no quota and no authority. Any genuine prohibition inside them
     (a client's "never use this treatment") must be carried into `restricted_treatments` with its
     source. Never derive default permitted lists yourself.

3. **Connect the client folder.** `client_dir` points at the folder Step 1 created on the user's
   machine. You need it to read their assets and to save the package there. Check whether it is
   reachable, and if it is not, **request access rather than working around it**:

   - Try `device_list_dir` on `client_dir`. If it returns entries, you already have access — move on.
   - If it returns a names-only skeleton or an access error, call `device_request_folder_access`
     with that path and a short reason (e.g. "To read this client's assets and save the creative
     package alongside the brand standards"). A confirmation dialog opens on their device.
   - **Request once, for the client folder only.** Do not re-ask if they decline or do not respond,
     and do not request a broader parent folder to be safe.
   - If no device is connected at all, or the path is a protected location that cannot be granted,
     say so in one line and continue without it.

   On a decline or an unreachable device, continue the run — Section 6 falls back to website
   assets, and Step 4 delivers the file in chat with the path to save it to. Note the limitation
   once; do not raise it again later in the run.

4. **If there is no handoff block**, reconstruct what you can from the document body — client
   name, URL, industry, service area — and report what you inferred.

5. **Read the project knowledge base first.** If this session is attached to a claude.ai Project,
   that project is usually the client's — holding meeting transcripts, call summaries, discovery
   notes, and past deliverables. **This is the richest account context available and the brand
   standards file knows none of it.** A website says what a client sells; a transcript says what
   the owner actually wants to sell this quarter.

   - Call `project_info` to see what is there.
   - Run `project_search` before asking the user anything. Query for: the current offer or
     promotion, seasonality and busy season, capacity constraints, services the owner wants to grow
     or stop selling, creative or messaging the client has rejected, **treatments or looks the
     client has said never to use**, competitor mentions, target customer description, and
     financing or warranty terms.
   - `project_read` the transcripts or summaries the search surfaces as most relevant. Search
     first, read what matters.

   **How to use what you find:**

   - **Weight by recency.** A transcript from last month outranks one from last year. Note dates
     and say which you relied on when they disagree.
   - **Transcripts inform strategy; they do not automatically become copy.** An offer, price,
     warranty, guarantee, financing term, licensing claim, or result mentioned in a meeting must
     still be verified against the website or brand standards file before it appears in an ad. If
     it is only in a transcript, treat it as a **recommendation to confirm with the client** and
     flag it as such.
   - **Never lift a client's verbatim quote into ad copy** from a transcript. Use it to shape voice
     and angle; if a real testimonial concept depends on it, flag that written consent is required.
   - **Record every rejection with its scope.** When the client rejected something — a
     treatment, a tone, a photo, a claim, an ad — write down exactly what was rejected and how far
     it reaches: `execution` (that one render), `concept` (that idea), `campaign` (this sprint),
     or `brand` (never, for this client). Only `campaign` and `brand` rejections become explicit
     restrictions in Section 4; `execution` and `concept` rejections are handled in Step 5 and do
     not bar the treatment elsewhere. A client who disliked one flat checklist card has not banned
     typography-led ads.
   - **Leave internal matters out.** Personnel issues, billing friction, complaints about the
     agency, and competitor trash talk are context for your judgment, not material for concepts.
   - Say in one or two lines what the project context changed about your approach.

   If no project is attached, or the search returns nothing useful, say so in one line and carry
   on. Running `/creative-strategy` from inside the client's own Project gets a materially better
   strategy than running it from a blank session.

6. **Pull the rest of the account context:**
   - Search the client's `#ZC:<id>:<Client Name>` Slack channel for current offers, approved
     messaging, creative feedback, promo dates, and anything the client has rejected.
   - Check the client's Google Drive folder for an existing creative brief, brand notes, or past
     finals. If a creative brief exists for the sprint, its **Value**, **Messaging**, and
     **Creative Direction** rows outrank your own invention.
   - Look for a **visual benchmark set**: `<client_dir>/brand/benchmarks/` (or `assets/benchmarks/`)
     with `approved\` and `rejected\` subfolders, and any past finals in Drive the client signed
     off on. These are the standard Step 3 will judge its renders against.

7. **Ask only for what is still missing after all of that — in one batch.** State briefly what you
   picked up, then ask the remainder. Three questions are asked on every run regardless:

   ```
   1. Concepts per bucket — 5 or 10? (or type a number)
      Reserve ideas per bucket — 2 or 3? (or a number, or 0)

   2. Seasonality — do we have any seasonality needs for this sprint?
      (run dates, a season to lean into, a promo window, or "none")

   3. Visual benchmarks — any ads you want this set to look like, or ads the
      client rejected, that aren't already in brand/benchmarks/?
      (drop files there, paste links, or "none — set the benchmark from the
      first review round")
   ```

   Plus, only when unresolved: `people_policy`, and any explicit restriction you could not source.

   **Concept count:** the number the strategist gives is the production set per bucket. It is a
   ceiling, not a quota — a concept you cannot defend is cut, not padded (see Quality bar). If
   they want more or fewer later, they will say so; do not propose a different number unprompted.

   **Seasonality** is the timing input for the concepts. Use the answer to time seasonal concepts
   correctly, decide whether a seasonal concept earns a slot at all, and flag any concept whose
   relevance expires. If the answer is "none," build evergreen and say so — do not invent a season.
   Stamp the sprint label or window into the handoff block.

   **Benchmarks:** if none exist and none are supplied, record `benchmarks: none — establish from
   round 1` in the handoff block. The first client review then becomes the benchmark set: approved
   ads go to `benchmarks/approved/`, rejected ones to `benchmarks/rejected/`, each with a one-line
   note on what to keep or avoid. Step 5 maintains this.

---

## Step 2 — Discovery and reconciliation

1. **Crawl the primary URL** and every entry in `sources`. Catalog:
   - The official logo and where it lives
   - Every usable real photo — people, owner/founder, storefront, crew, product and service
     shots, finished projects, lifestyle, trust and financing badges — with its URL and a note
     on what it shows
   - Colors (sample actual hex values), typography, and overall look
   - Real proof points: years in business, licensing, certifications, review counts, warranties,
     financing, service area — **only what is stated on the site**
2. **Inventory the client's local assets.** Read what is actually in `<client_dir>/assets/` — the
   `website/`, `social/`, `client/`, `generated/`, and `unsorted/` subfolders, plus any files left
   in place. These are real files the designer can use; treat them as the primary asset pool and
   the website images as the fallback. **Every client-provided asset is approved for use in ads,
   people in it or not** — the client gave it to us for exactly that. Never mark a client photo
   "not approved," "consent needed," or "restricted" because it shows a person. The only thing to
   note about a real person in a client photo is what an ad may *claim* about them: a real
   customer presented as a reviewer still needs a real quote, and a staff member is not called a
   customer. If access was declined or no device is connected, build Section 6 from the website
   alone and flag that the local inventory was not read.
3. **Read each local photo for what it can carry — and what it needs.** For every usable real
   photo note: subject, subject distance (tight / mid / environmental), which side has quiet
   space, whether it contains an isolatable product or material, whether it shows a real staff
   member or real work, whether it crops to 4:5 and 9:16, and **its condition** — lighting,
   sharpness, perspective, clutter, resolution. Existence is not suitability: a poorly lit phone
   photo of the right subject is a candidate for enhancement, not for use as-is, and Section 7's
   asset plans depend on knowing which is which.
4. **Do outside research when the category rewards it.** Regulations, standards, certifications,
   traditions, or technical facts that govern what the client sells (what may legally be called
   Neapolitan pizza; what a roofing warranty actually covers; what a certification requires) are
   creative substance. Use them as material for visual ideas and proof, sourced and labeled, not
   just the client's own website.
5. **Harvest explicit restrictions.** From the brand standards file, transcripts, Slack, and past
   feedback, list every "never" and "always" the client or strategist has stated about visuals,
   tone, claims, people, or treatments — each with its source, date, and scope (`campaign` or
   `brand`). These are mandatory and survive every other change in this skill. A one-off dislike
   of a single render is not a restriction; see the scope rule in Step 1.
6. **Reconcile the inputs.** The `.md` file wins on facts. The live site wins on current visuals
   and branding. **Flag every conflict explicitly** rather than picking silently — and then
   **resolve each one in Section 4** with a status, so Step 3 never has to reconcile them itself.
7. **Never invent** pricing, warranties, guarantees, financing, discounts, certifications, awards,
   partnerships, years of experience, reviews, testimonials, or service areas. If it cannot be
   verified, label it a **recommendation** and use a placeholder: `[Service Area]`,
   `[Project Type]`, `[Customer Story]`, `[Offer]`.

---

## Step 2.5 — Confirm the buckets before writing concepts

**Stop here.** A wrong bucket costs a full set of wasted concepts, and the strategist knows the
client's real service mix and what the client will approve better than the website does. Propose,
then wait.

Derive the buckets from the client's **real service menu**, ranked most cold-traffic-friendly,
high-frequency, and easy-to-explain first. Aim for the strongest **5 to 8**. Map each to the Drive
Social audience tier it fits (Primary, Secondary/AI, Secondary/Human-Made, Dynamic Reach) per the
Account Context below.

### First, map the full service menu

Before proposing anything, list **every service or product line the client actually sells**, from
the website and from the project transcripts. Then show which ones the proposed buckets cover and
which they do not. The common failure is splitting one part of the business into several buckets
while a whole revenue line goes unrepresented.

```
Service menu found (site + meetings):
  ✓ covered   Full-home window replacement
  ✓ covered   Storm & impact windows
  ✓ covered   Patio & sliding doors
  ✗ not covered  Entry & front doors      - owner mentioned this in the 7/14 call
  ✗ not covered  Commercial glass
  ✗ not covered  Repair & glass replacement
```

**Balance rules when forming buckets:**

- **One service line, one bucket** — do not split a single service into two or three buckets
  unless it genuinely sells as distinct jobs to distinct buyers at distinct price points.
- **No area should dominate.** If three of seven buckets are variations on the same service,
  collapse them and use the freed slots on uncovered service lines.
- **A service the owner named in a meeting outranks one the website merely lists.** Say which
  call it came from.
- **Hero-product businesses:** when one product defines the client (a pizzeria, a single-service
  studio), every bucket is about that product from a different side — the equipment behind it,
  the standard governing it, how it should be consumed, the room it is served in. Side categories
  support inside buckets; they never become buckets of their own.
- **Restaurants and experience businesses:** service-line buckets do not apply. Bucket by
  occasion and experience, with food and beverage combined inside each; the ads sell atmosphere,
  heritage, and the dining experience, not menu items alone.
- **Multi-location clients with one shared menu** that are not promoted independently: no
  location-specific concepts; any concept that mentions a location names every location.
- If a service is deliberately left out — no assets, compliance friction, capacity limits, the
  owner said stop selling it — **say so explicitly with the reason** rather than letting it
  silently disappear.

### Then propose the slate

Print it compactly — one line per bucket, using the count the strategist gave in Step 1:

```
Proposed service buckets, ranked by cold-traffic priority:

  #  Bucket                        Audience tier        Why it ranks here
  1  Full-Home Window Replacement  Primary              highest ticket, clearest intent
  2  Storm & Impact Windows        Secondary / AI       seasonal urgency, strong local demand
  3  Patio & Sliding Doors         Secondary / Human    easy to explain, good photo coverage
  ...

That's <n> buckets × <count> = <total> production concepts, plus <reserve> reserve ideas per bucket.

  1. Build these
  2. Cut a bucket    - give me the numbers
  3. Add a bucket    - name the service (including anything from the not-covered list)
  4. Swap a bucket   - replace one of these with an uncovered service
  5. Merge or reorder
  6. Change the count - tell me the new number per bucket
```

Note anything that shaped the ranking, one line per bucket: a service the owner wants to grow or
stop, a capacity constraint, a seasonal window, thin asset coverage, compliance friction, an offer
already in play. **Where a transcript drove the ranking, say so.**

**Wait for an answer before writing a single concept.**

### Then, the asset mode gate — only when coverage is thin

After the slate is approved, check its buckets against the asset inventory. **If every approved
bucket is well covered by real assets in usable condition, skip this gate silently.** If any bucket
is thinly covered, covered only by photos that need substantial work, or not covered, ask:

```
Asset coverage is thin or weak for: <bucket names>.

1. Real photos are coming — I just haven't added them to the client folder yet.
   (I'll plan these buckets around real photos; drop them into assets/ before Codex runs.)
2. Work with what's there — enhance the existing photos (lighting, perspective,
   background cleanup, extension) and generate scenes where nothing usable exists.
3. This client has little or no usable photography — plan AI-generated imagery.
4. Mix — tell me bucket by bucket.
```

Record the answer as each bucket's **`asset_mode`** summary: `real`, `ai-assisted`, or
`ai-generated`. The mode is a summary only — **the operative decision is the per-concept asset plan
in Section 7**, which says exactly what stays real, what gets enhanced, and what gets generated for
each ad.

Then build exactly the approved slate — no additions, no quiet substitutions. The approved slate
becomes Section 2 of the package, the `buckets:` list in the handoff block, and the entire scope of
what Codex builds. **This is where the strategist controls what the client's ads are about**, so do
not treat the answer as advisory.

---

## Step 3 — Build the package

Output **one `.md` file** with these sections, in this order. Never leave a section blank —
where the input is thin, you are the creative director. Fill the gap with sound, on-brand
strategy and mark it as your recommendation.

### 1. How to use this guide
Short framing: who reads it, what it produces, and the division of ownership — this file
resolves message, copy, facts, restrictions, and the visual idea per concept; Step 3 owns
execution and is expected to develop the strongest composition it can within those bounds, then
reject its own weak renders before the strategist sees them.

### 2. Strategy at a glance
The core acquisition thesis, then the **ranked list of service buckets** as approved in Step 2.5.
If the strategist changed the slate, reflect their version and note in one line what changed.
Map each bucket to its Drive Social audience tier. Open with a short **Account intelligence**
note listing what came from meetings or Slack rather than the website, and which of those items
still need client confirmation before they can appear in an ad.

### 3. Brand foundation
- Positioning
- Tone of voice: voice principles, words-we-love, words-we-avoid, right-vs-wrong examples. Both
  tonal registers are available by default — informative and serious, and playful and funny —
  and a set normally uses both, unless the audience, the subject, or an approved direction calls
  for one (funeral care, a health-anxiety subject, a client-approved serious-only campaign). Say
  which applies. A client who rejected a humor-built brand identity has not banned humor as a
  tool.
- Look and feel
- Color and branding system: palette with hex values, typography guidance, logo use rules, and
  the **text-on-image rule** (one headline on the graphic; detail lives in the caption)
- **Visual vocabulary for ads** — three lists, kept separate:
  - **Suggested treatments** (optional creative direction): looks the brand file or the
    strategist recommends — described in plain terms (editorial, product-on-color, photo-led,
    big-type, review card, and so on). Step 3 may use, combine, or ignore these.
  - **Explicit restrictions** (mandatory, sourced): every treatment, tone, subject, or device the
    client or strategist has said never to use, with date, source, and scope (`campaign` or
    `brand`). Nothing in this list is ever suggested in a concept.
  - **Unspecified** (available for considered use): anything not in either list.

Derive all of it from the site and the input `.md`. Do not impose a generic agency look, and do
not treat the website's own styling as the ceiling for paid creative — a weak website supplies
identity and facts, not a limit on how good the ads can be.

### 4. Resolved production brief
The rules that actually govern this run, in one place, so Step 3 never reconciles sources itself.
Every line carries **one status**:

| Status | Meaning |
|---|---|
| `client-approved requirement` | The client said it, in writing or on a call — cite the source |
| `strategist-approved direction` | The strategist confirmed it in this run or in the account channel |
| `verified fact` | Stated on the site or in the brand standards file |
| `proposed recommendation` | Your call — **not approved**; Step 3 treats it as a suggestion |
| `unresolved question` | A conflict or gap that affects the creative and has no answer yet |

Cover, in this order: brand essentials (logo file and rules, palette, type voice); `people_policy`
and what people may and may not do in images; explicit restrictions (repeated from Section 3);
category compliance; **asset permissions** — client-provided assets are always usable (state
this as a `client-approved requirement`; it applies to photos of people too); what must remain
authentic and unchanged (real staff, real work, real product identity, the logo); what may be
enhanced; what may be generated;
**imagery approval requirements** — any standing rule that the strategist or client approves
generated or enhanced imagery separately before it is used in an ad (carry every such rule
forward; removing the old whole-campaign plate stage does not remove an approval the client asked
for); and the **visual benchmark set** — paths to approved and rejected examples with a one-line
note each on what to retain or avoid.

**Overrides name what they supersede.** When a client decision or a live-site fact overrides a
rule in Appendix A, write it as: `overrides Appendix A §7 "…quoted rule…"` — so the superseded
rule is identifiable and Step 3 does not apply both. Writing a recommendation into this brief does
not make it approved; the status column is the authority. Unresolved conflicts that affect the
creative stay visible here, never buried in a note.

### 5. Value propositions and CTAs by bucket
For each bucket:
- Core value prop
- Proof points (verified only)
- An **on-brand offer** — value-add, not a race to the bottom, unless the brand is genuinely a
  discount brand. Premium brands get complimentary consults and value-adds.
- An approved CTA set drawn **only from real Meta Ads Manager CTA options**: Learn More,
  Contact Us, Book Now, Get Quote, Call Now, Sign Up, Shop Now.

### 6. Photo and asset library
Two tables, a shot list, and a coverage verdict.

**Table 1 — local assets.** Every usable file found in `<client_dir>/assets/`, with its real
path relative to the client folder, what it shows, its condition (usable as-is / needs
enhancement — say what), usable crops, and which concepts it fits. Lead with these.

**Table 2 — website and social assets.** Usable images found during the crawl, with their real
URLs, condition, and where each fits. Note which are already downloaded into `assets/website/` or
`assets/social/` and which are not.

**Then a net-new shot list** covering what no existing asset and no sensible generation can fill —
typically the real proof: the actual owner, the actual crew, the actual finished job, the actual
tattoo. Keep it achievable with a phone and the client's own people, location, and work (see
Photo/Video defaults in the Account Context). If the logo does not exist as a real file in
`assets/`, it heads this list — **the logo is never generated or redrawn.**

**Coverage verdict.** State plainly which buckets are **well covered**, **thinly covered**, and
**not covered** by real assets in usable condition. That tells the strategist whether to gather
more before Codex runs.

### 7. The concepts
For every bucket: the **production set** at the strategist's count, then the **reserve**.

**Variety is a test of ideas, not layouts.** Each concept in a bucket must rest on a different
visual idea — a different thing the image communicates, proves, shows, or makes the viewer feel.
Two concepts that share a visual idea are one concept; cut one. Distinct layouts on the same idea
do not count as variety, and the same layout on two strong ideas is not a problem. Vary the angle
across the set (owner/provider-led, testimonial, education/how-it-works, carousel, offer,
lifestyle, problem-solution, seasonal, one-liner) as the source of ideas, not as a checklist to
fill. No quota of any format, treatment, or "no-photo" concept exists — a typography-led concept
earns its slot on the strength of its idea like any other.

Each **production concept** specifies:

| Field | Requirement |
|---|---|
| **ID** | `{bucket}.{n}` — e.g. `1.1` through `1.5` |
| **Status** | `build` (new package) — Step 5 may later set `preserve`, `revise`, `correct`, or `replaced` |
| **Format** | feed 4:5, story/reel 9:16, or carousel |
| **Angle** | one of the angles above |
| **Visual idea** | One or two sentences: what stops the scroll, and what the image communicates. "Photo plus headline" is a layout, not an idea. "The four decisions a sofa buyer makes, made tangible on the actual sofa's features" is an idea. |
| **Message–image relationship** | How the picture carries or proves the headline — demonstration, comparison, evidence, recognizable situation, emotional payoff, or a surprising juxtaposition. |
| **Why this client** | One line on why the idea fits this brand and not a generic competitor. |
| **On-image headline** | The words that appear on the graphic. Short. One headline only. |
| **Primary text** | The Meta caption field. Sparing emoji allowed where it reinforces the message. Never the word "vibes". |
| **Meta headline** | The Ads Manager headline field — **40 characters or fewer, always.** Print the count. Must not restate the on-image headline. |
| **Meta description** | The Ads Manager description field — **25 characters or fewer, always.** Print the count. |
| **CTA** | A real Meta Ads Manager option. |
| **Destination** | A *chosen* page, never an unexamined default. Usually the page matching the concept's content. The homepage is legitimate when it is the best match (brand-level concepts, homepage-as-conversion-page sites, thin sites) — add one short line saying why. |
| **Asset plan** | Four lines: **Keep real** (what must remain authentic and unchanged — named file, or "n/a"); **Enhance** (what may be improved and how — lighting, perspective, background cleanup, extension, recomposition — or "none"); **Generate** (the concept-specific scene or element to create, as a concrete photographic direction: subject, environment, distance, angle, light, grade — or "none"); **Must accomplish** (the visual improvement the finished image has to deliver for the idea to work). People in generated imagery follow `people_policy`; generated imagery never depicts branded proof — no client trucks, uniforms, signage, staff, "customers," before/afters, or awards. |
| **Suggested execution** *(optional, provisional)* | A layout, treatment, or type direction if you have a strong one, in plain terms and drawn from the suggested vocabulary — explicitly marked `provisional`. Step 3 may use it or find better. Omit when you do not have a real opinion; do not fill it to look complete. |
| **Compliance notes** | Anything from Section 4 that bears on this specific concept. |
| **Button candidate** | `yes` for direct-response concepts (offer, promo, seasonal, urgency, concrete next step), `no` for education, testimonial, and founder/trust concepts. Step 3 uses this when the strategist sets a button ratio at production time. |

Two rules the design agent depends on:
- Keep on-image text minimal. One headline. Detail goes in the caption.
- **Do not specify on-image CTA buttons.** Whether ads carry a clickable-style button on the
  artwork is a per-client, per-run decision the strategist makes in Codex at production time.
  Write every concept so it works either way.

The **reserve** per bucket (the count the strategist gave, default 2–3) is a short list of
alternate visual ideas held for the replacement round: ID `{bucket}.R{n}`, angle, visual idea,
message–image relationship, and asset plan only — no copy yet. Each reserve idea must be distinct
from every production concept in the bucket. Mark the list **`NOT AUTHORIZED FOR PRODUCTION`**;
Step 3 does not build reserves. They exist so a rejected concept can be replaced from a bench
instead of a fresh strategy run.

### 8. Production and rollout notes
Sizing, text density, category compliance, testing cadence, landing pages, offers, and tracking.
Call out compliance explicitly for regulated categories — med spa and dental (no before/after in
cold ads, no result guarantees, consent required for real patient images), roofing and HVAC
(licensing claims, financing disclosure), funeral care (tone). Note any concept whose relevance
expires with the season.

### 9. Concept index and build lists
Confirm the totals: `<n> buckets × <count> = <total>` production concepts and `<reserve>` reserve
ideas per bucket. Then print the four lists Step 3 reads:

```
build:    1.1 1.2 1.3 1.4 1.5 2.1 …      (render these)
preserve: —                              (approved; do not touch)
revise:   —                              (idea approved; new execution)
correct:  —                              (targeted fix only)
reserve:  1.R1 1.R2 2.R1 …               (not authorized for production)
```

On a new package, `build` holds everything and the other three are empty.

---

## Step 4 — Write the file and hand off

1. **Carry the handoff block forward** at the top of the output file, upgrading it to `v2`:
   ```yaml
   drive_social_handoff: v2
   stage: creative-strategy
   produced_by: claude /creative-strategy
   date: <today>
   round: 1
   ```
   Fill in `service_area` and `industry` if discovery resolved them. Carry `client_dir` through
   unchanged. Keep every v1 field you received; never drop a field.

2. **Add the run structure to the block:**
   ```yaml
   concepts_per_bucket: 5              # the strategist's number
   reserve_per_bucket: 2
   brand_tile: brand/Texas-Windows-Brand-Tile.png    # optional; omit if none
   brand_tile_status: approved         # approved | reference — only when brand_tile is set
   people_policy: generic-allowed      # generic-allowed | none — resolved, never assumed
   suggested_treatments: [editorial, product-on-color, photo-led, big-type]   # optional vocabulary
   restricted_treatments:              # mandatory, each with a source
     - { rule: "no before/after imagery", source: "client, 2026-08-02 call", scope: brand }
   benchmarks:
     approved: brand/benchmarks/approved/        # or "none — establish from round 1"
     rejected: brand/benchmarks/rejected/
   buckets:
     - id: 1
       name: Full-Home Window Replacement
       concepts: 5
       reserve: 2
       asset_mode: real                # real | ai-assisted | ai-generated (summary only)
   build: ["1.1", "1.2", "1.3", "1.4", "1.5", "2.1", "2.2", "2.3", "2.4", "2.5"]   # always quote IDs
   preserve: []
   revise: []
   correct: []
   ```
   If the input was a v3 file, carry `permitted_families` / `permitted_color_modes` through
   unchanged for traceability and add a comment: `# v3 vocabulary — suggested only, no quota`.

3. **Append the brand standards as Appendix A.** The output is a single self-contained file Codex
   can build from without a second attachment. After Section 9, add:

   ```
   ---

   # Appendix A — Brand Standards (original source, reproduced for traceability)

   Reproduced verbatim from `<original filename>`, produced <its date>. Section 4 above — the
   resolved production brief — governs this run and names every rule here that it supersedes.
   Where the two disagree, Section 4 wins. This appendix is the record of the original standards,
   not an active instruction set.
   ```

   Then reproduce the input brand standards document **in full and verbatim**, minus its own YAML
   handoff block. Do not summarize, condense, reorder, or "improve" it. If you disagreed with
   something in it, that belongs in Section 4 as an override with a status, not in edits to the
   appendix.

4. **Record the sources in the handoff block:**
   ```yaml
   brand_standards_source: Texas-Windows-Brand-Standards.md
   brand_standards_date: 2026-08-18
   project_context_used: true          # or false
   project_sources:                    # transcripts/summaries you actually relied on
     - 2026-07-14 Quarterly Review transcript
     - Discovery call summary
   ```

5. **Name the file** `<Client>-Creative-Package.md` — client name exactly as in the block.

6. **Save it** into `<client_dir>/brand/` so it sits alongside the brand standards file, and
   deliver it in chat so it can be attached straight into Codex. If access was declined or no
   device is connected, deliver it in chat and state the exact path to save it to.

7. **Close with a short handoff note** telling the user the exact next command:
   `$meta-ad-creative-generator` in Codex, attaching this one file. Then one sentence on what
   happens after the client reviews the ads: go live with what they approve; if they want some of
   this round's copy or artwork kept and only the rejected ads remade, `/creative-strategy replace`
   does that — otherwise a fresh `/creative-strategy` run at the next refresh is the normal path.

   If the brand standards file is ever revised after this package is built, the appendix goes
   stale — say so in the handoff note, and tell the user to re-run `/creative-strategy` rather
   than hand-editing the package.

---

## Step 5 — Replacement round (`/creative-strategy replace`) — optional

**When to use this.** The client has reviewed the rendered ads. Approved ads go live. For the
rejected ones the strategist has two choices, and both are fine:

- **Do nothing now** (the default). Launch the approved ads. Build an entirely new set with a
  fresh `/creative-strategy` run at the next creative refresh. If the client rejected 20 of 50,
  going live with 30 is a normal outcome, not a problem to fix.
- **Run this step** — only when the strategist wants to keep some of this round's ideas, copy, or
  artwork and remake just the rejected ads as new options for a follow-up with the client.

If the strategist runs this step without saying which they want, ask once, in these words or
close to them:

```
Quick check before I start: do you want to remake only the rejected ads and keep
the rest of this round as-is (that's what this step does), or would you rather go
live with what's approved and build a fresh set next refresh (no need for this step)?
```

This is not per-ad editing and not performance iteration — see the note at the end.

1. **Read the current package.** Use the `<Client>-Creative-Package.md` the strategist attached,
   or read it from `<client_dir>/brand/` if they did not attach it. Also read the Ad Index Codex
   wrote (`<Client>-Ad-Index.md`, in the client folder) — it maps every rendered file to its
   concept, so the strategist never has to look IDs up.

2. **Ask for the rejections in plain language.** One question:

   ```
   Which ads did the client reject, and what did they say about each one?

   Describe them any way that's easy — the filename, the headline on the ad,
   "the two testimonial ones," a screenshot name, or the concept number if you
   happen to have it. One per line is ideal. I'll match each one to the package
   and show you a table to confirm before I change anything.

   Example:
     sofa checklist ad — client said it looks like a form
     both testimonial ads — "feel fake"
     Pamaro_2.4_round1_4x5.png — wrong price
   ```

   If the strategist already gave this in their message, do not ask again.

3. **Match each rejection to a concept — and show your work.** Resolve every item to a concept ID
   using the Ad Index and the package: filename stem (`Client_2.3_round1_4x5.png` → `2.3`),
   on-image headline text, bucket plus angle ("the testimonial ones in the roofing bucket"), or an
   ID given directly. If one description could mean two concepts, list both with their headlines
   and ask which — never guess. If a description matches nothing, say so and ask for a filename.

4. **Archive before touching anything.** Copy the current package to
   `<client_dir>/brand/archive/<Client>-Creative-Package-round<n>.md` (the round it represents).
   This is the comparison baseline for the preservation check below.

5. **Propose a response for each rejected ad, then wait.** Print one table and ask the strategist
   to confirm or change any row before you write anything. The table shows what the strategist
   said, what you matched it to, and what you propose:

   ```
   What you said              Matched     Headline on the ad          Proposed    Why
   sofa checklist ad          2.3         Four decisions, one sofa    revise      idea is sound; the flat card is what failed
   both testimonial ads       1.4, 3.2    "Best decision we made" /   replace     client doesn't trust testimonial format at all
                                          "Worth every penny"
   Pamaro_2.4_round1_4x5.png  2.4         Fall floor-model sale       correct     price wrong; nothing else changes

   Reply "go" to proceed, or tell me which rows to change (e.g. "make 2.3 a replace").
   ```

   The three responses, in plain terms:

   | Client's reason sounds like | Response | What happens |
   |---|---|---|
   | "Wrong message" / "not us" / "don't like the idea" | **replace** | A new concept with a **new** visual idea — from the bucket's reserve first, else newly developed. ID `{bucket}.{n}R{round}` with `replaces: {old id}`. The old concept is marked `replaced` and stays in the file for the record. |
   | "Good idea, looks bad" / "layout is off" / "photo is weak" | **revise** | Same ID, status `revise`. The visual idea, copy, and asset plan are preserved verbatim; you add an **execution note** stating what failed and what the next execution must do differently. Codex rebuilds from the same idea. |
   | "Wrong price / word / logo / crop" | **correct** | Same ID, status `correct`, with the exact fix named. Nothing else about the concept changes. |

   A strong idea is not thrown away because its first render was poor — "Four decisions before
   buying a sofa" can survive while the flat checklist execution is replaced. When the client's
   reason is ambiguous, say which way you lean and why, and ask.

6. **Update the benchmark set.** Approved renders are the client's taste made visible: list them
   under `benchmarks.approved` with one line each on what to retain; rejected renders go under
   `benchmarks.rejected` with one line on what to avoid. If the benchmark was "establish from
   round 1," it now exists — say so.

7. **Edit the package with targeted changes only.** Never regenerate the whole file. Approved
   concepts get their **Status** line set to `preserve`; every other line of the concept — copy,
   asset plan, destination, everything — stays **byte-for-byte unchanged**, and the original
   artwork Codex rendered for them is never regenerated or overwritten. New replacement concepts
   are written in full with the Section 7 schema. Reserves that were promoted are removed from the
   reserve list; if a bucket's reserve is now empty and further rounds are likely, add fresh
   reserve ideas and say so. Update the handoff block: `round: <n+1>`, the `build` / `preserve` /
   `revise` / `correct` lists, `benchmarks`, and `date`. Section 9 is rewritten to match.

8. **Verify preservation mechanically.** Diff the edited package against the archived copy. Every
   `preserve` concept block must be identical apart from its Status line; every other change must
   be inside a replaced, revised, or corrected concept, the reserve, Section 9, or the handoff
   block. Report the diff summary in one or two lines (which IDs changed, which are identical). If
   the diff shows an unintended change, fix it before delivering.

9. **Save and hand off** the same way as Step 4: same filename, same folder, delivered in chat,
   with the next command — `$meta-ad-creative-generator` on this file builds only the `build`,
   `revise`, and `correct` lists and leaves `preserve` alone. Tell the strategist in one line which
   ads will be rebuilt and which are untouched, in plain words, not just IDs.

**Not the same as `run_mode: iterate`.** `iterate` is Step 3's mode for controlled variations of
ads that have *performance data* behind them — scaling winners. Replacement rounds happen before
or regardless of performance, on the client's approval alone. Do not mix the two: a concept that
is live and performing is never revised through this step unless the client asks.

---

## Quality bar

- **Every concept has a visual idea** that would survive being described to the client in one
  sentence. If the sentence is a layout description, the concept is not done.
- **No two concepts in a bucket share a visual idea.** Different layouts on the same idea count
  as one.
- **Every concept has an asset plan** with all four lines filled in. "Use the photo" is not a plan.
- **Cull before handoff.** The strategist's count is a ceiling. A concept you would not defend in
  a client meeting is cut, and the bucket ships short with a one-line note saying why — never
  padded to the number.
- **Copy is production-ready.** Every character count is printed next to the Meta headline and
  description; on-image headline, primary text, CTA, and destination need no follow-up question.
- **Every claim traces** to the site, the input file, or a cited source — or is labeled a
  recommendation.
- **Every rule in Section 4 has a status**, every override names what it supersedes, and no
  conflict that affects the creative is left unlabeled.
- **Explicit restrictions are honored** in every concept and every reserve idea.
- **Client-facing language stays plain.** Internal jargon (AB, MM, shell, finals) does not appear
  in anything the client reads.

---

# Account Context — Drive Social Media

Required context for this skill. Everything below is standing policy for client work.

## Who this serves

An **Account Strategist at Drive Social Media**, a performance marketing agency, managing a book
of **SMB client accounts**. Every request is *on behalf of a client*, not the agency itself.
Clients are local or regional lead-gen businesses — the conversion event is a form fill, a phone
call, or a booked appointment, never an ecommerce purchase or a SaaS trial.

Book of business skews: marine, dental, roofing, HVAC, funeral care, tattoo, home services,
med spa, flooring, pools, sunrooms, aluminum/outdoor living, restaurants, retail, fitness.

Most clients have few assets, and the assets they have are often not professionally shot. AI
enhancement and editing of client-provided photography is permitted; fully generated backdrops
and scenes are necessary at times. **Anything the client hands us is approved for ad use, people
included** — the client's photos are the best material we have, never a liability to flag. What an
ad presents as real — the owner, the crew, the work, the product, the logo — stays real.

## Meta ad copy rules (non-negotiable)

1. Headline and description must **not** restate the graphic text — they add something new.
2. Emojis allowed sparingly in primary text where they reinforce the message.
3. Copy must match brand voice and the graphic it pairs with.
4. CTAs must be **real Meta Ads Manager options**: Learn More, Contact Us, Book Now, Get Quote,
   Call Now, Sign Up, Shop Now.
5. **Headlines: 40 characters or fewer. Always.**
6. **Descriptions: 25 characters or fewer. Always.**
7. Every destination is chosen, not defaulted. Usually the page matching the ad's specific
   content; the homepage is fine when it is genuinely the best-matching or best-converting page —
   state the reason when used.
8. The word "vibes" never appears in ad copy.

Print the character count next to every headline and description.

## Standard Meta audience strategy

Apply by default unless told otherwise.

- **Primary Audiences** — highest priority. Consumers who already showed brand interest: website
  visitors last 180 days, email submitters, callers, online engagers, past purchasers. Structured
  as **Leads** campaigns.
- **Secondary Audiences** — likely to convert, not yet brand-aware. **AI Audiences** (Meta
  lookalikes from real customer lists) and **Human-Made / Interest-Based** stacks. Also **Leads**.
- **Dynamic Reach** — almost always **Reach** campaigns, not Leads.

## Photo/Video defaults

Default assumption unless told otherwise: the client will **not** use paid models and has **no
budget** for a shoot. Keep net-new shot lists achievable with a phone and the client's own
people, location, and work.

## Internal vocabulary

Sprint (production cycle), packet (client-facing Slides deck of concepts), AB/Ad Builder
(Marketing Milk's ad tool), shell (reusable AB template), finals (approved copy/graphics),
one-off (ad-hoc small campaign), Data Acq (lead-magnet campaign), disco, debrief, GBP,
P/V (Photo/Video dept), MM (Marketing Milk), SF (Salesforce).

Slack: `#ZC:<id>:<Client Name>` per-client channels, `#f-<client>-all` for franchise accounts,
`#account-strategists` for the AS team. Search the client's `#ZC:` channel first for account
context. Internal jargon must never appear in anything the client reads.

## Output conventions

Pipeline deliverables go into the client folder — `client_dir` in the handoff block — which the
strategist chose in Step 1 (Mac or Windows; any path). Nothing from this pipeline is written
anywhere else on the strategist's machine. Client-facing docs are Google Docs, packets are Google
Slides, data pulls Sheets.

## The handoff block

Every `.md` in this pipeline opens with YAML front matter carrying client context, so nothing is
re-typed between tools. Step 1 (Codex) emits `v1`; this skill upgrades it to `v2` and every later
file carries `v2`.

```yaml
---
drive_social_handoff: v2
client: Texas Windows
industry: replacement windows & doors
primary_url: https://texaswindows.com/
sources:
  - https://texaswindows.com/
  - https://www.facebook.com/texaswindows
service_area: Dallas–Fort Worth, TX
client_dir: ~/Clients/Texas Windows              # wherever the strategist keeps this client; Windows paths work too
brand_tile: brand/Texas-Windows-Brand-Tile.png     # optional
brand_tile_status: approved                         # approved | reference
people_policy: generic-allowed                      # generic-allowed | none
suggested_treatments: [editorial, product-on-color, photo-led, big-type]
restricted_treatments:
  - { rule: "no before/after imagery", source: "client, 2026-08-02 call", scope: brand }
benchmarks:
  approved: brand/benchmarks/approved/
  rejected: brand/benchmarks/rejected/
concepts_per_bucket: 5
reserve_per_bucket: 2
round: 1
cta_button_ratio: 25%
run_mode: explore
buckets:
  - id: 1
    name: Full-Home Window Replacement
    concepts: 5
    reserve: 2
    asset_mode: real
build: ["1.1", "1.2", "1.3", "1.4", "1.5"]
preserve: []
revise: []
correct: []
sprint: 2026-09
stage: creative-strategy
produced_by: claude /creative-strategy
date: 2026-09-11
brand_standards_source: Texas-Windows-Brand-Standards.md
brand_standards_date: 2026-08-18
project_context_used: true
project_sources:
  - 2026-07-14 Quarterly Review transcript
---
```

Field notes:

- `sources` — every URL used: main site, additional sites, Facebook, Instagram, GBP, Yelp,
  Meta Ad Library, review sites. Always a list.
- `client_dir` — the client's local folder, created in Step 1. Holds `brand/` (with
  `benchmarks/approved/`, `benchmarks/rejected/`, and `archive/`), `assets/` (`website/`,
  `social/`, `client/`, `generated/`, `unsorted/`), and `ads/`. The path may be Windows-style or
  POSIX-style — read it as given and never rewrite the separators.
- `brand_tile` / `brand_tile_status` — optional. A tile is a reference for Step 3; it never
  overrides the actual logo file, exact hex values, or written specifications.
- `people_policy` — required to be resolved before any concept or generation involves
  **AI-generated** people. **Defaults to propose when absent:** `generic-allowed` for most
  verticals; `none` for funeral care; med spa, dental, and health only on confirmation. Always
  confirm; never assume silently. It never restricts client-provided photos — those are approved
  for use, people or not.
- `suggested_treatments` — optional vocabulary. No quota, no authority.
- `restricted_treatments` — mandatory prohibitions, each with a source and a scope (`campaign` |
  `brand`). Survives every revision.
- `benchmarks` — approved and rejected examples Step 3 compares its renders against; or the
  literal `none — establish from round 1`.
- `concepts_per_bucket` / `reserve_per_bucket` — the strategist's numbers for this run, asked
  every time. Ceilings, not quotas.
- `round` — 1 for a new package; incremented by each replacement round.
- `cta_button_ratio` / `run_mode` — how many ads carry a clickable-style CTA button on the
  artwork, and whether the run is `explore` (new sprint) or `iterate` (controlled variations of
  ads with performance data). Both are set by the strategist in Step 3 at production time, **never
  decided here**; carry them through if present.
- `build` / `preserve` / `revise` / `correct` — the lists Step 3 acts on. **Always quote concept
  IDs in YAML** (`"1.10"`, `"1.2R2"`) — unquoted, `1.10` becomes the number 1.1 in most parsers.
  `build` renders new; `preserve` is untouchable; `revise` keeps the idea and re-executes;
  `correct` applies the named fix only. Reserves are never in any of these lists.
- `buckets` — the approved slate with per-bucket counts and the `asset_mode` summary.
- `brand_standards_source` / `brand_standards_date` — the file and date the Appendix A copy came
  from, so a stale appendix is detectable.
- Legacy v3 fields (`permitted_families`, `permitted_color_modes`) — carry through if received,
  read as suggested vocabulary only.

**Carry-forward rule:** copy the whole block into the file you write, updating `stage`,
`produced_by`, `date`, and `round`, and filling in anything discovery resolved. Never drop a field.
Never silently change `client` — if the name needs correcting, say so before writing.

If an input file has no handoff block, reconstruct what you can from its contents and ask only
for what you cannot infer.

---

*Author: Jeremy Howard — Drive Social Media creative pipeline. v4.3, 2026-09-11 (v4.2 + system-agnostic
paths for team use). v3 (2026-09-10) is archived as `creative-strategy-SKILL-v3-backup-2026-09-11.md`.*