Skip to content

The Agentic Operator · Claude Skill

Stop switching between Shopify and Klaviyo. Ask Claude once.

62 ready-to-run prompts. Reads your Shopify catalog and Klaviyo events at the same time. Returns decisions, segments, email copy, and ad briefs with a fixed output contract. Free.

Unsubscribe with one click.

Reads from

Shopify Klaviyo
Answers in
Claude Claude

What is a Claude Skill?

Three things to know before you install it.

01 · What it is

A bundle of markdown.

A .skill file is a ZIP archive containing a SKILL.md and reference files. Not code. Not a plugin. No dev setup, no API keys, no config.

02 · How it works

Install once. Ask in plain language.

After install, Claude reads your intent, matches it to a named prompt inside the Skill, fills the variables, and runs. You do not paste prompts.

03 · Why it matters

Fixed output contracts.

Every one of the 62 prompts ships with an output contract. Two operators running the same prompt get the same shape of answer, so results stay predictable across your team.

Install in 3 steps.

From email to first prompt in about 90 seconds.

Step 1

Get the .skill file.

Drop your email at the top of this page. The .skill file arrives in your inbox within 60 seconds, attached to a delivery email from noreply@getatomz.com. Save the attachment to disk. You are also added to the weekly issue list — unsubscribe with one click.

Inbox · noreply@getatomz.com

Your skill: The Agentic Operator

The Agentic Operator is attached to this email as a .skill file. 62 production prompts for running a Shopify store on its own data.

📎 the-agentic-operator.skill · 33 KB

Step 2 · In Claude.ai

Upload the .skill file.

Open Claude.ai → Settings → Customize → Skills → Add → Upload a skill. Drop the .skill file in the upload zone. The skill is available in every new conversation immediately.

Works on Claude Free, Pro, and Team. Team and Enterprise admins can install it once for everyone.

Claude.ai Settings menu with Skills under Customize highlighted
Settings → Customize → Skills
Claude.ai Skills tab open with Upload skill button visible
Add → Upload a skill
Upload dialog with the-agentic-operator.skill file selected
Upload skill

Step 3 · In Claude Code

Unzip into your skills directory.

Claude Code reads skills from ~/.claude/skills/. Unzip the .skill file directly into that directory so the SKILL.md sits at ~/.claude/skills/the-agentic-operator/SKILL.md. Restart Claude Code. The skill loads on every session.

Terminal · zsh
$ unzip ~/Downloads/the-agentic-operator.skill -d ~/.claude/skills/
Archive:  the-agentic-operator.skill
   creating: the-agentic-operator/
  inflating: the-agentic-operator/SKILL.md
  inflating: the-agentic-operator/references/00-command-index.md
  inflating: the-agentic-operator/references/01-catalog-taxonomy.md
  ... 8 more reference files

$ ls ~/.claude/skills/the-agentic-operator/
SKILL.md    references/

How it works in practice

Type it like a shell. It maps you to the right prompt.

You do not memorize 62 prompt names. Type help to see the menu, ask in plain language, or ask something ambiguous and it suggests the closest match.

You type: help
Welcome to The Agentic Operator, maintained by Ankit Minocha.
Connect Shopify and Klaviyo, ask in plain language, get a decision back.
62 prompts across 9 domains. Say any of them and I will run the matching one.

01  Catalog & Taxonomy        (12)    try: "catalog completeness scorecard"
02  PDP & Content             (5)     try: "human-vs-agent page teardown"
03  Scoring & Segmentation    (6)     try: "full-base predictive scorecard"
04  Retention & Lifecycle     (7)     try: "winback wave planner"
05  Email & Flows             (10)    try: "campaign brief from a segment"
06  Acquisition & Ads         (7)     try: "lookalike seed builder"
07  Analytics & Reporting     (3)     try: "weekly store scorecard"
08  Merchandising, Collectio  (6)     try: "collection gap and overlap audit"
09  Agent Readiness & Audits  (6)     try: "full-store agent-readiness scorecard"

To see every prompt in a domain, say "list 03".
You type: what's broken in my catalog
That does not map to a prompt yet.
Did you mean:

- "catalog completeness scorecard"
  01, one number for how agent-ready your catalog is

- "attribute gap finder"
  01, buyer-facing attributes missing, ranked by impact

- "agent readiness scorecard"
  09, one score for how legible your store is to agents

Say one of those, or "help" for the full menu.

Every prompt in the skill

All 62 prompts, ready to copy.

Every prompt below is what runs inside the skill when you say it in plain language. You can also copy any prompt and paste it into a plain Claude conversation without installing the skill. Every one ships with a fixed output contract.

