objection-analyzer

Objection Analyzer

アウトバウンドの会話を分析し、実際に寄せられている反論を順位付けして示します。チームの回答を評価し、実行するたびに磨きがかかる対処プレイブックを作成します。

出力のルール — 最初にお読みください

このスキルを実行したら、成果物のみを返してください。それ以外は何も返さないでください。 前置き（「では…」「このスキルを使えば…」など）、取得・統合・表示しようとしている内容の説明、これらの指示の言い直しは不要です。ユーザーが求めているのは分析結果であり、処理の説明ではありません。

ユーザーが使用した言語で回答し、最後までその言語を使ってください。 英語で始めて、分析結果の途中でフランス語に切り替えないでください。

数値はテキストの壁ではなくウィジェットとして提示してください。 数値を含む結果を出す実行では、必ず最後にウィジェットを付け、周囲の文章では数値を繰り返さず、その意味を説明してください。モードごとのバリエーションと文章量の上限については、references/lgm-handoff.md を参照してください。数値がない場合は、その旨を伝えてウィジェットは省略してください。

出力するすべての数値は、スクリプトの JSON から一字一句変えずに引用してください。 数値を再計算したり、丸めたり、「約3分の1」のように曖昧にしたりしないでください。率を出すときは必ず n も併記してください。スクリプトが率を非表示にした場合は、推測せず非表示であることを示してください。

重要な情報が不足している場合は、具体的な質問を1つだけ簡潔にして、そこで止めてください。 回答例、件数、傾向を捏造しないでください。

情報源 — 最初にお読みください

必要な情報はすべてこのスキルのフォルダーにあります。 フォルダー外のファイルを grep しないでください。

9種類の反論、回答の内訳、コーチング用の表、各モードのワークフローは以下に記載されています。通常の処理では参照ファイルを開かないでください。その他の情報は必要に応じて確認してください。

読むもの	読むタイミング
references/coaching-rubric.md — 0〜3の評価基準を含む9つの評価項目、目標を考慮した採点、禁止表現、スレッドを台無しにする要因	回答を採点する前、モード1
references/lgm-handoff.md — 3種類のウィジェット、文章量の上限、固定 CTA、LGM の分岐	出力を表示する前
references/response-templates.md — テンプレートを用意する反論、出典、形式、変数	モード5
references/baseline-playbook.md — 表示処理で挿入するカードの全文	データなしでコーチングする場合、またはカードの根拠を尋ねられた場合
references/persistence.md — 解決手順、状態スキーマ、カードのレイアウト、消去	doctor が home 以外を報告した場合
references/sibling-patch.md — 検出手順と正確なパッチ	実行の最後、返信スキルとの連携を提案する場合
references/objection-taxonomy.json — 機械 ID、別名、スキル間の対応付け	別のスキルのラベルをカードに対応付ける場合のみ

数値を自分で計算しないでください。 件数、割合、リカバリー率、中央値、傾向、統合結果はすべて python3 scripts/analyze.py から取得します。分類して文章を書くのはあなた、集計するのはスクリプトです。もっともらしくても誤ったリカバリー率を出すと、チームは四半期にわたって誤った反論へのコーチングに取り組むことになります。

できること

5つのモードがあります。依頼が曖昧な場合（「自分の異議を見て」など）は、妥当なデフォルトの範囲でモード4を実行します。全体像を求められた場合は、モード5を実行します。

モード	出力内容
1 — 分析	異議のランキング、種類ごとの回復率、セグメンテーションの判定を含む返信の内訳、各異議への対応を採点した評価
2 — コーチング	ある種類への対処法：掘り下げる質問、捉え直し、切り上げ方、言ってはいけないこと。データがなくても使えます。
3 — キャンペーンの修正	回避可能な異議の原因となっているシーケンスのメッセージと、その書き直し
4 — フル	1を実行し、上位3件に対して2を実行してから、ユーザーが指定した範囲で3を実行
5 — 全件調査	コーパス全体を対象に、すべての異議を分類し、頻度の高い異議ごとに再利用可能な返信テンプレートを作成

どのモードでも、範囲を指定する必要があります。自然な言葉で、期間（「今週」「過去30日間」）、キャンペーン、チャネル、または個人を指定します。名前が指定された人物はlist_identitiesで、キャンペーンはlist_campaignsで照合します。曖昧な場合は候補を列挙して確認し、ひとつに決めつけないでください。「自分の異議」は独立した範囲であり、チームレポートの縮小版ではありません。二人称で回答し、名前の挙がった同僚と比較せず、担当者ごとのランキングはteam-performance-dashboardに任せてください。

