gate-news-eventexplain

gate-news-eventexplain

一般ルール

⚠️ 停止 — 続行する前に、共通のランタイムルールを必ず読み、厳守してください。 すべてのルールを読み終えるまで、ツールを選択したり呼び出したりしないでください。これらのルールが最優先です。 → gate-runtime-rules.md をお読みください。 → gate-info／gate-news 固有のルール（ツールの機能低下、レポート基準、セキュリティ、ルーティングの機能低下、scripts/ が存在する場合のスキルごとのバージョン確認、レガシーラッパーのルーティング）については、info-news-runtime-rules.md もお読みください。

• このスキルに明示的に記載されている MCP ツールのみ呼び出してください。 MCP サーバーに存在していても、ここに記載されていないツールを呼び出してはなりません。
• レガシー／ルーティングモード： Step 0 が __FALLBACK__ を出力した場合は、このファイルに記載されている MCP ツールのみを使用してください。Step 0 が __ROUTE_CLI__ を出力した場合は、それらの MCP ツールを呼び出さず、Step 0 に従って対応するプライマリスキルに処理を委ねてください。

「なぜ急騰／急落しているのか？」スキルです。市場で異常な変動が起こり、ユーザーがその理由を尋ねた場合、システムは複数段階の呼び出しを通じてイベントの発生源を追跡し、市場データと照合して影響の大きさを検証し、「イベント → 影響の連鎖 → 市場の反応」を網羅した分析レポートを提供します。

トリガーとなるシナリオ：ユーザーが「BTC が暴落したのはなぜ？」「何が起きたの？」「ETH が突然急騰したのはなぜ？」など、市場の異常な動きに関心を示した場合。

スキルごとの更新： このディレクトリには scripts/update-skill.sh が含まれており、scripts/update-skill.ps1 が含まれている場合もあります。マーケットプレイスにアップロードされた ClawHub パッケージでは、アップロードページの制限により update-skill.ps1 が省略されていることがよくあります。GitHub／Bitbucket のソースツリーには、両方のファイルがあります。ポリシー：info-news-runtime-rules.md §1。以下の更新トリガー手順は gate-runtime-rules.md に加えて適用されます。スクリプトが存在する場合は、実行前のバージョン確認にこの手順を使用してください。

更新確認 — ユーザーへの表示： バージョン確認中の技術的な失敗（スクリプトがない、サンドボックス、ネットワーク、ゼロ以外の終了コード、解析可能な Result= 行がない）は、ユーザーに説明してはなりません。info-news-runtime-rules.md に従って、実行を続けてください。要約してよいのは、成功した check／apply の結果のみです（update_available／厳密な 終了コード 3 を含みます。これらも成功経路であり、apply の前にユーザーの確認が必要です）。ネットワークから update-skill.* を自動ダウンロードしてはなりません。.ps1 がない場合の静的参照先：正規のスクリプトは gate/gate-skills の skills/<name>/scripts/ にあります（frontmatter と同じ <name>）。

---

Step 0 — ラッパーのルーティング確認

このレガシースキルは、プライマリ CLI スキル gate-news-intel の互換エイリアスです。

更新トリガー、MCP ツールの選択、またはレガシー実行ワークフローを開始する前に、 決定的なシェル確認を実行してください。

PRIMARY_SKILL="gate-news-intel"
HAS_PRIMARY=0
for root in \
  "$HOME/.cursor/skills" \
  "$HOME/.codex/skills" \
  "$HOME/.openclaw/skills" \
  "$HOME/.agents/skills" \
  "$HOME/.gemini/antigravity/skills"
do
  if [ -f "$root/$PRIMARY_SKILL/SKILL.md" ]; then
    HAS_PRIMARY=1
    break
  fi
done

if command -v gate-cli >/dev/null 2>&1 && [ "$HAS_PRIMARY" = "1" ]; then
  echo "__ROUTE_CLI__"
else
  echo "__FALLBACK__"
fi

解釈：

