weekly-performance-advisor

Weekly Performance Advisor

ユーザー自身の La Growth Machine（LGM）データから、2つのタブを備えたライブアーティファクトである Weekly Performance Advisor を生成します。このスキルは完全に自己完結しており、環境の検出、キャンペーンのスコアリング、返信の分類、ダッシュボードへの入力に必要なすべてのルールが以下に記載されています。他のドキュメントは参照しません。

常に守るべき重要なルールが2つあります。

1. ダウンロードしたユーザー自身のデータのみを表示します。 接続されているユーザー本人の MCP からのみデータを取得します。他の人の数値、キャンペーン名、返信、例を決して挿入しません。テンプレートは空の状態で提供され、実行時にユーザー本人のライブデータが入力されます。値を取得できない場合は、仕様に記載された空の状態を表示します。プレースホルダーの数値や、別の場所から流用した値は決して使いません。
2. 出力は保存済み HTML ファイルではなく、ライブアーティファクトです。 Generate モードでは、テンプレートをメモリ内で入力し、利用可能なアーティファクトツールを使用してライブアーティファクトとしてレンダリングします（現在の Cowork ビルドでアーティファクトの作成・更新に使えるツールを使用し、ツール名をハードコードしないでください）。更新時は、新しいアーティファクトを作成するのではなく、既存のアーティファクトを更新します。assets/dashboard-template.html ファイルはビルドソースのみです。

---

2つのモード

• Setup モード（初回実行時、または LGM が接続されていない／ID がまだ選択されていない場合）：対話形式です。環境を検出し、必要に応じてインストールを案内し、範囲を設定する質問をします。会話形式で進めます。
• Generate モード（Setup 完了後のすべての実行時）：エンジンを実行し、テンプレートに入力して、アーティファクトと短い引き継ぎを出力します。ここでは出力の規律を守り、アーティファクトと数行の引き継ぎのみを返します。手順ごとの説明はしません。

このプロジェクトで Setup がすでに完了していて（./.lgm-wpa/ スナップショットが存在し、LGM が接続されている場合）、そのまま Generate モードに進みます。情報が不足している場合にのみ、質問をし直します。

---

Phase 0 — 検出（サイレント、質問なし）

自身のツール一覧を確認します。ユーザーにインストール済みのものを尋ねないでください。

• LGM MCP があるか？ La Growth Machine 用の mcp__* という名前のツールが利用可能な場合です。つまり、list_identities、list_campaigns、get_campaign_stats、get_conversations_to_reply、get_conversation_messages、search_conversations のいずれかが利用可能な場合です。（ターミナルでは claude mcp list を実行して LGM サーバーを確認することもできますが、ツールの有無だけで十分です。ユーザーに尋ねないでください。）
• CRM／取引 MCP があるか？ HubSpot MCP（取引／会社／連絡先のツール）が利用可能かどうかを確認します。
• campaign-impact-analyzer スキルが利用可能か？（オプションの取引／€ レイヤーの構築に使用します。）

この3つの真偽値を記録して、次に進みます。検出結果を伝えないでください。

---

Phase 1 — LGM MCP の確認

LGM MCP がある場合： 1行で「LGM connected ✓」と伝え、Phase 2 に進みます。

LGM MCP がない場合： ダッシュボードはすべて LGM データから作成するため、まだ実行できません。そのことを1文で説明してから、インストールを案内します（「インストールされていますか？」とは尋ねないでください。インストールされていないことはすでに分かっています）。

1. gtm-system リポジトリから、インストーラーを実行してブラウザーでのサインインを完了します。

   sh install.sh
   

   （または、リポジトリの README に記載されている curl のワンライナーを使用します）。認証にはブラウザー OAuthを使用します。貼り付ける API キーはありません。
2. LGM アカウントをまだ持っていない場合は、https://app.lagrowthmachine.com で登録してから、インストーラーを再実行するよう案内します。
3. 実行後、再検出します（Phase 0）。LGM ツールが表示されるまで繰り返し、その後続行します。

親しみやすく簡潔に伝えてください。これは先へ進むための確認であり、長い説明をする場面ではありません。

---

フェーズ 2 — ID の対象範囲（重要な確認事項）

list_identities を呼び出します。次に、妥当なデフォルトを選ぶため、各 ID のキャンペーン数を取得します。list_campaigns {status:"RUNNING"} を呼び出して（ページネーションを使用）、identity.id ごとに RUNNING キャンペーン数を数えます。

