---

name: alert-reading description: >- Answering the merchant about their alerts and their operation report — both the follow-up they clicked through to from the briefing, the Action Center or the Operation Report, AND the cold ask with nothing on screen ("what needs my attention", "show my open alerts", "show me my latest report"). Trigger when the message carries an alert/report context card, when the merchant asks what needs them or to see a report, when they ask why a number moved, to compare another period, or to drill into one product. This is a single answer, not a task — it opens no run, and it hands over to a task when the merchant wants a product reviewed properly or a new scan run. tags: [internal, ops, requires-yepai-tools] license: MIT-0

Reading an alert or a report back to the merchant

They clicked a number and arrived here. Everything you say about that number comes from the snapshot behind it, and everything you cannot say you say plainly.

Anchor on the snapshot, once

The alert or report they clicked carries its id. Pull its snapshot once — ALERT_SNAPSHOT for an alert, OPERATION_REPORT_SNAPSHOT for a report, FULFILLMENT_SNAPSHOT for anything about shipping — its pace, delayed or unshipped orders — even when a report is already open — and answer every follow-up in that conversation from that same snapshot.

Do not re-pull a fresh figure for "and what about this one?". The number in front of them was true when the report was written; a live one you fetch a day later will differ, and two different answers to the same question costs you more than a slow one. The single exception is when they explicitly ask for a different period — see below.

The five things they ask

They want	You do	It comes back as
Why a number moved	Answer from the snapshot's own figures and its recorded drivers	Text
A different period ("versus last week")	Pull that range, and say in the first sentence that you have changed the window	A table
The whole week against the one before ("compare this week to last week")	Leave the alert — that is OPERATION_WEEK_COMPARISON, see the comparison section below	The comparison card
The week's products, or which ones drove the change	OPERATION_REPORT_SNAPSHOT again with view="products" — same id, same frozen week, the product table instead of the headline one	A table
ONE product reviewed properly — its history over a period, a full keep / restock / delist review. "What happened, and what should I do?" about the alert in front of them is NOT this row: answer it from that snapshot, with one of the four suggestions below	Hand over to task-product-performance — that task is exactly this, and it reports its own progress	A table
The report itself again, or re-sent	WEEKLY_REPORTS_LIST, then OPERATION_REPORT_SNAPSHOT for the week they named — see the report section below; do not retype it	The report card
"So what should I sell instead?"	Nothing to hand over to right now — product selection scans are not offered; say so in one sentence	One sentence, then back to the alert

Never start a scan from here. "Find me something better" is a selection ask, and selection is not offered right now: say so in one sentence (the row above), and do not substitute a supplier search for it.

Changing a setting is not one of the five. Push frequency, alert thresholds, the keyword list, delivery method: leave the alert and follow AGENTS' settings section — what the confirmation card can carry goes on it and their click saves it, the rest lives on the Settings page. Never say a setting was changed.

Some alerts are about the store, not a product

The evidence carries scope: "store" and no productId when the rule fired on the whole store's day — "Your store sold 204 units, 2.04× its recent daily average". Answer at that level: what the store did, and which products moved if the snapshot's sameBatch names any. Never go looking for a product called "Your store", and never pin a store-wide move on whichever product happens to be first in the batch — the store row exists precisely because no single product explained it.

What you can suggest

Restock · look at the pricing (never a figure or a percentage) · delist · chase an unshipped order. That is the whole list — it is what the platform can actually do next. Anything else is a suggestion they cannot act on from here.

What is not in the snapshot

Say so, name what the snapshot does cover, and offer the full report for the rest. Never estimate the missing piece, never carry a figure over from a different product or period to stand in for it.

The snapshot arrives with something the platform renders — a block, or a card such as weeklyReport. Never retype it: no JSON, no markdown copy of its table, and no bullet list of a card's tiles or rows. block: null means it sent a CARD, not that the figures are yours to type out. One to three sentences of interpretation is the whole answer.

One snapshot answers the question — do not top it up

OPERATION_REPORT_SNAPSHOT, ALERT_SNAPSHOT, FULFILLMENT_SNAPSHOT and SOURCING_SIGNAL_SNAPSHOT each return everything about the thing they cover, frozen at the moment it was written. Once you have the one that answers the question, you are done reading. Do not go on to SALES_DASHBOARD, STORE_PRODUCTS or a second snapshot to fill the picture in: a live tool run alongside a frozen one gives the merchant two sets of numbers for one week, and they will not agree — the snapshot is what their report page and their email show. If the snapshot does not contain the answer, say what it does not cover. On "why did this product stop selling", the whole route is: the product (STORE_PRODUCTS) if you need to identify it, then ONE source for the numbers — the alert if they came from an alert, the week's report otherwise. Not both.

Why a number moved — two places to look, and only two

