Skill: gate-exchange/gate-exchange-trading-copilot (version 1.0.2)

--- name: gate-exchange-trading-copilot version: "2026.3.23-1" updated: "2026-03-23" description: "Gate Trading Copilot L2. Use when the user wants to execute complex trades, margin borrowing, or query positions and open orders. Triggers on 'market buy', 'margin borrow', 'TradFi', 'Alpha', or spot-plus-futures combos. Requires Action Draft." --- # Gate Exchange Trading Copilot This is an **L2 composite skill** for users who want a single skill to complete the full trading loop: `judge the opportunity -> control risk -> produce order draft -> explicit confirmation -> execute -> verify/manage` It is neither a pure research skill nor a pure execution skill. Its purpose is to provide a complete trading workflow inside one skill. ## 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](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md) - **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. Before calling any named MCP tool, verify that the concrete tool name exists in the current runtime tool list. If a helper tool is absent, disclose the mismatch, use only the nearest valid fallback combination, and do not overclaim unavailable coverage such as rankings, macro breadth, or automated fund-flow tracing. Also validate that the returned payload is rich enough for the intended analytical claim. If a tool returns sparse metadata, empty structures, or requires missing disambiguation inputs, treat it as supporting context only rather than primary evidence. For portability across Gate MCP runtimes, treat the documented surfaces as the baseline: - `info_*` -> Gate Info MCP - `news_feed_*` -> Gate News MCP - read-only `cex_spot_*` / `cex_fx_*` market-data calls -> Gate public market MCP or a local combined Gate MCP runtime - private order / account / position `cex_*` calls -> authenticated Gate Exchange MCP or a local authenticated Gate MCP runtime Do not make `news_events_*` a required dependency in scenario design, because it is not part of the documented baseline news surface. ## MCP Mode **Read and strictly follow** [`references/mcp.md`](./references/mcp.md), then execute this skill's copilot workflow. - `SKILL.md` keeps composite routing, trade lifecycle policy, and guardrails. - `references/mcp.md` is the authoritative MCP orchestration layer for cross-domain tool sequencing, execution gates, and degradation. --- Read `references/scenarios.md` for: - representative user scenarios - representative prompt examples - expected tool-routing patterns ## Authentication - API Key Required: Not always - Read-only analysis: public `info_*`, `news_feed_*`, and some public `cex_spot_*` / `cex_fx_*` market-data calls may work without authentication, depending on runtime - Execution and private account actions: Yes, authenticated Exchange MCP tools with the required API key permissions are mandatory - Note: Do not block analysis-only use just because private execution tools are unavailable; only block when the requested action needs private trading/account access. ## Positioning - For users who want to trade without switching across multiple skills - Self-contained: can be installed alone and still understand both analysis and execution mapping - Supports **spot trading** and **USDT perpetual futures** - Supports post-trade **amend / cancel / close / verification** ## Suitable Scenarios ### Suitable - The user already has a target asset and wants analysis before trading - `Check whether BTC is worth buying now, then give me a spot order draft` - `I want to long ETH, but check momentum, liquidation, and liquidity first` - The user is triggered by news, abnormal moves, or new listings and wants to trade after analysis - `ETH just dumped. Explain why and tell me whether it is worth buying` - `This newly listed coin looks interesting. Check the risk before giving me a starter trade plan` - The user already placed an order or opened a position and now wants management - `Raise my unfilled buy order by 1%` - `Close half of my BTC position` ### Not Suitable - Pure market research with no trading goal - Options, Alpha trading, on-chain swap, DeFi execution, copy trading, wealth products - Fully automatic trading, skipping confirmation, bypassing compliance or risk controls ## Capability Boundary ### This skill can do 1. Recognize whether the user wants: - pre-trade judgment - judgment plus execution - order / position management 2. Dynamically combine analysis modules around one trade target: - market/news context - single-coin analysis - technical analysis - liquidity/slippage/liquidation/order-book analysis - token or contract risk check 3. Produce a **Trading Brief** 4. Produce an **Order Draft** when risk is acceptable 5. Execute after explicit confirmation: - spot buy/sell, conditional limit logic, amend/cancel/verification - USDT perpetual open/close/reverse/amend/cancel 6. Continue after execution: - fill verification - position verification - order / position management ### This skill cannot do 1. Decide and trade automatically on behalf of the user 2. Place orders without explicit confirmation 3. Bypass compliance, risk, minimum order, or contract safety constraints 4. Promise profit or present analysis as certainty 5. Pretend to support unsupported products ## Operating Principles ### Principle 1: Work around the trading goal This skill is built for trading closure, not broad research. - If the user only asks `How is the market?` - a lightweight market scan is fine - do not proactively move into order execution - If the user says `How is the market today? Give me one trade idea` - a lightweight scan is allowed - but the workflow must narrow down to **one asset + one market (spot or futures)** before entering execution ### Principle 2: Judge first, execute second Unless the user only wants pure order/position management, default to one round of pre-trade judgment before producing an order draft. ### Principle 3: Use the minimum necessary analysis Do not run every module every time. Only call the modules needed for the current decision. Read `references/routing-and-analysis.md` for: - intent routing - analysis module selection by scenario - risk gating - module-to-MCP mapping and call patterns ### Principle 4: Strong confirmation at execution layer Any real trading action must follow this order: 1. Produce a `Trading Brief` 2. Produce an `Order Draft` 3. Wait for explicit confirmation in the immediately previous user turn 4. Execute only after confirmation Read `references/execution-and-guardrails.md` for: - spot and futures execution rules - execution MCP mapping - draft requirements - confirmation rules - hard and soft blocks ## Overall Workflow ### Step 0: Apply the shared runtime rules first Before analysis or execution: - read and follow [gate-runtime-rules.md](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md) - resolve any required runtime, update, or authorization gate before continuing - verify that the named tools you plan to call exist in the current runtime before relying on them ### Step 1: Identify task mode Classify the user request into one of these modes: 1. **Trade Decision** - analyze first, then decide whether to trade 2. **Trade Draft / Execute** - the user already wants to trade and wants analysis plus draft plus execution 3. **Order / Position Management** - the user wants to manage an existing order or position ### Step 2: Narrow down to one trade target Before entering execution, try to make these explicit: - asset: BTC / ETH / SOL / a new coin / a futures contract - market: spot or USDT perpetual - direction: buy / sell / long / short / close If information is still incomplete: - a lightweight market scan is allowed - but before producing an order draft, the workflow must narrow down to one asset and one market ### Step 3: Build the pre-trade analysis package Call only the modules needed for this request: - market overview / news briefing - listing / exchange announcement context - single-coin analysis - technical analysis - event explanation - risk check - address tracing (only when the user really provides an address and wants tracing) - liquidity / slippage / momentum / liquidation / basis / order-book analysis ### Step 4: Produce a Trading Brief `Trading Brief` is the mandatory intermediate artifact before execution. It must include: 1. what the user wants to do 2. current market/asset judgment 3. key risks 4. whether the skill should continue to order drafting Only three result states are allowed: - `GO` = safe enough to continue to order drafting - `CAUTION` = meaningful risk exists, but drafting may continue after warning - `BLOCK` = do not continue into order drafting ### Step 5: Produce an Order Draft Only produce an order draft when all of the following are true: - the user has real trading intent - the trade target is sufficiently clear - no hard block is triggered ### Step 6: Wait for explicit confirmation If the user does not provide a clear, immediate confirmation: - do not execute - remain in analysis / draft / query mode only ### Step 7: Execute and verify After execution, always return: - whether execution succeeded - core fill/order/position results - reasonable next actions, such as verify fill, amend, cancel, or close ## Market Identification Rules ### Default behavior - If the request clearly contains `long / short / leverage / contract / perp / futures / open / close` - route to **USDT perpetual futures** - If the request clearly contains `buy coin / sell coin / spot / buy BTC / sell ETH` - route to **spot** - If the user says `buy BTC` without specifying market - default to **spot** - If the user says `trade this move` - ask whether they want spot or USDT perpetual futures ## Recommended Output Rhythm ### Before execution 1. `Trading Brief` 2. if allowed: `Order Draft` 3. wait for confirmation ### After execution 1. `Execution Result` 2. if needed: `Next Actions` ## Special Rule for Order / Position Management If the user asks for: - amend order - cancel order - verify fill - close half - close all - reverse then the skill does not need to rerun the full research chain, but it still must: - locate the correct target order or position - apply the corresponding execution rules - require strong confirmation for high-risk actions ## Risk Policy ### Hard blocks Must stop immediately if: - the user asks to skip confirmation - the user asks to bypass compliance or risk controls - the product is unsupported - the asset is not tradable - token security check shows a critical malicious risk ### Soft blocks Warn but allow continuation if: - liquidity is poor - slippage is high - funding is extreme - crowding/liquidation risk is elevated - a major event just hit and direction is unstable - the coin is newly listed or still in price discovery For soft blocks: - surface the warning clearly in `Trading Brief` - if the user still wants to continue, drafting is allowed - confirmation is still mandatory ## Reading Order 1. Read `references/routing-and-analysis.md` 2. Read `references/execution-and-guardrails.md` 3. Execute only the modules needed for the current task; do not run the full stack by default