プレイブックの保存場所

毎回、最初にpython3 scripts/analyze.py doctorを実行し、保存先を一文で伝えてください。スキルフォルダーは起点にすぎません。データは更新後も残る場所に保存されます。

次の5つの階層のうち、書き込み可能な最初の場所を使用します：$OBJECTION_PLAYBOOK_DIR（チーム共有フォルダー）、~/.gtm-skills/objection-analyzer/（デフォルト。再インストール後も保持されます）、スキルフォルダー、作業ディレクトリ、続いてpaste。階層の詳細はreferences/persistence.mdを参照してください。skill階層の場合は、更新によってデータが消えることを警告してください。

paste階層にはエンジンがありません。その旨を伝え、すべての数値に推定値と明記し、n<10の場合は回復率を出さないでください。最後に、状態をフェンス付きコードブロックで出力します：「これはあなたのプレイブックです。保存して、次回貼り付けてください。」

ワークフロー

ステップ0 — 範囲を確定して読み込む

doctorを実行し、階層、インスタンス数、既存の実行回数を記録します。seen_thread_idsを読み込みます。該当するスレッドはすでに分析済みであり、再読込してはいけません。初回の実行であれば、その旨を一文で伝えてください。

ステップ 1 — 会話を取得し、取得前に確認する

ソースを黙って検出します。 利用可能なツールと、ユーザーから提供された情報を確認します。ユーザーに環境を説明するよう求めたり、検出内容を逐一伝えたりしてはいけません。

• ソースがまったくない場合 → 会話の提供を依頼し、そこで終了します。thread_id, direction, timestamp, content（任意項目：channel、campaign、identity、lead_ref、status）を含む CSV、または貼り付けられたスレッドのどちらかを依頼します。データを捏造してはいけません。
• 「自分の」反論の場合 → まず list_identities で誰の反論なのかを特定します。明らかな候補があればそれを使い、複数の候補が考えられる場合は質問します。自分について尋ねた人に対して、チーム全体を黙って分析してはいけません。
• 1 つ以上のソースがある場合 → 必ず、何かを取得する前に確認します。ツール名、対象範囲、おおよその量を伝えます：

  「La Growth Machine の会話を分析しますか？ 対象範囲：キャンペーン『Q3 Founders』、過去 90 日間、返信のあるスレッドが約 60 件です。先に対象を絞り込みますか？」 複数のツールが使える場合は、それらを列挙してユーザーに選んでもらいます。ユーザーが望んでいない大量取得は、このスキルがユーザーに余計な費用を発生させる主な原因です。

La Growth Machine MCP を使う場合は、ハイドレートする前に絞り込みます：

search_conversations(leadReplied=true, campaignIds?, lastMessageAtFrom?, limit)
   → conversationId, leadId, identityId, channel, status      (ids only, no text)
get_conversation_messages(conversationId)                     → the FULL thread

seen_thread_ids に含まれるものは除外しますが、recheck_thread_ids に含まれるものは必ず再読み込みします。結果はまだ変わる可能性があり、スキップするとリカバリー率の分母から除外されてしまいます。キャンペーンを対象範囲にする場合は、list_campaigns → get_audience_leads → get_lead_conversations の順に実行すると、リード名も取得できます。

数値に影響する注意点が 3 つあります：

• status: SEND_FAILED は direction: received として現れることがあります。 これは返信ではなく、こちらからの送信失敗です。direction よりも status を優先してください。
• INFO と AUTO_QUALIFY の行はプラットフォームイベントであり、direction: received として届きます。is_event: true としてマークし、絶対に除外しないでください。メッセージを削除すると、その後のすべてのインデックスがずれ、同じ反論に新しい instance_id が付与されて、次のマージで二重計上されます。マークしないと、返信後にイベントが届いた場合に、リードが戻ってきたと判定され、リカバリー率が水増しされます。イベントの内容自体も手がかりになります。「すでに導入済みのようです」という AUTO_QUALIFY のメモは、competitor_in_place という判断を裏付けます。
• LGM の受信トレイ URL に含まれるのは会話 ID ではなく identityId です。 キャンペーン名から始めてください。

別のプロスペクティング MCP を使う場合も、同じ手順です：返信のあるスレッドを一覧表示し、全タイムラインを取得して、実行スキーマにマッピングします。CSV の場合は、 python3 scripts/analyze.py normalize export.csv を実行します。