追跡する ID を確認します。RUNNING キャンペーンが最も多い ID をデフォルトとして提示し（名前を伝え、確認または変更を促します）。チーム全体を表示するため、後から ID を追加できることも伝えます（ダッシュボードは複数の ID に対応しており、それらのキャンペーンと返信をまとめて表示します）。

選択した ID の ID と表示名を保存します。以下のすべての LGM データ取得は、それらを対象とします。

---

フェーズ 3 — ディールレイヤー（任意、追加機能 — 決して作成を妨げない）

ダッシュボードには 「キャンペーン経由のディール」 ボックスが用意されています。CRM がない場合は — と 「ディールデータを取得するには HubSpot に接続してください」 という注記が表示されます。より充実したレイヤーを提案しますが、決して作成の条件にはしないでください。

• CRM／ディール用 MCP がある場合 → 今すぐ提案します：「ディール／€ レイヤー（実際にパイプラインを生み出したキャンペーン）を追加しますか？ それとも、先にダッシュボードを公開して後から追加しますか？」
• CRM 用 MCP がない場合 → 「ディールは何で管理していますか？」（HubSpot／Salesforce／Sheets／その他／なし）と尋ねます。
  • HubSpot を使っているが未接続の場合 → 接続を提案します（接続後は「利用可能」になります）。
  • Salesforce／Sheets／その他／複雑な場合 → まずダッシュボードを作成し、後からディールレイヤーを追加します。

委任（ここで結合処理を再実装しないでください）：

• campaign-impact-analyzer が利用可能な場合 → LGM と CRM の相互参照を委任し、「キャンペーン経由のディール」ボックスにデータを入力します（ディール数と €、今週分、ポートフォリオ全体）。その出力を使って {{DEALS_VALUE}}／{{DEALS_NOTE}} を設定します。
• campaign-impact-analyzer が利用できない場合 → 作成を妨げず、結合処理を独自に連鎖させないでください。LGM のみのダッシュボードを公開します（ディールボックスは —）。引き継ぎ時に、次の案内を追加します。 「ディール／€ レイヤーを利用するには、gtm-system から campaign-impact-analyzer をインストールしてから、もう一度実行してください。」

---

フェーズ 4 — 作成

ユーザーの最新データに対してエンジン（以下）を実行し、assets/dashboard-template.html のすべてのプレースホルダーに値を入力します。利用可能なアーティファクトツールを使って、ライブアーティファクトとしてレンダリングします（2 つのタブ）。初回実行時は作成し、次回以降は既存のアーティファクトを更新します。その後、今週分のスナップショットを ./.lgm-wpa/ に書き込みます。

フェーズ 4.5 — 週次更新を設定する（定期処理）

ダッシュボードには ↻ 更新 ボタンがあります。データを再取得してアーティファクトを更新する週次定期処理を設定した後にのみ機能するため、今すぐ設定するか提案してください（同意があった場合のみ設定します）。

確認（英語、原文に近い表現）： 「↻ 更新ボタンを使えるようにするため、毎週月曜日の朝に La Growth Machine のデータを再取得し、このダッシュボードを更新する定期処理を設定できます。設定しますか？」

• はい → 利用可能なスケジュール設定ツールを使って、実行頻度を毎週月曜日の朝に設定したタスクを作成します。タスクのプロンプトでは、同じ ID を対象にこのスキルを Generate モードで再実行し、既存のアーティファクトを更新するよう指定します（新しいアーティファクトは作成しません）。保存するタスクプロンプトの例：

  「weekly-performance-advisor スキルを Generate モードで ID [] に対して再実行してください。最新の La Growth Machine データを取得してエンジンを再計算し、既存の Weekly Performance Advisor アーティファクトを更新して、今週分のスナップショットを ./.lgm-wpa/ に書き込んでください。質問はしないでください。設定は完了しています。」

  • 実行時にツールから返されるタスク ID を取得し、{{REFRESH_TASK_ID}} としてテンプレートに渡します。これにより、↻ ボタンが このユーザーの タスクを実行します。ID は作成時にユーザーごとに決まるため、配布ファイルに ID をハードコードしないでください。
  • ボタンはすでに runScheduledTask(<that id>) を呼び出し、実行できない場合は適切なメッセージを表示します。
• いいえ／スキップ → {{REFRESH_TASK_ID}} を空文字列にします。↻ ボタンはその場合、わかりやすいアラートを表示します（問題は発生しません）。スキルを再実行すれば、いつでも定期処理を有効にできることを伝えてください。

