Stop switching between Shopify and Klaviyo. Ask Claude once.

For {{store}}, score catalog completeness across all products. For each product, check whether it has each of these required fields populated with a real value: {{required_attributes}}. A field stuffed with a placeholder ("N/A", "-", "default") counts as missing. Produce a per-field fill rate across the catalog and an overall completeness score (average fill rate across all fields). Then list the 20 products with the lowest completeness, worst first.

For {{store}} in category {{category}}, identify the buyer-facing attributes that agents and shoppers filter on but that are missing from product data. Compare each product against this attribute set: {{buyer_attributes}}. For each attribute, report how many products are missing it. Rank attributes by number of products missing it times how often that attribute is used to filter, so the gap that would move the most products sits first. Each filled attribute is one more match point, so treat fill rate as revenue work rather than housekeeping.

Take the product {{product}} from the store. Read its current description. Produce two things side by side: the marketing copy as it stands, and a structured payload an agent can parse, using this schema: {{attribute_schema}}. The payload should be flat key-value pairs, machine-readable, no prose. Where the current copy implies a value without stating it, extract it. Where a value is genuinely absent, mark it needs-input. Show the contrast so it is obvious how differently a human and an agent read the same page.

For {{store}}, map every product's current product type and tags to {{target_taxonomy}}. For each product, output its current type, the mapped category path, and a confidence level. Flag products where the current type is blank, ambiguous, or maps to more than one branch. Group the flags so I can fix the taxonomy in batches rather than one product at a time.

For {{store}}, audit variant option names and values across {{option_dimensions}}. Find inconsistencies: the same value written differently (e.g. "L", "Large", "lg"), option names that vary product to product, and values in the wrong dimension. Propose one canonical form per value and show every raw form that should collapse into it.

For {{store}}, find duplicate and near-duplicate products using {{match_basis}}. Group suspected duplicates together, show why they matched, and recommend which listing to keep as canonical based on which has the most orders, reviews, and complete data. Do not recommend deletion, only consolidation candidates.

For {{store}}, run an unfindable audit. A product is unfindable if it fails enough of these signals that an AI shopping agent could not confidently match it to a query: {{findability_signals}}. Score each product on how many signals it passes. List the products most likely to be invisible to agents, worst first, and name the single fastest fix for each.

For {{store}}, check every product against {{feed_spec}}. Report which required fields are missing (these block the feed) and which recommended fields are missing (these lower match quality). Separate hard failures from soft ones so I fix blockers first.

For {{store}}, check every product for a {{taxonomy}} category assignment. Report the share of products with a category and list the ones with none. An uncategorized product is invisible to category browse and to an agent that navigates by category, so treat a blank category as an unreachable product. Group the uncategorized by the category that likely fits so they can be fixed in batches rather than one at a time.

For {{store}}, measure the category attribute gap in two layers. Layer one: does each product have a {{taxonomy}} category assigned. Layer two: for each categorized product, how many of the attributes that category defines are populated with a real value, treating {{placeholder_values}} as empty. Report the share of categorized products with zero attributes filled, the average attributes filled per product, and a per-category breakdown so I can see where the emptiness concentrates. Category attributes are the fields an agent filters on inside a category, so an empty set means the product is a category match with nothing to confirm it. Do not confuse this with a raw metafield count. Only the attributes the assigned category actually defines count here.

For {{category}} in {{store}} under {{taxonomy}}, list every attribute that category defines. For each attribute, report how many products in that category leave it empty and its fill rate across the category. Rank by number of products missing it, so the attribute absent from the most products sits first. Each filled category attribute is one more way an agent can match this product to a query, so treat the fill order as a revenue queue rather than housekeeping.

For {{store}}, find products whose {{taxonomy}} category looks wrong given their title, product type, and description. For example a kitchen tool filed under a garden branch, or a physical product filed as a service. List each suspect with its current category and the category that actually fits. A wrong category is worse than no category, because it offers attributes that do not apply and hides the ones that do, so an agent reads the product through the wrong lens.

Take {{product_url}}. Read it the way a human does: what stands out, what the pitch is, what a person walks away knowing. Then read it the way an AI shopping agent does: what structured facts it can extract with confidence, and what it cannot determine because the page never states it plainly. List the gaps where a human infers something an agent cannot. State the mechanism, not the marketing.

