SKILLOfficialmonitoring

store-pulse

プラグイン: noibu
ソース: GitHub で見る ↗

説明

お店の過去24時間の状態を、一目で確認できるまとめです。ライブダッシュボード（リアルタイムで更新される情報表示画面）として保存することも、定期的なレポート送信を予定することもできます。 **次のような場合に使用:** - お店全体の現在の状況をすばやく確認したい - ライブダッシュボードを保存して継続的に監視したい - 定期的なサマリー（要約レポート）の送信をスケジュールしたい

原文を表示

An instant, at-a-glance read on your store's health from the last 24 hours — with the option to save it as a live Cowork dashboard artifact or schedule a recurring report. Use to check on how the overall store is doing, save a live dashboard, or schedule a recurring summary.

ユースケース

お店全体の現在状況をすばやく確認したい
ライブダッシュボードを保存して継続的に監視したい
定期的なサマリーレポートの送信をスケジュールしたい

本文（日本語訳）

Store Pulse

日々の業務に使うネットショップの状態把握ツール。毎回実行するたびに、最新の簡潔な回答をまず示します（24時間のサマリー、重要指標の行、購入漏斗）。ダッシュボードを保存したり定期レポートを設定したりするのは、明示的で任意の操作です。必須ではありません。

ドメインごとに1つのダッシュボードと1つのスケジュール。 異なるドメインはそれぞれ独立して持つことができます。

デフォルトの流れ

毎回の実行時に動きます（「ストアの調子どう？」「flyinmiata.comをチェック」、または単に /store-pulse と入力）。既存ダッシュボードの有無チェックはしません。また list_artifacts も呼び出さないため、常に最新の情報を表示します。保存済みのダッシュボードがあってもそれを言及しません（「ダッシュボードとして保存」の項を参照。そこだけが有無チェックをします）。

ドメインを確定する — コンテキストから明らかなら、それをそのまま使用します。不明な場合は noibu_list_domains を実行します。結果が1つなら使用、複数あって該当するものがなければ AskUserQuestion で利用者に選択してもらいます。
references/inline-snapshot.md を読み込み、その通りに従う — このファイルが応答の全体形式を定義しています（サマリー、ウィジェット、締めの一文、調査を促す質問）。

ダッシュボードとして保存

スナップショット（現在の状態）ウィジェットの「ダッシュボードとして保存」ボタンから呼び出されます（Save Store Pulse dashboard for [domain] として到着）。または直接リクエスト（「これをダッシュボードとして保存して」）されます。

既存ダッシュボードをチェック。 list_artifacts を実行します。ID またはタイトルが store-pulse-[domain-slug] に合致するもの、または古い形式の store-pulse-dashboard で SP_CONFIG.domain.name が一致するものを探します（移行に関する注記を参照。古いものの ID は変更しません）。
- この呼び出しと同時に、タイトルを決めます。デフォルトではドメイン部分を削除します（例：Store Pulse — Atari）。ただし別のダッシュボードとタイトルが重複する場合だけ、ドメインを加えます（例：atari.ca が既に存在する場合は Store Pulse — Atari (atari.ca)）。詳しくは references/live-dashboard.md を参照。
ダッシュボード、ありますか？ こう聞きます。「既に1つ持っていますね。編集しますか？」
- はい → 何を変更するか聞いて、「既存ダッシュボードの編集」に進みます。
- いいえ → 承認して、終了。
ダッシュボード、ありませんか？ オプションのブロック（複数選択可、デフォルトはすべてオフ）について一度だけ聞きます。core-kpis（基本指標）と purchase-funnel（購入漏斗）は常に含まれるため、これについては聞きません：
「ダッシュボードには、基本指標（セッション数、エンゲージメント、コンバージョン、平均注文額、セッションあたり売上）と購入漏斗が最初から含まれます。ほかに追加したいものはありますか？」
- トップ商品 — アクセス数の多い上位5商品とカート追加率
- チャネルのパフォーマンス — トラフィックソース別のセッション数とコンバージョン
- 有料広告のパフォーマンス — 広告プラットフォーム別のセッション数、コンバージョン、売上
この3つだけです。「これらは必要ない」というオプションはありません（複数選択の場合は不要。未チェックか「スキップ」で十分です）。選択された各ブロックについて references/blocks/<id>.md を読み込みます。
構築します — references/live-dashboard.md を読み込み、その通りに従います（ツール名の解決、テンプレート、プレースホルダー、ID とタイトルの規則）。設定の形式：
```
{ "version": 1, "domain": { "id": "uuid", "name": "..." }, "blocks": ["core-kpis", "purchase-funnel", "..."] }
```
確認：「[ドメイン] の Store Pulse がサイドバーで配信開始されました — いつでも開いてそのストアをチェックできます。」
スケジュール設定を提案します（このドメイン用にまだスケジュールがなければ）。この後、あなたのターンは終了：