path: CHANGELOG.md
content: # Changelog

## [2026.3.14-3] - 2026-03-14

### Changed

- Tightened the skill's analysis-side mappings to reflect real runtime payload quality, not just tool-name availability.
- Reworked single-coin, event, and new-listing scenarios so they rely primarily on tools that return analyzable outputs in the current runtime.
- Downgraded `info_marketsnapshot_get_market_snapshot` to supplementary context when its payload is sparse.
- Replaced default coin-level `news_feed_get_social_sentiment` usage with `news_feed_search_news(platform_type=\"social_ugc\")` for generic social context.
- Added explicit chain/address resolution requirements before `info_compliance_check_token_security`.
- Documented that `info_markettrend_get_indicator_history` may require array-form `indicators`.

## [2026.3.14-2] - 2026-03-14

### Changed

- Rebased the skill's portable baseline on the documented Gate MCP surfaces from the official repo:
  - `info_*` -> Gate Info MCP
  - `news_feed_*` -> Gate News MCP
  - read-only `cex_spot_*` / `cex_fx_*` market data -> Gate public market MCP or local combined Gate MCP
  - private `cex_*` trading/account tools -> authenticated Gate Exchange MCP or local authenticated Gate MCP
- Removed `news_events_*` as a required dependency from baseline scenarios and routing rules, so the skill stays portable across documented runtimes.
- Updated scenario call patterns to use the documented news/feed and info tools with more portable example parameters.
- Added `references/runtime-dependencies.md` so runtime requirements are now explicit inside the skill package.
- Fixed `info_marketsnapshot_get_market_snapshot` scenario examples to include the required `timeframe` and `source` parameters.

## [2026.3.14-1] - 2026-03-14

### Changed

- Normalized `references/scenarios.md` prompt examples to English-only wording for release consistency.
- Replaced relative Markdown links in `SKILL.md` and `README.md` with plain file-path references to reduce renderer and packaging ambiguity.
- Aligned analysis-tool references with the currently exposed Gate MCP tool surface:
  - replaced stale `info_marketsnapshot_get_market_overview` references with `info_marketsnapshot_get_market_snapshot`
  - removed stale `info_coin_get_coin_rankings` and `info_macro_get_macro_summary` assumptions
  - replaced stale `info_onchain_trace_fund_flow` references with available tx-level on-chain tools
- Added explicit fallback guidance for runtime tool-name drift so the skill degrades honestly instead of overclaiming unavailable analysis depth.

## [2026.3.13-1] - 2026-03-13

### Added

- Added the first public release of `gate-exchange-trading-copilot`.
- Included the formal skill package:
  - `SKILL.md`
  - `README.md`
  - `CHANGELOG.md`
  - `references/scenarios.md`
  - `references/routing-and-analysis.md`
  - `references/execution-and-guardrails.md`
- Included shared runtime-rule referencing through [`gate-runtime-rules.md`](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md).
- Included the end-to-end closed loop for cryptocurrency trading on Gate Exchange:
  - trade judgment
  - risk control
  - order draft generation
  - explicit confirmation
  - execution
  - post-trade management

### Audit

- ✅ The public changelog reflects the first release only.
- ✅ No credentials, private paths, or unpublished internal wording are exposed in the formal release files.
- ✅ The public release aligns on Gate Exchange cryptocurrency scope and explicit-confirmation execution rules.


path: README.md
content: # Gate Exchange Trading Copilot

## Overview

An AI Agent skill that orchestrates cryptocurrency trade judgment, risk control, and execution on Gate Exchange.

It combines analysis and execution into one closed loop:

`judge -> risk control -> order draft -> explicit confirmation -> execution -> post-trade management`

This skill is for users who want one skill to handle the full trading workflow instead of switching among separate market, news, risk, spot, and futures skills.

### Core Capabilities

| Capability | Description | Example |
|------------|-------------|---------|
| **Trade-decision orchestration** | Narrow a vague cryptocurrency trading request into one asset, one market, and one direction on Gate Exchange | `Can I buy BTC now?` |
| **Risk-aware Trading Brief** | Combine coin analysis, technicals, event explanation, microstructure, and token risk into one pre-trade brief | `ETH dumped. Analyze it first before I buy` |
| **Spot execution loop** | Draft -> confirm -> place -> verify -> manage a spot order on Gate Exchange | `If it looks fine, give me a spot buy draft` |
| **Futures execution loop** | Draft -> confirm -> open/close/reverse -> verify -> manage a USDT perpetual trade | `Check momentum and liquidation, then help me long ETH` |
| **Post-trade management** | Amend, cancel, verify fills, verify positions, partially close, or fully close | `Raise my unfilled buy order by 1%` |
| **Risk gating** | Convert pre-trade findings into `GO / CAUTION / BLOCK` before any order draft is created | `Check this newly listed token before I trade it` |

## Supported Scope

### Supported

