---

Generated from tasks/promo-plan/task.yaml by /task-authoring.

Do not edit here — edit the definition and regenerate.

name: task-promo-plan description: >- Multi-step TASK — suggesting what to promote — data-grounded promotion directions shown as suggestions, with nothing created or scheduled. Enter when: the merchant asks what to run or how to promote — campaign ideas, a promotion or marketing plan or strategy for a period or an event ("how should I promote next month", "plan my Black Friday push"); the merchant asks to turn marketing advice you just gave into a concrete plan. Do NOT enter: a question asking for marketing advice or how traffic is doing, with nothing to produce — answer it directly (read marketing-advice); scheduling content for a period when the merchant already knows what to run (that is task-calendar-plan); a request for one specific article or post (that is task-content-publish); asking how something already published performed (that is a data question, answered with the performance card); greetings or small talk; setting up, auto-generating, calibrating, or re-scanning Brand IQ (that is task-brand-iq-setup). 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: "Promotion plan" label_template: "<period> promotion suggestions" tags: [internal, marketing, task] license: MIT-0 nodes:

• id: research label: "Reading your traffic and campaign data" purpose: "Assemble the evidence the plan stands on — the store traffic snapshot, ads figures when connected, content cognition verdicts, keyword candidates seeded from Brand IQ, the campaigns already running, and the current content calendar." advance_by: agent tools:
  • yepairag_share__BRAND_IQ_GET
  • yepairag_marketing__GET_TRAFFIC_SNAPSHOT
  • yepairag_marketing__GET_GOOGLE_ADS_REPORT
  • yepairag_marketing__GET_META_ADS_REPORT
  • yepairag_marketing__GET_CONTENT_COGNITION
  • yepairag_marketing__GET_CHANNEL_KEYWORD_CANDIDATES
  • yepairag_marketing__LIST_CAMPAIGNS
  • yepairag_marketing__GET_CONTENT_CALENDAR next:
  • to: propose when: "the evidence is assembled — each source has either returned figures or stated plainly that it is not connected or has no data yet"
• id: propose label: "Drafting promotion directions" purpose: "Put the promotion directions the data honestly supports on the directions card as suggestions — aim for two or three; each a theme, the channels it runs on, the promotion it suggests (a discount's type, value and window, or none), and the figure that argues for it. The card ends the task: no pick is waited for, and nothing is created or scheduled." advance_by: agent tools:
  • yepairag_marketing__SHOW_PROMOTION_DIRECTIONS

---

Task — Promotion plan

Flow

flowchart TD
  research["Reading your traffic and campaign data"] --> propose["Drafting promotion directions"]
  classDef terminal stroke-width:3px
  class propose terminal

Square = you are working · bold border = terminal.

research

Reading your traffic and campaign data — Assemble the evidence the plan stands on — the store traffic snapshot, ads figures when connected, content cognition verdicts, keyword candidates seeded from Brand IQ, the campaigns already running, and the current content calendar.

• Every figure the plan later quotes comes from a tool result in THIS run. The snapshot and report tools return computed figures with their windows — quote them exactly, never derive a new percentage, total or average (their own reply_contract says the same). A source that answers NOT_CONNECTED, NO_DATA_YET or PROPERTY_UNRESOLVED is relayed as its next_step in ONE clause, and the plan is built on the sources that did answer; never estimate the missing one, and never ask the merchant which Analytics property to read or name a property id — the traffic snapshot already reads the one the server chose.
• Seed GET_CHANNEL_KEYWORD_CANDIDATES with Brand IQ keywords — it does not fetch them itself.

propose

Drafting promotion directions — Put the promotion directions the data honestly supports on the directions card as suggestions — aim for two or three; each a theme, the channels it runs on, the promotion it suggests (a discount's type, value and window, or none), and the figure that argues for it. The card ends the task: no pick is waited for, and nothing is created or scheduled.

• The directions go on the card: one SHOW_PROMOTION_DIRECTIONS call is the whole reply — no text before or after it — and that card ends the turn and the task, with no pick to wait for. summary is the data's verdict in one sentence. directions holds two or three (one only under the gate below), at most one recommended, each with its title, theme, channels — only the three you can write end to end: Shopify blog, Instagram post, Facebook post — promotion, a one-or-two-sentence why, and a kpi when the figures give it a target. evidence is one sentence per figure, each figure a tool's own value quoted exactly (research's rule). No direction is built on a number a tool did not return, and that gate outranks the count: when the data honestly carries only one direction (a new store, few sources connected), the card carries that one, with missing_data naming each gap in one sentence; when it carries none, there is no card and one sentence says what data is missing — never stretch one figure across directions or dress a direction in a figure-shaped sentence. Adjusted or different directions are a fresh call of the same card.
• A direction's promotion is a suggestion stated in full, so the merchant can judge it — a discount's type, value and window, or that it carries none; never "we could add a code". It stays a suggestion: no discount campaign is created from a direction in this task.
• Social impressions and Instagram per-post clicks are not obtainable; when a direction would want them, its why says so plainly and argues from the figures that exist.

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: "promo-plan"
  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.