フェーズ 5 — 引き継ぎ

アーティファクトが表示されたら、手順の説明はせず、簡潔に引き継ぎます。

• To do タブ = 今週の対応：実行する施策、対応する返信（緊急度順）、修正が必要な🔴キャンペーンのみです。Weekly performance タブ = 統計情報：WoW／30日間の差分付きの件数 KPI、ボリューム加重のヘルスゲージ、すべてのキャンペーンの全体像です。
• 毎週更新： 定期タスクを有効にしている場合（フェーズ 4.5）、↻ボタンと月曜日のタスクでダッシュボードを最新の状態に保てます。それ以外の場合は、いつでもこのスキルを再実行できます（その際に定期タスクを有効にすることもできます）。差分と30日間のトレンドは、スナップショットが2週間分以上たまると表示されます。
• 定期タスクの状態： 月曜日の自動更新が設定されたかどうかを確認します（フェーズ 4.5）。設定されていない場合は、定期タスクが作成されるまで↻ボタンは機能しないことを伝えます。
• LGM で返信を分類： LGM の受信トレイで返信に「興味あり／なし」のタグを付けるよう促します。これにより、来週の肯定的な返信数とトレンドの精度が上がります。
• アーティファクトの Fix-this ボタンをクリックすると、コピー＆ペースト用のプロンプトモーダルが開きます（用意されているプロンプトは、該当する gtm-system スキル（/reply-draft-assistant、/campaign-challenger、/sales-nav-search-builder、/won-deal-icp-finder）を対象としています）。新しい会話に貼り付けてください。

---

THE ENGINE（インライン — 正確に再現）

すべてのスコアリングは決定論的です。パーセンテージは整数です。エンダッシュは使わず、通常のハイフンを使用してください。

E1. 取得（選択した ID にスコープを限定）

1. list_identities → 選択した ID と名前を解決します。
2. list_campaigns {status:"RUNNING"}（ページネーション）→ identity.id ∈ 選択した ID のキャンペーンを保持します。
3. 保持した各キャンペーンについて get_campaign_stats を実行します → チャネルごとのカウンターを取得します。
4. 返信 — 混同せず、次の2種類の取得を行います。
   • 対応が必要な返信リスト → get_conversations_to_reply {identityIds:[...selected]}：現在、あなたの返信を待っているスレッドです。E8（To do タブに表示する行）に反映します。
   • 今週の件数セット → 選択した ID にスコープを限定し、今週 RECEIVED になった返信（リードが月曜日以降に返信）で絞り込んだ search_conversations：すでに返信したかどうかは問いません。E9 の件数 KPI に反映します。これにより、ヒーローカウントの正確性を保てます。すでに返信した「興味あり」のリードは対応待ちキューから外れていますが、今週の件数には引き続き含める必要があります。
   • どちらかのセットに含まれるスレッドが最新のスナップショットの classifiedReplyIds にまだない場合は、get_conversation_messages を読み込んで分類します（差分処理 — 既知の ID は再分類しません）。

E2. 各キャンペーンを正規化

campaign = {
  id, name, contacted,
  li: {accept, reply, csent, msent} | null,     // % values; csent = connection-request sends, msent = message sends
  em: {sent, deliv, open, reply, click, bounce, atag, eng} | null
}

• atag = メールのステップにトラッキング対象の <a href> リンクが含まれる（この場合に限り、クリックは実際の KPI になります）。
• eng = スコア対象となるメールのエンゲージメントがある =（メール返信 > 0）OR（メールクリック > 0）。
• contacted < 20 のキャンペーンはサンプル数不足です。リストには含めますが、スコアリングや順位付けはしません。

E3. ベンチマーク定数（組み込み — アーティファクト内で出典やブランド名に言及しない）

KPI ごとに3つのゾーン：🟢 目標達成 / 🟡 要注意 / 🔴 要修正。(good, floor, direction)：

linkedin_acceptance = (30, 20, up)
linkedin_reply      = (25, 15, up)
email_open          = (60, 45, up)
email_reply         = (6,  3,  up)      # cold-email calibration
email_click         = (8,  4,  up)      # shown, NOT status-driving
email_bounce        = (15, 25, down)    # lower is better
email_deliverability= (90, 80, up)      # not shown as a gauge (see note)