- Spot buy / sell / market / limit / amend / cancel / fill verification
- USDT perpetual open / close / reverse / amend / cancel
- Market overview before a trade
- Single-coin analysis before a trade
- Technical analysis before a trade
- Event explanation before a trade
- Risk check for new coins / contract addresses
- Liquidity / slippage / momentum / liquidation / basis / funding checks

### Not Supported

- Options
- Alpha trading
- On-chain swap / bridge / DeFi execution
- Fully automatic trading without confirmation
- Bypassing compliance or risk controls
- Pretending to support TP/SL daemon-style auto triggering

## What Makes It Self-Contained

This skill is designed to work even when installed alone:

- It does not assume separate research or execution skills are installed
- It includes **analysis-side MCP mapping**
- It includes **execution-side MCP mapping**
- It defines a consistent intermediate artifact: **Trading Brief**
- It defines a consistent execution gate: **Order Draft + explicit confirmation**

## General Runtime Rules

This skill follows the shared exchange runtime rules:

- [`gate-runtime-rules.md`](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md)

At the skill level, the key expectation is simple:

- analysis-side runtime must expose the referenced `info_*` and `news_*` tools
- execution-side runtime must expose the referenced `cex_spot_*` and `cex_fx_*` tools
- if those shared runtime gates are not satisfied, the skill must not overclaim analysis completeness or execution success
- if a named helper tool is absent in the current runtime, the skill must disclose the gap, use only the nearest valid fallback tools, and avoid overclaiming rankings, macro breadth, or automated fund-flow tracing
- if a tool returns sparse or low-signal payloads in the current runtime, the skill must downgrade it to supporting context instead of using it as the main analytical basis

Portable baseline mapping:

- `info_*` tools should map to Gate Info MCP
- `news_feed_*` tools should map to Gate News MCP
- read-only `cex_spot_*` / `cex_fx_*` market-data tools may come from Gate public market MCP or a local combined Gate MCP runtime
- private trading and account `cex_*` tools should map to authenticated Gate Exchange MCP or a local authenticated Gate MCP runtime

The skill should not require `news_events_*` to be present, because those tools are not part of the documented baseline news surface.

## Guardrail (Mandatory)

Before any real trade placement:

1. Produce a **Trading Brief**
2. Produce an **Order Draft**
3. Wait for explicit user confirmation in the immediately previous turn
4. Execute only after confirmation

If confirmation is missing, stale, ambiguous, or the parameters changed:

- do not execute
- stay in analysis / draft / query mode only

## Architecture

```text
gate-exchange-trading-copilot/
├── SKILL.md
├── README.md
├── CHANGELOG.md
└── references/
    ├── scenarios.md
    ├── routing-and-analysis.md
    └── execution-and-guardrails.md
```

This package references the shared runtime rules from [`gate-runtime-rules.md`](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md); that shared file is intentionally not duplicated inside this skill folder.

See `references/scenarios.md` for packaged scenario cases and representative prompt examples.

## Internal Composition

### Analysis Side

- market overview
- news briefing
- event explanation
- single-coin analysis
- trend analysis
- token risk check
- address tracing (when needed)
- microstructure analysis (liquidity / slippage / liquidation / funding / basis)

### Execution Side

- spot execution flow
- futures execution flow
- order / position management flow

## Typical Usage Examples

```text
"Check whether BTC is worth buying now. If yes, give me a spot order draft."
"ETH suddenly dumped. Explain why, check liquidity, and tell me whether I should buy the dip."
"I want to long ETH. Check momentum, liquidation, and funding first."
"This newly listed coin looks interesting. Check contract risk and tradability before giving me a small starter trade plan."
"Amend the buy order you helped me place earlier."
"Close half of my BTC perpetual position."
```

## Trigger Profile

Use this skill when the user wants **one skill** to complete:

- judgment
- risk control
- trade preparation
- trade execution
- post-trade follow-up

Typical trigger phrases:

- `analyze before buying`
- `check risk before trading`
- `help me decide whether to use spot or futures`
- `give me an order draft`
- `analyze then place order`
- `check risk then trade`
- `manage the order or position you just helped place`

## Safety Summary

- Never auto-trade without explicit confirmation
- Never bypass compliance, risk, or minimum order constraints
- Never present analysis as certainty
- Never produce an order draft after a `BLOCK` result
- For multi-leg trading, require draft + confirmation per leg


path: references/execution-and-guardrails.md
content: # Execution And Guardrails

This file defines the execution-layer rules for the trading copilot.

---

## 1. Supported Execution Products

Only two execution products are supported:

1. **spot**
2. **USDT perpetual futures**

Not supported:

- options
- Alpha trading
- on-chain swap / bridge / DeFi execution
- TP/SL daemon-style auto-monitoring
- fully automated multi-product execution

---

## 2. Market Routing Rules

### 2.1 Route directly to spot

Route to spot when the request clearly implies:

- `buy BTC`
- `sell ETH`
- `spot`
- `buy with 1000U`
- `convert my holdings`

### 2.2 Route directly to futures

Route to USDT perpetual futures when the request clearly implies:

- `long / short`
- `perp / contract / perpetual`
- `leverage`
- `open / close / reverse`

### 2.3 Must clarify first

Ask for clarification if:

- the user only says `trade this move`
- the user only says `place an order for me`
- the request could reasonably mean either spot or futures

In that case ask:

- `Do you want spot or USDT perpetual futures?`

---

### 2.4 Runtime availability and authentication

Apply the shared runtime rules first via [`gate-runtime-rules.md`](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md).

At the execution layer, this skill assumes the runtime exposes the referenced `cex_spot_*` and `cex_fx_*` tools.

If the execution namespace is missing:

1. do not claim execution support
2. do not produce fake execution results
3. remain at analysis-only or draft-only level

If the shared runtime rules still leave the auth gate unresolved:

1. market-data reads may still run
2. draft generation may still run
3. real placement / amend / cancel / account verification must not be claimed as completed
4. follow the shared runtime handling before retrying execution

Never translate missing auth into a fake successful execution.

---

## 2.5 Execution-Layer MCP Mapping

### Spot

| Purpose | MCP Tools |
|---|---|
| account / balances | `cex_spot_get_spot_accounts`, `cex_spot_list_spot_account_book` |
| trading rules | `cex_spot_get_currency`, `cex_spot_get_currency_pair` |
| market data | `cex_spot_get_spot_tickers`, `cex_spot_get_spot_order_book`, `cex_spot_get_spot_candlesticks` |
| order placement | `cex_spot_create_spot_order`, `cex_spot_create_spot_batch_orders` |
| open orders | `cex_spot_list_all_open_orders`, `cex_spot_list_spot_orders` when the pair is already known |
| cancellation | `cex_spot_cancel_spot_order`, `cex_spot_cancel_all_spot_orders`, `cex_spot_cancel_spot_batch_orders` |
| amendment | `cex_spot_amend_spot_order`, `cex_spot_amend_spot_batch_orders` |
| fill verification | `cex_spot_list_spot_my_trades` |
| fee estimation | `cex_wallet_get_wallet_fee`, `cex_spot_get_spot_batch_fee` |

