| name | gate-news-eventexplain |
| version | 2026.4.3-1 |
| updated | 2026-04-03 |
| description | Event attribution and explanation. Use this skill ONLY when the user's query is exclusively about the reason behind a price move with no other analysis dimensions. Trigger phrases: why did X crash, what just happened, why is it pumping, what caused. If the query ALSO mentions fundamentals, risk check, technicals, or any other analysis dimension, use gate-info-research instead — it handles multi-dimension queries in a single unified report. |
| required_credentials | [] |
| required_env_vars | [] |
| required_permissions | [] |
gate-news-eventexplain
General Rules
⚠️ STOP — You MUST read and strictly follow the shared runtime rules before proceeding.
Do NOT select or call any tool until all rules are read. These rules have the highest priority.
→ Read gate-runtime-rules.md
→ Also read info-news-runtime-rules.md for gate-info / gate-news-specific rules (tool degradation, report standards, security, routing degradation, per-skill version checks when scripts/ is present, and legacy wrapper routing).
- Only call MCP tools explicitly listed in this skill. Tools not documented here must NOT be called, even if they
exist in the MCP server.
- Legacy / routing mode: when Step 0 emits
__FALLBACK__, use only the MCP tools listed in this file. When Step 0 emits __ROUTE_CLI__, do not call those MCP tools; delegate to the mapped primary skill per Step 0.
The "Why is it pumping/dumping?" Skill. When the market experiences abnormal volatility and the user asks why, the system traces the event source through multi-step calls, cross-references market data to verify impact magnitude, and delivers a complete "Event → Impact Chain → Market Reaction" analysis report.
Trigger Scenarios: User expresses curiosity about a market anomaly, e.g., "why did BTC crash", "what just happened", "why did ETH suddenly spike".
Per-skill updates: This directory includes scripts/update-skill.sh and may include scripts/update-skill.ps1. ClawHub packages uploaded to the marketplace often omit update-skill.ps1 (upload-page restriction); GitHub / Bitbucket source trees keep both. Policy: info-news-runtime-rules.md §1. The Trigger update steps below apply in addition to gate-runtime-rules.md; when scripts are present, use this flow for version checks before execution.
Update check — user visibility: Technical failures during version check (missing script, sandbox, network, non-zero exit, no parseable Result= line) must not be explained to the user; continue with Execution per info-news-runtime-rules.md. Only successful check / apply outcomes may be summarized (including update_available / strict exit 3, which is still a success path that requires user confirmation before apply). Do not auto-download update-skill.* from the network. Static reference if .ps1 is missing: canonical scripts live in gate/gate-skills under skills/<name>/scripts/ (same <name> as frontmatter).
Step 0 — Wrapper routing probe
This legacy skill is a compatibility alias for the primary CLI skill
gate-news-intel.
Before Trigger update, MCP tool selection, or any legacy Execution Workflow,
run a deterministic shell probe:
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
Interpretation:
__ROUTE_CLI__ → stop here. Do not run Trigger update or the legacy MCP
sections below. Follow
https://github.com/gate/gate-skills/blob/master/skills/gate-news-intel/SKILL.md
and its playbook contract. Carry over the minimum context: symbol, optional
time_range, and event_id when the user already references a concrete
event.__FALLBACK__ → continue with Trigger update and the legacy MCP workflow in
this file.
Trigger update (with Execution)
Default (PD / blocking): On each trigger, run check first without GATE_SKILL_UPDATE_MODE=auto. The script only compares local vs remote; if Result=update_available, it does not overwrite files. STOP — ask the user whether to update before any apply, run, or skill Execution. In sandboxes (e.g. Cursor), use full / all permissions when later running apply. This matches blocking update confirmation in the independent-script TEST_REPORT: blocking is enforced by these SKILL instructions plus check-only behavior (not by silent auto-apply).
Strict check (Agent / IDE — recommended on check): Use GATE_SKILL_CHECK_STRICT=1. When Result=update_available, check exits 3 and prints GATE_SKILL_CHECK_EXIT=3 — it stops only that shell step. Hard rule: after you ask the user, end this assistant turn; do not call apply, run, or MCP in the same message. run applies without a prior user step — do not use run in chat for the blocking flow; use check → user confirms → apply.
Step 1 — Check
Install root: check / apply read $DEST/SKILL.md. Typical $SKILL_ROOT: $HOME/.cursor/skills/<name>/, $HOME/.codex/skills/<name>/, $HOME/.openclaw/skills/<name>/, $HOME/.agents/skills/<name>/, $HOME/.gemini/antigravity/skills/<name>/. Single-arg: the script resolves DEST in that order when SKILL.md exists; otherwise DEST is scripts/../. Workspace-only trees need two-arg check / apply with explicit DEST.
Agent selection rules (run at most one of the fenced examples below; choose by OS and files under $SKILL_ROOT/scripts/):
- macOS / Linux / WSL / Git Bash: If
update-skill.sh exists → use only the Bash example.
- Windows (native PowerShell): If
update-skill.ps1 exists → use only the PowerShell example.
- Windows without
.ps1 (typical ClawHub install): If only update-skill.sh exists → try WSL or Git Bash (bash) using the same command shape as the Bash example. If bash is unavailable or execution fails → skip Step 1 silently (no script stderr or “version check failed” message to the user); proceed to Execution.
- Neither script exists: Skip Step 1 silently; proceed to Execution. Do not invent
GATE_SKILL_CONFIRM_TOKEN or run apply / revoke-pending.
Bash (blocking — no auto; example 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"
Result semantics: skipped = no action. update_available = remote newer; with blocking flow, do not apply until the user agrees. check_failed = could not compare — proceed with current version per info-news-runtime-rules.md; do not surface technical check failure details to the user.
Agent parse (stdout): GATE_SKILL_UPDATE_AGENT_ACTION=…. BLOCK_UNTIL_USER_CONFIRMS_UPDATE → Step 2 before Execution. CONTINUE_SKILL_EXECUTION → no block from the check script.
Step 2 — Confirm or Reject (blocking)
Runtime: Use the same shell family for Step 2 as for Step 1 (Bash vs PowerShell). If Step 1 was skipped, do not run apply or revoke-pending.
If update_available:
-
STOP — do NOT proceed to Execution yet.
-
Inform the user (e.g. newer version available; summarize if helpful).
-
Wait for the user’s reply — blocking step.
Hard rule (Cursor / Agent): When check reports update_available, or BLOCK_UNTIL_USER_CONFIRMS_UPDATE, or strict exit 3, end this turn after asking. Only in the user’s next message run apply (if they agree) or revoke-pending (if they decline). Do not chain apply in the same turn as check for this flow.
- User agrees → run
apply with GATE_SKILL_CONFIRM_TOKEN from strict check stdout when required, then Execution.
- User declines →
revoke-pending, then Execution on the current install.
Two-step gate (strict check): apply / run (without GATE_SKILL_UPDATE_MODE=auto) fail until GATE_SKILL_CONFIRM_TOKEN matches .gate-skill-apply-token. User decline → 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"
If Step 1 was not strict (no pending token): apply without GATE_SKILL_CONFIRM_TOKEN is allowed.
If skipped or check_failed: no update step; proceed to Execution.
Optional — GATE_SKILL_UPDATE_MODE=auto
For CI / unattended automation only: setting GATE_SKILL_UPDATE_MODE=auto on check makes the script apply immediately when the remote is newer — no user confirmation and incompatible with blocking update confirmation tests. Do not use auto on check when reproducing the blocking PD flow.
Parameters
- name: Frontmatter
name above; must match skills/<name>/ on gate-skills.
- Invoke: Use
$SKILL_ROOT/scripts/update-skill.sh (or .ps1) where $SKILL_ROOT/SKILL.md is this skill — e.g. ~/.cursor/skills/<name>, ~/.codex/skills/<name>, ~/.openclaw/skills/<name>, ~/.agents/skills/<name>, ~/.gemini/antigravity/skills/<name>; do not treat ~/.cursor (or any host root without skills/<name>/SKILL.md) as the install. With one arg, the script resolves $SKILL_ROOT in that order before falling back to the script’s directory; workspace installs need explicit DEST. Two-arg check / apply / revoke-pending: canonical order is absolute DEST (skill root) first, then name; update-skill.sh / update-skill.ps1 auto-swap when only one normalized path contains SKILL.md (e.g. agent passes name then path).
- ClawHub vs full tree: Installs without
update-skill.ps1 may copy it from gate/gate-skills under skills/<name>/scripts/ (manual only; agents must not auto-download).
Do not dump raw script logs into the user-facing reply except when debugging. On check exit 3 (strict), do not run Execution until Step 2 is resolved. On check_failed or apply failure, still run Execution when appropriate per runtime rules.
MCP Dependencies
Legacy path only — this section applies when Step 0 emitted __FALLBACK__.
Required MCP Servers
| MCP Server | Status |
|---|
| Gate-News | ✅ Required |
| Gate-Info | ✅ Required |
MCP Tools Used
Query Operations (Read-only)
- info_marketsnapshot_get_market_snapshot
- info_onchain_get_token_onchain
- news_events_get_event_detail
- news_events_get_latest_events
- news_feed_search_news
Authentication
- API Key Required: No
- Credentials Source: None; this skill uses read-only Gate Info / Gate News MCP access only.
Installation Check
- Required: Gate-News, Gate-Info (for
info_marketsnapshot_get_market_snapshot and info_onchain_get_token_onchain in this skill)
- Install: Use the local Gate MCP installation flow for the current host IDE before continuing.
- Continue only after the required Gate MCP server is available in the current environment.
Routing Rules
Legacy path only — when Step 0 emitted __ROUTE_CLI__, routing is delegated to
gate-news-intel.
| User Intent | Keywords | Action |
|---|
| Reason for price move | "why pump" "why dump" "crash" "surge" "what caused" "what happened" | Execute this Skill's full workflow |
| General news query | "any recent news" | Route to gate-news-briefing |
| Comprehensive coin analysis | "analyze BTC for me" | Route to gate-info-coinanalysis |
| Technical analysis | "BTC technical analysis" | Route to gate-info-trendanalysis |
| Market overview | "how's the market" | Route to gate-info-marketoverview |
Execution Workflow
Legacy path only — this section applies when Step 0 emitted __FALLBACK__.
Step 0: Multi-Dimension Intent Check
Before executing this Skill, check if the user's query involves multiple analysis dimensions:
- If the query is exclusively about the reason behind a price move, proceed with this Skill.
- If the query also mentions fundamentals, risk check, technicals, comparison, or any other analysis dimension beyond event attribution, route to
gate-info-research — it handles multi-dimension queries with unified tool deduplication and coherent report aggregation.
Step 1: Intent Recognition & Parameter Extraction
Extract from user input:
coin: The coin involved (e.g., BTC, ETH; may be empty = overall market)direction: Up or down (aids search)time_hint: Time clue ("just now", "today", "yesterday"; default: past 24h)
Step 2: Phase 1 — Event Search + Market Verification (Parallel)
| Step | MCP Tool | Parameters | Retrieved Data | Parallel |
|---|
| 1a | news_events_get_latest_events | coin={coin}, time_range="24h", limit=10 | Related event list | Yes |
| 1b | info_marketsnapshot_get_market_snapshot | symbol={coin}, timeframe="1d", source="spot" | Real-time market snapshot (verify volatility magnitude) | Yes |
Both Tools called in parallel.
Step 3: Decision Branch
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: Event Found → Get Details + On-chain Verification
| Step | MCP Tool | Parameters | Retrieved Data | Parallel |
|---|
| 2a | news_events_get_event_detail | event_id={matched_event_id} | Event details (cause, impact, timeline) | Yes |
| 2b | info_onchain_get_token_onchain | token={coin}, chain="eth", scope="transfers" | On-chain anomalies (large transfers, exchange inflows/outflows) | Yes |
Step 4b: No Event Found → Expand Search
| Step | MCP Tool | Parameters | Retrieved Data | Parallel |
|---|
| 2c | news_feed_search_news | coin={coin}, sort_by="time", limit=15 | Latest related news (sorted by time) | Yes |
| 2d | info_onchain_get_token_onchain | token={coin}, chain="eth", scope="transfers" | On-chain anomalies | Yes |
Step 5: LLM Attribution Reasoning
The LLM must complete the following reasoning chain:
- Confirm the volatility: Based on the market snapshot, confirm the timing, magnitude, and volume change
- Identify the trigger event: From events/news, find the event with the closest time alignment
- Verify causality: Did the event precede the price move? Is there corresponding on-chain activity?
- Assess the impact chain: Event → Direct impact → Sentiment transmission → Price reaction
- Evaluate follow-on potential: Based on the event's nature, assess whether the impact is short-term or sustained
Step 6: Output Structured Report
Report Template
Legacy path only — this section applies when Step 0 emitted __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}
│
├── Direct Impact: {description}
│ e.g., SEC lawsuit → Regulatory uncertainty for the token increases
│
├── Sentiment Transmission: {description}
│ e.g., Panic spreads → Fear & Greed Index drops from 65 to 35
│
└── Price Reaction: {description}
e.g., {coin} dropped from ${high} to ${low} within 2 hours of the event
### 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.
Template When No Event Can Be Identified
## {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.
Reasoning Logic
Event Matching Logic
| Condition | Assessment |
|---|
| Event time < price move start time | ✅ Temporally plausible as a trigger |
| Event time > price move start time | ❌ Unlikely to be the trigger (may be follow-up reporting) |
| Event impact rating = "High" | Weight +2 |
| Event involves the queried coin | Weight +3 |
| Event type = "Regulation/Policy" | Typically causes larger moves |
| Multiple events simultaneously | Composite analysis — likely multi-factor |
Volatility Magnitude Assessment
| Magnitude | Label |
|---|
| < 3% | Normal volatility — may not require a specific event explanation |
| 3% – 10% | Moderate volatility — look for recent news/events |
| 10% – 20% | Large volatility — typically has a clear event driver |
| > 20% | Extreme volatility — major event or black swan almost certain |
On-chain Anomaly Assessment
| Condition | Assessment |
|---|
| Exchange inflows surge > 3x average | "Large token inflows to exchanges — potential selling pressure" |
| Exchange outflows surge > 3x average | "Large token outflows from exchanges — possible accumulation" |
| Large transfer count > 5x average | "Abnormally active large transfers" |
| Futures liquidations > $100M | "Massive futures liquidation cascade — amplified price volatility" |
Error Handling
| Error Type | Handling |
|---|
news_events_get_latest_events finds no matching event | Proceed to Step 4b — expand news search |
news_events_get_event_detail fails | Generate report based on event list summaries only |
info_onchain_get_token_onchain unavailable (P1 phase) | Skip on-chain verification section; note "On-chain data temporarily unavailable" |
info_marketsnapshot_get_market_snapshot fails | Cannot confirm volatility magnitude; degrade to showing event info only |
| Both news and events return no results | Honestly inform the user "No clear cause has been identified at this time"; suggest monitoring for updates |
| All Tools fail | Return error message; suggest the user try again later |
Cross-Skill Routing
| User Follow-up Intent | Route To |
|---|
| "Analyze BTC for me" | gate-info-coinanalysis |
| "Give me a technical analysis" | gate-info-trendanalysis |
| "How's the overall market?" | gate-info-marketoverview |
| "Recent news?" | gate-news-briefing |
| "Any on-chain anomalies?" | gate-info-tokenonchain |
| "Track this address" | gate-info-addresstracker |
Safety Rules
- No definitive causal claims: Use language like "likely caused by", "the most closely related event is" — avoid absolute causal assertions
- No follow-on predictions: Do not output "it will continue to rise/fall" style predictions
- No investment advice: Do not give buy/sell recommendations based on event analysis
- Acknowledge uncertainty: When the causal link between event and move is uncertain, explicitly state it
- Source attribution: Events and news must cite their sources
- Flag missing data: When on-chain data or event details are unavailable, explicitly state it
- Avoid amplifying panic: When describing crashes or black-swan events, maintain objective, neutral language — no sensationalist rhetoric
