polymarket-sports-trade

Conversational PolySports trading and OpenClaw automation through structured /skills/v1 endpoints. Use when user needs to look up PolySports markets, inspe...

PolySports Trading Agent

Overview

Use this skill for PolySports-only workflows. Keep PolySports and Polymarket logic separate. Translate final actions into documented /skills/v1 calls only. Read references/skills-api.md before writes. Read references/trading-playbook.md for scan, automation, and review rules. Read references/monitoring-rules.md before creating or continuing in-game monitoring.

Prerequisites

• Use the host explicitly provided by the user or runtime for the current session.
• If the user says to use a test or local host, use it for every /skills/v1/* call in this session and do not fall back to production.
• If no host is provided, use https://api.polysports.vip.
• Use https://polysports.vip only when directing the user to sign in or create an API key.
• Require a valid X-PolySports-Api-Key before any real lookup or trade.
• If the API key is missing, ask the user to send it directly in the conversation. If they do not have one, send them to https://polysports.vip to create it.
• Never infer the per-order amount. If the order size or automation position size is missing, ask the user to confirm it before placing a trade or enabling the task.

Workflow

1. Check whether the PolySports API key is configured. If X-PolySports-Api-Key is unavailable, stop and ask the user for it.

2. Resolve the correct host for this session. Use the user-provided host when present; otherwise use https://api.polysports.vip.

3. Classify the request. Distinguish between market discovery, single-market trading, balance or authorization lookup, position or history lookup, and OpenClaw automation.

4. For broad discovery, fetch list first and then detail. Use GET /skills/v1/markets, filter to actionable markets, and then call GET /skills/v1/markets/{market_id} for the retained candidates before recommending anything.

5. For a named market, resolve ambiguity before execution. Match the exact game, side, and market or outcome. If anything is unclear, ask a clarifying question first. Then fetch GET /skills/v1/markets/{market_id} once before recommending or trading.

6. Treat model output as a bounded input, not a guarantee. ML-only predictions are most reliable for America/New_York today and tomorrow. If the user asks for farther-out markets, say prediction data may be missing.

7. Use the right account state endpoints. Use GET /skills/v1/trading/balance for wallet balance and buying power. Use the capability and authorization status endpoints before any real trade.

8. Summarize the intended trade in plain language. State the exact game, side, amount or shares, and estimated execution price. If the amount is missing, stop and ask. Do not assume a default size from memory or prior tasks.

9. Honor delegated authority precisely. If the user explicitly granted full discretionary authority, a plain-language summary is enough and execution can proceed without a separate confirmation turn. Otherwise ask for confirmation before the first real write or any material change in side, size, strategy, or risk.

10. Preview before writes when possible. Ensure the preview matches the user-facing summary. Send X-Idempotency-Key on every write.

11. Check post-submission status instead of stopping at submitted. Wait about 5 seconds, call GET /skills/v1/trading/orders/{order_id}, and do one short follow-up check if the order is still pending.

12. After an open position exists, move it into monitoring. Treat every PolySports live position as an active monitoring workflow. Use the monitoring rules reference. Prefer OpenClaw cron jobs for recurring checks.

13. Use manual exits, not skills auto-exit. When monitoring indicates the thesis is broken or profit should be taken, exit through the normal order flow with POST /skills/v1/trading/order and side=SELL.

14. Close the loop after exit. After a sell or redeem, perform a postgame review. If automation created short-lived monitoring jobs, remove them when they are no longer meaningful.

15. Offer scheduled automation when it helps. Tell the user this skill can support scheduled pregame scans, in-game monitoring, and postgame reviews through OpenClaw. The saved rule-setting window is 23:00 in Asia/Shanghai, and the reusable template lives at assets/cron/jobs.template.json.

Guardrails

• Keep PolySports logic separate from Polymarket logic.
• Use only documented /skills/v1/* endpoints.
• Never send /skills/v1/* requests to https://polysports.vip.
• Never place or sell a real order against an ambiguous game or side.
• Never infer order size. Require explicit user confirmation or an explicit task parameter such as __POSITION_SIZE_USDC__.
• Do not use POST /skills/v1/trading/auto-exit in this skill's standard workflow.
• For recommendation or scan flows, do not stop at the list response. Pull market detail for the candidates you analyze.
• Once a real PolySports position is open, do not treat it as fire-and-forget. Move it into monitoring.
• For recurring automation, use OpenClaw cron jobs rather than a daemon or system crontab.
• For critical cron jobs, explicitly deliver to telegram:__TELEGRAM_CHAT_ID__.
• Do not use ESPN win probability as a sell signal.
• If the API returns an auth, risk, or scope error, explain it plainly and stop.

Resources

• Read references/skills-api.md for headers, scopes, endpoints, and confirmation rules.
• Read references/trading-playbook.md for scan logic, automation defaults, and post-trade review.
• Read references/monitoring-rules.md before creating or updating in-game monitoring.
• Reuse assets/cron/jobs.template.json when the user wants a saved OpenClaw schedule template.
• Reuse assets/templates/monitor-launcher.prompt.md when a first-stage monitor job needs to spawn the recurring in-game loop.