「定期レポートも設定しちゃいましょうか？メールでもSlackでも、好きな頻度で送信できます。」

拒否された → 終了。このターンでは再度提案しません。

既存ダッシュボードの編集

「ダッシュボードとして保存」のステップ2、または直接（「flyinmiata.com のダッシュボードにチャネルパフォーマンスを追加して」、「atari.com のダッシュボードを別のドメインに変更して」）から到達します。

対象のアーティファクト（保存物）から SP_CONFIG を読み込み、変更を加え、references/live-dashboard.md で再構築します。同じ id で update_artifact を実行します。既にダッシュボードを持つドメイン用に、2番目のアーティファクトを作ってはいけません。

再構築するたびに、現在のセッションから noibu_search_sessions ツール名を静かに再解決し、mcp_tools として渡します。古いアーティファクトに焼き込まれたものは再利用しません。インスタンス ID が変わっている可能性があるためです。この手順は利用者には説明しません。毎回の編集で古いツール名が自動修正されます。「mcp_tools許可リスト」エラーが出たら、再構築して更新してください。

ブロックの変更 → blocks を更新、再構築、更新。
このアーティファクトのドメイン変更：
1. noibu_list_domains を実行、大文字小文字を区別せず（www. 付きの変種も受け入れる）照合。見つからなければ、オプションを列挙して停止。
2. 確認：「このダッシュボードを [現在のドメイン] から [新しいドメイン] に切り替えます。データソースが置き換わりますが、続けますか？」
3. SP_CONFIG.domain を更新、再構築、更新。ID とタイトルは、名前変更を明示的に求めない限り、古いドメイン由来のままです。外見上の不一致は無害です。
4. 古いドメイン用のスケジュールが存在 → update_scheduled_task を実行（新しいドメイン焼き込み）し、タスク名を store-pulse-[new-domain-slug] に変更。
- 別のドメイン用に2番目のダッシュボードが欲しい？ → そのドメイン用に「ダッシュボードとして保存」を実行。このダッシュボードはそのまま。
アーティファクトがない → 設定も消失。「ダッシュボードとして保存」を再実行。

レポートのスケジュール設定

スナップショットウィジェットの「レポートをスケジュール」ボタンから呼び出されます（Schedule Store Pulse report for [domain] として到着）。直接リクエストされるか、上記ステップ6から。保存済みのダッシュボードは必須ではありません。定期実行（クロン）が独自の設定を焼き込み、ライブダッシュボードは読まないためです。