• __ROUTE_CLI__ → ここで停止してください。以下の更新トリガーやレガシー MCP セクションを 実行してはなりません。 https://github.com/gate/gate-skills/blob/master/skills/gate-news-intel/SKILL.md とそのプレイブック契約に従ってください。必要最小限のコンテキストを引き継いでください：symbol、任意の time_range、およびユーザーがすでに具体的なイベントに言及している場合は event_id。
• __FALLBACK__ → 更新トリガーと、このファイルに記載されているレガシー MCP ワークフローを 続行してください。

---

トリガー時の更新（実行を伴う場合）

デフォルト（PD／ブロッキング）： トリガーごとに、GATE_SKILL_UPDATE_MODE=autoを指定せず、まずcheckを実行します。スクリプトはローカルとリモートを比較するだけです。Result=update_availableの場合、ファイルは上書きされません。停止し、apply、run、またはスキルの実行を行う前に、ユーザーに更新するかどうかを確認してください。サンドボックス（Cursorなど）で後から**applyを実行する場合は、すべての権限を使用してください。これは、独立したスクリプトのTEST_REPORTにおけるブロッキング更新確認の仕様に合致します。ブロッキングは、サイレントな自動適用によるものではなく、これらのSKILLの指示とcheckのみ**の動作によって実現されます。

厳密なチェック（エージェント／IDE — check時に推奨）： GATE_SKILL_CHECK_STRICT=1を使用します。Result=update_availableの場合、checkは終了コード3で終了し、GATE_SKILL_CHECK_EXIT=3を出力します。停止するのはそのシェルステップだけです。厳守事項：ユーザーに確認を求めた後は、このアシスタントのターンを終了してください。同じメッセージ内でapply、run、またはMCPを呼び出してはいけません。**runは事前のユーザーステップなしで適用します。ブロッキングフローのチャットではrunを使用せず、check → ユーザーが確認 → apply**の順に進めてください。

ステップ1 — チェック

インストール先のルート： check／applyは**$DEST/SKILL.mdを読み込みます。一般的な$SKILL_ROOT：$HOME/.cursor/skills/<name>/、$HOME/.codex/skills/<name>/、$HOME/.openclaw/skills/<name>/、$HOME/.agents/skills/<name>/、$HOME/.gemini/antigravity/skills/<name>/。引数が1つの場合、SKILL.mdが存在すれば、スクリプトはこの順にDESTを解決します。それ以外の場合、DESTは‌scripts/../です。ワークスペース内のツリーのみを対象とする場合は、DESTを明示して、引数2つでcheck／apply**を実行する必要があります。

エージェントの選択ルール（以下のコード例は最大1つだけ実行し、OSと$SKILL_ROOT/scripts/内のファイルに応じて選択してください）：

• macOS／Linux／WSL／Git Bash： update-skill.shが存在する場合は、Bashの例のみを使用してください。
• Windows（ネイティブPowerShell）： update-skill.ps1が存在する場合は、PowerShellの例のみを使用してください。
• Windowsで.ps1がない場合（一般的なClawHubのインストール）：update-skill.shのみが存在する場合は、WSLまたはGit Bash（bash）で、Bashの例と同じ形式のコマンドを試してください。bashを利用できない場合、または実行に失敗した場合は、ステップ1を何も通知せずにスキップし（スクリプトのstderrや「バージョンチェックに失敗しました」というメッセージをユーザーに表示しないでください）、実行に進んでください。
• どちらのスクリプトも存在しない場合： ステップ1を何も通知せずにスキップし、実行に進んでください。**GATE_SKILL_CONFIRM_TOKEN**を捏造したり、apply／revoke-pendingを実行したりしないでください。

Bash（ブロッキング — 自動適用なし。Cursorの例）：

GATE_SKILL_CHECK_STRICT=1 bash "$HOME/.cursor/skills/gate-news-eventexplain/scripts/update-skill.sh" check "gate-news-eventexplain"

PowerShell：

$env:GATE_SKILL_CHECK_STRICT = '1'
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-news-eventexplain\scripts\update-skill.ps1" check "gate-news-eventexplain"

結果の意味： skipped = 対応不要です。update_available = リモートのほうが新しい状態です。ブロッキングフローでは、ユーザーが同意するまで適用しないでください。 check_failed = 比較できませんでした。info-news-runtime-rules.mdに従い、現在のバージョンで続行してください。技術的なチェック失敗の詳細をユーザーに伝えてはいけません。