For {{product}}, generate a structured content block to add near the top of the PDP, using {{attribute_schema}}. Output it as clean labeled pairs a shopper can skim and an agent can parse. Keep every value concrete and specific. If the product's current data does not support a value, mark it needs-input rather than inventing it.

Rewrite the description for {{product}} in {{length}}. Lead with the mechanism: what it is, what it does, who it is for, how it works. Every claim must map to a concrete attribute. Cut adjectives that do not carry a fact. Keep the brand's register but make it legible to an agent. Do not use em dashes. Do not use the words elevate, unlock, leverage, seamless, transform, holistic, robust, curate.

For {{product_set}}, build a comparison table across {{compare_on}}. Pick the dimensions that genuinely differentiate these products, drop the ones where they are all identical. The table should let a shopper or an agent choose between them on facts alone. Flag any dimension where a value is missing for one or more products, because a gap breaks the comparison.

For {{product}}, take the buyer queries in {{query_set}} (or infer the top ones for this category). For each query, decide whether the current page contains the fact an agent needs to confidently return this product as a match. Mark covered, partial, or missing. For every gap, name the exact attribute to add.

Pull every customer profile from {{esp}} that has predictive data. For each, return {{fields}}. Do not bucket into named segments yet. I want the raw scores on every customer as one table so I can set thresholds myself. If the API caps results, say so and report how many you pulled versus the estimated total.

From {{esp}}, find every repeat buyer with at least {{min_orders}} orders and churn probability at or above {{churn_floor}} whose expected next order date has already passed. Rank by value at stake, which is predicted CLV times churn probability. This is the list of who to spend retention budget on this week. Cut the ranking where the marginal customer is not worth a send.

From {{esp}}, list every customer with historic CLV above {{clv_floor}} and churn probability above {{churn_floor}}. These are high-value people about to leave. Give me names, not counts. Include what they buy and when they last ordered so someone can reach out personally.

For every repeat buyer in {{esp}}, calculate their personal reorder cadence: average days between orders and days since last order. Compute days-until-due as average gap minus days since last order. Flag anyone past their due date. Then compute the nudge date as due date minus {{lead_days}}. Do not use a store-wide window. Each customer has their own clock.

List every segment in {{esp}}. For each, return current member count, when it was last edited, and whether any active flow or campaign references it. Flag segments last edited before {{stale_before}} with zero current members or no active usage. These are archive candidates. Do not delete anything, just recommend.

I want to take this action: {{action}}, within this constraint: {{constraint}}. Define the segment purely by who that action should move, using scores from {{esp}}. State the exact rule (thresholds on churn, CLV, recency, order count). Estimate the size. Name the one metric this segment should move and how I would know it worked.

Take {{risk_list}}. Design a {{waves}}-wave winback over 3 weeks. Wave 1 is no discount, only a reminder tied to what they buy. Wave 2 introduces a soft offer. Wave 3 uses the ceiling offer for anyone still silent, capped at {{offer_ceiling}}. Segment recipients by value so the ceiling offer only goes to customers worth it. Escalate the offer, not the frequency.

Design a flow in {{esp}} that fires when a repeat buyer passes {{trip_multiple}} times their personal average days-between-orders with no new order. The trigger must read each customer's own cadence, not a store-wide window. Specify the entry condition, the wait logic, the message, the exit condition (they order), and a suppression so a customer cannot re-enter for 30 days. This is the moment to catch someone before churn, so timing is the whole design.

Take {{target_list}}. Randomly hold out {{holdout_pct}}% as a control that receives nothing. Send to the rest. Over {{measure_window}}, measure repurchase rate and revenue per customer for treated versus held-out. Define lift as treated minus control. Specify the exact numbers I need to capture and how to read whether the send actually caused incremental revenue rather than catching orders that would have happened anyway.

Split at-risk repeat buyers into recoverable (next order overdue by less than {{recoverable_ceiling}}) and long-gone (overdue well beyond it). For each group, total the historic CLV at stake so I know how much revenue is genuinely recoverable versus already lost. Recommend a different treatment for each: active winback for recoverable, low-cost annual reactivation or suppression for long-gone.

