Store Pulse

Daily-driver ecommerce snapshot. Every invocation leads with a fresh inline answer (24h summary, KPI row, funnel). Saving a dashboard artifact and scheduling a recurring report are explicit, optional actions — never prerequisites.

One dashboard + one schedule per domain. Different domains can each have their own, side by side.

Default flow

Runs on every invocation ("how's my store doing", "check on flyinmiata.com", a bare /store-pulse). No existence check gates this and no list_artifacts call here — always fresh, and never mentions an existing saved dashboard even if one exists (see "Save as artifact" for the one place existence is checked).

1. Resolve the domain — use it without asking if already clear from context; otherwise noibu_list_domains (one result → use it; multiple with none named → AskUserQuestion).
2. Read references/inline-snapshot.md and follow it exactly — it owns the full response shape (summary, widget, closing line, investigate-thread question).

---

Save as artifact

Triggered by the snapshot widget's "Save as artifact" button (arrives as Save Store Pulse dashboard for [domain]) or a direct request ("save this as a dashboard").

1. Check for an existing dashboard. list_artifacts — match on id/title containing store-pulse-[domain-slug], or a legacy store-pulse-dashboard whose SP_CONFIG.domain.name matches (see Migration note; leave its id alone).

   • Same call also decides the title: drop the domain suffix by default (Store Pulse — Atari), add it back only on a Label collision with another live dashboard (e.g. atari.ca already exists) — see references/live-dashboard.md.

2. Exists? Ask: "You already have one, do you want to edit it?"

   • Yes → ask what to change, go to "Edit an existing dashboard".
   • No → acknowledge, stop.

3. Doesn't exist? Ask once about optional blocks (multi-select, all default-off; core-kpis/purchase-funnel are always included, don't ask about those):

   "Your dashboard will include Core KPIs (sessions, engagement, conversion, AOV, revenue per session) and a Purchase Funnel by default. Anything else you'd like to add?"

   • Top products — top 5 by traffic with add-to-cart rate
   • Channel performance — sessions and conversion by traffic source
   • Paid ad performance — sessions, conversions, revenue per ad platform

   Exactly these 3 — no "None of these" option (redundant on a multi-select; unchecked or Skip already covers it). Read references/blocks/<id>.md for each picked block.

4. Build it — read references/live-dashboard.md and follow it exactly (tool-name resolution, template, placeholders, id/title). Config shape:

   { "version": 1, "domain": { "id": "uuid", "name": "..." }, "blocks": ["core-kpis", "purchase-funnel", "..."] }
   

5. Confirm: "Store Pulse for [domain] is live in your sidebar — open it whenever you want to check that store."

6. Offer scheduling (skip if already scheduled for this domain), then stop your turn:

   "Want me to set up a recurring report for this too? I can send it on whatever cadence works for you — email or Slack."

   Declined → end, don't re-offer this turn.

---

Edit an existing dashboard

Reached from "Save as artifact" step 2, or directly ("add channel performance to my flyinmiata.com dashboard", "switch my atari.com dashboard to a different domain").

Read SP_CONFIG from the target artifact, mutate, rebuild via references/live-dashboard.md, update_artifact on the same id — never create a second artifact for a domain that already has one.

Every rebuild silently re-resolves the live noibu_search_sessions tool name from your current session (never reuse the one baked into the old artifact — its instance id may have changed) and passes it as mcp_tools. This self-heals stale tool names on every edit — an "mcp_tools allowlist" error just means rebuild + update. Don't narrate this resolution to the user.

• Block change → update blocks, rebuild, update.
• Domain change on this artifact:
  1. noibu_list_domains, match case-insensitively (accept www. variants); not found → list options, stop.
  2. Confirm: "Switching this dashboard from [current] to [new] — it'll replace this dashboard's data source. Continue?"
  3. Update SP_CONFIG.domain, rebuild, update. Id/title stay derived from the old domain unless asked to rename — cosmetic mismatch is harmless.
  4. Schedule exists for the old domain → update_scheduled_task (new domain baked in) and rename the task to store-pulse-[new-domain-slug].
  • Want a second dashboard for a different domain instead? → "Save as artifact" for that domain; leave this one untouched.
• Artifact missing → its config went with it; re-run "Save as artifact".

---

Schedule report

Triggered by the snapshot widget's "Schedule report" button (arrives as Schedule Store Pulse report for [domain]), a direct request, or step 6 above. Never requires a saved artifact — the cron bakes its own config and never reads the live dashboard.

1. Check for an existing schedule. list_scheduled_tasks, look for store-pulse-[domain-slug] (see references/schedule.md's Task identity section) — found → this is an edit.

2. Read references/schedule.md's ## Scheduling form widget and pass that HTML verbatim (the JS depends on every selector).

3. Render via show_widget, title schedule_store_pulse — the only renderer that auto-sends on submit. Load read_me (modules: ["interactive"]) once, silently, if not already loaded.

4. On submit (frequency, day, time, delivery, detail), resolve each picked delivery's connector before asking for its target — never fall back to a plain-text install link, use the connector-recommendation widget instead:

   • Email → look for a live Gmail (create_draft/search_threads/list_drafts) or Outlook draft tool.
     • Found → ask for the email address (ask which inbox first if both are available).
     • Neither found → search_mcp_registry(["gmail","email"]) and search_mcp_registry(["outlook","microsoft 365","email"]), then suggest_connectors(keywords:["email"], uuids: <both>) so Gmail and Microsoft 365 show up together. Skip this delivery until connected; keep going with the rest.
   • Slack → look for a live slack_search_channels tool.
     • Found → ask which channel, resolve it.
     • Missing or unauthenticated → search_mcp_registry(["slack","messages","chat"]), then suggest_connectors(keywords:["messages"], uuids: <match>). Same skip-don't-block rule.
   • All deliveries unresolved → don't create the cron; tell them to come back once something's connected.

5. Create/update the cron — update_scheduled_task (existing) or create_scheduled_task name store-pulse-[domain-slug] (new). Bake frequency/day/time/detail plus only the resolved deliveries into the prompt template (references/schedule.md). Resolve and substitute the connector tool-name placeholders ({{slack_canvas_tool}}, {{slack_message_tool}}, {{gmail_draft_tool}}, {{outlook_draft_tool}}) from your current session's tools — see references/schedule.md's "Connector tool names must also be baked in".

6. Confirm, including the permission note:

   "Scheduled — your Store Pulse report for [domain] will go out [readable summary]. One heads-up: you'll need to run the task once manually from your scheduled tasks to grant the permissions it needs. After that first run, it'll deliver on its own."

Skipped form → acknowledge, move on.

---

Migration note

Pre-multi-domain dashboards sit at the fixed id store-pulse-dashboard — leave exactly as-is (no rename, recreate, or migrate). Any "does domain X already have a dashboard" check must treat it as that domain's dashboard (match via SP_CONFIG.domain.name). Only new dashboards use the domain-derived id scheme.

---

File map

store-pulse/
├── SKILL.md
├── references/blocks/{core-kpis,purchase-funnel,top-products,channel-performance,paid-performance}.md
├── references/inline-snapshot.md
├── references/live-dashboard.md
└── references/schedule.md

• references/blocks/<id>.md — block specs (metrics, queries, tooltips); shared by the snapshot, the dashboard, and scheduled reports.
• references/inline-snapshot.md — default response shape: summary, KPI+funnel widget, action buttons, investigate-thread question.
• references/live-dashboard.md — persistent artifact: template, tool-name resolution, id/title convention.
• references/schedule.md — cron windows, task naming, message formats, and the scheduling form widget.