Gate News Listing

Listing radar Skill. The user queries exchange listing/delisting/maintenance announcements, the system first calls the exchange announcements Tool, then supplements high-interest coins with fundamentals and market data. The LLM aggregates everything into a structured exchange activity report.

Trigger Scenarios: User mentions an exchange name + listing/delisting keywords, or asks "any new coins listed recently" or "any new projects".

Per-skill updates: This directory includes scripts/update-skill.sh and scripts/update-skill.ps1. 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.

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.

Bash (blocking — no auto; example Cursor):

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

PowerShell:

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

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.

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)

If update_available:

1. STOP — do NOT proceed to Execution yet.

2. Inform the user (e.g. newer version available; summarize if helpful).

3. 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-listing/scripts/update-skill.sh" apply "gate-news-listing"

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

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

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

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.

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

Required MCP Servers

MCP Tools Used

Query Operations (Read-only)

• info_coin_get_coin_info
• info_coin_get_coin_rankings
• info_marketsnapshot_get_market_snapshot
• news_feed_get_exchange_announcements

Authentication

• API Key Required: No

Installation Check

• Required: Gate-News
• Install: Run installer skill for your IDE
  • Cursor: gate-mcp-cursor-installer
  • Codex: gate-mcp-codex-installer
  • Claude: gate-mcp-claude-installer
  • OpenClaw: gate-mcp-openclaw-installer

Routing Rules

Execution Workflow

Step 1: Intent Recognition & Parameter Extraction

Extract from user input:

• exchange (optional): Exchange name (e.g., Binance, Gate, OKX, Bybit, Coinbase)
• coin (optional): Specific coin symbol
• announcement_type (optional): Announcement type (listing / delisting / maintenance)
• limit: Number of results, default 10

Default Logic:

• If no exchange specified, query all exchanges
• If no announcement type specified, default to listing
• If user mentions "delisting" or "maintenance", set the corresponding announcement_type

Step 2: Call Exchange Announcements Tool

Step 3: Supplement Key Coins with Data (Parallel)

From Step 2 results, extract the top 3-5 newly listed coins and supplement in parallel:

Only supplement data for listing-type announcements. Delisting/maintenance announcements do not need market data.

Step 4: LLM Aggregation — Generate Report

Pass announcement data and supplementary info to the LLM to generate the exchange activity report using the template below.

Report Template

## Exchange Activity Report

> Data range: {start_time} — {end_time} | Exchange: {exchange / "All"} | Type: {type / "Listings"}

### 1. Latest Listing Announcements

| # | Exchange | Coin | Type | Listing Time | Trading Pairs |
|---|---------|------|------|-------------|---------------|
| 1 | {exchange_1} | {coin_1} | Listed | {time_1} | {pairs_1} |
| 2 | {exchange_2} | {coin_2} | Listed | {time_2} | {pairs_2} |
| ... | ... | ... | ... | ... | ... |

### 2. Featured New Coins

{Quick analysis of the top 3-5 newly listed coins}

#### {coin_1}

| Metric | Value |
|--------|-------|
| Project Description | {description} |
| Sector | {category} |
| Funding Background | {funding} |
| Current Price | ${price} |
| Post-Listing Change | {change}% |
| 24h Volume | ${volume} |
| Market Cap | ${market_cap} |

{LLM one-liner: highlights and risks to watch for this project}

#### {coin_2}
...

### 3. Delisting / Maintenance Notices (if any)

| # | Exchange | Coin | Type | Effective Date | Notes |
|---|---------|------|------|---------------|-------|
| 1 | ... | ... | Delisted | ... | ... |

### 4. Activity Summary

{LLM generates a 2-3 sentence summary based on all announcement data:}
- Most active exchange for new listings recently
- Trending listing sectors (Meme / AI / DePIN / L2, etc.)
- Notable projects and why they stand out
- Delisting/maintenance reminders (if any)

### ⚠️ Risk Warnings

- Newly listed coins experience extreme volatility — the price discovery phase carries very high risk
- Some newly listed tokens may have insufficient liquidity — watch for slippage on large trades
- It is recommended to use the "Risk Assessment" feature to check contract security before trading

> The above information is compiled from public announcements and on-chain data and does not constitute investment advice.

Decision Logic

Error Handling

Cross-Skill Routing

Available Tools & Degradation Notes

Safety Rules

1. No investment advice: Announcement analysis is based on public information and must include a "not investment advice" disclaimer
2. No listing predictions: Do not predict whether a coin will be listed on a specific exchange
3. New coin risk reminder: All reports on newly listed coins must include the "extreme volatility during initial listing" risk warning
4. Data transparency: Label announcement source and update time
5. Flag missing data: When any dimension has no data, explicitly inform the user — never fabricate data
6. Delisting urgency: For delisting announcements, prominently remind users to manage their positions