• 到達率ゲージはありません。 LGM では Delivered = Sent − Bounced なので、「到達率」は単に 100 − bounce であり、実際の受信トレイ到達率を示す指標ではありません。代わりに、対応可能なメールの技術的健全性指標であるバウンスを追跡します。ポートフォリオの5つのゲージは、LinkedIn の承認率、LinkedIn の返信率、メールのバウンス率、メールの開封率、メールの返信率です。
• MIN_SEND = 10：KPI またはステップのスコアリングには送信数が10以上必要です。それ未満の場合は「ボリューム不足」です。

zone(k, v): up → g if v≥good else y if v≥floor else r。down → g if v<good else y if v≤floor else r。 sev(k, v)（floor をどれだけ下回るか、≥0）：up → max(0,(floor−v)/floor)；down → max(0,(v−floor)/floor)；小数点以下3桁に丸めます。

E4. キャンペーンごとの KPI セット（kpis_for）

順序を維持して (kpi, value, state, driving) を出力します。

• li がある場合：linkedin_acceptance（csent≥10 なら採点、それ以外は不足）、linkedin_reply（ msent≥10 なら採点、それ以外は不足）。
• em があり、em.sent≥10 かつ em.eng の場合：email_open、email_reply、続いて em.atag の場合に限り email_click（非駆動）、その後に email_bounce。
• em があり、em.sent≥10 かつ em.eng ではない場合：メール KPI は採点対象外とし、次の行を表示します。 "Email: {sent} sent · {open}% open · 0 replies · 0 clicks - delivered, no engagement to score"。

E5. 主要チャネルの重み付け → ステータス

• li_sends = li.msent (or 0)、em_raw = em.sent (or 0)、total = li_sends + em_raw。
• primary = 'li' if li_sends ≥ em_raw else 'email'。SEC_MIN = 0.30。
• balanced = li_sends>0 AND em scored AND min(li_share, em_share) ≥ 0.30。
• is_driving(k)：
  • email_click → 常に非駆動です。
  • linkedin_* → li present AND li.msent≥10 AND (primary=='li' OR balanced)。
  • email_bounce → メールが採点対象なら常に駆動します（技術的な健全性は常にカウントします）。
  • email_open / email_reply → email scored AND (primary=='email' OR balanced)。
• driving_reds / driving_yellows = 🔴 / 🟡 の駆動 KPI。
• ステータス = 駆動対象の赤があれば To fix、なければ駆動対象の黄があれば Watch、それ以外は On target。 (内部的には「On target」が健全な状態です。「Healthy」や「needs work」という語は表示しないでください。)
• セカンダリチャネルの赤（linkedin_acceptance/linkedin_reply/ email_open/email_reply のうち、駆動対象ではない 🔴 KPI）→ キャンペーン全体のステータスは変更せず、代わりに 「email leg to fix」 または 「LinkedIn leg to fix」 チップを付けます。

E6. To-fix キャンペーンの修正 #1（診断）

• driving_reds の中から、ファネルの順序で最も弱いステップを選びます。最終的な別れのステップは除外します。 FUNNEL = [email_bounce, linkedin_acceptance, email_open, linkedin_reply, email_reply] → この順序で最初に赤となる KPI を選びます。
• s = sev(k, v)、conf = high if s≥0.4 else medium。フラグが付いたステップの送信数が <20 の場合（駆動の根拠が不十分なため）、conf は medium が上限です。「現在の文面」をそのまま表示する場合は、ステップの種類（Intro / Follow-up / BreakUp）を注記します。フラグが付いたステップは別れのステップであってはなりません。
• KPI ごとの原因 + ルーティングスキル：

  linkedin_acceptance -> "targeting or connection note" -> sales-nav-search-builder
  linkedin_reply      -> "message copy"                 -> campaign-challenger
  email_open          -> "subject line or setup"        -> campaign-challenger
  email_reply         -> "message copy"                 -> campaign-challenger
  email_bounce        -> "list quality / warm-up"       -> won-deal-icp-finder   (also flag list hygiene / email verification)
  

• チャネルのヒント（reco）：LinkedIn の返信とメールの返信の両方が採点対象で、一方が赤、もう一方が緑または黄の場合、より強いチャネルを優先し、弱いチャネルの工程を作り直すか削除することを推奨します。
• ランキング： prio = maxsev(driving_reds) × contacted。To-fix カードは prio の降順で並べます。

E7. 送信数で重み付けしたポートフォリオ指標

5 つの指標 KPI それぞれについて、チャネルがアクティブで採点対象となるキャンペーンを横断して Σ分子 / Σ分母 を集計します（パーセンテージの平均ではありません）。整数の % に丸めます。N_LI = LinkedIn 指標に反映されるキャンペーン数、N_EM = メール指標に反映されるキャンペーン数です。指標のゾーン = zone(k, weightedValue)。