エージェントによる解析（標準出力）： GATE_SKILL_UPDATE_AGENT_ACTION=…。**BLOCK_UNTIL_USER_CONFIRMS_UPDATEの場合は、実行前にステップ2へ進みます。CONTINUE_SKILL_EXECUTION**の場合、チェック用スクリプトによるブロックはありません。

ステップ 2 — 確認または拒否（ブロック）

実行時： ステップ 2 では、ステップ 1 と同じシェルファミリー（Bash または PowerShell）を使用します。ステップ 1 をスキップした場合は、apply や revoke-pending を実行しないでください。

update_available の場合：

1. 停止 — まだ実行に進まないでください。

2. ユーザーに知らせます（例：新しいバージョンが利用可能です。必要に応じて概要を説明します）。

3. ユーザーの返信を待ちます — ブロックされるステップです。

   厳守事項（Cursor / Agent）： check が update_available、BLOCK_UNTIL_USER_CONFIRMS_UPDATE、または strict exit 3 を報告した場合は、確認を求めた後、このターンを終了します。ユーザーの次のメッセージでのみ、同意した場合は apply、拒否した場合は revoke-pending を実行します。このフローでは、check と同じターン内で apply を続けて実行しないでください。

   • ユーザーが同意 → 必要な場合は strict check の stdout にある GATE_SKILL_CONFIRM_TOKEN を指定して apply を実行し、その後、実行に進みます。
   • ユーザーが拒否 → revoke-pending を実行し、その後、現在のインストールで実行に進みます。

2 段階ゲート（strict check）： GATE_SKILL_UPDATE_MODE=auto を指定せずに apply / run を実行すると、GATE_SKILL_CONFIRM_TOKEN が .gate-skill-apply-token と一致するまで失敗します。ユーザーが拒否した場合は revoke-pending を実行します。

GATE_SKILL_CONFIRM_TOKEN="<paste from check stdout>" bash "$HOME/.cursor/skills/gate-news-eventexplain/scripts/update-skill.sh" apply "gate-news-eventexplain"

bash "$HOME/.cursor/skills/gate-news-eventexplain/scripts/update-skill.sh" revoke-pending "gate-news-eventexplain"

$env:GATE_SKILL_CONFIRM_TOKEN = '<paste from check stdout>'
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-news-eventexplain\scripts\update-skill.ps1" apply "gate-news-eventexplain"

powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.cursor\skills\gate-news-eventexplain\scripts\update-skill.ps1" revoke-pending "gate-news-eventexplain"

ステップ 1 が strict ではなかった場合（保留中のトークンがない場合）：GATE_SKILL_CONFIRM_TOKEN なしで apply を実行できます。

skipped または check_failed の場合： 更新ステップはありません。実行に進みます。

任意 — GATE_SKILL_UPDATE_MODE=auto

CI / 無人自動化専用： check で GATE_SKILL_UPDATE_MODE=auto を設定すると、リモートのバージョンが新しい場合、スクリプトは確認を求めずに直ちに適用します。また、ブロックされる更新確認テストとは互換性がありません。ブロックされる PD フローを再現する場合、check で auto を使用しないでください。

パラメーター

• name：上記の Frontmatter の name。gate-skills の skills/<name>/ と一致する必要があります。
• Invoke：このスキルの $SKILL_ROOT/SKILL.md がある場所を基準に、$SKILL_ROOT/scripts/update-skill.sh（または .ps1）を使用します。例：~/.cursor/skills/<name>、~/.codex/skills/<name>、~/.openclaw/skills/<name>、~/.agents/skills/<name>、~/.gemini/antigravity/skills/<name>。~/.cursor（または skills/<name>/SKILL.md を含まないホストルート）をインストール先として扱わないでください。引数が 1 つの場合、スクリプトはその順序で $SKILL_ROOT を解決し、見つからない場合はスクリプトのディレクトリを使用します。ワークスペースへのインストールでは、DEST を明示する必要があります。2 つの引数を取る check / apply / revoke-pending： 正式な順序は、先に絶対パスの DEST（スキルルート）、次に name です。update-skill.sh / update-skill.ps1 は、正規化後のパスのうち SKILL.md を含むのが 1 つだけの場合、順序を自動で入れ替えます（例：エージェントが name、パスの順で渡す場合）。
• ClawHub と完全なツリーの違い： update-skill.ps1 がないインストールでは、gate/gate-skills から skills/<name>/scripts/ にコピーできます（手動のみ。エージェントが自動ダウンロードしてはいけません）。