ステップ 2 — 会話の目的を明確にする

キャンペーンごとに、またはスレッドから目的が明らかでない場合は、必ず確認します。 対象範囲の確認と一緒に 1 つ質問すれば、追加のやり取りは必要ありません：

「これらの会話で目指している成果は何ですか？ 商談の予約、セルフサービスでの登録、リソースのダウンロード、パートナーシップ、それとも今四半期は提案を行わないナーチャリングですか？」

これは形式的な質問ではありません。反論の内容はほとんど変わりませんが、返信の着地点は目的によってまったく異なります。同じ「高すぎる」という反論でも、商談が目的なら確認質問をしてから日程を提案し、登録が目的なら直接回答して製品を紹介し、ナーチャリングが目的なら提案自体を行いません。誤った着地点を基準に評価される担当者は、誤った評価を受けることになります。

実行時に scope.goal として引き継ぎ、meeting、signup、resource、partnership、nurture、unspecified のいずれかを指定します。スクリプトはこれを実行情報とともに記録し、未知の値は受け付けません。そのため、プレイブックには常に何を基準に評価したかが示されます。ユーザーが本当に分からない場合は unspecified を使い、その場合は対応スコアのディメンション 7 が信頼できないことを明確に伝えます。複数の目的が混在する場合は、目的ごとに平均するのではなく、キャンペーンごとに分けます。

9 種類の異議

異議とは、やり取りを続けている相手から提示される障壁です。自ら対象外だと判断した相手は wrong_fit で、別にカウントされます。また、同じくらい重要です（返信の内訳を参照）。

種類	分類	例
competitor_in_place	ソリューション	「すでに X を使っています」「社内で対応済みです」
feature_gap	ソリューション	「X はできますか？」「SSO がなければ契約しません」
tried_before	ソリューション	「2 年前に試しましたが、うまくいきませんでした」
price_budget	商業面	「高すぎます」「今年は予算がありません」
timing	商業面	「今は適切なタイミングではありません」「次の四半期なら」
value_doubt	商業面	「本当に効果がありますか？」「うますぎる話に聞こえます」
process_authority	プロセス	「X に確認する必要があります」「調達部門が担当しています」
scope_mismatch	プロセス	「外部委託しました」「現在はインバウンドのみです」
channel_trust	信頼	「私の番号をどこで入手しましたか？」「これは自動化されていますか？」

スクリプトは、このリスト以外の種類を受け付けません。タイプミスがあると、いつまでも増え続ける架空のカテゴリが作られてしまいます。

返信の内訳 — 付随的な指標ではなく、主要な出力

異議のランキングと合わせて、返ってきた返信の内訳全体を必ず報告してください。 interested、curious、question、objection、wrong_fit、not_interested、 auto_ooo、voice_message です。分母は受信した返信数とし、その旨も明記してください。

wrong_fit には、独自のセグメンテーション判定が伴います。これは、最も明確なターゲティングの証拠だからです。サブタイプを付けてください。

サブタイプ	リストに対する意味
wrong-person	対象とした職位または職能が間違っています。役職のフィルターを修正してください。
not-icp-segment	業界または企業規模が間違っています。セグメントのフィルターを修正してください。
not-icp-junior	対象とする職位の下限が低すぎます。引き上げてください。
job-seeker	リストのソースに不適切なデータが混入しています。対象者の情報源を確認してください。

本物か、口実か

これは種類ではなく、個別のケースに付けるフラグです。3 つのブール値を付け、スクリプトに 2/3 ルールを適用させます。値は pre_information、no_specifics、immediate_drop です。定義と、対応が異なる理由（掘り下げてから再構成するか、相手に率直に断れる機会を示す沈静化の質問を 1 つするか）については、references/coaching-rubric.md を参照してください。

モード 1 — 分析（ステップ 3）

1. 各スレッドに注釈を付けます。 返信カテゴリを記録します。objection の場合は、種類、異議のメッセージインデックス、200 文字以内の逐語引用、3 つの煙幕マーカー、異議後の結果を記録します。reply_category と post_objection_category は固定の語彙であり、スクリプトは未知の値を拒否します。後者は回復率の分子を決めるため、推測してはいけません。こちらが返信している場合は、こちらの返信インデックス、そのテキストを handling.verbatim として記録します（カードの「clone this」に引用される内容です）。さらに、references/coaching-rubric.md の 9 次元ルーブリック（各 0～3 点、合計 27 点満点）と、最も弱い項目についての 1 文の should_have を記録します。次元 7 は、一般的な「良い返信」の考え方ではなく、ステップ 2 の目標に照らして採点します。送る内容はフックであり、誘導する先が目的地です。完璧なフックを送っても目的地につなげていない返信の得点は 3 ではなく 1 です。
2. 実行用 JSON を作成し、エンジンに渡します。