E8. 返信の分類と緊急度による並べ替え

• 新たに受信した各返信をスレッドから interested / neutral / not_interested / wrong_fit に分類します。hot = 電話またはミーティングの明示的な依頼です。corr = LGM の自動判定では interested とされたものの、ここで修正したことを示します。chan ∈ {LINKEDIN, EMAIL}。act（対応可能）= cls ∈ {interested, neutral}。
• 経過日数 = floor((asOf − lastMessageAt)/86400000)、最小値は 0 です。urgent = 対応可能かつ経過日数が 3 日超。
• 緊急度による並べ替え（対応可能なもののみ）：グループ 0 = 電話の依頼（hot）、1 = interested、2 = neutral。各グループ内では、待機時間が長いものから並べます。各行に 「waited Xd」 バッジを表示します（緊急の場合は赤いマーカーを付けます）。
• 行として表示するのは interested と neutral のみです。 not_interested / wrong_fit は "open in LGM inbox ↗" リンクの背後に件数としてまとめます。自動判定の修正が引き続き見えるよう、「N corrected」 の集計も小さく表示します。LGM への書き戻しは行いません（ユーザーが LGM で検証します）。

E9. KPI のカウント（North Star、ポートフォリオ全体、今週分）— 更新しても安全

カウントは、処理待ちキューではなく、今週受信したセット（E1 の手順 4b、search_conversations）を参照してください。すでに返信したリードもカウントに含めます。

• TOTAL_POSITIVE_REPLIES（ヒーロー）= 今週受信したスレッドのうち、interested に分類されたもの（通話のリクエストを含む）の数。ポートフォリオ全体が対象です。
• TOTAL_REPLIES（セカンダリ）= 今週受信したスレッドの数（今週リードから届いた返信すべて）。
• 週累計＋更新しても安全： 今週のポジティブな返信数と返信総数（および classifiedReplyIds）をスナップショットに保存します。同じ ISO 週内に再実行する場合、カウント済み ID と新しいセットの和集合を使用します。更新によって、今週すでにカウントした返信が減ることはなく、追加のみとします。（週をまたぐと、想定どおりカウントはリセットされます。）
• 「ポジティブなリード 0 件」というヒーロー表示はしないでください。0 件の場合は、差分に関する注記を付けて 0 とだけ表示します。

E10. 期間比較（差分）

./.lgm-wpa/ のローリングスナップショット履歴から取得します（5 週間以上保持してください）。

• 各カウント KPI と各ゲージについて、先週比と直近 30 日間の週平均比（過去最大 4 週）を表示します。矢印は ▲/▼。上昇は緑、下降は赤 — バウンス率は逆（下降が良好）です。
• 単位：カウントには単位なし。ゲージは pt を使用します。差分が 0 の場合は +0 とします。
• 履歴がまだない場合 → — · 2+ weeks of history からトレンドを表示 と表示し、キャプションを "基準週 — 2 週間以上の履歴が蓄積されるとトレンドが表示されます。" とします。履歴がある場合、キャプションは "差分は今週と先週、および直近 30 日間の週平均を比較します。" とします。

E11. ヘルスカード（ゲージの下、Weekly performance タブ）

1 文だけの「判定」を、次の 2 枚のカードに置き換えます。

• 🟢 On target — 現在緑色のゲージを列挙します（"LinkedIn の承認率 53%、メールのバウンス率 7% ... - すべて目標達成。"）。
• 🟡 Watch — 緑色ではない各ゲージについて、"<KPI> <v>% - 目標 <good>% を <gap>pt 下回る／上回る、<note>" と表示します。note は、gap が 3 以下なら 最適化のみ、緊急ではありません、それ以外は 確認する価値があります（ゲージが赤の場合は 対応が必要です）とします。N 件のキャンペーンを修正 のピルを追加します。続けて赤い行を表示します。 "実際の修正：メインチャネルで修正が必要なキャンペーン N 件 — <name>（<KPI> <v>%）；... まずそのコピーを書き直してください。" — これにより、🔴 キャンペーンがこのタブにも表示され、To do タブへ誘導されます。
• 空の状態： 🔴 キャンペーンがない場合、修正対象カードの領域に "今週は 🔴 キャンペーンがありません — 実施中のキャンペーンはすべて、主要チャネルで On target または Watch です。" と表示します。