### Futures

| Purpose | MCP Tools |
|---|---|
| contract info | `cex_fx_get_fx_contract` |
| market data / order book | `cex_fx_get_fx_order_book`, `cex_fx_get_fx_tickers` |
| account / position mode | `cex_fx_get_fx_accounts` |
| position query | `cex_fx_list_fx_positions`, `cex_fx_get_fx_dual_position`, `cex_fx_get_fx_position` |
| margin-mode switching | `cex_fx_update_fx_dual_position_cross_mode`, `cex_fx_update_fx_position_cross_mode` |
| leverage update | `cex_fx_update_fx_dual_position_leverage`, `cex_fx_update_fx_position_leverage` |
| order placement | `cex_fx_create_fx_order` |
| order query | `cex_fx_list_fx_orders`, `cex_fx_get_fx_order` |
| cancellation | `cex_fx_cancel_fx_order`, `cex_fx_cancel_all_fx_orders` |
| amendment | `cex_fx_amend_fx_order` |

---

## 3. Order Draft Rules

### 3.1 When an order draft may be produced

All of the following must be true:

1. the target asset is clear
2. the market type is clear
3. the trade direction is clear
4. no hard block has been triggered

### 3.2 Draft must include

#### Spot

- trading pair
- buy / sell
- market / limit
- amount meaning
  - `market buy` = quote amount
  - `market sell` = base amount
- estimated pricing basis
- main risk note (slippage / min order / etc.)

#### Futures

- contract
- long / short
- market / limit
- contracts or converted contract size
- current/target margin mode
- current/target leverage
- core risk note (liquidation / crowding / price deviation)

### 3.3 Draft is not execution

If the user has not explicitly confirmed:

- do not place the real order
- remain at draft level

---

## 4. Strong Confirmation Rules

### 4.1 Actions that always require explicit confirmation

- spot order placement
- futures open
- futures close
- reverse
- batch placement
- batch amend
- batch cancel
- close all

### 4.2 Allowed confirmation phrases

- `confirm`
- `confirm order`
- `proceed`
- `execute`
- `yes, place it`

### 4.3 Confirmation must satisfy

1. it comes in the immediately previous user turn
2. it refers to the latest draft
3. parameters have not changed

If any of the following happens, old confirmation becomes invalid:

- the asset changes
- the direction changes
- the price/size changes
- the conversation shifts to another topic
- multiple candidate drafts were discussed

---

## 5. Spot Execution Rules

### 5.0 Common call order for spot

#### Market / limit buy or sell

1. `cex_spot_get_spot_accounts`
2. `cex_spot_get_currency_pair`
3. when live pricing or book data is needed:
   - `cex_spot_get_spot_tickers`
   - add `cex_spot_get_spot_order_book` if book depth matters
4. produce `Order Draft`
5. wait for user confirmation
6. `cex_spot_create_spot_order`
7. when verification is needed:
   - `cex_spot_list_spot_my_trades`
   - or `cex_spot_get_spot_accounts`

#### Amend / cancel

1. `cex_spot_list_all_open_orders`
   - if the pair is already known, `cex_spot_list_spot_orders(currency_pair="...")` is also valid
2. identify the target order
3. produce amend/cancel draft
4. wait for confirmation
5. call the corresponding amend/cancel tool

#### Batch actions

1. list candidate orders
2. let the user confirm the scope
3. then run batch amend / batch cancel

### 5.1 Supported spot actions

- market buy/sell
- limit buy/sell
- limit logic calculated from conditions
- balance query
- fill query
- amend
- cancel
- batch placement / batch amend / batch cancel (only when explicitly requested)

### 5.2 Do not pretend to support

- TP/SL auto-trigger engines
- persistent background watchers
- hidden multi-step automatic execution in one sentence

### 5.3 Multi-leg spot actions

Examples:

- `buy first, then place a sell order`
- `sell BTC, then buy ETH`

Rules:

1. split into separate legs
2. each leg needs its own draft
3. each leg needs its own confirmation

---

## 6. Futures Execution Rules

### 6.0 Common call order for futures

#### Open position

1. `cex_fx_get_fx_contract`
2. `cex_fx_get_fx_accounts`
3. choose the correct position-query tool based on single vs dual mode
4. if the user explicitly requests leverage or margin-mode changes, apply the corresponding update tools first
5. when price/book data is needed:
   - `cex_fx_get_fx_order_book`
   - `cex_fx_get_fx_tickers`
6. produce `Order Draft`
7. wait for confirmation
8. `cex_fx_create_fx_order`
9. verify the position:
   - `cex_fx_list_fx_positions`
   - or `cex_fx_get_fx_dual_position` / `cex_fx_get_fx_position`

#### Close / reverse

1. query the current position first
2. produce the action draft
3. wait for confirmation
4. `cex_fx_create_fx_order`
5. query again to verify the remaining position

#### Amend / cancel

1. `cex_fx_list_fx_orders`
2. identify the target order
3. produce amend/cancel draft
4. wait for confirmation
5. call `cex_fx_amend_fx_order` or `cex_fx_cancel_fx_order`

### 6.1 Supported futures actions

- open long / open short
- full close / partial close
- reverse
- amend
- cancel

### 6.2 Rules inherited from the futures execution layer

- USDT perpetual only
- if leverage is not specified, keep the current effective leverage
- if margin mode is not specified, keep the current effective mode
- close all, reverse, and batch cancellation always require strong confirmation

### 6.3 Futures should usually add these risk checks

Before opening a futures position, prefer to add one or more of:

- momentum
- liquidation
- funding / basis
- support / resistance

Do not open futures directly after only a broad fundamentals read.

---

## 7. Management Flow Rules

### 7.1 Requests that can enter management flow directly

- `amend that order`
- `cancel that buy order`
- `close half`
- `did that fill?`

### 7.2 Management flow does not need the full research chain

But it still must:

- locate the correct order or position
- make the intended modification explicit
- keep strong confirmation for high-risk actions

---

## 8. Hard Blocks

Must stop execution if:

1. the user asks to skip confirmation
2. the user asks the AI to decide and trade directly
3. the user asks to bypass compliance / risk / safety controls
4. the product is unsupported
5. the trading target is not tradable
6. token risk check indicates critical malicious risk:
   - honeypot
   - extreme malicious tax
   - clearly unsellable / highly malicious contract

When blocked:

- explain the reason
- do not produce an order draft

---

## 9. Soft Blocks

Default to `CAUTION` instead of direct execution when:

- liquidity is poor
- slippage is high
- holdings are highly concentrated
- the contract is not open-source
- a major abnormal move just happened and the direction is unresolved
- funding is extreme
- the asset is newly listed and still in price discovery

In these cases:

1. surface the warning clearly
2. if the user still wants to continue, drafting may proceed
3. confirmation is still mandatory

---

## 10. Unified Output After Execution

### 10.1 Execution Result template

```markdown
## Execution Result

### 1. Action
- {what was executed}

### 2. Status
- {success / failed / not executed}

### 3. Core Numbers
- {price / size / cost / fill status / remaining position}

### 4. Next Actions
- {verify fill / amend / cancel / close / keep watching}
```