Build a reactivation offer ladder keyed to lapse depth and customer value, never crossing {{margin_floor}}. Recently lapsed high-value buyers get the softest nudge; deeply lapsed low-value buyers get either the maximum allowed offer or suppression. Show the rung, the audience rule, the offer, and the expected response tier for each.

Design a {{sequence_len}} post-purchase sequence for a first-time buyer of {{product_category}}. Goal is second order. Cover: how to use what they bought, what to expect, the natural next product or replenishment moment, and a reason to come back before their cadence would predict. Tie the timing to when the product is used up or the benefit lands.

Given AOV {{aov}}, repeat rate {{repeat_rate}}, and margin {{margin}}, model a reorder incentive (points, subscribe-and-save, or reorder discount). Show the breakeven: how much lift in repeat rate the incentive must produce to cover its cost. Recommend the structure with the best expected return and name the assumption it depends on most.

Write a one-screen campaign brief for {{segment}} with goal {{goal}} under {{constraint}}. Cover: who they are in one line, the single job of this send, the offer if any, the one message angle, the primary CTA, and the metric that judges success against a holdout. No fluff. The brief is the contract for the copy.

Write a winback email for {{cohort_desc}}. Center it on {{top_product}}, the thing they already buy. Give one concrete reason to come back now. If {{offer}} is set, include it once, plainly. Line breaks do the work. One thought per line. Mechanism, not marketing. No em dashes. Do not use elevate, unlock, leverage, seamless, transform, holistic, robust, curate. End on the one line that distills why now.

Write a replenishment nudge for a buyer of {{product}} who is about {{days_to_empty}} days from running out. Frame it around the product running low, not a generic promo. Make reordering one tap. Keep it short. The value is timing, so the copy should feel like a helpful reminder, not a campaign.

Map the full set of lifecycle flows a store should run: welcome, browse abandon, cart abandon, checkout abandon, post-purchase onboarding, replenishment/cadence-break, winback, VIP, sunset. For {{esp}}, mark which exist and which are missing. For each missing flow, state its trigger and the revenue moment it protects.

Design a {{steps}}-step checkout recovery flow in {{esp}} under {{discount_policy}}. Step 1 removes friction (reminder, reassurance, support). Step 2 adds urgency or social proof. Step 3 introduces an incentive only if still unconverted. Specify timing between steps and the exit condition. Do not lead with a discount, because it trains customers to abandon.

For {{campaign}}, write {{variants}} subject-line and preview-text pairs, each from a genuinely different angle: benefit, curiosity, urgency, social proof, plain-spoken. Not five rewordings of one idea. Keep subjects under 45 characters. No em dashes. Note which angle each represents so I can read the test.

Build a weekly send cadence for {{esp}} that segments by engagement: engaged get more, dormant get less, unengaged get a sunset path before suppression. Recommend send windows by tier. Specify a frequency cap per profile so a single customer never gets over-mailed. Protect deliverability by mailing engaged profiles more and dead weight less.

Pull results for {{campaign}} from {{esp}}. Report opens, clicks, conversion, revenue, revenue per recipient, and unsubscribe rate, each against {{benchmark}}. If a holdout was used, report lift versus control as the headline number. Call out the one metric that most explains the outcome.

Draft a library of reusable email content blocks for {{brand_voice}}: {{blocks}}. Each block is copy-only, on-brand, with placeholders for product, price, and image. Written so any campaign can drop them in. Keep the voice consistent across all blocks.

Write SMS copy for {{moment}} under {{char_limit}} characters including the link placeholder. SMS is not a shrunk email. One idea, one link, plain language, easy opt-out implied by compliance. Match the email's intent but earn the interruption.

From {{esp}} or {{shopify}}, build the best lookalike seed using {{seed_basis}}. Explain who is in it, why they are the strongest seed (value plus recency plus repeat behavior), and how large it is. Then describe the profile so ad platforms and I both understand what "more like this" means. Quality of seed beats size of seed.

Write {{variants}} Meta ad variants for {{product}} aimed at {{audience}}. Each: primary text, headline, description. Lead with the mechanism, the specific reason this product fits this audience. Different angle per variant (problem-first, proof-first, use-case, comparison). One thought per line in primary text. No em dashes. Avoid elevate, unlock, leverage, seamless, transform, holistic, robust, curate.