python3 scripts/analyze.py analyze run.json > report.json
python3 scripts/analyze.py merge report.json --write
python3 scripts/analyze.py render

3. report.json を読み、そこに書かれていることだけを報告します。 1 つの種類が複数のシグナルに該当することがあります。diagnosis.also_firing にその他のシグナルが列挙されるため、重複を隠さず「コピーであり、ターゲティングにも問題があります」のように伝えてください。こちらの最初のメッセージが引き起こした種類は、プロダクトのギャップではありません。種類ごとに、件数、割合、n を併記した回復率、未返信率、返信時間の中央値、対応スコアの中央値、初回接触の割合、煙幕の割合、コピー／ターゲティング／プロダクトに関する判定とその確信度を報告します。

回復率は分析の中心となる指標なので、正確に述べてください。こちらが返信し、かつ少なくとも 7 日間経過した異議のうち、見込み客が再び返信した割合です。それより新しいスレッドは pending として扱い、分数の分子にも分母にも含めません。n が 5 未満の場合、スクリプトは抑制を返します。その場合はパーセンテージではなく、n=3 — too few to rate と表示します。

コーチングのパート。 種類ごとに最高得点の返信（22 点以上）を「clone this」の例として取り上げ、最も弱い返信を should_have とともに示し、傾向を読み取ります。高得点なのに回復率が低い場合、問題は対応方法ではありません。回復率がまずまずなのに得点が低い場合は、全体の中で最も簡単に改善できます。初回の実行では、未返信率の高さが最大の発見となることがよくあります。

報告してはいけない内容は、レポートの not_computed[] 自体に記載されています。推論で補わず、これに従ってください。主な例として、異議による売上損失（campaign-impact-analyzer を参照）や、どのシーケンスのステップが異議を引き起こしたかがあります。また、次の点を一度、はっきり伝えてください。この分析は返信を読み取るため、一度も返信しなかった人が何に異議を唱えていたかは分かりません。

モード 2 — コーチ

プレイブックに該当するタイプのデータがあればユーザー自身のカードから、なければベースラインから回答します。どちらを使っているか伝えてください。

タイプ	通常の意味	掘り下げる質問	その後	絶対にしないこと
competitor_in_place	現状で十分に対応できている、オンボーディングがうまくいかなかった、または丁寧に断ろうとしている	「そちらでは［具体的な業務］はどのように進んでいますか？」	相手が挙げたギャップを軸にし、機能を持ち出さない	既存の製品を批判する
feature_gap	ブロッカーを装った購入のシグナル	「日々の業務で、具体的にどんなことができる必要がありますか？」	正直に回答する：対応している、別の方法で対応している、または対応していない	期日を示さずに「ロードマップにあります」と言う
tried_before	あなたへの異議ではなく、過去の経験に基づく反応	「ツール自体が問題でしたか、それともその周辺すべてが問題でしたか？」	具体的に何が違うのかを伝える	「今はすっかり違います」と言う
price_budget	比較対象が見えない価格比較	「何と比べて高いのでしょうか？」	相手が挙げたものを軸にする	初回の返信で値引きする。絶対にしない
timing	優先順位の調整、やんわりとした断り、予算不足を含む	「今、何を優先されていますか？」	その優先事項に結び付け、相手の予定に合わせた日付を設定する	「いつ頃がよろしいですか？」と言う
value_doubt	カテゴリー自体は信じているが、あなたの主張は信じていない	「どのようなことを確認できればよいですか？」	主張を仕組みの説明に置き換え、注意点を加える	より大きな数字を出す
process_authority	後押しの材料を必要としている推進役、または盾	「そちらでは通常、何を基準に決めていますか？」	そのまま転送できるものを一つ渡す	上司に取り次いでもらうよう頼む
scope_mismatch	担当業務がなくなった。たいていは単にそのとおり	「どなたが引き継がれましたか？」	紹介を頼むか、ここで終える	「でも、きっとまだ必要ですよね……」と言う
channel_trust	こちらの文面が招いた不信感	掘り下げない	情報源を正直に答え、こちらから先に配信停止を提案する	曖昧な情報源を示すこと、またはそのメッセージで売り込むこと