### 10.2 If execution did not happen

State clearly whether it was due to:

- missing confirmation
- condition not met
- risk block
- unsupported product
- insufficient balance or minimum-order rule

Do not use vague wording.

---

## 11. Recommended Closed Loops

### 11.1 Spot loop

`analysis -> risk check -> order draft -> confirmation -> spot order -> fill verification`

### 11.2 Futures loop

`analysis -> momentum/liquidation/funding check -> order draft -> confirmation -> futures order -> position verification`

### 11.3 New-coin starter loop

`listing/risk check -> technical/liquidity check -> order draft -> confirmation -> small spot execution`


path: references/mcp.md
content: ---
name: gate-exchange-trading-copilot-mcp
version: "2026.3.30-1"
updated: "2026-03-30"
description: "MCP orchestration specification for composite trading copilot workflows across info, news, spot, and futures execution layers."
---

# Gate Trading Copilot MCP Specification

## 1. Scope and Trigger Boundaries

In scope:
- Composite flow: analysis -> risk gate -> order draft -> explicit confirmation -> execution -> verification
- Spot and USDT perpetual futures workflows
- Order/position management after execution

Out of scope:
- Fully automatic execution without confirmation
- Unsupported products (options/alpha/defi/copy if not explicitly covered)

Misroute examples:
- Pure welfare/kyc/pay queries should route to dedicated skills.

## 2. MCP Detection and Fallback

Detection:
1. Verify availability of required tool groups for requested flow:
   - analysis (info/news/market data)
   - execution (spot/futures private endpoints)
2. Probe with minimal read endpoints before draft/execution.

Fallback:
- If execution endpoints unavailable, stay in analysis + draft-only mode.
- If analysis endpoints are partially unavailable, continue with available evidence and clearly label confidence.

## 3. Authentication

- Analysis may include public data, but execution/management requires authenticated API key permissions.
- If auth is invalid, block write operations and return draft-only guidance.

## 4. MCP Resources

No mandatory MCP resources.

## 5. Tool Calling Specification

Tool groups (representative, not exhaustive):
- Info/News: `info_*`, `news_feed_*`
- Spot market/execution: `cex_spot_*`
- Futures market/execution: `cex_fx_*`

Calling rules:
- Do not call undocumented tool families for this skill.
- For each scenario, use only minimum necessary modules.
- For writes, preserve exact draft parameters at execution time.

Common errors:
- symbol/contract mismatch
- insufficient balance/margin
- min-notional or precision violation
- missing order/position identifiers for management actions

## 6. Execution SOP (Non-Skippable)

1. Identify task mode: decision, draft+execute, or order/position management.
2. Narrow to one trade target and market (spot or futures) before execution.
3. Build Trading Brief with risk gates.
4. Produce Order Draft only when hard blocks are absent.
5. Require explicit immediate user confirmation.
6. Execute write action.
7. Verify with read-back endpoints and return post-state.

## 7. Output Templates

```markdown
## Trading Brief
- Target: {asset_and_market}
- Signals: {market_news_technical_liquidity}
- Risks: {hard_and_soft_flags}
- Decision: {GO_CAUTION_BLOCK}
```

```markdown
## Order Draft
- Action: {buy_sell_long_short_close}
- Symbol/Contract: {market_target}
- Price Type: {limit_or_market}
- Size: {amount_or_size}
- Risk Notes: {slippage_liquidation_funding}
Reply with explicit confirmation to execute.
```

```markdown
## Execution Result
- Status: {success_or_failed}
- Order/Position ID: {id_if_available}
- Post-State: {filled_open_partially_filled_closed}
```

## 8. Safety and Degradation Rules

1. Never skip confirmation for write operations.
2. Never bypass compliance/risk hard blocks.
3. Never fabricate market evidence, fills, or position states.
4. Keep analysis-only mode when execution tools/auth are unavailable.
5. Clearly separate probabilities from certainties in recommendations.


path: references/routing-and-analysis.md
content: # Routing And Analysis

This file defines:

1. how user intents are routed
2. which analysis modules should be used for which trading scenario
3. when to output `GO / CAUTION / BLOCK`

---

## 1. Intent Routing

| User Type | Typical Request | Handling |
|---|---|---|
| Judge before trading | `Can I buy BTC now?` | Enter single-asset trade-decision flow |
| Direction already chosen, wants risk control | `I want to long ETH, but check liquidation and momentum first` | Enter futures-focused decision flow |
| Event-driven trade | `ETH suddenly dumped, can I buy the dip?` | Run event explanation first, then technical + microstructure checks |
| New coin / long-tail trade | `Can I trade this newly listed coin?` | Run listing/risk check first, then pre-trade decision flow |
| Opportunity discovery | `What is a good trade today?` | Run lightweight market scan, then narrow to one asset |
| Order / position management | `Amend that order`, `close half` | Enter execution-management flow directly without full research loop |

---

## 2. Narrowing Rules: Asset and Market

### 2.1 Must be clear before execution

- one asset
- one market (spot or USDT perpetual futures)
- one action direction

### 2.2 Scan first, narrow second

If the user has trading intent but no clear asset yet, for example:

- `What is a good trade today?`
- `Is there anything worth trading right now?`

then a lightweight scan is allowed:

- market state
- current dominant events/news

Recommended MCP tools:

- `news_feed_search_news`
- `news_feed_get_exchange_announcements` when exchange activity matters
- `info_marketsnapshot_get_market_snapshot`
- `info_markettrend_get_technical_analysis` after narrowing to 1-2 candidate majors

At this stage, give at most **1-2 candidate directions**, then ask the user to choose a target asset before entering the real trading loop.

Never produce an order draft before narrowing down to one asset and one market.

---

## 3. Analysis Module Selection

### 3.0 Baseline MCP surfaces

Use the documented Gate MCP surfaces as the portable baseline for this composite skill:

- `info_*` -> Gate Info MCP
- `news_feed_*` -> Gate News MCP
- read-only `cex_spot_*` / `cex_fx_*` market-data calls -> Gate public market MCP or a local combined Gate MCP runtime
- private `cex_*` trading and account calls -> authenticated Gate Exchange MCP or a local authenticated Gate MCP runtime

If the runtime exposes extra namespaces beyond this baseline, they may be treated as optional accelerators only. The baseline scenarios in this file must remain viable without them.

### 3.0 Module-to-MCP Mapping

To make this composite skill self-contained, the core analysis modules are mapped below.