62/62

Domain 01 · 12 prompts

Catalog & Taxonomy

An agent can only match a product it can read, so these prompts find the gaps in your product data, fill them, and map the catalog to a taxonomy an agent understands.

01.1

Catalog completeness scorecard

#
When to use
You want one number for how agent-ready the whole catalog is, plus where the holes are.
Inputs
{{store}}, {{required_attributes}} (default: title, description over 40 words, product type, vendor, at least 3 tags, price, at least 1 image, at least 5 structured attributes/metafields).
The prompt
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.

Output contract

  • Line 1: Catalog completeness: XX.X% across {{N}} products
  • Table A Field fill rates: columns Field | Filled | Total | Fill rate %, sorted by fill rate ascending (worst field first).
  • Table B Lowest 20 products: columns Product | Missing fields | Completeness %, sorted by completeness ascending, ties broken by product title A→Z.
  • Close with the Data gaps line if any field could not be read.

01.2

Attribute gap finder

#
When to use
You know products are thin but want the specific attributes to add, ranked by impact.
Inputs
{{store}}, {{category}} (optional, default all), {{buyer_attributes}} (the attributes a shopper or agent filters on, e.g. size, material, skin type, concern, active ingredient, use case, fit, flavor).
The prompt
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.

Output contract

  • Table Attribute gaps: columns Attribute | Products missing | Fill rate % | Priority, sorted by number missing descending, ties by attribute name A→Z.
  • Priority is High if fill rate under 40%, Medium if 40–75%, Low if over 75%.
  • Line at end: Top fix: populate <attribute> on <N> products.

01.3

Structured payload rewrite

#
When to use
A product reads like marketing copy and you want the agent-legible version alongside it.
Inputs
{{product}} (title or ID), {{attribute_schema}} (the fields to extract, default: category, core function, key ingredients/materials, target use, target buyer, size/format, differentiators, exclusions).
The prompt
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.

Output contract

  • Section Marketing copy: the current text, verbatim, quoted.
  • Section Structured payload: a fenced code block of key: value lines, one attribute per line, in schema order.
  • Any absent value written as key: needs-input.
  • No commentary between or after the two sections.

01.4

Taxonomy mapper

#
When to use
Your product types are a mess and you want them mapped to a clean, consistent taxonomy.
Inputs
{{store}}, {{target_taxonomy}} (default: Shopify Standard Product Taxonomy; can be Google Product Category or a custom tree).
The prompt
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.

Output contract

  • Table Taxonomy map: columns Product | Current type | Mapped path | Confidence, sorted by confidence ascending (least certain first).
  • Confidence is High, Medium, or Low.
  • Section Needs review: bullet groups of products sharing the same ambiguity, each group headed by the reason.
  • Line: Mapped with High confidence: N of {{total}}.

01.5

Variant and option normalizer

#
When to use
Sizes, colors, and options are spelled five different ways and an agent can't group them.
Inputs
{{store}}, {{option_dimensions}} (default: size, color, material, flavor, pack count).
The prompt
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.

Output contract

  • Table Normalization map: columns Dimension | Canonical value | Raw variants collapsing in | Products affected, sorted by products affected descending.
  • Line: Total variant values reduced: from X raw to Y canonical.

01.6

Duplicate and near-duplicate finder

#
When to use
You suspect the same product exists under multiple listings, splitting reviews and inventory.
Inputs
{{store}}, {{match_basis}} (default: title similarity, shared images, matching SKU root, near-identical description).
The prompt
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.

Output contract

  • Section per duplicate group headed Group N: columns Product | Orders | Reviews | Completeness % | Keep as canonical?.
  • One product per group marked Yes under keep, the rest Merge.
  • Line at end: Suspected duplicate groups: N covering M products.

01.7

Missing product finder (unfindable audit)

#
When to use
You want to know which products no agent would ever surface, because unfindable is missing.
Inputs
{{store}}, {{findability_signals}} (default: has product type, 3+ tags, description over 40 words, at least 5 attributes, in at least one collection, has an image with alt text).
The prompt
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.

Output contract

  • Line 1: Unfindable (fails 3+ signals): N of {{total}} products.
  • Table Unfindable products: columns Product | Signals passed / total | Fastest fix, sorted by signals passed ascending, ties by title A→Z, capped at 30 rows.
  • Line: if more than 30, Plus M more below the cap.

01.8

Feed readiness check

#
When to use
Before syndicating the catalog to Google, Meta, or an agent marketplace.
Inputs
{{store}}, {{feed_spec}} (default: Google Merchant Center required + recommended fields).
The prompt
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.