E12. ステータス用語（どこでも次の 3 語を使用）

🟢 On target · 🟡 Watch · 🔴 To fix — ゲージの凡例、2 枚のヘルスカード、パノラマのバッジ、キャンペーンカードで同じ用語を使用します。「Healthy」「needs work」「To improve」は表示しないでください。

---

FILL CONTRACT — assets/dashboard-template.html 内のプレースホルダー

assets/dashboard-template.html を読み込み、以下の値を計算して、すべての {{...}} を置換し、結果をライブアーティファクトとしてレンダリングしてください。ユーザーが入力したすべてのテキスト（キャンペーン名、返信メモ、リード名）は、HTML 用にエスケープしてください。色付きゲージ帯と目標目盛りは、入力時に E3 定数から導出します（ゲージのスニペットを参照）。帯の幅をハードコードしてはいけません。しきい値を変更すると、帯も移動します。

プレースホルダー	ソース／値
{{WEEK_LABEL}}	今週の月曜日。例：Jul 6, 2026（タイトルのみ）。
{{LAST_UPDATE}}	データ取得を実行した日付。例：Jul 7, 2026。
{{REFRESH_TASK_ID}}	フェーズ 4.5 で実行時に取得したスケジュール済みタスク ID（このユーザー自身のタスク）。ルーチンが作成されなかった場合は、空文字列を入力してください。すると ↻ ボタンに親切なアラートが表示されます。テンプレートファイルに実際の ID を入れないでください。
{{SR_SUMMARY}}	スクリーンリーダー用の 1 行サマリー：Weekly Performance Advisor, week of {WEEK_LABEL}: {posReplies} positive replies of {totalReplies}; {tofixCount} campaigns to fix; {nAct} actionable replies including {nHot} call requests.
{{TODO_COUNT}}	nAct（対応が必要な返信）— To-do タブのピル表示数。
{{MOVES}}	<li>...</li> を 2～3 項目（スニペット M を参照）。通話、興味あり、中立、修正対象数から作成します。
{{N_ACT}}	対応が必要な返信数（3 か所で使用）。
{{N_HOT}}	通話リクエスト数。
{{REPLY_PROMPT}}	エスケープした返信トリアージ用プロンプト（スニペット P）。
{{REPLY_ROWS}}	対応が必要な返信 1 件につき <tr> を 1 行。緊急度順（スニペット R）。
{{INBOX_LINK}}	対応不要な返信がある場合は、修正後の件数を含む受信トレイリンク（スニペット I）。それ以外は空文字列。
{{TOFIX_CARDS}}	prio 順の修正対象カード（スニペット C）。該当なしの場合は空状態カード（E11）。
{{TOTAL_POSITIVE_REPLIES}}	posReplies（E9）。
{{TOTAL_REPLIES}}	totalReplies（E9）。
{{POS_REPLIES_DELTA}} / {{TOTAL_REPLIES_DELTA}}	各件数 KPI の増減スパン（スニペット D）。
{{DEALS_VALUE}}	デフォルトは —。ディールレイヤーが実行された場合（フェーズ 3）は、ディール数／€。
{{DEALS_NOTE}}	デフォルトは connect HubSpot to pull deal data。それ以外は短いディールに関するメモ。
{{DELTA_CAPTION}}	E10 のキャプション（履歴とベースラインの比較）。
{{N_LI}} / {{N_EM}}	ゲージのデータ件数（E7）。
{{GAUGES}}	順番に 5 つのポートフォリオゲージ：linkedin_acceptance、linkedin_reply、email_bounce、email_open、email_reply（スニペット G。各ゲージは .stat と増減表示で囲みます）。
{{HEALTH_CARDS}}	.hcards ブロック（E11、スニペット H）。
{{PANORAMA_ROWS}}	スコア付けされたキャンペーンごとに prow+drow の組を 1 つ。修正対象を先にし、その後は接触数の降順で Watch／On-target を並べます（スニペット PANO）。
{{LOW_SAMPLE_ROWS}}	サンプル数が少ない場合のヘッダー行と、該当するキャンペーンごとの行（スニペット LOW）。該当なしの場合は空文字列。

スニペット G — ゲージ（帯は定数から導出）

「up」KPI の場合（good, floor）は、針の左端 = clamp(value,0,100)%、z = zone(k,value)：