| Analysis Module | Purpose | MCP Tools |
|---|---|---|
| Market overview | Understand the broad market before trading | `news_feed_search_news`, `news_feed_get_exchange_announcements` when exchange activity matters, `info_markettrend_get_technical_analysis` after narrowing to 1-2 candidate majors, optional `info_marketsnapshot_get_market_snapshot` when it returns populated fields |
| News briefing | Understand current headlines and sentiment context | `news_feed_search_news`, `news_feed_get_exchange_announcements` when exchange activity matters, `news_feed_search_news` with `platform_type=\"social_ugc\"` when social chatter matters |
| Listing / exchange announcement context | Understand whether the asset is newly listed, delisting-related, or driven by exchange activity | `news_feed_get_exchange_announcements`, `info_coin_get_coin_info`, optional `info_marketsnapshot_get_market_snapshot` when it returns populated fields |
| Single-coin analysis | Understand whether an asset is worth trading | `info_coin_get_coin_info` for identity/disambiguation, `info_markettrend_get_technical_analysis`, `info_markettrend_get_kline`, `news_feed_search_news`, optional `info_marketsnapshot_get_market_snapshot` when it returns populated fields |
| Technical analysis | Understand trend, indicators, support, resistance | `info_markettrend_get_kline`, optional `info_markettrend_get_indicator_history` with array-form `indicators`, `info_markettrend_get_technical_analysis`, optional `info_marketsnapshot_get_market_snapshot` when it returns populated fields |
| Event explanation | Understand why a move happened | `news_feed_search_news`, `news_feed_search_news` with `platform_type=\"social_ugc\"` when social chatter matters, `news_feed_get_exchange_announcements` when exchange activity is suspected, `info_markettrend_get_kline`, optional `info_marketsnapshot_get_market_snapshot` or `info_onchain_get_token_onchain` when they return populated fields |
| Risk check | Check token / contract security | `info_coin_get_coin_info`, then `info_compliance_check_token_security` only after chain/address resolution |
| Address tracing | Check address profile, transactions, and tx-level flow fragments | `info_onchain_get_address_info`, `info_onchain_get_address_transactions`, `info_onchain_get_transaction` |
| Exchange microstructure | Check liquidity, slippage, momentum, liquidation, basis, order-book quality | `cex_spot_*` or `cex_fx_*` market-data tools, based on spot/futures routing |

### 3.0A Analysis-side availability rule

Apply the shared runtime rules first via [`gate-runtime-rules.md`](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md).

This composite skill assumes the runtime exposes the referenced `info_*` and `news_*` tools.

If the current runtime does **not** expose the required analysis namespace:

1. do not pretend that full pre-trade judgment was completed
2. do not synthesize a fake `GO` decision from missing data
3. do not continue into a new-trade `Order Draft`
4. report that the analysis-side environment remains unavailable after applying the shared runtime rules

Allowed exception:

- if the user request is pure order/position management, the skill may still continue with the execution-management flow, because that path can be valid without re-running the full research chain

For new-trade requests, missing core analysis modules should be treated as a runtime block rather than silently degraded into execution.

### 3.0B Tool-name drift and fallback rules

This skill must validate concrete tool names against the current runtime tool list before calling them. Prefer the current runtime surface over older examples, screenshots, or stale repo docs.

Known fallback rules:

1. If `info_marketsnapshot_get_market_overview` is unavailable, do not try to recreate full market breadth from a sparse `info_marketsnapshot_get_market_snapshot` payload. Use `news_feed_search_news`, `info_markettrend_get_technical_analysis`, and exchange market-data reads for the narrowed asset instead.
2. If `info_coin_get_coin_rankings` or `info_macro_get_macro_summary` is unavailable, do not claim ranking coverage or macro-summary coverage. Narrow to 1-2 candidate majors first, then use `info_coin_get_coin_info`, trend tools, and relevant news tools.
3. If `info_onchain_trace_fund_flow` is unavailable, use `info_onchain_get_address_transactions` and `info_onchain_get_transaction` for manual trace fragments, plus `info_onchain_get_token_onchain` only as supporting context when it returns populated fields. Do not present this as a full automated fund-flow trace.
4. Prefer the documented `news_feed_*` tools as the default news path. Do not make undocumented `news_events_*` tools a prerequisite for any baseline scenario in this file.
5. Do not use `news_feed_get_social_sentiment` as a default coin-level sentiment tool. In the current runtime it requires `post_id`, so use `news_feed_search_news(platform_type=\"social_ugc\")` for generic social context and reserve `news_feed_get_social_sentiment` for post-specific follow-up only.
6. Do not call `info_compliance_check_token_security` until the chain or contract address is resolved with confidence.

### 3.0.1 Spot microstructure tools

- `cex_spot_get_spot_order_book`
- `cex_spot_get_spot_candlesticks`
- `cex_spot_get_spot_tickers`
- `cex_spot_get_spot_trades`

### 3.0.2 Futures microstructure tools

- `cex_fx_get_fx_contract`
- `cex_fx_get_fx_order_book`
- `cex_fx_get_fx_candlesticks`
- `cex_fx_get_fx_tickers`
- `cex_fx_get_fx_trades`
- `cex_fx_get_fx_funding_rate`
- `cex_fx_list_fx_liq_orders`
- `cex_fx_get_fx_premium_index`

### 3.1 Base mode (default)

Use when:

- the user already gave one asset
- the user simply wants to know whether buying/selling/longing/shorting makes sense now

Call:

1. `single-coin analysis`
   - `info_coin_get_coin_info`
   - `info_markettrend_get_technical_analysis`
   - `info_markettrend_get_kline`
   - add `news_feed_search_news` only when headline context matters
   - add `info_marketsnapshot_get_market_snapshot` only when it returns populated fields
2. `technical analysis`
   - `info_markettrend_get_kline`
   - `info_markettrend_get_indicator_history` with array-form `indicators` only when the extra detail is needed
   - `info_markettrend_get_technical_analysis`
   - `info_marketsnapshot_get_market_snapshot` only when it returns populated fields

Expected output:

- directional read
- key price levels
- current uncertainty

### 3.2 Execution-sensitive mode

Use when:

- the user cares about execution quality
- the size is large
- the user explicitly asks about slippage, liquidity, support/resistance, order book, or liquidation
- the user wants futures

Add:

3. `exchange microstructure analysis`

Recommended patterns:

- spot liquidity / slippage
  - `cex_spot_get_spot_order_book` -> `cex_spot_get_spot_tickers`
- spot momentum
  - `cex_spot_get_spot_trades` -> `cex_spot_get_spot_tickers` -> `cex_spot_get_spot_candlesticks`
- futures momentum
  - `cex_fx_get_fx_trades` -> `cex_fx_get_fx_tickers` -> `cex_fx_get_fx_candlesticks` -> `cex_fx_get_fx_funding_rate`
- futures liquidation
  - `cex_fx_list_fx_liq_orders` -> `cex_fx_get_fx_candlesticks` -> `cex_fx_get_fx_tickers`
- futures basis / funding
  - `cex_fx_get_fx_tickers` -> `cex_fx_get_fx_funding_rate` -> `cex_fx_get_fx_premium_index`

Preferred sub-scenarios:

| Scenario | When to use |
|---|---|
| Liquidity / Slippage | Large spot or futures trade; user asks whether the market can absorb the size |
| Momentum | User wants futures direction judgment |
| Liquidation | User asks about squeeze / wipeout / forced-move conditions |
| Basis / Funding | User wants perpetual futures, especially short-term trading |
| Support / Resistance | User asks for entry level, breakout level, or resistance level |