9つすべてに共通するルールは2つです：言い換える前に掘り下げること、そして会話の終了もプレイの一部だということです。掘り下げる質問は目標によってほとんど変わりません。変わるのは、返信がどこへつながるかです。ミーティングが目標なら日程調整、サインアップが目標なら製品、リソースが目標なら適切な資料を一つ提示して質問を添える、ナーチャリングなら依頼はしません。前向きな反応を示した相手を待たせず、反応が控えめな相手に最も負担の大きい依頼をしないでください。channel_trustで自動送信か、AIが書いたものかを尋ねられた場合は、正直に答えてそこで止めます。自律型ワークフローでは、人間に引き継ぐケースです。

このモードが示すのは切り口です。メッセージの作成は行いません。ユーザーが具体的なスレッドを1件貼り付けて、送信できる文面を求めている場合は、reply-draft-assistantに引き継いでください。また、MCPに接続されているもののプレイブックが空の場合は、アップグレードを一度だけ提案してください：「会話を取り込んで、ベースラインではなく、あなた自身の数値をもとに回答できます。ご希望ですか？」 — ステップ1と同じ確認ゲートを適用します。

モード 3 — キャンペーンの修正

スコープの境界。 対象：どのシーケンスメッセージが回避可能な異議を引き起こしているか、およびその書き換え。 対象外：ベンチマーク（campaign-challenger）、シーケンス全体の作成 （multichannel-campaign-builder）、ターゲティング戦略、アトリビューション。

異議がファーストタッチで発生し、その割合が他のすべてのタイプのベースレートを15ポイント以上上回る場合（1つずつ除外して比較し、判定が他にまとめた項目に左右されないようにします）、または判定が copy の場合、あるいはタイプが channel_trust または value_doubt の場合、その異議は上流で修正できる可能性があります。以下の5つの原因に当てはめます。

原因	特徴	修正
価格を早い段階で提示	ファーストタッチでの price_budget	金額を削除し、仕事の内容から話を始める
仕組みの説明がない主張	value_doubt が高い	主張を控えめにし、仕組みと注意点を加える
スクレイピングを思わせるパーソナライズ	channel_trust が上昇	人間なら把握していないような詳細を削る
ニーズを決めつけている	1つのキャンペーンに scope_mismatch が集中	これはコピーの問題ではなく、リストの問題です。その旨を伝えます。
機能を前面に出した書き出し	ファーストタッチでの feature_gap	仕事の内容から始め、機能の話は後にする

MCP が利用できる場合は、get_campaign_messages で現在のコピーを取得します。各書き換えは、それぞれ独立したネイティブのフェンス付きコードブロックに入れ、置き換えるステップを見出しとして付けます。メッセージと異議の対応関係を示す Variant B ウィジェットより上に配置してください。コピーの原因に該当するものがなければ、無理に当てはめず、ウィジェットも表示しないでください。確認した異議、そのいずれも該当しなかった理由、コピーのパターンを明らかにするために実際に必要なスコープを伝えます。

このスキルでは edit_campaign_message をはじめ、いかなる書き込みツールも絶対に呼び出さないでください。 分析の副作用として、実際に進行中のキャンペーンを変更してはいけません。代わりに、次のスキルを検索して連携してください。**/campaign-challenger/SKILL.md と **/multichannel-campaign-builder/SKILL.md を Glob で検索します。どちらか一方でも見つからない場合は、次の文を先頭に付けてください。 "> campaign-challenger と multichannel-campaign-builder を併用すると効果的です。見つからないスキル： <name> — そのステップを可能な範囲でインラインで実行します。"

モード 4 — フル

モード 1 を実行し、続けて上位3タイプにモード 2 を実行します。その後、指定されたスコープを対象に、上流で修正できるものにモード 3 を実行します。ウィジェットは3つではなく、最後に1つだけ表示します。

モード 5 — コーパス全体を調査し、テンプレートを作成する

フラッグシップの実行です。同じエンジンを使いますが、モード 4 とは 3 つの違いがあります。スコープフィルターを使わず、すべての異議をサンプルではなく分類し、再利用できるチーム向け資料で締めくくります。

