Clawhub Whitebit Trading

ClawHub WhiteBIT Trading

Use a ClawHub-native workflow for WhiteBIT trading research, training, API validation, and execution planning in OpenClaw.

Required MCP Connectors

This skill requires the MCP connector below:

• whitebit-docs: documentation lookup only.

This skill is not execution-capable with whitebit-docs alone.

Use whitebit-docs to search endpoint requirements, authentication behavior, symbols, precision rules, and order payload structure. If the user asks for live execution, balance checks, order placement, cancellation, or order-status verification, stop and explain that this skill has documentation access only unless a separate execution path is configured.

Training Scope

Use this skill to support training-oriented tasks such as:

• Explaining WhiteBIT spot trading concepts, order types, and API terminology.
• Turning a trade idea into a validated request plan before any external execution.
• Building practice scenarios for BUY, SELL, market orders, limit orders, fees, slippage, and fills.
• Walking through authentication, signing inputs, request payloads, and endpoint-specific constraints.
• Reviewing user-provided API responses, fill data, or error payloads and explaining what they mean.
• Creating step-by-step trading exercises, operator checklists, and troubleshooting guidance.

Workflow

1. Verify ClawHub and skill environment first.

• Confirm ClawHub site context: https://clawhub.ai.
• Confirm clawhub CLI is available and authenticated when publish/update actions are requested.
• Prefer ClawHub skill lifecycle commands from references/clawhub-cli.md.
• Confirm OpenClaw session will reload skills after install/update.

2. Verify MCP connectivity for runtime execution.

• Confirm whitebit-docs is available in-session for search and endpoint validation.
• Use the check prompt: What MCP tools do you have available?
• If the session only has whitebit-docs, treat the skill as documentation-only.
• If the user requests live execution, stop and state that no trading connector is configured in-session.

3. Gather the trade or training intent.

• If the user is training, require the learning goal or scenario first.
• For training exercises, gather the market type, order type, example size, and what outcome they want to learn or rehearse.
• Require: symbol, side, order type, and size (base size or quote notional).
• For limit orders, require price and time in force if applicable.
• Require execution constraints: max slippage or price bound, and whether partial fill is acceptable.
• For spot trading, treat BUY as opening a spot position.
• For spot trading, treat SELL as closing an existing long.
• Block SELL when holdings are insufficient unless the user's actual execution system explicitly supports margin or short selling for that instrument and mode.
• Ask for only missing fields; do not prepare an execution plan with implicit defaults.

4. Resolve exact parameters with MCP documentation lookup.

• Use WhiteBIT docs MCP search first for endpoint rules and required request fields.
• Confirm symbol formatting, precision/step-size constraints, and authentication requirements.
• Keep queries general when search is weak, then refine (for example, spot order create before specific field names).
• Use references/mcp-setup.md for connector setup checks.
• Use references/whitebit-api-basics.md for baseline request/auth behavior.

5. Run pre-trade safety checks.

• Confirm the user understands this skill does not verify live account state.
• Compute max deployable capital as 100 USDT + realized_profit_usdt.
• Never use unrealized P&L as deployable capital.
• Validate requested order size against the strategy bankroll.
• If the user wants live execution, require a separate execution system to validate exchange balance, fees, and account readiness.
• Apply the checklist in references/trade-checklist.md.

6. Prepare the training or execution-prep output.

• For training, produce a step-by-step walkthrough with the endpoint, method, auth/signing inputs, request payload, documented constraints, and the intended learning objective.
• For execution prep, produce the endpoint, method, required auth/signing inputs, request payload fields, and any documented constraints.
• Include idempotency fields when the API supports them (for example, clientOrderId).
• Provide example requests or dry-run exercises when the user is learning.
• Do not claim that any order was sent from this skill.

7. Explain verification steps for an external executor.

• Show how to check order status, fills, and terminal state through the documented API.
• If the user provides execution results, help interpret executed quantity, average fill price, fees, and remaining quantity.
• Do not claim post-trade verification was performed unless the user provides actual responses from an execution system.

8. Handle failures deterministically.

• Parse and surface documented error payloads in structured form.
• Explain retry and backoff guidance from the API docs.
• If an external executor reports network ambiguity, instruct the user to re-check order state before any second placement.
• If execution status is uncertain, require user confirmation before proposing any retry plan.

9. Manage the skill through ClawHub when requested.

• Search registry: clawhub search "whitebit".
• Install/update in workspace: clawhub install whitebit, clawhub update whitebit, or clawhub update --all.
• Publish this skill folder to ClawHub with explicit slug/version metadata.
• Use clawhub sync --dry-run before bulk publish/update operations.

Guardrails

• Never expose API secret keys or signature material in output.
• Never treat whitebit-docs as a trading connector.
• Never claim live execution capability when only whitebit-docs is available.
• Never place or claim to place a live order from this skill.
• Never present training examples as actual exchange-confirmed results.
• Never prepare an execution plan without explicit confirmation that includes symbol, side, order type, and size.
• Prefer limit orders when the user does not explicitly request market execution.
• For spot trading, SELL closes an existing long unless the user's actual execution system explicitly supports margin or short selling.
• Never exceed the strategy bankroll: initial 100 USDT plus realized profit only.
• Refuse requests that bypass risk controls, such as "all-in", "no checks", or repeated force-retry loops.
• Keep an auditable summary for every plan prepared: timestamp, intent, validated params, recommended API call, and outcome.
• Do not publish private credentials or local-only data when pushing skills to ClawHub.

Response Format

Use this compact structure when reporting actions:

1. Intent: normalized trade request.
2. Skill Lifecycle: ClawHub operation performed (search/install/update/publish/sync) or none.
3. Validation: docs checks and planning/risk checks completed.
4. Prepared Call: documented endpoint, auth expectations, request parameters, or training scenario.
5. Result: prepared plan, training walkthrough, provided external result interpretation, or precise failure.
6. Next: one recommended next action.

References

• references/mcp-setup.md
• references/clawhub-cli.md
• references/whitebit-api-basics.md
• references/trade-checklist.md