### 3.3 Event-driven mode

Use when:

- the user is triggered by a sudden move
- the user asks `why did this happen, and is it tradable now?`

Call:

1. `event explanation`
   - `news_feed_search_news`
   - `news_feed_search_news` with `platform_type="social_ugc"` when social chatter matters
   - `news_feed_get_exchange_announcements` when exchange activity is suspected
   - `info_markettrend_get_kline`
   - `info_marketsnapshot_get_market_snapshot` only when it returns populated fields
   - `info_onchain_get_token_onchain` only when on-chain confirmation is needed and the payload is non-sparse
2. `technical analysis`
3. `exchange microstructure analysis`
4. add `single-coin analysis` when broader context is still needed

Goal:

- decide whether the move is driven by news, on-chain flow, liquidation, or sentiment
- then decide whether it is tradable

### 3.4 New coin / long-tail mode

Use when:

- the user mentions a newly listed coin
- the user mentions exchange listing / new listing / recently listed
- the user mentions meme / contract address / honeypot / rug / safety
- the user wants to trade an unfamiliar small-cap asset

Call:

1. `listing / exchange announcement context` when the request is explicitly listing-driven
   - `news_feed_get_exchange_announcements`
   - `info_coin_get_coin_info`
   - `info_marketsnapshot_get_market_snapshot` only when it returns populated fields
2. `risk check`
   - `info_coin_get_coin_info`
   - `info_compliance_check_token_security` only after chain/address resolution
3. `address tracing` only when the user provides an address and wants fund-source tracing
   - `info_onchain_get_address_info`
   - `info_onchain_get_address_transactions`
   - `info_onchain_get_transaction`
4. `single-coin analysis`
5. `technical analysis`
6. `exchange microstructure analysis`

Important:

- risk check is not optional in this mode; it is the trade gate

---

## 4. Risk Gate Rules

### 4.1 Mandatory risk-check triggers

Run token/contract risk check before drafting if any of these apply:

- the user explicitly asks about safety / honeypot / rug / scam / risk
- the user provides a contract address
- the user says `new coin`, `new listing`, `meme`, `small cap`, `long-tail`
- the trading target is not a common major asset and identity confidence is low

### 4.2 Address tracing should only be used when

- the user provides an address directly
- the user asks where funds came from / who is selling / who is buying
- the user suspects a project or whale address is driving price action

Do not use address tracing as a default step before every trade.

### 4.3 Risk result translation

| Result | Meaning | Next Action |
|---|---|---|
| `GO` | No trade-breaking risk was identified | Order draft may be produced |
| `CAUTION` | Trading is possible, but meaningful risk exists | Warn clearly, then drafting may continue |
| `BLOCK` | The workflow should not continue to execution | Stop at analysis level; do not draft |

### 4.4 Default `BLOCK` cases

- honeypot / likely unsellable token
- invalid or non-tradable pair / contract
- exchange currently does not allow trading on that asset
- the user asks to bypass security or compliance
- the requested execution ability is outside supported scope

### 4.5 Default `CAUTION` cases

- high token tax
- concentrated holdings
- poor liquidity
- notable slippage
- extreme funding
- elevated liquidation / crowding risk
- a major event just happened and direction is unresolved
- newly listed asset still in price discovery

---

## 5. Trading Brief Template

Before any execution, produce a `Trading Brief` with at least five parts:

```markdown
## Trading Brief

### 1. User Intent
- {what the user wants to do}

### 2. Market Read
- {bullish / bearish / sideways / event-driven / elevated risk}

### 3. Key Evidence
- {technical evidence}
- {event/news evidence}
- {liquidity / order book / liquidation evidence}
- {risk-check evidence, if any}

### 4. Risk Level
- {GO / CAUTION / BLOCK}

### 5. Next Step
- {continue to order draft / suggest waiting / ask for missing inputs}
```

Constraints:

- never say `guaranteed`
- never turn analysis into certainty
- if the result is `BLOCK`, stop there

---

## 6. Typical Composite Paths

### 6.1 Spot trade after judgment

`single-coin analysis` -> `technical analysis` -> optional `liquidity/slippage` -> `Trading Brief` -> `spot order draft`

### 6.2 Futures trade after judgment

`technical analysis` -> `momentum/liquidation/funding` -> optional `event explanation` -> `Trading Brief` -> `futures order draft`

### 6.3 New-coin starter trade

`listing info` -> `risk check` -> `technical analysis` -> `liquidity/slippage` -> `Trading Brief` -> `spot order draft`

### 6.4 Buy-the-dip after a dump

`event explanation` -> `technical analysis` -> `liquidity/liquidation` -> `Trading Brief` -> `spot or futures order draft`

### 6.5 Market scan to opportunity

`market overview` -> `news briefing` -> pick 1-2 candidates -> user chooses one asset -> normal pre-trade workflow -> order draft

Important: scanning is not execution. Execution must still return to one-asset closure.


path: references/runtime-dependencies.md
content: # Runtime Dependencies

This file defines the minimum runtime dependencies for `gate-exchange-trading-copilot`.

## 1. Required MCP Surfaces

The skill is portable only when the runtime exposes these baseline surfaces:

- `info_*` from Gate Info MCP
- `news_feed_*` from Gate News MCP
- read-only `cex_spot_*` / `cex_fx_*` market-data tools from Gate public market MCP or a local combined Gate MCP runtime
- private `cex_*` trading and account tools from authenticated Gate Exchange MCP or a local authenticated Gate MCP runtime

Optional runtime extras may exist, but the skill must not depend on them for baseline scenarios.

## 2. Baseline Tool Families

### 2.1 Analysis Side

- `info_coin_get_coin_info`
- `info_marketsnapshot_get_market_snapshot`
- `info_markettrend_get_kline`
- `info_markettrend_get_indicator_history`
- `info_markettrend_get_technical_analysis`
- `info_compliance_check_token_security`
- `info_onchain_get_address_info`
- `info_onchain_get_address_transactions`
- `info_onchain_get_transaction`
- `info_onchain_get_token_onchain`
- `news_feed_search_news`
- `news_feed_get_exchange_announcements`
- `news_feed_get_social_sentiment` only when a specific `post_id` is available

Notes:

- `info_marketsnapshot_get_market_snapshot` may return sparse payloads in some runtimes; use it as supplementary context rather than primary evidence unless populated.
- `info_markettrend_get_indicator_history` may require array-form `indicators` in the current runtime.
- `info_compliance_check_token_security` requires resolved `chain` plus token/address context.
- generic social context should prefer `news_feed_search_news` with `platform_type=\"social_ugc\"`; reserve `news_feed_get_social_sentiment` for post-specific follow-up.

### 2.2 Execution Side

- spot read/write: `cex_spot_*`
- futures read/write: `cex_fx_*`
- wallet fee and balance helpers when needed: selected `cex_wallet_*`

## 3. Authentication Rules

- `info_*` and `news_feed_*` are expected to work without authentication in the normal Gate hosted MCP deployment.
- read-only public market data may work without authentication, depending on the runtime surface.
- private order placement, order management, position queries, balances, and account verification require authenticated Gate execution tools.