既存スケジュール（スケジュール済みタスク）をチェック。 list_scheduled_tasks を実行、store-pulse-[domain-slug] を探します（references/schedule.md の「タスク識別」セクションを参照）。見つかれば、これは編集です。
references/schedule.md の「## スケジュール設定フォームウィジェット」を読み込み、その HTML をそのまま渡します（JavaScript は各セレクターに依存しています）。
show_widget でレンダリング、タイトル schedule_store_pulse。このレンダラーだけが送信時に自動送信します。read_me を読み込みます（modules: ["interactive"]）一度だけ、静かに、まだ読み込まれていなければ。
送信時（frequency（頻度）、day（曜日）、time（時刻）、delivery（配信先）、detail（詳細度））に、選択された各配信先のコネクタを解決します。これは配信先（ターゲット）を聞く前です。プレーンテキストのインストールリンクにはフォールバックしません。コネクタ推奨ウィジェットを使います：
- メール → ライブの Gmail（create_draft/search_threads/list_drafts）または Outlook ドラフトツールを探します。
  - 見つかった → メールアドレスを聞きます（どちらのインボックスも利用可能なら、先に選んでもらいます）。
  - どちらもない → search_mcp_registry(["gmail","email"]) と search_mcp_registry(["outlook","microsoft 365","email"]) を実行。その後 suggest_connectors(keywords:["email"], uuids: <both>) で Gmail と Microsoft 365 を並べて提案。この配信先は接続まで飛ばして、他は続行します。
- Slack → ライブの slack_search_channels ツールを探します。
  - 見つかった → どのチャネルか聞いて、解決。
  - ない、または認証されていない → search_mcp_registry(["slack","messages","chat"])、その後 suggest_connectors(keywords:["messages"], uuids: <match>)。同じ「飛ばす、ブロックしない」ルール。
- すべての配信先が未解決 → クロンを作らない。何か接続されたら戻ってくるよう言う。
クロンを作成/更新 — update_scheduled_task（既存）または create_scheduled_task で名前 store-pulse-[domain-slug]（新規）。頻度・曜日・時刻・詳細度と、解決済みの配信先だけをプロンプトテンプレート（references/schedule.md）に焼き込みます。コネクタツール名プレースホルダー（{{slack_canvas_tool}}、{{slack_message_tool}}、{{gmail_draft_tool}}、{{outlook_draft_tool}}）を現在のセッションのツールから解決して置き換えます。references/schedule.md の「コネクタツール名も焼き込む必要がある」を参照。
確認。権限に関する注記も含みます：

「スケジュール設定完了 — [ドメイン] の Store Pulse レポートが [読みやすいサマリー] で配信されます。1つ注意：初回は、スケジュール済みタスクから手動で1度実行して、必要な権限を付与する必要があります。その後は自動配信されます。」

フォームをスキップ → 承認、次へ。

移行に関する注記

マルチドメイン対応前のダッシュボードは固定の ID store-pulse-dashboard に置かれています。完全にそのままにしてください（名前変更、再作成、移行なし）。「ドメイン X にダッシュボードは既にあるか？」というチェックでは、これをそのドメインのダッシュボードとして扱う（SP_CONFIG.domain.name で照合）。新しいダッシュボードだけが、ドメイン由来の ID 規則を使います。

ファイル構成

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 — ブロック仕様（指標、クエリ、ツールチップ）。スナップショット、ダッシュボード、定期レポートで共有。
references/inline-snapshot.md — デフォルト応答の形式：サマリー、KPI・漏斗ウィジェット、アクションボタン、調査を促す質問。
references/live-dashboard.md — 永続アーティファクト：テンプレート、ツール名解決、ID・タイトル規則。
references/schedule.md — 定期実行の時間枠、タスク命