デバッグ時を除き、ユーザー向けの返信にスクリプトの生ログを出力しないでください。check の終了コードが 3（strict）の場合、ステップ 2 が解決するまで実行に進まないでください。check_failed または apply の失敗の場合は、実行時ルールに従い、適切であれば実行を続けてください。

---

MCP の依存関係

レガシーのパスのみ — このセクションは、ステップ 0 で __FALLBACK__ が出力された場合に適用されます。

必須の MCP サーバー

MCP サーバー	状態
Gate-News	✅ 必須
Gate-Info	✅ 必須

使用する MCP ツール

クエリ操作（読み取り専用）

• info_marketsnapshot_get_market_snapshot
• info_onchain_get_token_onchain
• news_events_get_event_detail
• news_events_get_latest_events
• news_feed_search_news

認証

• API キーが必要：いいえ
• 認証情報の取得元：なし。このスキルは読み取り専用の Gate Info / Gate News MCP アクセスのみを使用します。

インストールの確認

• 必須：Gate-News、Gate-Info（このスキルの info_marketsnapshot_get_market_snapshot と info_onchain_get_token_onchain 用）
• インストール：続行する前に、現在のホスト IDE 用のローカル Gate MCP インストール手順を使用してください。
• 現在の環境で必要な Gate MCP サーバーが利用可能になってから続行してください。

ルーティングルール

レガシーパスのみ — Step 0 で __ROUTE_CLI__ が出力された場合、ルーティングは gate-news-intel に委任されます。

ユーザーの意図	キーワード	アクション
値動きの理由	"why pump" "why dump" "crash" "surge" "what caused" "what happened"	このスキルのワークフロー全体を実行
一般的なニュースの問い合わせ	"any recent news"	gate-news-briefing にルーティング
包括的なコイン分析	"analyze BTC for me"	gate-info-coinanalysis にルーティング
テクニカル分析	"BTC technical analysis"	gate-info-trendanalysis にルーティング
市場の概要	"how's the market"	gate-info-marketoverview にルーティング

---

実行ワークフロー

レガシーパスのみ — Step 0 で __FALLBACK__ が出力された場合、このセクションを適用します。

Step 0：複数の分析軸に関する意図の確認

このスキルを実行する前に、ユーザーの問い合わせに複数の分析軸が含まれているか確認します。

• 問い合わせが値動きの理由だけに関するものであれば、このスキルを続行します。
• 問い合わせにファンダメンタルズ、リスクチェック、テクニカル分析、比較、またはイベントの要因分析以外の分析軸も含まれている場合は、gate-info-research にルーティングします。複数の分析軸を含む問い合わせに対応し、ツールの重複を一元的に排除して、一貫性のあるレポートをまとめます。

Step 1：意図の認識とパラメーターの抽出

ユーザー入力から以下を抽出します。

• coin：対象のコイン（例：BTC、ETH。空の場合は市場全体）
• direction：上昇または下落（検索に使用）
• time_hint：時間の手掛かり（「たった今」「今日」「昨日」など。デフォルト：過去24時間）

Step 2：フェーズ1 — イベント検索と市場の確認（並列）

ステップ	MCP ツール	パラメーター	取得データ	並列
1a	news_events_get_latest_events	coin={coin}, time_range="24h", limit=10	関連イベントの一覧	はい
1b	info_marketsnapshot_get_market_snapshot	symbol={coin}, timeframe="1d", source="spot"	リアルタイムの市場スナップショット（変動幅を確認）	はい

両方のツールを並列で呼び出します。

Step 3：分岐の判定

events response
    │
    ├── Matching event found (event time aligns with volatility onset)
    │   └── → Step 4a: Get event details
    │
    └── No clear event match
        └── → Step 4b: Expand news search

