---

Generated from tasks/product-performance/task.yaml by /task-authoring.

Do not edit here — edit the definition and regenerate.

name: task-product-performance description: >- Multi-step TASK — reviewing how one specific product has been selling and what to do about it. Enter when: the merchant asks how a specific product has been selling lately; the merchant asks whether to keep, restock, promote or delist a specific product; the merchant asks why one product's sales moved. Do NOT enter: a store-wide KPI, trend or dashboard question with no single product in view — answer it from the ecommerce-sales-dashboard skill, there is no task; they are deciding what to source or sell next — selection scans are not offered right now; say so; listing a new product — that happens in Product Management → Listing Hub, not in chat; say so; a bare reprice / restock / unlist instruction — that is one gated write, not a review; greetings or small talk; the message is about an alert — an alert card on screen or an alert id in the message — even when it names one product and asks why it moved or what to do; that is the alert-reading skill, answered from one ALERT_SNAPSHOT with no task. Read this skill's full body BEFORE your first action — it carries the node graph you must report progress against, one node at a time. kind: task task_name: "Product performance review" label_template: <productName> performance nodes:

• id: scope label: Confirming which product and period purpose: Hold exactly one product and one time window before pulling anything. advance_by: user expects:
  • one specific product, identified in the catalogue rather than by a guess
  • the period to look at — default to the last 30 days unless they say otherwise tools:
  • yepairag_operation__STORE_PRODUCTS next:
  • to: pull when: one catalogue product is identified and the period is settled
• id: pull label: Pulling your sales and stock purpose: Gather the real numbers this review will be built on. advance_by: agent tools:
  • yepairag_operation__SALES_DASHBOARD
  • yepairag_operation__STORE_PRODUCTS
  • yepairag_operation__MARGIN_ANALYZE next:
  • to: brief when: the product's sales figures and its current stock level are both in hand
  • to: scope when: the merchant switches the review to a different product or a different period
• id: brief label: Writing up what it means purpose: Say how the product did, why, and what you would do next. advance_by: agent tools: [] artifact: type: operation_report route: operation-hub next: [] tags: [internal, task, ops, requires-yepai-tools] license: MIT-0

---

Task — Product performance review

One product, one period, one write-up. If the merchant's question spans the whole store, this is not the task — answer it from ecommerce-sales-dashboard.

Flow

flowchart TD
  scope("Confirming which product and period") -->|"one catalogue product is identified and…"| pull
  pull["Pulling your sales and stock"] -->|"the product's sales figures and its cu…"| brief
  pull -.->|"the merchant switches the review to a…"| scope
  brief["Writing up what it means"]
  classDef terminal stroke-width:3px
  class brief terminal

Rounded = waiting on the merchant · square = you are working · bold border = terminal.

scope

Confirming which product and period — Hold exactly one product and one time window before pulling anything.

Never review a product the merchant only half-named. "the parka", "my best seller", "the winter one" is not an identification — resolve it against the catalogue with STORE_PRODUCTS first. That lookup comes before any question: you ask only when it came back with two or more products that could match, and the question names them. A review built on the wrong product reads as authoritative and is entirely wrong.

If they named a period, use it. If they did not, use the last 30 days and say so in the write-up — do not ask.

When they arrive here from an alert or a report they clicked through, that context already names the product and the window: take both from it instead of asking again.

This review only reads. Identifying a product is a catalogue lookup, so nothing in this task lists, reprices, restocks or unlists anything — acting on what the review says is a separate, gated write the merchant asks for afterwards.

pull

Pulling your sales and stock — Gather the real numbers this review will be built on.

SALES_DASHBOARD emits one view per call. For a product review you want view="recs" — it carries per-product cumulative and recent units plus a Keep / Watch / Delist reason, which is most of this review. Add view="kpi" only when the merchant asked about the store's overall shape too.

Stock level comes from the catalogue, not from the dashboard.

Quote the figures the tools returned, as they returned them — they are the same numbers the merchant sees on the report page, and a recomputed one is the number that disagrees.

Conversion rate does not exist — there is no GA4 or session data. Never estimate it, and never present a figure the tools did not return.

If they name a different product, or a different window, before the write-up lands, go back to scope and settle the new one there. A review covers one product over one period, so a switch re-scopes the run rather than widening this pull.

brief

Writing up what it means — Say how the product did, why, and what you would do next.

Lead with the answer, not the method: how it sold, whether that is up or down, and what you would do. Period-over-period swings inside ±20% are noise — say "flat", not "down 12%".

Every recommendation names the action the merchant can actually take — restock, reprice, promote, delist — and one reason from the numbers you just pulled.

Do not carry out the recommendation. Acting on it is a separate, gated write the merchant asks for after reading this.

How a task runs

This part is the same for every task; only the nodes differ.

1 — Entering the task. Report the first node before doing anything else. That report is what opens the run: it tells the backend a task has started and gives the merchant their first progress line.

2 — Entering each node. Report it the moment you enter, before doing that node's work. One report per node. A single turn usually passes through several nodes with no input from the merchant in between — reporting as you go is what lets them watch the work happen instead of staring at nothing until you finish. A node whose work is a single tool call still gets its report first.

3 — Reaching the end. A terminal node is one with no way out except back to itself. Reporting it completes the task — the backend works that out from the graph, so there is nothing extra for you to send.

4 — After completion. A completed task is not sealed. If the merchant later asks to change something, report the node that owns it again and the task is simply unfinished again. Never open a second task for a change to work you already did.

How to report

yepairag_task__REPORT_TASK_STEP
  task: "product-performance"
  node: "<the node you just entered>"

• Two fields, both read straight off the graph above. The step's label, its number, the total and whether the task just completed are filled in by the backend — you cannot get them wrong because you do not send them.
• The reply carries legal_next: the only nodes you may report next.
• ok: false means nothing was recorded and the run has not moved. Correct the node id and report again rather than carrying on as if it had been accepted.
• Never restate any of it to the merchant. It drives a progress bar they are already looking at.