原文（English）を表示

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).

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).
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").

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.
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.
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.
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", "..."] }
```
Confirm: "Store Pulse for [domain] is live in your sidebar — open it whenever you want to check that store."
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.

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.
Read references/schedule.md's ## Scheduling form widget and pass that HTML verbatim (the JS depends on every selector).
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.
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.
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".
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.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。

SKILLOfficialmonitoring

store-pulse

プラグイン: noibu
ソース: GitHub で見る ↗

説明

原文を表示

ユースケース

お店全体の現在状況をすばやく確認したい
ライブダッシュボードを保存して継続的に監視したい
定期的なサマリーレポートの送信をスケジュールしたい

本文（日本語訳）

Store Pulse

ドメインごとに1つのダッシュボードと1つのスケジュール。 異なるドメインはそれぞれ独立して持つことができます。

デフォルトの流れ

ドメインを確定する — コンテキストから明らかなら、それをそのまま使用します。不明な場合は noibu_list_domains を実行します。結果が1つなら使用、複数あって該当するものがなければ AskUserQuestion で利用者に選択してもらいます。
references/inline-snapshot.md を読み込み、その通りに従う — このファイルが応答の全体形式を定義しています（サマリー、ウィジェット、締めの一文、調査を促す質問）。

ダッシュボードとして保存

既存ダッシュボードをチェック。 list_artifacts を実行します。ID またはタイトルが store-pulse-[domain-slug] に合致するもの、または古い形式の store-pulse-dashboard で SP_CONFIG.domain.name が一致するものを探します（移行に関する注記を参照。古いものの ID は変更しません）。
- この呼び出しと同時に、タイトルを決めます。デフォルトではドメイン部分を削除します（例：Store Pulse — Atari）。ただし別のダッシュボードとタイトルが重複する場合だけ、ドメインを加えます（例：atari.ca が既に存在する場合は Store Pulse — Atari (atari.ca)）。詳しくは references/live-dashboard.md を参照。
ダッシュボード、ありますか？ こう聞きます。「既に1つ持っていますね。編集しますか？」
- はい → 何を変更するか聞いて、「既存ダッシュボードの編集」に進みます。
- いいえ → 承認して、終了。
ダッシュボード、ありませんか？ オプションのブロック（複数選択可、デフォルトはすべてオフ）について一度だけ聞きます。core-kpis（基本指標）と purchase-funnel（購入漏斗）は常に含まれるため、これについては聞きません：
「ダッシュボードには、基本指標（セッション数、エンゲージメント、コンバージョン、平均注文額、セッションあたり売上）と購入漏斗が最初から含まれます。ほかに追加したいものはありますか？」
- トップ商品 — アクセス数の多い上位5商品とカート追加率
- チャネルのパフォーマンス — トラフィックソース別のセッション数とコンバージョン
- 有料広告のパフォーマンス — 広告プラットフォーム別のセッション数、コンバージョン、売上
この3つだけです。「これらは必要ない」というオプションはありません（複数選択の場合は不要。未チェックか「スキップ」で十分です）。選択された各ブロックについて references/blocks/<id>.md を読み込みます。
構築します — references/live-dashboard.md を読み込み、その通りに従います（ツール名の解決、テンプレート、プレースホルダー、ID とタイトルの規則）。設定の形式：
```
{ "version": 1, "domain": { "id": "uuid", "name": "..." }, "blocks": ["core-kpis", "purchase-funnel", "..."] }
```
確認：「[ドメイン] の Store Pulse がサイドバーで配信開始されました — いつでも開いてそのストアをチェックできます。」
スケジュール設定を提案します（このドメイン用にまだスケジュールがなければ）。この後、あなたのターンは終了：

「定期レポートも設定しちゃいましょうか？メールでもSlackでも、好きな頻度で送信できます。」

拒否された → 終了。このターンでは再度提案しません。

既存ダッシュボードの編集

ブロックの変更 → blocks を更新、再構築、更新。
このアーティファクトのドメイン変更：
1. noibu_list_domains を実行、大文字小文字を区別せず（www. 付きの変種も受け入れる）照合。見つからなければ、オプションを列挙して停止。
2. 確認：「このダッシュボードを [現在のドメイン] から [新しいドメイン] に切り替えます。データソースが置き換わりますが、続けますか？」
3. SP_CONFIG.domain を更新、再構築、更新。ID とタイトルは、名前変更を明示的に求めない限り、古いドメイン由来のままです。外見上の不一致は無害です。
4. 古いドメイン用のスケジュールが存在 → update_scheduled_task を実行（新しいドメイン焼き込み）し、タスク名を store-pulse-[new-domain-slug] に変更。
- 別のドメイン用に2番目のダッシュボードが欲しい？ → そのドメイン用に「ダッシュボードとして保存」を実行。このダッシュボードはそのまま。
アーティファクトがない → 設定も消失。「ダッシュボードとして保存」を再実行。

レポートのスケジュール設定

既存スケジュール（スケジュール済みタスク）をチェック。 list_scheduled_tasks を実行、store-pulse-[domain-slug] を探します（references/schedule.md の「タスク識別」セクションを参照）。見つかれば、これは編集です。
references/schedule.md の「## スケジュール設定フォームウィジェット」を読み込み、その HTML をそのまま渡します（JavaScript は各セレクターに依存しています）。
show_widget でレンダリング、タイトル schedule_store_pulse。このレンダラーだけが送信時に自動送信します。read_me を読み込みます（modules: ["interactive"]）一度だけ、静かに、まだ読み込まれていなければ。
送信時（frequency（頻度）、day（曜日）、time（時刻）、delivery（配信先）、detail（詳細度））に、選択された各配信先のコネクタを解決します。これは配信先（ターゲット）を聞く前です。プレーンテキストのインストールリンクにはフォールバックしません。コネクタ推奨ウィジェットを使います：
- メール → ライブの Gmail（create_draft/search_threads/list_drafts）または Outlook ドラフトツールを探します。
  - 見つかった → メールアドレスを聞きます（どちらのインボックスも利用可能なら、先に選んでもらいます）。
  - どちらもない → search_mcp_registry(["gmail","email"]) と search_mcp_registry(["outlook","microsoft 365","email"]) を実行。その後 suggest_connectors(keywords:["email"], uuids: <both>) で Gmail と Microsoft 365 を並べて提案。この配信先は接続まで飛ばして、他は続行します。
- Slack → ライブの slack_search_channels ツールを探します。
  - 見つかった → どのチャネルか聞いて、解決。
  - ない、または認証されていない → search_mcp_registry(["slack","messages","chat"])、その後 suggest_connectors(keywords:["messages"], uuids: <match>)。同じ「飛ばす、ブロックしない」ルール。
- すべての配信先が未解決 → クロンを作らない。何か接続されたら戻ってくるよう言う。
クロンを作成/更新 — update_scheduled_task（既存）または create_scheduled_task で名前 store-pulse-[domain-slug]（新規）。頻度・曜日・時刻・詳細度と、解決済みの配信先だけをプロンプトテンプレート（references/schedule.md）に焼き込みます。コネクタツール名プレースホルダー（{{slack_canvas_tool}}、{{slack_message_tool}}、{{gmail_draft_tool}}、{{outlook_draft_tool}}）を現在のセッションのツールから解決して置き換えます。references/schedule.md の「コネクタツール名も焼き込む必要がある」を参照。
確認。権限に関する注記も含みます：

「スケジュール設定完了 — [ドメイン] の Store Pulse レポートが [読みやすいサマリー] で配信されます。1つ注意：初回は、スケジュール済みタスクから手動で1度実行して、必要な権限を付与する必要があります。その後は自動配信されます。」

フォームをスキップ → 承認、次へ。

移行に関する注記

ファイル構成

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 — ブロック仕様（指標、クエリ、ツールチップ）。スナップショット、ダッシュボード、定期レポートで共有。
references/inline-snapshot.md — デフォルト応答の形式：サマリー、KPI・漏斗ウィジェット、アクションボタン、調査を促す質問。
references/live-dashboard.md — 永続アーティファクト：テンプレート、ツール名解決、ID・タイトル規則。
references/schedule.md — 定期実行の時間枠、タスク命

原文（English）を表示

Store Pulse

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

Default flow

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).
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").

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.
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.
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.
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", "..."] }
```
Confirm: "Store Pulse for [domain] is live in your sidebar — open it whenever you want to check that store."
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").

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

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.
Read references/schedule.md's ## Scheduling form widget and pass that HTML verbatim (the JS depends on every selector).
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.
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.
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".
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

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.

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。