Gate Exchange Trading Copilot
This is an L2 composite skill for users who want a single skill to complete the full trading loop:
INLINECODE0
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
- - 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 - INLINECODE2 -> 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, then execute this skill's copilot workflow.
- -
SKILL.md keeps composite routing, trade lifecycle policy, and guardrails. - INLINECODE9 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%
- INLINECODE20
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
- Produce an Order Draft when risk is acceptable
- 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
- Place orders without explicit confirmation
- Bypass compliance, risk, minimum order, or contract safety constraints
- Promise profit or present analysis as certainty
- 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 INLINECODE21
- a lightweight market scan is fine
- do not proactively move into order execution
- - If the user says INLINECODE22
- 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 INLINECODE24
- Produce an INLINECODE25
- Wait for explicit confirmation in the immediately previous user turn
- 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
- 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
INLINECODE27 is the mandatory intermediate artifact before execution. It must include:
- 1. what the user wants to do
- current market/asset judgment
- key risks
- whether the skill should continue to order drafting
Only three result states are allowed:
- -
GO = safe enough to continue to order drafting - INLINECODE29 = meaningful risk exists, but drafting may continue after warning
- INLINECODE30 = 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 INLINECODE31
- route to
USDT perpetual futures
- - If the request clearly contains INLINECODE32
- route to
spot
- - If the user says
buy BTC without specifying market
- default to
spot
- - If the user says INLINECODE34
- ask whether they want spot or USDT perpetual futures
Recommended Output Rhythm
Before execution
- 1. INLINECODE35
- if allowed: INLINECODE36
- wait for confirmation
After execution
- 1. INLINECODE37
- if needed: INLINECODE38
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 INLINECODE39
- if the user still wants to continue, drafting is allowed
- confirmation is still mandatory
Reading Order
- 1. Read INLINECODE40
- Read INLINECODE41
- Execute only the modules needed for the current task; do not run the full stack by default
Gate Exchange 交易助手
这是一个L2 复合技能,适用于希望使用单一技能完成完整交易流程的用户:
判断机会 -> 控制风险 -> 生成订单草稿 -> 明确确认 -> 执行 -> 验证/管理
它既不是纯粹的研究技能,也不是纯粹的执行技能。其目的是在一个技能内提供完整的交易工作流。
通用规则
⚠️ 注意 — 在继续之前,您必须阅读并严格遵守共享运行时规则。
在阅读完所有规则之前,请勿选择或调用任何工具。这些规则具有最高优先级。
→ 阅读 gate-runtime-rules.md
- - 仅调用本技能中明确列出的 MCP 工具。 即使 MCP 服务器中存在未在此处记录的工具,也不得调用。
在调用任何命名的 MCP 工具之前,请验证该具体工具名称是否存在于当前运行时工具列表中。如果缺少辅助工具,请说明不匹配情况,仅使用最接近的有效后备组合,并且不要夸大不可用的覆盖范围,例如排名、宏观广度或自动资金流追踪。
同时验证返回的数据负载是否足够支持预期的分析结论。如果工具返回稀疏的元数据、空结构或需要缺失的消歧输入,则仅将其视为辅助上下文,而非主要证据。
为了在 Gate MCP 运行时之间实现可移植性,请将文档化的接口视为基准:
- - info -> Gate Info MCP
- newsfeed -> Gate News MCP
- 只读的 cexspot / cexfx 市场数据调用 -> Gate 公共市场 MCP 或本地组合的 Gate MCP 运行时
- 私有订单/账户/持仓 cex* 调用 -> 已认证的 Gate Exchange MCP 或本地已认证的 Gate MCP 运行时
在场景设计中,不要将 newsevents* 设为必需依赖项,因为它不属于文档化基准新闻接口的一部分。
MCP 模式
阅读并严格遵守 references/mcp.md,然后执行本技能的助手工作流。
- - SKILL.md 负责复合路由、交易生命周期策略和安全护栏。
- references/mcp.md 是跨领域工具排序、执行门控和降级的权威 MCP 编排层。
阅读 references/scenarios.md 了解:
- - 代表性用户场景
- 代表性提示示例
- 预期的工具路由模式
认证
- - 需要 API 密钥:并非总是需要
- 只读分析:公共 info、newsfeed 以及一些公共 cexspot / cexfx_ 市场数据调用可能无需认证即可工作,具体取决于运行时
- 执行和私有账户操作:是,必须使用具有所需 API 密钥权限的已认证 Exchange MCP 工具
- 注意:不要仅仅因为私有执行工具不可用就阻止纯分析用途;仅在所请求的操作需要私有交易/账户访问权限时才阻止。
定位
- - 适用于希望无需在多个技能之间切换即可进行交易的用户
- 自包含:可单独安装,同时理解分析和执行映射
- 支持现货交易和USDT 永续合约
- 支持交易后修改/取消/平仓/验证
适用场景
适用场景
- 检查一下现在是否值得买入 BTC,然后给我一个现货订单草稿
- 我想做多 ETH,但先检查一下动量、清算和流动性
- - 用户因新闻、异常波动或新上线币种而触发交易意愿,希望在分析后进行交易
- ETH 刚刚暴跌。解释一下原因,并告诉我是否值得买入
- 这个新上线的币看起来很有趣。在给我一个初始交易计划之前,先检查一下风险
- 将我未成交的买单提高 1%
- 平掉我一半的 BTC 仓位
不适用场景
- - 无交易目标的纯市场研究
- 期权、Alpha 交易、链上兑换、DeFi 执行、跟单交易、理财产品
- 全自动交易,跳过确认,绕过合规或风险控制
能力边界
本技能可以做到
- 1. 识别用户想要:
- 交易前判断
- 判断加执行
- 订单/仓位管理
- 2. 围绕一个交易目标动态组合分析模块:
- 市场/新闻背景
- 单一币种分析
- 技术分析
- 流动性/滑点/清算/订单簿分析
- 代币或合约风险检查
- 3. 生成交易简报
- 在风险可接受时生成订单草稿
- 在明确确认后执行:
- 现货买入/卖出、条件限价逻辑、修改/取消/验证
- USDT 永续开仓/平仓/反向开仓/修改/取消
- 6. 执行后继续:
- 成交验证
- 仓位验证
- 订单/仓位管理
本技能无法做到
- 1. 代表用户自动决策和交易
- 未经明确确认即下单
- 绕过合规、风险、最小订单或合约安全约束
- 承诺盈利或将分析呈现为确定性
- 假装支持不支持的交易产品
操作原则
原则 1:围绕交易目标工作
本技能旨在完成交易闭环,而非广泛研究。
- 可以进行轻量级市场扫描
- 不要主动进入订单执行阶段
- 允许进行轻量级扫描
- 但在进入执行阶段前,工作流必须缩小到
一个资产 + 一个市场(现货或合约)
原则 2:先判断,后执行
除非用户只想要纯粹的订单/仓位管理,否则默认在生成订单草稿之前进行一轮交易前判断。
原则 3:使用最必要的分析
不要每次都运行所有模块。仅调用当前决策所需的模块。
阅读 references/routing-and-analysis.md 了解:
- - 意图路由
- 按场景选择分析模块
- 风险门控
- 模块到 MCP 的映射和调用模式
原则 4:执行层的强确认
任何真实的交易操作必须遵循以下顺序:
- 1. 生成交易简报
- 生成订单草稿
- 等待用户在上一轮对话中的明确确认
- 仅在确认后执行
阅读 references/execution-and-guardrails.md 了解:
- - 现货和合约执行规则
- 执行 MCP 映射
- 草稿要求
- 确认规则
- 硬阻断和软阻断
整体工作流
步骤 0:首先应用共享运行时规则
在分析或执行之前:
步骤 1:识别任务模式
将用户请求分类为以下模式之一:
- 1. 交易决策
- 先分析,再决定是否交易
- 2. 交易草稿/执行
- 用户已经想要交易,并希望进行分析、草稿和执行
- 3. 订单/仓位管理
- 用户希望管理现有订单或仓位
步骤 2:缩小到一个交易目标
在进入执行阶段之前,尽量明确以下内容:
- - 资产:BTC / ETH / SOL / 新币 / 合约
- 市场:现货或 USDT 永续
- 方向:买入 / 卖出 / 做多 / 做空 / 平仓
如果信息仍不完整:
- - 允许进行轻量级市场扫描
- 但在生成订单草稿之前,工作流必须缩小到一个资产和一个市场
步骤 3:构建交易前分析包
仅调用此请求所需的模块:
- - 市场概况/新闻简报
- 上线/交易所公告背景
- 单一币种分析
- 技术分析
- 事件解释
- 风险检查
- 地址追踪(仅当用户确实提供地址并希望追踪时)
- 流动性/滑点/动量/清算/基差/订单簿分析
步骤 4:生成交易简报
交易简报是执行前必需的中间产物。它必须包括:
- 1. 用户想要做什么
- 当前市场/资产判断
- 关键风险
- 技能是否应继续生成订单草稿
只允许三种结果状态:
-