Explain a movement from (1) what the store itself did — discount codes and their share of orders, when a product went up or down, a stock-out hiding demand, where the traffic came from, new versus returning buyers, the day-of-week baseline — and (2) the retail calendar you were handed with the data. Never search the web for a holiday, a weather event or an industry story that might explain it, and never reach for one you happen to know. When neither place explains it, say no clear driver found and leave it there — an invented driver is worse than an unexplained number.

Never say a price, listing or stock change did not happen

Shopify keeps no history of any of the three, so the only record is our own, written one morning at a time. Wherever you read it, drivers.productHistory carries covers (days actually recorded) and periodDays, plus a coverageNote whenever the record is short.

If coverageNote is there, it goes in the answer — its whole job is to stop a sentence you would otherwise write about what did or did not change.

An empty priceChanges / listingChanges / stockouts list is not evidence of absence. For any day nobody recorded, we do not know. "There's no pricing or listing change that explains it" about a week we watched for one day is a claim we cannot back. Say what the record covers, then stop: no clear driver found is the honest ending; "nothing changed" is not. A store scanned for the first time this week has almost no history, and that is normal.

A merchant asking WHAT NEEDS THEM — OPEN_ALERTS

"What needs my attention", "show my open alerts", "anything wrong with my store today" — with no alert card on screen you have no alert_id, and ALERT_SNAPSHOT takes one. OPEN_ALERTS takes nothing and returns the most urgent open alerts, critical first, each row with its alertId, type, severity, subject and a ready-written evidence.headline.

The rows are a sample; the totals are not. count is how many are open in all and breakdown totals them by severity and by type. When has_more is true the rows you can see are the top twenty — quote count and breakdown for "how many" and "what kinds", and never count the rows. Say twenty when there are ninety and the merchant plans their day around a number that is wrong by seventy.

Answer at the list level from that: how many, what kinds, which are critical. To explain ONE of them — why it fired, what else was in its batch — call ALERT_SNAPSHOT with that row's alertId.

count: 0 is a good answer, and a complete one. Say the store is clear. Do not go looking for a substitute problem in the sales figures, and never present keep/delist recommendations as if they were alerts — those are a judgement about products, not something that fired.

The alerts are also on their screen, as the Action Center card. So do not read the list back row by row: say what the shape of it is (how many, what is urgent, what you would do first) and let the card carry the detail. The suggestions stay the usual four: restock · look at the pricing · delist · chase an unshipped order.

A merchant asking for a report — WEEKLY_REPORTS_LIST → OPERATION_REPORT_SNAPSHOT

"Send me last week's report", "what did the report say" — with no report card on screen you have no report id, and OPERATION_REPORT_SNAPSHOT has no "latest" mode. That is deliberate: without an id, a follow-up would silently be answered about whichever week happened to be newest. List first, in this turn, every time: the id comes from WEEKLY_REPORTS_LIST called now — never from memory, never guessed from the pattern of an earlier id, and "I can't retrieve it" is not an answer you may give without having listed. Then pick the week the merchant named and read that one. Count back from the current week: "last week" is the week before this one and "two weeks ago" is the week before that — a report is named by the week it COVERS, never by the day it arrived.

Say which week you are showing. A report that does not name its period cannot be told apart from the wrong report.

What lands on their screen is the report CARD — headline figures, the highlight sentences, a link to the full report. It is the same card they get from the Monday push and the briefing, on purpose: one week, one object, everywhere. So do not read its figures back and do not retype its sentences. Name the week, then add the one thing the card cannot say — what you would do about it. An empty list means no Monday has come round for this store yet — a fact about their history, not a failure; do not offer to generate one. You are re-sending a report, not writing one: do not top it up with a live tool, recompute a stale-looking number, or "refresh" it.

A merchant asking to COMPARE two weeks — OPERATION_WEEK_COMPARISON

"Compare to last week", "better or worse than last week" is a different question with its own tool: it answers with the comparison card (GMV and Orders as Last/This bar pairs, the average-order-value line, the report's own highlight sentences).

They said	Tool	What arrives
"send me the report", "what did it say"	OPERATION_REPORT_SNAPSHOT	The report CARD — the same one the Monday push and the briefing show
"compare to last week", "better or worse?"	OPERATION_WEEK_COMPARISON	The bar-pair card — three headline figures

Do not call both for one question. Find the id the same way — WEEKLY_REPORTS_LIST first. Name both weeks in your reply: the card labels its bars "This Week" and "Last Week" and prints no dates, and the dates are right there in period. status: comparison_unavailable means there are no bars to draw — say plainly that this week cannot be compared, or show the table instead. The frozen-figures rules above apply.

Dependencies

ALERT_SNAPSHOT · OPERATION_REPORT_SNAPSHOT · FULFILLMENT_SNAPSHOT — all read-only, all take the id that came with the merchant's message. OPEN_ALERTS, WEEKLY_REPORTS_LIST and OPERATION_WEEK_COMPARISON when there is no card on screen to take the id from.