Step 4a：イベントが見つかった場合 → 詳細取得とオンチェーンの確認

ステップ	MCP ツール	パラメーター	取得データ	並列
2a	news_events_get_event_detail	event_id={matched_event_id}	イベントの詳細（原因、影響、タイムライン）	はい
2b	info_onchain_get_token_onchain	token={coin}, chain="eth", scope="transfers"	オンチェーンの異常（大口送金、取引所への入出金）	はい

Step 4b：イベントが見つからない場合 → 検索範囲を拡大

ステップ	MCP ツール	パラメーター	取得データ	並列
2c	news_feed_search_news	coin={coin}, sort_by="time", limit=15	最新の関連ニュース（時間順）	はい
2d	info_onchain_get_token_onchain	token={coin}, chain="eth", scope="transfers"	オンチェーンの異常	はい

Step 5：LLM による要因分析

LLM は以下の推論プロセスを完了する必要があります。

1. 変動を確認する：市場スナップショットに基づき、タイミング、変動幅、出来高の変化を確認します
2. きっかけとなったイベントを特定する：イベントやニュースから、時期が最も近いイベントを見つけます
3. 因果関係を検証する：イベントは値動きに先行していましたか？対応するオンチェーンの動きはありますか？
4. 影響の連鎖を評価する：イベント → 直接的な影響 → センチメントの伝播 → 価格の反応
5. 今後の影響の可能性を評価する：イベントの性質に基づき、影響が短期的か継続的かを評価します

Step 6：構造化レポートを出力する

---

レポートテンプレート

レガシーパスのみ — このセクションは、Step 0 で __FALLBACK__ が出力された場合に適用されます。

## {coin} {Pump/Dump} Attribution Analysis

> Analysis time: {timestamp}

### 1. Volatility Summary

| Metric | Value |
|--------|-------|
| Current Price | ${price} |
| Move Magnitude | {change}% (within {timeframe}) |
| High | ${high} ({time}) |
| Low | ${low} ({time}) |
| Volume Change | {volume_change}% (vs 24h average) |
| Futures Liquidations | ${liquidation} (if available) |

### 2. Core Triggering Event

🔴 **{event_title}**

- Event Time: {event_time}
- Event Type: {Regulation / Project Development / Market Manipulation / Macro Economic / Technical Failure / Whale Activity}
- Details: {2-3 sentence description}
- Source: {source}

### 3. Event → Impact Chain

{event} │ ├── 直接的な影響：{description} │ 例：SEC による訴訟 → トークンの規制上の不確実性が高まる │ ├── センチメントの波及：{description} │ 例：パニックが広がる → 恐怖・強欲指数が 65 から 35 に低下する │ └── 価格の反応：{description} 例：{coin} は、イベント発生から 2 時間以内に ${high} から ${low} に下落した

### 4. On-chain Verification

{If on-chain data is available:}

| On-chain Metric | Anomaly |
|----------------|---------|
| Exchange Inflows | {increase/decrease}, {description} |
| Large Transfers | {count} transfers exceeding ${threshold} |
| Whale Activity | {description} |
| Futures Funding Rate | {change description} |

{Does the on-chain data corroborate the event narrative?}

### 5. Ripple Effects

{Did this event affect other coins/sectors?}

- {Related coin 1}: {impact description}
- {Related coin 2}: {impact description}
- Sector impact: {e.g., L1 sector declined across the market, DeFi sector affected}

### 6. Forward Outlook