For {{product}} targeting {{keywords}}, write {{headlines}} headlines (under 30 chars each) and {{descriptions}} descriptions (under 90 chars each) for a responsive search ad. Cover distinct value points and intents, no near-duplicates. Include at least one with the exact query intent, one with price/offer if relevant, one with a differentiator. Plain, specific, benefit-carrying.

Write {{hooks}} TikTok hooks for {{product}}, each a spoken first line that stops the scroll in three seconds. Native to the platform, not repurposed TV. Mix formats: problem call-out, unexpected fact, before/after tease, POV, direct address. Follow each hook with a one-line beat on where the video goes next.

For {{product}}, map each audience in {{audiences}} to the message angle that fits it. Different buyers need different reasons. State, per audience, the core motivation, the angle that lands, the proof point to lead with, and the objection to preempt. Do not reuse the same angle across audiences.

Compare {{ad_copy}} against {{landing_url}}. Score message match: does the page deliver on the promise, keyword, and offer the ad made? List every mismatch where the ad sets an expectation the page does not immediately confirm. Recommend the specific page edit for each. Mismatch is wasted click spend.

Pull the {{top_n}} best sellers from {{shopify}}. Find what they share: attributes, price band, buyer, use case, the hook that likely drives them. Turn the pattern into a creative brief for the next round of ads: what to feature, which angle, which proof, which audience. Ground the brief in demonstrated demand, not taste.

Build the weekly scorecard for {{shopify}} for {{week}}, compared to {{compare}}. Report revenue, orders, AOV, conversion rate, new vs repeat revenue, sessions, and refund rate. For each, show the value and the change versus both comparison periods. End with the single most important movement of the week and the likely cause.

Rank products in {{shopify}} over {{window}} by {{rank_by}}. Show top and bottom performers. Flag products with high revenue but low margin, and low revenue but high margin, since both change what you promote. Note any product with a sharp trend versus the prior window.

Scan {{shopify}} for anomalies at {{sensitivity}}: sudden drops in conversion, spikes in refunds, products that stopped selling, traffic sources that vanished, AOV shifts. List each anomaly with its magnitude and the most likely explanation to check first. This is a smoke detector, so bias toward flagging.

Audit collections in {{shopify}}. Find products in no collection (invisible to browse and to agents navigating by category), products in too many (diluted), and collections that overlap so heavily they should merge. Recommend a home for every orphan and a merge or split for every problem collection.

Build a smart-collection rule for {{theme}} in {{shopify}} using product attributes, tags, price, and type. State the exact conditions. Estimate how many products qualify today and which near-misses would qualify if one attribute were added, since that reveals a data gap worth filling.

Review the pricing ladder for {{category}} in {{shopify}}. Lay out every product by price. Find gaps (a price band with no product), clusters (too many at one point), and inversions (a lesser product priced above a better one). Recommend where a good/better/best structure is missing and what would fill it.

Design a discount code structure for {{goals}}, never crossing {{margin_floor}}. For each goal, specify the code type (percentage, fixed, threshold, tiered), the value, the audience, and the guardrail (usage cap, expiry, exclusions). Keep the highest discounts reserved for the highest-value recovery only.

Recommend the merchandising order for {{surface}} in {{shopify}} to maximize {{objective}}. Rank products or collections by the objective, balanced against inventory depth (do not feature what you cannot fulfill) and newness (give new products a fair test slot). Show the recommended order and the reason each item earns its position.

Plan promotions for {{quarter}} around {{moments}}, never crossing {{margin_floor}}. For each moment, recommend the offer, the products to feature (favor high-margin and overstock), the audience, and the expected trade of margin for volume. Space promos so you are not always discounting, which erodes full-price demand.

Score {{store}} for agent readiness across {{dimensions}}. Rate each dimension 0–100 with a one-line reason and the single highest-impact fix. Compute a weighted overall readiness score. An agent can only sell what it can read, so weight legibility dimensions (attributes, structured data, taxonomy) most heavily. State the weighting you used.