Output contract

  • Section Hard failures (block feed): table Field | Products missing | % of catalog, sorted by products missing descending.
  • Section Soft gaps (lower match quality): same columns and sort.
  • Line: Products feed-ready today: N of {{total}}.

01.9

Category assignment coverage

#
When to use
You want to know which products carry a taxonomy category and which are uncategorized, since an uncategorized product cannot be reached by category browse or by an agent navigating the tree.
Inputs
{{store}}, {{taxonomy}} (default: the platform's standard product taxonomy, e.g. Shopify Standard Product Taxonomy; can be Google Product Category or a custom tree).
The prompt
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.

Output contract

  • Line 1: Category assigned: N of {{total}} ({{XX.X}}%).
  • Table Uncategorized products: columns Product | Likely category, sorted by likely category then title A→Z.
  • Line: Uncategorized: N.

01.10

Category attribute (metafield) fill gap

#
When to use
Assignment is only half the job, and this measures whether the category-specific attributes each category defines are actually populated, since those are what agents filter on inside a category.
Inputs
{{store}}, {{taxonomy}}, {{placeholder_values}} (default: N/A, -, default, none, blank count as empty).
The prompt
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.

Output contract

  • Line 1: Category assigned: N ({{XX.X}}%). Assigned but zero attributes filled: M ({{YY.Y}}%).
  • Line 2: Average category attributes filled: Z.
  • Table By category: columns Category | Products | Avg attributes filled | % with zero filled, sorted by products descending (biggest category first).
  • Line: Fix first: <the category with the most products and the lowest fill>.
  • Add the Data gaps line if any category's attribute schema could not be read.

01.11

Category attribute fill order (per category)

#
When to use
You picked one category and want the exact attributes to fill, ranked by how many products miss each.
Inputs
{{store}}, {{category}}, {{taxonomy}}.
The prompt
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.

Output contract

  • Table Attribute fill order: columns Attribute | Products missing | Fill rate % | Priority, sorted by products missing descending, ties by attribute name A→Z.
  • Priority is High if fill rate under 40%, Medium if 40–75%, Low if over 75%.
  • Line: Start with: <attribute> (missing on N of M products).

01.12

Miscategorization detector

#
When to use
A wrong category offers the wrong attribute set, so the product can never be enriched correctly. This flags products whose category does not fit.
Inputs
{{store}}, {{taxonomy}}.
The prompt
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.

Output contract

  • Table Suspected miscategorization: columns Product | Current category | Better fit | Confidence, sorted by confidence descending (High → Low).
  • Confidence is High, Medium, or Low.
  • Line: Suspected miscategorizations: N of {{total}}.

Domain 02 · 5 prompts

PDP & Content

A product page gets read once by a person and once by an agent, and most pages are written for the first reader while ignoring the second, so these prompts make the page work for both.

02.1

Human-vs-agent page teardown

#
When to use
You want to show, for one page, exactly what a shopper sees versus what an agent can extract.
Inputs
{{product_url}}.
The prompt
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.

Output contract

  • Section What a human reads: 4–7 short lines, one thought per line.
  • Section What an agent extracts: a fenced key: value block of only the facts stated plainly enough to parse.
  • Section Gaps (human infers, agent cannot): bullet list, each line naming the missing fact and why it matters for matching.
  • Close: one line distilling the single biggest fix.

02.2

PDP structured content block

#
When to use
You want a drop-in structured block to add to a product page so agents stop guessing.
Inputs
{{product}}, {{attribute_schema}} (default: category, core function, key ingredients/materials, target use, target buyer, size/format, what it is not).
The prompt
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.

Output contract

  • A single fenced block of Label: value lines in schema order.
  • Values are fragments, not sentences. One fact per line.
  • Absent values as Label: needs-input.
  • Nothing before or after the block.

02.3

Description rewrite (mechanism-first)

#
When to use
A description is all vibe and no substance.
Inputs
{{product}}, {{length}} (default: 90–140 words).
The prompt
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.

Output contract

  • Section Rewritten description: the prose, within the word count.
  • Section Attributes surfaced: a fenced key: value block listing every concrete attribute the new copy now states.
  • Line: Word count: N.

02.4

Comparison table builder

#
When to use
Buyers and agents both need to tell your similar products apart.
Inputs
{{product_set}} (a collection or list), {{compare_on}} (default: the attributes that actually differ across the set).
The prompt
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.

Output contract

  • Table Comparison: first column Attribute, one column per product in the set.
  • Only rows where at least two products differ.
  • Missing cells written as MISSING.
  • Line: Dimensions dropped as identical: N. Dimensions broken by a gap: M.

02.5

Buying-intent keyword coverage

#
When to use
You want to know which real buyer queries your page can and cannot answer.
Inputs
{{product}}, {{query_set}} (default: infer the top intent queries for this product's category).
The prompt
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.

Output contract

  • Table Query coverage: columns Query | Coverage | Missing fact to add, sorted Covered last so gaps surface first (Missing, then Partial, then Covered).
  • Line: Queries fully covered: N of M.

Domain 03 · 6 prompts

Scoring & Segmentation

Instead of drawing named lists by hand, you score every customer and attach one decision to each threshold, because a segment is really a threshold on a live score rather than a folder someone made back in 2020.

03.1

Full-base predictive scorecard

#
When to use
The foundation. Score every customer before doing anything else.
Inputs
{{esp}} (Klaviyo or equivalent), {{fields}} (default: churn probability, predicted CLV, historic CLV, historic order count, average days between orders, expected date of next order).
The prompt
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.

Output contract

  • Line 1: Sample: N of ~{{total}} profiles if capped, else Full base: N profiles.
  • Table Customer scores: columns Email | Orders | Historic CLV | Predicted CLV | Churn prob | Avg gap (days) | Next order due, sorted by predicted CLV descending, capped at 50 rows with Plus M more line.
  • Section Distribution: churn probability bucketed into 0–0.2, 0.2–0.4, 0.4–0.6, 0.6–0.8, 0.8–1.0 with a count each.

03.2

Churn-risk ranked list

#
When to use
You want the people about to leave, ranked by what they are worth.
Inputs
{{esp}}, {{churn_floor}} (default 0.6), {{min_orders}} (default 2).
The prompt
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.

Output contract

  • Line 1: Assumed: churn_floor = {{churn_floor}}, min_orders = {{min_orders}} (only if defaults used).
  • Table Churn risk, ranked: columns Email | Orders | Predicted CLV | Churn prob | Value at stake | Days overdue, sorted by value at stake descending, ties by days overdue descending.
  • Line: Total value at stake in this list: {{currency}}X across N customers.

03.3

VIP-at-risk break-glass list

#
When to use
Your best customers are slipping and deserve a human, not a batch send.
Inputs
{{esp}}, {{clv_floor}} (default 300 in store currency), {{churn_floor}} (default 0.7).
The prompt
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.

Output contract

  • Table VIP at risk: columns Name | Email | Historic CLV | Churn prob | Top product | Last order date | Days since, sorted by historic CLV descending.
  • No aggregation, no batching language. This list is meant to be actioned one row at a time.
  • Line: VIPs at risk: N. Combined historic CLV: {{currency}}X.

03.4

Replenishment cadence per customer

#
When to use
For consumables, timing beats messaging. Find each buyer's personal reorder clock.
Inputs
{{esp}}, {{lead_days}} (default 3, how many days before predicted empty to nudge).
The prompt
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.

Output contract

  • Table Replenishment clock: columns Email | Top product | Avg gap | Days since last | Due in (days) | Nudge date | Status, sorted by Due-in ascending (most overdue first).
  • Status is Overdue, Due soon (nudge within 7 days), or On track.
  • Line: Overdue now: N. Due to nudge in next 7 days: M.

03.5

Segment audit (find the dead relics)

#
When to use
Your ESP is full of old segments no one uses.
Inputs
{{esp}}, {{stale_before}} (default: last edited before 2 years ago).
The prompt
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.

Output contract

  • Table Segment audit: columns Segment | Members | Last edited | Used by active flow/campaign? | Verdict, sorted by Verdict (Archive first), then members ascending.
  • Verdict is Archive, Review, or Keep.
  • Line: Archive candidates: N of M segments.

03.6

Decision-first segment builder

#
When to use
You have an action in mind and want the segment defined by that action, not by a name.
Inputs
{{action}} (e.g. "send a 15% winback"), {{constraint}} (e.g. budget, margin floor), {{esp}}.
The prompt
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.

Output contract

  • Section Segment rule: a fenced block of the exact filter logic.
  • Line Estimated size: N customers.
  • Line Success metric: <metric>, measured against a holdout.
  • No narrative beyond these.

Domain 04 · 7 prompts

Retention & Lifecycle

Scores tell you who is at risk, and these prompts tell you what to do about it and how to prove the action worked, since every send here carries a holdout and a program that shows no incremental lift does not earn its place.

04.1

Winback wave planner

#
When to use
You have a churn-risk list and want a sequenced winback, not a single blast.
Inputs
{{risk_list}} (from Scoring prompt 2), {{waves}} (default 3), {{offer_ceiling}} (default: escalate 0% → 10% → 15%).
The prompt
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.

Output contract

  • Table Wave plan: columns Wave | Day | Trigger to advance | Offer | Recipients | Message angle.
  • Section Value gating: which CLV band gets the ceiling offer and which does not.
  • Line: Recipients receiving max discount: N of M (only those worth it).

04.2

Cadence-break trigger design

#
When to use
You want an always-on flow that catches a repeat buyer the moment they slip.
Inputs
{{esp}}, {{trip_multiple}} (default 1.5x personal average gap).
The prompt
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.

Output contract

  • Section Flow spec: Trigger, Entry filter, Wait/branch logic, Message(s), Exit condition, Suppression: each named and defined.
  • Section Why it works: 2–3 lines on why per-customer cadence beats a fixed window.
  • Line: Estimated monthly entrants: N (or needs base data if not computable).

04.3

Holdout test setup

#
When to use
Before any retention send, so you can prove it caused the revenue.
Inputs
{{target_list}}, {{holdout_pct}} (default 10), {{measure_window}} (default 30 days).
The prompt
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.

Output contract

  • Section Design: Target size, Holdout size, Treatment, Measure window, Primary metric (lift), Guardrail metric.
  • Section Read-out template: a table Group | Customers | Repurchase rate | Revenue/customer with treated and control rows and a Lift row.
  • Line: Decision rule: keep the program if lift exceeds <threshold> and is not explained by chance.

04.4

Dying-vs-dead split

#
When to use
So you stop spending sends on customers who are never coming back.
Inputs
{{esp}}, {{recoverable_ceiling}} (default: overdue under 200 days).
The prompt
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.

Output contract

  • Table Split: columns Group | Customers | Historic CLV at stake | Recommended treatment, recoverable row first.
  • Line: Recoverable revenue: {{currency}}X. Effectively lost: {{currency}}Y.

04.5

Reactivation offer ladder

#
When to use
You want the right incentive per lapse depth, not one discount for everyone.
Inputs
{{esp}}, {{margin_floor}} (the discount you cannot cross).
The prompt
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.

Output contract

  • Table Offer ladder: columns Rung | Audience rule | Offer | Expected response, softest offer first.
  • Line: Rungs that stay above margin floor: all (or flag any that do not).

04.6

Post-purchase onboarding sequence

#
When to use
First-order buyers churn fastest; this is where you convert them to repeat.
Inputs
{{product_category}}, {{sequence_len}} (default 4 emails over 3 weeks).
The prompt
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.

Output contract

  • Table Sequence: columns Email | Day | Goal | Core message | CTA.
  • Line: Second-order trigger lands on day N, timed to <reason>.

04.7

Loyalty and reorder incentive model

#
When to use
You want a repeat-purchase incentive that pays for itself.
Inputs
{{aov}}, {{repeat_rate}}, {{margin}}.
The prompt
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.

Output contract

  • Table Incentive options: columns Structure | Cost per order | Repeat lift needed to break even | Expected return.
  • Line: Recommended: <structure>. Depends most on: <assumption>.

Domain 05 · 10 prompts

Email & Flows

The message is where the work reaches the customer, so these prompts write the copy and design the flows, always tied to a score or a moment rather than blasted to everyone.

05.1

Campaign brief from a segment

#
When to use
You have a segment and need a tight brief before writing anything.
Inputs
{{segment}}, {{goal}} (default: drive next order), {{constraint}} (offer or margin limits).
The prompt
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.

Output contract

  • Section Brief: labeled lines Audience, Job, Offer, Angle, CTA, Success metric.
  • Line: One-line thesis: <the send in a sentence>.

05.2

Winback email copy

#
When to use
You need the actual email for a lapsed cohort.
Inputs
{{cohort_desc}}, {{top_product}}, {{offer}} (optional).
The prompt
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.

Output contract

  • Section Subject and Preview (one line each).
  • Section Body: the email, formatted with line breaks, one thought per line.
  • Section CTA: the button text.
  • Nothing after the CTA.

05.3

Replenishment nudge copy

#
When to use
A consumable buyer is near empty and you want the timed reminder.
Inputs
{{product}}, {{days_to_empty}}.
The prompt
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.

Output contract

  • Subject, Preview, Body (short, line-broken), CTA.
  • Line: Send timing: <days_to_empty minus lead> days after last order.

05.4

Flow architecture map

#
When to use
You want to see every lifecycle flow that should exist and which you're missing.
Inputs
{{esp}}.
The prompt
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.

Output contract

  • Table Flow coverage: columns Flow | Exists? | Trigger | Revenue moment it protects | Priority, sorted by Priority (missing high-value flows first).
  • Line: Flows missing: N. Highest-value gap: <flow>.

05.5

Abandoned-checkout recovery

#
When to use
You want a recovery sequence that recovers margin, not just orders.
Inputs
{{esp}}, {{steps}} (default 3), {{discount_policy}} (default: no discount until step 3).
The prompt
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.

Output contract

  • Table Recovery flow: columns Step | Delay | Angle | Offer | Exit.
  • Line: First discount appears at step N, by design.

05.6

Subject-line and preview matrix

#
When to use
You want testable variants across distinct angles, not ten rewordings of one idea.
Inputs
{{campaign}}, {{variants}} (default 5).
The prompt
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.

Output contract

  • Table Subject matrix: columns # | Angle | Subject | Preview | Chars.
  • Line: Recommended first test: # vs # (most different angles).

05.7

Send-time and cadence plan

#
When to use
You want a sending calendar that respects fatigue.
Inputs
{{esp}}, {{list_health}} (engagement tiers if available).
The prompt
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.

Output contract

  • Table Cadence by tier: columns Engagement tier | Sends/week | Best window | Notes.
  • Line: Frequency cap: N sends per profile per week.

05.8

Campaign performance readout

#
When to use
After a send, you want the read in a fixed shape every time.
Inputs
{{campaign}}, {{esp}}, {{benchmark}} (default: account trailing average).
The prompt
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.

Output contract

  • Table Results: columns Metric | This campaign | Benchmark | Delta.
  • Line (if holdout): Incremental lift vs control: XX.X%.
  • Line: Driver: <the metric that explains the result>.

05.9

Universal content block library

#
When to use
You want reusable, on-brand modules so every email isn't built from scratch.
Inputs
{{brand_voice}}, {{blocks}} (default: hero, product card, reorder CTA, review quote, footer).
The prompt
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.

Output contract

  • Section per block, headed by block name, containing the copy with {{placeholders}} marked.
  • Line: Blocks delivered: N.

05.10

SMS companion copy

#
When to use
You want the SMS version of an email moment, not a copy-paste.
Inputs
{{moment}} (winback, replenishment, drop), {{char_limit}} (default 160).
The prompt
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.

Output contract

  • Line SMS: <the message with {link} placeholder>
  • Line Chars: N / {{char_limit}}.

Domain 06 · 7 prompts

Acquisition & Ads

Acquisition gets cheaper when the audience comes from real store data and the copy states the mechanism, and these prompts build both the audience and the copy.

06.1

Lookalike seed builder

#
When to use
You want the highest-quality seed audience to build lookalikes from, not just all buyers.
Inputs
{{esp}} or {{shopify}}, {{seed_basis}} (default: top 10% by predicted CLV who bought in last 180 days).
The prompt
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.

Output contract

  • Section Seed definition: the exact rule, as a fenced block.
  • Section Seed profile: 4–6 lines describing the shared traits (top products, AOV, cadence, geography).
  • Line: Seed size: N. Median predicted CLV: {{currency}}X.

06.2

Meta ad copy set

#
When to use
You need scroll-stopping primary text and headlines grounded in real product facts.
Inputs
{{product}}, {{audience}}, {{variants}} (default 4).
The prompt
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.

Output contract

  • Table Meta variants: columns # | Angle | Primary text | Headline | Description.
  • Line: Sharpest test pair: # vs #.

06.3

Google search ad set

#
When to use
You want responsive search ad assets that cover intent, not repeat it.
Inputs
{{product}}, {{keywords}} (target intent), {{headlines}} (default 12), {{descriptions}} (default 4).
The prompt
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.

Output contract

  • Table Headlines: columns # | Headline | Chars | Intent covered.
  • Table Descriptions: columns # | Description | Chars.
  • Line: Distinct intents covered: N.

06.4

TikTok hook set

#
When to use
You want first-3-second hooks that fit the platform.
Inputs
{{product}}, {{hooks}} (default 6).
The prompt
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.

Output contract

  • Table Hooks: columns # | Format | Hook (spoken line) | Next beat.
  • Line: Strongest opener: #.

06.5

Audience-to-angle matcher

#
When to use
You have several audiences and want the right message for each.
Inputs
{{audiences}} (list), {{product}}.
The prompt
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.

Output contract

  • Table Audience map: columns Audience | Core motivation | Angle | Lead proof | Objection to preempt.
  • Line: Highest-intent audience: <name>.

06.6

Landing-page message match

#
When to use
Your ad and your landing page say different things and it's costing conversion.
Inputs
{{ad_copy}}, {{landing_url}}.
The prompt
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.

Output contract

  • Line 1: Message match: Strong / Partial / Weak.
  • Table Mismatches: columns Ad promise | Page delivers? | Fix, gaps first.
  • Line: Fastest conversion fix: <the top mismatch>.

06.7

Creative brief from best sellers

#
When to use
You want new creative grounded in what already sells.
Inputs
{{shopify}}, {{top_n}} (default 10 best sellers).
The prompt
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.

Output contract

  • Section Best-seller pattern: 4–6 lines on the shared traits.
  • Section Creative brief: labeled lines Feature, Angle, Proof, Audience, Format.
  • Line: Pattern confidence: High/Medium/Low based on how consistent the top sellers are.

Domain 07 · 3 prompts

Analytics & Reporting

Numbers are only useful when they point at a decision, so these prompts return a fixed shape every time and a weekly report reads the same from one week to the next.

07.1

Weekly store scorecard

#
When to use
The standing weekly read, identical shape every week.
Inputs
{{shopify}}, {{week}} (default: last complete week), {{compare}} (default: prior week and same week last year).
The prompt
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.

Output contract

  • Table Scorecard: columns Metric | {{week}} | vs prior wk | vs last yr, fixed metric order as listed in the prompt.
  • Line: Movement of the week: <metric> <direction>, likely because <cause>.
  • Any missing metric shown as MISSING, not skipped.

07.2

Product performance ranking

#
When to use
You want winners, losers, and the ones quietly carrying margin.
Inputs
{{shopify}}, {{window}} (default trailing 90 days), {{rank_by}} (default: revenue, then units, then margin if available).
The prompt
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.

Output contract

  • Table Top 15: columns Product | Revenue | Units | Margin (if avail) | Trend vs prior.
  • Table Bottom 15: same columns.
  • Section Margin flags: high-revenue-low-margin and low-revenue-high-margin lists.

07.3

Anomaly scan

#
When to use
A fast weekly scan for anything breaking or spiking.
Inputs
{{shopify}}, {{sensitivity}} (default: flag moves over 2 standard deviations from trailing 8-week norm).
The prompt
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.

Output contract

  • Table Anomalies: columns Signal | Change | Magnitude (σ) | First thing to check, sorted by magnitude descending.
  • Line: Anomalies flagged: N. Most urgent: <signal>.

Domain 08 · 6 prompts

Merchandising, Collections & Pricing

Where products sit, how they group, and what they cost are all signals an agent reads, and these prompts make those decisions deliberate rather than accidental.

08.1

Collection gap and overlap audit

#
When to use
Collections have drifted; some products live everywhere, some nowhere.
Inputs
{{shopify}}.
The prompt
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.

Output contract

  • Section Orphans: table Product | Recommended collection.
  • Section Over-collected: table Product | Collections count | Keep in.
  • Section Overlaps: table Collection A | Collection B | Shared % | Action.
  • Line: Products in no collection: N.

08.2

Smart collection rule builder

#
When to use
You want automated collections driven by attributes, not manual curation.
Inputs
{{theme}} (e.g. "under $30 gifts", "sensitive skin"), {{shopify}}.
The prompt
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.

Output contract

  • Section Rule: fenced block of conditions (all/any, each condition explicit).
  • Line: Qualifying today: N products.
  • Section Near-misses: table Product | Missing condition (products one attribute away).

08.3

Pricing ladder review

#
When to use
You want to see whether your price tiers make sense across a category.
Inputs
{{category}}, {{shopify}}.
The prompt
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.

Output contract

  • Table Price ladder: columns Product | Price | Tier (good/better/best) | Note, sorted by price ascending.
  • Section Findings: gaps, clusters, inversions as labeled bullets.
  • Line: Missing tier: <band>.

08.4

Discount code strategy

#
When to use
You want a coherent discount structure, not ad-hoc codes.
Inputs
{{goals}} (e.g. new-customer, winback, AOV lift), {{margin_floor}}.
The prompt
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.

Output contract

  • Table Discount structure: columns Goal | Code type | Value | Audience | Guardrail.
  • Line: Codes that stay above margin floor: all (or flag exceptions).

08.5

Homepage and merchandising order

#
When to use
You want your merchandising order driven by performance, not habit.
Inputs
{{shopify}}, {{surface}} (homepage, collection page), {{objective}} (default: revenue per view).
The prompt
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.

Output contract

  • Table Merchandising order: columns Position | Product/Collection | Reason | Inventory OK?, in recommended order.
  • Line: New products given a test slot: N.

08.6

Margin-aware promotion planner

#
When to use
You want a promo calendar that protects margin across the quarter.
Inputs
{{quarter}}, {{moments}} (holidays, drops, seasons relevant to the brand), {{margin_floor}}.
The prompt
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.

Output contract

  • Table Promo calendar: columns Date/moment | Offer | Featured products | Audience | Margin/volume trade, in date order.
  • Line: Full-price weeks preserved this quarter: N.

Domain 09 · 6 prompts

Agent Readiness & Audits

This is the whole-store view, asking how legible the business is to an AI agent shopping on a customer's behalf, and these prompts produce the scorecards you act on and hand to a client.

09.1

Full-store agent-readiness scorecard

#
When to use
The headline number: how ready is the whole store for agentic shopping.
Inputs
{{store}}, {{dimensions}} (default: catalog completeness, attribute depth, taxonomy consistency, PDP legibility, structured data/schema, search/filter coverage, feed readiness, image labeling).
The prompt
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.

Output contract

  • Line 1: Agent readiness: XX / 100.
  • Line 2: Weighting: <dimension: weight, ...>.
  • Table Dimension scores: columns Dimension | Score /100 | Reason | Highest-impact fix, sorted by score ascending (weakest first).
  • Line: Fix first: <the lowest weighted-impact dimension>.

09.2

Structured data and schema audit

#
When to use
You want to know whether machine-readable markup is present and correct.
Inputs
{{store}} or {{product_url}}, {{schema_types}} (default: Product, Offer, AggregateRating, BreadcrumbList).
The prompt
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.

Output contract

  • Section Present: schema types found with completeness %.
  • Section Missing required properties: table Schema | Property | Impact.
  • Section Contradictions: table Field | Markup says | Page says.
  • Line: Schema health: Good / Partial / Poor.

09.3

Search and filter coverage audit

#
When to use
An agent navigates by filters; missing facets make products unreachable.
Inputs
{{store}}, {{expected_facets}} (default: the filters buyers in this category expect: price, size, color, material, use case, concern, rating).
The prompt
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.

Output contract

  • Table Facet coverage: columns Facet | Exists? | Products with attribute | Coverage % | Priority, sorted by priority.
  • Line: Facets missing or broken: N. Highest-reach fix: <facet>.

09.4

Prioritized remediation roadmap

#
When to use
You have audit findings and need the ordered plan to fix them.
Inputs
{{findings}} (from any audit above), {{capacity}} (default: rank by impact over effort).
The prompt
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.

Output contract

  • Table Roadmap: columns Fix | Impact | Effort | Depends on | Bucket, sorted Now → Next → Later, high impact first within each.
  • Line: Start today: <the top Now item>.

09.5

Before/after readiness diff

#
When to use
After remediation, to prove the store got more legible.
Inputs
{{store}}, {{baseline_scorecard}} (a prior run of prompt 1).
The prompt
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.

Output contract

  • Table Readiness diff: columns Dimension | Before | After | Change, sorted by change descending.
  • Line: Overall: XX → YY (+/- Z).
  • Line: Still lagging: <dimension>.

09.6

Client-ready audit summary

#
When to use
You want the audit packaged for a merchant who is not technical.
Inputs
{{store}}, {{scorecard}} and {{roadmap}} from earlier prompts.
The prompt
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.

Output contract

  • Section The number: readiness score and one plain-language sentence on what it costs them.
  • Section Three biggest opportunities: each a short paragraph in revenue terms.
  • Section The plan: Now, Next, Later as short lists.
  • Final line: one sentence distilling the stakes. No sign-off, no question.

Operating principles

Four rules the skill enforces on every prompt.

Think before running.

If a request is ambiguous, the skill names the interpretations and asks one question rather than guessing. Every assumption and default is stated at the top of the answer.

Keep it minimal.

Answers return the least that answers the question. No preamble, no invented metrics, no flourish. When an answer starts growing complicated, that is a signal to cut rather than to add.

Change surgically.

All 62 prompts read from Shopify or Klaviyo and return analysis by default. Writes require a separate explicit instruction plus a shown plan. Never bulk-write silently.

Work to a verifiable outcome.

Every prompt ships with an output contract that describes what a correct answer looks like. Two operators running the same prompt get the same shape of answer.

Ready?

Send me the skill.

Unsubscribe with one click.