{Based on the event's nature, assess the follow-on impact:}

| Dimension | Assessment |
|-----------|------------|
| Impact Duration | {One-time shock / Short-term (1-3 days) / Medium-term (1-2 weeks) / Long-term} |
| What to Watch Next | {Items to monitor: court ruling, policy details, project response, etc.} |
| Historical Precedent | {Similar past events and their outcomes, if any} |

### ⚠️ Important Notes

- Market moves may be caused by multiple overlapping factors; the above analysis is based on currently available information
- Long-term impact of the event remains uncertain

> The above analysis is based on public information and on-chain data. It does not constitute investment advice.

イベントを特定できない場合のテンプレート

## {coin} Volatility Analysis

> Analysis time: {timestamp}

### Volatility Summary

{Same as above}

### Possible Cause Analysis

⚠️ No single clear triggering event was identified. The following is a composite analysis:

**Possible Factor 1: {description}**
- Evidence: {related news/data}
- Likelihood: {High/Medium/Low}

**Possible Factor 2: {description}**
- Evidence: ...
- Likelihood: ...

**On-chain Clues**
{Any anomalous on-chain data that could help explain the move?}

### Composite Assessment

{LLM's composite analysis, with uncertainty explicitly acknowledged}

> Note: No single clear triggering event was found for this move. The above analysis is an informed assessment based on available data.

---

推論ロジック

イベントの照合ロジック

条件	評価
イベントの発生時刻 < 価格変動の開始時刻	✅ 時系列的に、引き金となった可能性があります
イベントの発生時刻 > 価格変動の開始時刻	❌ 引き金となった可能性は低いです（後追い報道の可能性があります）
イベントの影響度評価 = "High"	重み +2
イベントが問い合わせ対象のコインに関係する	重み +3
イベントの種類 = "Regulation/Policy"	通常、より大きな価格変動を引き起こします
複数のイベントが同時に発生	複合分析 — 複数要因の可能性が高いです

変動幅の評価

変動幅	ラベル
< 3%	通常の変動 — 特定のイベントによる説明は不要な場合があります
3% – 10%	中程度の変動 — 最近のニュースやイベントを確認してください
10% – 20%	大きな変動 — 通常、明確なイベント要因があります
> 20%	極端な変動 — 大きなイベント、またはブラックスワンがほぼ確実に発生しています

オンチェーン異常の評価

条件	評価
取引所への流入が平均の 3 倍超に急増	「取引所への大量のトークン流入 — 売り圧力の可能性」
取引所からの流出が平均の 3 倍超に急増	「取引所からの大量のトークン流出 — 買い集めの可能性」
大口送金件数が平均の 5 倍超	「大口送金が異常に活発です」
先物の清算額が $100M 超	「大規模な先物清算の連鎖 — 価格変動が増幅されています」

---

エラー処理

エラーの種類	対応
news_events_get_latest_events で一致するイベントが見つからない	Step 4b に進み、ニュース検索を拡大します
news_events_get_event_detail が失敗する	イベント一覧の要約のみを基にレポートを生成します
info_onchain_get_token_onchain が利用できない（P1 フェーズ）	オンチェーン検証セクションを省略し、「オンチェーンデータは一時的に利用できません」と記載します
info_marketsnapshot_get_market_snapshot が失敗する	変動幅を確認できないため、イベント情報のみの表示に切り替えます
ニュースとイベントの両方で結果が得られない	「現時点では明確な原因を特定できていません」と正直に伝え、最新情報の確認を提案します
すべてのツールが失敗する	エラーメッセージを返し、後でもう一度試すよう提案します

---

スキル間のルーティング

ユーザーの追加依頼	ルーティング先
「BTC を分析してください」	gate-info-coinanalysis
「テクニカル分析をしてください」	gate-info-trendanalysis
「市場全体の状況はどうですか？」	gate-info-marketoverview
「最近のニュースはありますか？」	gate-news-briefing
「オンチェーンに異常はありますか？」	gate-info-tokenonchain
「このアドレスを追跡してください」	gate-info-addresstracker

---

安全ルール

1. 因果関係を断定しない：「原因となった可能性があります」「最も関連性の高いイベントは」といった表現を使い、因果関係を断定する表現は避けてください
2. その後の予測をしない：「今後も上昇／下落し続ける」といった予測を出力しないでください
3. 投資助言をしない：イベント分析に基づく買い／売りの推奨は行わないでください
4. 不確実性を認める：イベントと価格変動の因果関係が不確かな場合は、その旨を明示してください
5. 情報源を明記する：イベントやニュースには情報源を記載してください
6. データの欠落を明示する：オンチェーンデータやイベント詳細が利用できない場合は、その旨を明記してください
7. パニックをあおらない：暴落やブラックスワンについて説明する際は、扇情的な表現を避け、客観的で中立的な言葉を使ってください