<div class="stat"><div class="k">{LABEL}</div>
 <div class="gauge"><span class="gbands">
  <span class="gb r" style="left:0;width:{floor}%"></span>
  <span class="gb y" style="left:{floor}%;width:{good-floor}%"></span>
  <span class="gb g" style="left:{good}%;width:{100-good}%"></span>
  <span class="gtick" style="left:{good}%"></span>
  <span class="gneedle {z}" style="left:{value}%"></span></span>
  <span class="gval {z}">{value}%</span><span class="gtgt">target ≥{good}%</span></div>
 <div class="dwrap">{DELTA}</div></div>

「down」 KPI（email_bounce）の場合：帯は g（0→good）、y（good→floor）、r（floor→100）、目盛りは good、目標テキストは target <{good}% です。ラベル：LinkedIn acceptance、LinkedIn reply、Email bounce、Email open、Email reply。同じゲージのマークアップ（.dg による行レイアウト）をキャンペーン詳細行でも再利用します。詳細行では .stat／増減表示のラッパーを付けません。

スニペット D — 増減スパン

<span class="delta"><span class="dl">vs last wk</span> <b class="d {cls}">{▲/▼ ±d}{unit}</b><span class="dl">· vs 30d</span> <b class="d {cls}">{▲/▼ ±d}{unit}</b></span>

cls は up/down/flat のいずれかです。履歴がない場合 → <span class="delta none">- · trend starts after 2+ weeks</span>。

スニペット M — 動きのリスト（形式例。データに合わせて調整してください）

<li><b>Answer the {nHot} call requests</b> ({callNames}){ - firstCall waited Xd if urgent}. Then reply to {firstInterested} and nudge the {nNeutral} warm neutrals.</li>
<li><b>Rewrite the flagged copy</b> on the {N} campaign(s) leaking their main-channel reply rate.</li>
<li><b>Keep classifying replies in LGM</b> so next week's trend stays live.</li>

返信がなければ 1 行目を、修正対象のキャンペーンがなければ 2 行目を削除してください。内容を捏造せず、実際に存在する名前や件数のみを記載してください。

スニペット R — 返信行（対応が必要なもののみ、緊急度順）

<tr><td class="cname">{lead}{ <span class="hotpill">CALL</span> if hot}{ <span class="corrpill" title="LGM auto-qualify said interested; corrected">corrected</span> if corr}</td>
<td><span class="wbadge{ urgent}">waited {X}d</span></td>
<td><span class="chan {li|em}">{LINKEDIN|EMAIL}</span></td>
<td><span class="rcls {good|neu}">{interested|neutral}</span></td>
<td class="rnote">{why}</td></tr>

スニペット I — 受信トレイリンク（修正後の件数を含む）

<a class="inboxlink" href="https://app.lagrowthmachine.com/" target="_blank" rel="noopener">{N} more replies (not interested / wrong fit){, M corrected} - open in LGM inbox ↗</a>

スニペット P — 返信トリアージ用プロンプト（ボタンの data-prompt に設定。エスケープ済み）

Use the /reply-draft-assistant skill. Handle my {nAct} actionable replies across all running campaigns, most urgent first: {nHot} call requests ({callNames}) first, then {nInterested} interested and {nNeutral} warm neutrals to nudge (some have waited over a week). Draft each in the thread language for my approval. If the /reply-draft-assistant skill is not installed, download it from https://github.com/LaGrowthMachine/gtm-system first, then run it.

スニペット C — 修正対象カード

card-name、badge tofix バッジと contacted N のメタ情報、data-prompt（エスケープ済み）がルーティングスキルに従って生成される Fix-this ボタンを含むカードです。

• campaign-challenger: Use the /campaign-challenger skill. Challenge campaign "{name}" ({label} {value}%, below the {floor}% floor, likely {cause}): rewrite the current copy of the flagged step. If the /campaign-challenger skill is not installed, download it from https://github.com/LaGrowthMachine/gtm-system first, then run it.
• sales-nav-search-builder: ... Rebuild the targeting for campaign "{name}" ({label} {value}%, below the {floor}% floor): draft a tighter Sales Navigator search and connection note. ...
• won-deal-icp-finder: ... Clean the audience for campaign "{name}" ({label} {value}%, below the {floor}% floor): rebuild it from a verified ICP list. ...

続いて fix1 ブロック（Fix #1 タグ、KPI ラベル、{conf} confidence、{value}% now · target ≥{good}% · floor {floor}% · {gap} pt(s) under target、Likely cause: {cause}）、任意のチャネルヒント reco ボックスとウォッチ／レッグのチップ、任意の diag-out 診断行と focus の「Current copy to rewrite」 ブロック（ステップのコピー原文、チャネルとステップ種別）、およびファネル全体のゲージを含む <details> です。テンプレートの CSS にあるクラス名をそのまま使用してください。

