Write playbooks that actually work

Every playbook is a prompt that gets re-used. A vague prompt produces a different answer every time; a specific one produces the same answer every time. For a morning briefing, a weekly report, or a client deliverable, same every time is the product.

The difference isn't length. A five-word playbook that names the exact tool and inputs beats a two-paragraph one that describes the goal. Your AI client always knows which tools exist — your job is to tell it which ones to use, and in what order.

Here's the same intent written two ways. Both ask for a store health check. Only one produces a playbook you can run every weekday and trust.

text
Create a playbook that helps me understand my store better

text
Create a playbook named "Daily Shopify Health Check" that:

1. Calls `shopify_get_orders` with created_at_min set to yesterday's date.
2. Calls `shopify_get_products` with limit=250.
3. Counts unfulfilled orders older than 48 hours from step 1.
4. Flags products with inventory < 5 from step 2.
5. Presents a markdown summary with two sections: "Orders at risk"
   and "Stock at risk", each as a table with SKU, name, and the
   relevant field.

Use inputs:
  - date (date, defaults to yesterday)
  - stock_threshold (number, default 5)

When you ask your AI client to create a playbook, give it all five of these. Missing any one makes the run fragile.

• Name. Short, descriptive, human-readable. Daily Shopify Health Check, Q4 Budget Pacing. Avoid Playbook v3 final-style filenames.
• Tools by name. Call out every tool explicitly — shopify_get_orders, ga4_run_report, gsc_find_quick_wins. Saying “check my store” works the first time and breaks on the second. Ask your AI client which tools are available; it knows.
• Steps, numbered.The order the engine should invoke them. If step 4 needs output from step 1, say so explicitly (“from step 1”).
• Inputs, typed. Parameters the caller can override at run time. List them as name (type, default). Supported types: string, number, boolean, date, string[].
• Output shape. Describe the markdown report literally — sections, tables, column headers. Optionally add a render scene (kpi-grid or callout) for the dashboard view.

A morning snapshot. One tool, one output, no branching. This is the playbook a merchant writes first and keeps forever.

text
Create a playbook named "Abandoned Cart Snapshot" that calls
`neto_get_cart` and returns a markdown table of the top 20 most
recently abandoned carts, sorted by cart value descending.

Input:
  - limit (number, default 20)

Why this works.It names the tool. It declares one input with a default. The output is a table — reading it doesn't require interpretation. If you paste this into Claude with ShopMCP connected, you get a new playbook in the dashboard you can run with one click.

Most real workflows combine two data sources. SEO “quick wins” from Search Console are only actionable if you know whether those pages also engage visitors — that's a join between GSC and GA4 on landing page URL.

text
Create a playbook named "Weekly SEO Quick Wins" that:

1. Calls `gsc_find_quick_wins` with startDate and endDate inputs.
   Return queries where position is 8-20 and impressions > 100.
2. For each returned query, also fetch the landing page URL from
   the same response.
3. Calls `ga4_run_report` for the same date range with:
   - metrics: sessions, engagementRate
   - dimensions: landingPagePlusQueryString
   - filter to the URLs from step 2.
4. Joins the GSC queries with GA4 engagement on URL, so the reader
   sees: query, current position, impressions, sessions, engagement
   rate — one row per page.
5. Presents as a markdown table, sorted by impressions descending.
6. Adds a short "what to do" note at the top recommending the
   reader pick the top 3 rows and refresh their on-page content.

Inputs:
  - startDate (date, required)
  - endDate (date, required)

What makes it reliable.The join key (landing page URL) is named. The sort order is named. The “what to do” note at the top is a named deliverable — not a judgement the LLM has to invent. Every run produces the same shape with different numbers.

A Monday briefing that pulls from five sources and renders a KPI grid plus a markdown report. Optional steps make it degrade gracefully on workspaces that haven't connected every integration — the cards for missing sources render as skipped instead of failing the run.

text
Create a playbook named "Monday Morning Brief" that assembles a
single report combining orders, ads, and search performance.
Optimise for readability over completeness — this runs every
Monday and should be scannable in under 60 seconds.

Steps:
  1. `shopify_get_orders` — created_at_min = 7 days ago. Required.
  2. `ga4_run_report` — last 7 days, metrics sessions and
     totalUsers, dimension sessionDefaultChannelGroup. Optional.
  3. `gsc_get_search_analytics` — last 7 days, dimensions query,
     rowLimit 10. Optional.
  4. `meta_ads_morning_dashboard` — optional.
  5. `google_ads_morning_dashboard` — optional.

Output a markdown report with sections in this exact order:
  - "Orders" — count + total revenue + top 5 products by units.
  - "Traffic" — table of channel to sessions.
  - "Top search queries" — list of 10 query strings with position.
  - "Ads — Meta" and "Ads — Google" — paste the tool text as-is.

Also render a kpi-grid above the report with four cards:
  - label "Orders", value = order count
  - label "Revenue", value = total revenue formatted as currency
  - label "Sessions", value = sessions from step 2
  - label "Ad spend", value = combined spend from steps 4+5

Inputs: none (defaults to last 7 days).

What to notice. Steps 2–5 are marked optional. The section order in the output is frozen — the reader sees the same layout every Monday, which is what makes it scannable in a minute. The kpi-grid is named directly so the dashboard renders the scene above the markdown report. Labels carry units (“Revenue”, “Ad spend”) so the card values don't need extra context.

• Did you nameevery tool? If the prompt says “pull my orders” without a tool name, reword it.
• Are the steps numbered? Bullet-list order is ambiguous; numbers aren't.
• Are the inputs typed? A date input with default: yesterday is safer than a string everyone has to remember to format.
• Did you describe the output literally? If you want a table, say “markdown table with columns X, Y, Z” — not “present the findings nicely”.
• Are optional steps marked optional? Without that flag, a missing integration fails the run instead of degrading gracefully.
• Would a new teammatereading the prompt produce the same playbook by hand? That's the specificity bar.

Everything above produces a reusable instruction packet for the user's AI client. Two habits keep it compounding.

• Iterate with shopmcp_update_playbook. Don't delete-and-recreate. Tell the AI client “update the Monday Morning Brief playbook to also include refund rate” — it patches the existing definition so the slug stays stable.
• Share a good playbook. Use workspace sharing or copy it into another workspace so a client or teammate can use the same AI-client instructions with their own connected tools.
• Save chats as playbooks. Any ad-hoc chat that ends with a useful result can be crystallised with“save this as a playbook called [name]”— your AI client calls shopmcp_save_chat_as_playbook with the tools and instructions it just used. The next person who wants the same result retrieves it by slug and lets their AI client continue.

• Browse the playbook library and read the source — every seed is a worked example of concrete prompts.
• Playbooks reference — JSON shape, input types, render scenes.
• Connect Claude Desktopif you haven't yet — creating playbooks from chat requires an AI client wired to your ShopMCP MCP URL.