Audit {{store}} (or {{product_url}}) for structured data across {{schema_types}}. Report which schema types are present, which required properties are missing, and where markup contradicts the visible content. Contradictions are worse than absence because they mislead the agent. Separate missing from broken.

For {{store}}, check on-site search and filter facets against {{expected_facets}}. Report which facets exist, which are missing, and which exist but are underpopulated (too many products lack the attribute for the filter to work). A filter that returns nothing is as bad as no filter. Prioritize facets by how many products they would make reachable.

Turn {{findings}} into a remediation roadmap ranked by {{capacity}}. For each fix, estimate impact (how much readiness or revenue it recovers), effort (low/medium/high), and sequence (what must come first, e.g. taxonomy before smart collections). Group into Now, Next, Later so I can start today.

Re-run the agent-readiness scorecard for {{store}} and diff it against {{baseline_scorecard}}. Show the change per dimension and the overall score delta. Call out what improved most, what still lags, and whether any dimension regressed. Progress is the point, so make the movement obvious.

Package the audit of {{store}} into a summary a busy merchant reads in two minutes. Open with the readiness score and what it means in plain terms (what they are losing to unreadable products). Then the three biggest opportunities in revenue language, not jargon. Then the roadmap as Now/Next/Later. Mechanism, not marketing. No em dashes. End on the one line that distills the stakes.

python scripts/pacer.py plan --growth {{growth}}

Set the season definition. Anchor on {{anchor_event}}, {{anchor_date_ty}} this year and {{anchor_date_ly}} last year, over a {{window_days}} day window ending on the anchor. Revenue goal {{rev_goal}}, spend goal {{spend_goal}}, gross margin {{gross_margin}}. Resolve the day of week for both anchor dates and report whether they match. Write season.md and confirm. Do not pull any data and do not analyse anything.

Load {{ly_daily}} and {{ty_daily}} against the season in season.md. Validate before accepting: missing dates inside the window, duplicate dates, blocks of three or more consecutive rows repeating an earlier block's values (a copy-paste placeholder), zero or null spend on a day with revenue, negative net sales, and coverage against the window. Report the defects. Do not repair anything and do not analyse the season.

Index both series by days to anchor, where k=0 is the anchor day and k=-30 is thirty days before it. For each k report the LY date and its day of week, the TY date and its day of week, revenue and spend and MER for both years, and revenue year over year. Do not interpret the result.

Read pace as of {{as_of}}. Compute cumulative revenue, cumulative spend, cumulative MER, and share of season delivered, this year and last year at the same k. This year's share divides cumulative revenue by rev_goal, because the season is not closed and its own total is not knowable yet. Last year's share divides cumulative revenue by last year's actual season total. Return the verdict, the four-row table, and one action. Nothing else.

Compute today's spend for {{as_of}}. Take remaining revenue goal, distribute it across the remaining days using last year's share of season curve rather than an even split, take today's implied revenue, and divide by {{mer_floor}} to get today's budget. Report the number, the curve plan for the same day, and what last year actually spent at the same k. Give one clause of reasoning. If channel mix is in state, split the number by planned mix.

Report MER as of {{as_of}}. Give daily MER and accrual MER for this year, the same two for last year at the same k, and the deltas. Then give the last {{trend_days}} daily MER values in order and state whether the trend is rising, flat, or decaying. If gross margin is set, add contribution MER. Do not recommend anything.

Compare the cumulative share of season delivered this year against last year at the same k, as of {{as_of}}. Report the delta in points. Identify the five days that contributed most to that delta, positive or negative. State in one sentence what the delta implies for the days still ahead, specifically whether the remaining days should be expected to read soft even if demand is healthy.

Compare channel spend mix as of {{as_of}} against mix_plan_ty and against mix_ly. Report every channel, sorted by absolute drift from plan, largest first. Flag any channel drifting more than {{threshold}} points from plan. Do not recommend a reallocation unless a channel breaches the threshold, and then give one line naming the dollars to move and where.

Project the season close as of {{as_of}} using {{method}}. Take cumulative actuals, project the remaining days on last year's share of season curve, and report landing revenue, landing spend, landing MER, and attainment against goal. Give a low and high band by applying the current pull-forward delta as the adjustment in both directions. Name the assumption in one line.