スニペット PANO / LOW — パノラマ行

スコア対象のキャンペーンごとに、クリック可能な prow と非表示の詳細行 drow を配置します。列は Campaign、Contacted、Accept、 LI reply、Email open、Email reply、Status badge、Fix #1 です。KPI が欠けている場合は —、サンプル不足／エンゲージメントなしの場合は n/a（クラス zi）を表示します。サンプル数が少ないブロックでは、lowhead 行に Below sample floor - listed for completeness, not scored を表示し、サンプル数の少ないキャンペーンごとに prow low を配置します。詳細には {contacted} contacted · ... - not scored (below the 20-contact floor; rates on so few sends aren't reliable). と表示します。

---

スナップショットの永続化（現在のプロジェクト内）

スキルを実行するプロジェクトに ./.lgm-wpa/ を作成し、現在の ISO 週の ./.lgm-wpa/snapshot-<YYYY>-W<ww>.json に書き込みます。保存する内容：

{
  "week": "2026-W28",
  "identities": ["<id>", ...],
  "counts": { "posReplies": N, "totalReplies": N },
  "positiveReplyIds": ["<conversationId>", ...],   // this-week ids classified interested (for the union)
  "weekReplyIds": ["<conversationId>", ...],        // this-week ids that received a lead reply
  "gauges": { "linkedin_acceptance": %, "linkedin_reply": %, "email_bounce": %, "email_open": %, "email_reply": % },
  "campaigns": [ { "id", "name", "contacted", "status", "fix1": {...}|null, "kpis": {...} } ],
  "classifiedReplyIds": ["<conversationId>", ...]   // every id already classified (skip-list, incremental)
}

• 初回実行 = ベースライン： 過去のスナップショットがない場合、すべての差分に — とベースラインのキャプションを表示します。
• 上書きする前に最新の過去のスナップショットを読み込み、週次（WoW）および過去 30 日間の差分を計算し、すでに分類済みの返信 ID をスキップします。約 4 週間の平均を計算できるように5 週間以上保持し、それより古いものは削除します。
• ISO 週ごとにスナップショットは 1 つです。 同じ週に再実行した場合、その週のファイルを更新します。新しい取得結果を使って positiveReplyIds / weekReplyIds を統合し、統合結果から counts を再計算してから保存します（これにより、ヒーロー数は再取得後も安全に保たれ、その週の間は増加のみとなります）。差分の比較対象は常に過去の週のスナップショットであり、今週の以前の実行結果は対象にしません。

受け入れ基準（完了前のセルフチェック）

• 新しい環境で LGM が存在しない → スキルに沿ってインストールし、完了を待ってから再検出し、その後に処理を続行した。
• LGM が存在する → 通知なしで検出し、本人確認を尋ね、（任意で）商談についても尋ね、ユーザー自身の実際のデータから成果物を作成した。ユーザー以外のデータは、どこにも表示されていない。
• HubSpot と campaign-impact-analyzer が存在する → 商談レイヤーを提示し、処理を委任した。
• campaign-impact-analyzer が存在しない → ダッシュボードはそのまま提供し、引き継ぎ時にインストール先を案内した。
• 出力は、利用可能な成果物ツール（ツール名をハードコードしない）でレンダリングしたライブ成果物（2 タブ）であり、スナップショットを ./.lgm-wpa/ に保存した。
• 更新ルーチンを提示した（Phase 4.5）： はいの場合 → 月曜日のタスクを作成し、実行時 ID を {{REFRESH_TASK_ID}} に挿入して、↻ ボタンを有効にした。スキップの場合 → ID を空にし、ボタンが適切にフォールバックするようにした。提供するファイルには実際のタスク ID を埋め込んでいない。
• 件数は更新に安全： posReplies／totalReplies は、今週の RECEIVED セット（search_conversations）から取得し、週内で保存・統合するため、週の途中で更新しても既にカウント済みの返信が消えることはなく、追加のみが行われる（対応待ちキューによる過少カウントを解消）。
• ステータス用語を「目標達成／要注意／要修正」に統一し、すべての箇所で使用した。メール返信では 🟢≥6／🟡3-6／🔴<3 を使用した。バウンス率ゲージ（到達可能性ではない）を使用した。ベンチマークの出典やブランドは記載していない。英語で、単独で完結している。