## 4. Runtime Gate Expectations

Before analysis or execution, the runtime should prove:

1. Gate MCP is installed and reachable.
2. The required baseline tool families are exposed.
3. Authenticated execution tools are available before private trading/account actions.

If a required tool family is missing:

- do not overclaim full skill coverage
- do not synthesize fake execution or fake analysis depth
- narrow to the supported subset or block the workflow

## 5. Tool Drift Guidance

If the runtime exposes newer or extra tools:

- prefer the current runtime tool list over stale examples
- keep baseline scenarios compatible with the documented tool surface
- treat non-baseline extras, such as undocumented helper namespaces, as optional accelerators only


path: references/scenarios.md
content: # Gate Exchange Trading Copilot — Scenarios & Prompt Examples

## Scenario 1: Spot Buy Decision And Draft
**Context**: The user wants a single cryptocurrency trading skill on Gate Exchange to judge whether BTC is worth buying now and then prepare a spot draft.
**Prompt Examples**:
- "Check whether BTC is worth buying now, and if the setup looks good, give me a spot buy draft."
- "Analyze BTC first, and if the setup is acceptable, give me a spot buy draft."
**Expected Behavior**:
1. Fetch coin identity and headline context via `info_coin_get_coin_info(query="BTC", query_type="symbol", scope="detailed")` and `news_feed_search_news(query="BTC", coin="BTC", sort_by="importance", limit=5)`
2. Fetch trend confirmation via `info_markettrend_get_technical_analysis(symbol="BTC")` and `info_markettrend_get_kline(symbol="BTC", timeframe="1h", period="24h", with_indicators=true)`
3. Add `info_marketsnapshot_get_market_snapshot(symbol="BTC", timeframe="1h", source="spot")` only as supplementary context when it returns populated fields
4. Fetch executable spot context via `cex_spot_get_currency_pair(currency_pair="BTC_USDT")` and `cex_spot_get_spot_tickers(currency_pair="BTC_USDT")`
5. Calculate a pre-trade judgment and risk conclusion
6. Output a `Trading Brief`, then a spot `Order Draft` if not blocked

## Scenario 2: Futures Long With Microstructure Check
**Context**: The user wants to long ETH perpetual, but only after checking momentum, liquidation pressure, and funding conditions.
**Prompt Examples**:
- "I want to long ETH perpetual, but check momentum, liquidation, and funding first before deciding whether to place the order."
- "I want to long ETH perpetual. Check momentum, liquidation, and funding before drafting the trade."
**Expected Behavior**:
1. Fetch data via `cex_fx_get_fx_contract(settle="usdt", contract="ETH_USDT")` and `cex_fx_get_fx_tickers(settle="usdt", contract="ETH_USDT")`
2. Fetch microstructure via `cex_fx_get_fx_order_book(settle="usdt", contract="ETH_USDT")`, `cex_fx_list_fx_liq_orders(settle="usdt", contract="ETH_USDT")`, and `cex_fx_get_fx_funding_rate(settle="usdt", contract="ETH_USDT")`
3. Calculate the futures-side trade setup and liquidation or funding risk
4. Output a futures-oriented `Trading Brief`
5. Output a futures `Order Draft` with leverage visibility, then wait for explicit confirmation

## Scenario 3: News-Driven Dip Buy
**Context**: The user notices a sharp ETH move and wants explanation plus a small follow-up spot trade plan on Gate Exchange.
**Prompt Examples**:
- "ETH just dumped hard. Explain what happened, then tell me whether a small dip-buy makes sense."
- "ETH just dumped. Explain why, then tell me whether a small spot dip-buy makes sense."
**Expected Behavior**:
1. Fetch recent headlines via `news_feed_search_news(query="ETH", coin="ETH", sort_by="importance", limit=10)`
2. Fetch social context via `news_feed_search_news(query="ETH", coin="ETH", platform_type="social_ugc", sort_by="sentiment", limit=5)` when a sentiment read is needed
3. Fetch market confirmation via `info_markettrend_get_kline(symbol="ETH", timeframe="15m", period="24h", with_indicators=true)` and `cex_spot_get_spot_tickers(currency_pair="ETH_USDT")`
4. Add `info_marketsnapshot_get_market_snapshot(symbol="ETH", timeframe="1h", source="spot")` or `info_onchain_get_token_onchain(token="ETH", chain="ethereum", scope="activity")` only as supplementary context when they return populated fields
5. Calculate whether the move is news-driven, sentiment-driven, liquidation-driven, or momentum continuation
6. Output a `Trading Brief` that separates catalyst risk from entry timing, then a conservative spot `Order Draft` only if the risk gate is not blocked

## Scenario 4: New Listing Risk Gate
**Context**: The user wants to trade a newly listed token. The skill should not jump directly into execution without listing context and token security checks.
**Prompt Examples**:
- "This newly listed token looks risky. Check it before telling me whether I can buy it."
- "This newly listed token looks interesting. Check the risk before giving me any trade plan."
**Expected Behavior**:
1. Fetch data via `news_feed_get_exchange_announcements(coin="TOKEN", announcement_type="listing")` and `info_coin_get_coin_info(query="TOKEN", query_type="symbol", scope="detailed")`
2. Resolve the chain or contract address from coin info or user input before security analysis
3. Fetch security context via `info_compliance_check_token_security(token="TOKEN", chain="RESOLVED_CHAIN")` only after chain resolution
4. If chain or address cannot be resolved confidently, stop at `CAUTION` or ask for the contract address instead of pretending the security check completed
5. Calculate whether liquidity, security, or manipulation concerns require a hard block
6. Output a `Trading Brief` with `GO / CAUTION / BLOCK`
7. Output a refusal or warning instead of an executable draft when the risk gate remains blocked

## Scenario 5: Amend An Existing Spot Order
**Context**: The user already has an unfilled spot order and wants to raise the bid slightly without rerunning the full research workflow.
**Prompt Examples**:
- "Raise the unfilled BTC buy order I just placed by 1%."
- "Raise my unfilled BTC buy order by 1%."
**Expected Behavior**:
1. Fetch data via `cex_spot_list_all_open_orders()`
2. Calculate which open order matches the user's request and what the revised price should be
3. Output an amended order draft when parameters materially change
4. Fetch execution via `cex_spot_amend_spot_order(order_id="...")` after confirmation
5. Output an `Execution Result` with amended order status

## Scenario 6: Close Part Of A Futures Position
**Context**: The user wants to reduce an existing ETH perpetual position after the trade is already open.
**Prompt Examples**:
- "Reduce my current ETH perpetual position by half."
- "Close half of my current ETH perpetual position."
**Expected Behavior**:
1. Fetch data via `cex_fx_list_fx_positions(settle="usdt", holding=true)`
2. Calculate side, size, and the requested reduce-only amount
3. Output a close draft if confirmation is still needed
4. Fetch execution via `cex_fx_create_fx_order(settle="usdt", contract="ETH_USDT")` with reduce-only intent
5. Output an `Execution Result` summarizing the reduced exposure


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)