Rank every aligned day by MER. Show the best {{n}} and the worst {{n}}. For each, give the share of total season spend that day absorbed and the share of total season revenue it produced. Then close with the worst dollar in the season, which is a different question: rank days by share of spend minus share of revenue, in points, and name the day with the largest gap. A low MER day that absorbed two percent of budget matters less than a mid MER day that absorbed fourteen.

Find every run of {{min_days}} or more consecutive days where all three are true: cumulative share of season is behind last year at that k, daily MER is below the season median, and spend is up year over year. Report each run with its dates, total spend, average MER against the season median, and spend growth year over year. Give one line naming the dollars to cut or the day to move them to. If no run qualifies, say so in one line and stop.

Close the season. Report totals and year over year for revenue, spend, and MER, and attainment against both goals. Give the three findings that would change how the next season is run, each as one sentence carrying its own number. Name the day that earned the most per dollar and the day that earned the least. State one thing this read cannot see.

Build next season's daily curve from the closed season, blending this year and last year at {{blend}}. For each k report the share of season revenue and the share of season spend, indexed against the mean day so the peaks are readable at a glance. Name the days that hold more than five percent of season revenue. Output the curve as a CSV block that can be pasted into a pacing sheet.

Open {{store_url}} in a new tab. Pick an in-stock product from /products.json and run three checkout paths: product page, add to cart, cart drawer, Checkout; /cart with session storage cleared, Checkout; /cart again in the same session, Checkout. Record the landing host of each. PASS is the store's own domain with /checkouts/ or shop.app. After the clicks, check session storage for opaque one-time flags. Apply the incident tripwire on any FAIL. Do not enter any data on the checkout page.

Audit {{store_url}} under the shared rules for this domain.

1. Inventory. On the homepage, record Shopify.shop, theme name, role and schema; every external script as hostname plus path; unique hosts; app embed handles; integrity attributes; jQuery version.
2. Inline scripts. Flag eval, new Function, atob, fromCharCode, location.href, assign or replace, window.open, click or submit listeners. Attribute each flagged script.
3. App config. From performance entries, list fetch, XHR and beacon hosts. Replay one GET of each vendor config URL and record code-capable keys and any outside hosts.
4. Headers. CSP directives, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy.
5. Catalog sample. One product body and the page's hidden blocks.
6. Checkout. Run prompt 1.
7. Research only what is needed: vendor identity, incident status, CVEs.
8. Score every app with prompt 4 and assess the ten threat classes.

Close the tab when done. Publish as {{report_format}}.

Confirm the connected shop matches {{store_url}}, then run prompt 2 and add these Shopify reads, validating each query against the schema first:

1. Themes: the live theme, unpublished theme count, and every live theme file updated in the last {{window_days}} days or inside any attack window listed in references/incident-register.md.
2. config/settings_data.json: every app embed block with handle, enabled state and risky setting values.
3. Theme files: external script loads, checkout interception, navigation sinks, obfuscation, innerHTML fed by settings, hardcoded tokens.
4. URL redirects to outside domains or covering /cart, /checkout or /account.
5. Discounts created in the last {{window_days}} days at 50% or more, or with no usage limit.
6. Up to 250 recently updated products with metafields: script, iframe, hidden text or agent-directed text.

Score each app in {{apps}} from 0 to 15: runs code on cart or product pages +3; loads remote config or code +3; that config can carry HTML, JS or redirects +3 (CONFIRMED only if seen, otherwise NEEDS MANUAL CHECK and 0); vendor-confirmed incident in references/incident-register.md +3, unconfirmed report or same vendor +1; delisted today +1; not used for revenue per {{revenue_use}} +2. Delisting alone does not prove compromise, so say so where it applies. Group low-risk trackers into one row.

Write one email for {{vendors}} that the merchant at {{store_domain}} sends as themselves. Keep it short and factual. Ask the six standard questions, then add one line per vendor from {{specifics}} naming exactly what the audit saw.

Package {{audit}} for {{store}} into a page a busy founder reads in two minutes. Open with the verdict and what it means for card safety and the payment processor relationship. Then the three biggest risks in business terms, each with who fixes it and how long it takes. Then what is already in good shape. Mechanism, not marketing. No em dashes. End on the one line that distills the stakes.