1. すべてを調査します。 キャンペーンや担当者のフィルターは使いません。 search_conversations {leadReplied: true} を最後までページネーションし、seen_thread_ids をスキップします。開始前に合計件数を伝えます。「返信のあるスレッドは約 340 件です。コーパス全体を対象にしますか、それとも直近 6 か月にしますか？」バッチごとに分類して統合するので、途中で中断しても学習した内容が残ります。キャンペーンごとに目標は異なるため、グローバルな値を 1 つ設定するのではなく、キャンペーンごとに scope.goal を記録します。
2. 分析します。 モード 1 と同じ方法で、ランキング、回復率、セグメンテーションの判定を含む返信の内訳、対応評価を行います。
3. 推奨します。 何を改善できるかに基づいて優先順位を付けた 3〜5 件のアクションを示し、それぞれで異議、その判定、担当者を明記します。copy はシーケンスの修正、targeting はリストの修正、product はルーティングの判断です。未返信率が高い場合は、この 3 つより優先されるプロセスの修正が必要です。各アクションには JSON 内の数値を引用します。
4. よくある異議ごとに返信テンプレートを 1 つ作成します。 references/response-templates.md に従います。異議の 8% 以上を占めるものを対象とし、最大 6 つまでとします。存在する場合は channel_trust を必ず含め、判定が product の場合は含めません。該当する異議への返信が 22 件以上ある場合は、それらから文面を引用してその旨を明記します。そうでない場合はベースラインから引用し、その旨を明記します。各テンプレートはそれぞれ独立したフェンス付きブロックに入れ、出典、変数、機能しない状況を記載します。
5. 保存します。 各テンプレートを出典とともに cards.<type>.template に書き込みます。これにより、render がカードにテンプレートを含められ、次回の調査で最初からやり直すのではなく改善できます。

テンプレートはチーム向けの資料であり、送信用メッセージではありません。変数を含み、そのまま送信することはありません。実際のスレッドへの実際の返信文の作成は、reply-draft-assistant の役割です。引き継ぎ時にその旨を伝えてください。さもないと、LinkedIn にそのまま貼り付けられてしまいます。

関連する返信スキル

モード 1、4、5 の実行終了時に限り、ロード時には行わず、返信文作成スキルがインストールされているか確認し、プレイブックと連携することを提案します。これにより、そのスキルの異議への下書きが一般的な切り口ではなく、バトルカードに基づいて作成されます。

提案するだけで、編集はしません。 このスキルが別のスキルのファイルを編集することはありません。対象の絶対パスと差分を表示し、明示的な承諾があった場合に限り適用します。また、そのスキルをパッケージから再インストールすると変更が元に戻る可能性があることを伝えます。

検出の手順、reply-draft-assistant に適用する正確な 3 部構成のパッチ、インストールされているスキルがない場合の提案内容は references/sibling-patch.md に記載されています。実行時にこの段階で参照してください。

バトルカード

render はタイプごとに 1 枚のカードを作成します。カードには数値、自分のデータが示す内容、モード 5 で作成済みの場合は返信テンプレート、ベースラインの本文が含まれます。セクションの順序は references/persistence.md に記載されています。次の 2 つの誠実性ルールが適用されます。22/27 未満の事例は掲載せず、手動編集されたカードは報告してスキップし、上書きしません。会話が 0 件でも、ベースラインカード 9 枚はすべて生成されます。

出力と LGM への引き継ぎ

数値を出す実行はすべてウィジェットで締めくくり、その周囲の説明文では数値を繰り返すのではなく、その意味を伝えます。3 つの形式があります。モード 1、4、5 のランキング、モード 3 の原因と書き換え、アドホックなモード 2 の単一カードです。それぞれに説明文の上限があります。詳細は references/lgm-handoff.md を参照してください。コピー可能なテキストをウィジェットに入れてはいけません。iframe はサンドボックス化されており、クリップボードを使えないため、書き換え文とテンプレートはウィジェットの上にあるフェンス付きブロックに記載します。数値を出さない実行では、説明文のみを出力し、ウィジェットは表示しません。

ウィジェットの正確な HTML、プレースホルダーの表、判定ごとに固定された CTA ラベル、解決済みの引き継ぎ分岐は references/lgm-handoff.md に記載されています。ウィジェットを表示する前に参照してください。また、すべての分岐に適用される「会話全体で LGM に一度だけ言及する」ルールも記載されています。

例

What objections are we getting most, and are we handling them well?
Sweep everything, categorize the objections, and give me a template for each frequent one.
Comment répondre à l'objection "on a déjà un outil" ?
Which sequence messages are causing these objections, and how would you rewrite them?

テスト

python3 scripts/analyze.py --test

カウント、回復コホート、マージの冪等性、およびすべての拒否パスを網羅するゴールデンケースです。件数は実行時に出力される値です。テストがすべて成功しなければ、リリースしません。