Skill: dreamcoin1998/polysports-trading-agent (version 1.0.0)

--- name: polysports-trading-agent description: Conversational PolySports trading and OpenClaw automation through structured `/skills/v1` endpoints. Use when user needs to look up PolySports markets, inspect balances or authorization, buy or sell real positions, redeem settled positions, or set up scheduled pregame scans, in-game monitoring, or postgame review workflows while keeping user confirmation in plain language. --- # 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](references/skills-api.md) before writes. Read [references/trading-playbook.md](references/trading-playbook.md) for scan, automation, and review rules. Read [references/monitoring-rules.md](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](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](references/skills-api.md) for headers, scopes, endpoints, and confirmation rules. - Read [references/trading-playbook.md](references/trading-playbook.md) for scan logic, automation defaults, and post-trade review. - Read [references/monitoring-rules.md](references/monitoring-rules.md) before creating or updating in-game monitoring. - Reuse [assets/cron/jobs.template.json](assets/cron/jobs.template.json) when the user wants a saved OpenClaw schedule template. - Reuse [assets/templates/monitor-launcher.prompt.md](assets/templates/monitor-launcher.prompt.md) when a first-stage monitor job needs to spawn the recurring in-game loop.

path: assets/cron/jobs.template.json
content: {
  "jobs": [
    {
      "id": "__JOB_ID__",
      "agentId": "main",
      "name": "PolySports NBA Daily Opportunity Scan",
      "enabled": true,
      "schedule": {
        "kind": "cron",
        "expr": "0 23 * * *",
        "tz": "Asia/Shanghai"
      },
      "sessionTarget": "isolated",
      "wakeMode": "next-heartbeat",
      "payload": {
        "kind": "agentTurn",
        "message": "执行一次真正的 PolySports NBA 每日交易机会扫描（不是空跑说明，不是只复述规则）。\n\n固定要求：\n1. 首先强制 read `polysports-trading-agent` 的 SKILL.md。\n2. 然后读取：\n   - `references/skills-api.md`\n   - `references/trading-playbook.md`\n   - `references/monitoring-rules.md`\n3. 真实检查：交易余额、当前持仓、授权状态、今日/明日可交易 NBA 市场。\n4. 先拉市场列表，再对候选市场逐个拉 `/skills/v1/markets/{market_id}` 详情；不能只看列表。\n5. 分析必须综合：ML 预测、`odds_compare`、PolySports 当前定价、近期球队数据、必要时的网络查询，以及可得的 smart money 等详情字段。\n6. 目标是赚钱，不是保持活跃。没有可执行优势就不要下单。\n7. 单笔金额必须使用任务参数 `__POSITION_SIZE_USDC__`，不要自作主张改仓位；若余额不足该额度，则停止新增仓位。\n8. 若下单成交并形成持仓，必须立即创建独立的两段式赛中监控；监控时重点看比赛内容、关键事件、市场价格与持仓盈亏，必要时补充网络检索。\n9. 不要使用 skills 自带 auto-exit；若需要离场，用标准下单端点手动 `SELL`。\n10. 禁止重复下单：如果同一 `market_id` / `outcome` 已持有，或今天已做过同方向，不要重复再下。\n11. 每笔 PolySports 交易在平仓或赎回后，都必须做赛后复盘并回报结果。\n12. 输出必须使用中文；无论下单、不下单还是失败，都必须明确汇报，不允许静默。\n\n执行本任务时涉及的占位符：\n- PolySports API Key: __POLYSPORTS_API_KEY__\n- Telegram target: telegram:__TELEGRAM_CHAT_ID__\n- 所有 PolySports 请求都必须显式带 `X-PolySports-Api-Key`、`X-PolySports-Skill: polysports-trading-agent`、`X-PolySports-Client: chatgpt`\n- 不要把 `/skills/v1/*` 请求发到 `https://polysports.vip`，默认 API host 是 `https://api.polysports.vip`。"
      },
      "delivery": {
        "mode": "announce",
        "channel": "telegram",
        "to": "telegram:__TELEGRAM_CHAT_ID__",
        "accountId": "default",
        "bestEffort": false
      },
      "deleteAfterRun": false,
      "state": {}
    }
  ],
  "total": 1,
  "offset": 0,
  "limit": 1,
  "hasMore": false,
  "nextOffset": null
}


path: assets/templates/monitor-launcher.prompt.md
content: This is a PolySports two-stage monitor launcher template.

Read first:

- `skills/polysports-trading-agent/SKILL.md`
- `skills/polysports-trading-agent/references/skills-api.md`
- `skills/polysports-trading-agent/references/monitoring-rules.md`

Current target:

- Match: `__MATCH_LABEL__`
- Market ID: `__MARKET_ID__`
- Outcome: `__OUTCOME__`
- Token ID: `__TOKEN_ID__`
- Telegram target: `telegram:__TELEGRAM_CHAT_ID__`

Your task:

1. Immediately create the second-stage `every 5m` monitoring cron.
2. The second stage must explicitly include the correct API host, API key header rules, monitoring inputs, SELL execution rules, double-checking empty positions, self-deletion, and postgame review requirements.
3. When creating the job, include `--to telegram:__TELEGRAM_CHAT_ID__ --channel telegram --account default --announce`.
4. After creation succeeds, immediately report the second-stage cron id, next run time, and delivery target.

Once creation is complete, this launcher task can finish.


path: agents/openai.yaml
content: interface:
  display_name: "PolySports Trading Agent"
  short_description: "PolySports trading and OpenClaw automation"
  default_prompt: "Use $polysports-trading-agent to analyze PolySports markets, confirm order size, trade through `/skills/v1`, and set up OpenClaw pregame scans, in-game monitoring, or postgame reviews."


path: references/monitoring-rules.md
content: # PolySports Monitoring Rules

## Required Inputs

- Market price, executable sell price when available, and live PnL
- ESPN scoreboard, gamecast, and boxscore
- Key game events such as injury exits, foul trouble, rotation changes, runs, endgame possessions, garbage time, and overtime risk
- Targeted web search when a material in-game development needs confirmation or context

## Decision Priority

1. Game state first: score, remaining time, lineup quality, star-player condition, foul trouble, rebounding, turnovers, paint or perimeter profile, pace, and matchup changes.
2. Key events second: injury, foul crisis, unusual rotation, momentum swing, timeout adjustment, and clutch-possession dynamics.
3. Market price and PnL are validation inputs, not the main decision.
4. Do not use ESPN win probability as a decision signal.
5. Only take profit or stop out after the basketball case for the thesis materially changes, then use price and liquidity to confirm execution.
6. In early fourth-quarter but still reversible games without a hard trigger, do not exit only because of low implied win probability or weak liquidity.

## Automation Pattern

- Use a two-stage monitoring setup:
  1. Create one `at` starter scheduled for game start plus 5 minutes.
  2. Let that starter create the real `every 5m` monitoring loop.
  3. Verify the starter will actually create the recurring loop.
- Reuse [../assets/templates/monitor-launcher.prompt.md](../assets/templates/monitor-launcher.prompt.md) as the launcher template when you need a ready-made first-stage prompt.
- Keep prompts focused on the task. Do not dump unrelated system implementation detail into the cron message.
- Each monitoring prompt must explicitly load `polysports-trading-agent` before making PolySports calls.
- Each PolySports request must send `X-PolySports-Api-Key`, `X-PolySports-Skill: polysports-trading-agent`, and `X-PolySports-Client`.

## Exit Discipline

- Do not hardcode fixed take-profit or stop-loss thresholds into the monitoring prompt. Let AI judge from the combined game and market context.
- When the position is reported as flat or exited, confirm once more with the positions endpoint before declaring the workflow finished.
- After a successful closing trade, remove the monitoring cron job itself.
- Every closed position must get a review, regardless of profit or loss.
- Every monitoring or review run must report a result instead of failing silently.


path: references/skills-api.md
content: # PolySports Skills API

## Prerequisite

- Use the host explicitly provided by the user or runtime for the current session.
- If the user specifies a test, staging, or local host, use that host for every request in this session.
- If no host is specified, use the production API host `https://api.polysports.vip`.
- Do not use `https://polysports.vip` as the API host for `/skills/v1/*`. That domain is the website and should only be used when directing the user to sign in or create an API key.
- The runtime must provide a valid `X-PolySports-Api-Key`.
- If the API key is missing, first ask the user to send their PolySports API key directly in the conversation so it can be used for this skill session.
- If the user does not have an API key yet, instruct them to register or sign in at `https://polysports.vip`, open the account menu, create an API key, and then send it back in the conversation.

## Headers

- `X-PolySports-Api-Key`: required for skill calls authenticated by API key
- `X-PolySports-Skill`: set to `polysports-trading-agent`
- `X-PolySports-Client`: caller name such as `chatgpt`
- `X-PolySports-Conversation-Id`: conversation identifier when available
- `X-Idempotency-Key`: required for write requests

## User-Facing Confirmation Rule

Do not show raw request JSON to the user. Before the first authorization or any real trade, summarize the action in plain language:

- exact game or match
- side to buy or sell
- amount or shares
- estimated execution price
- exit intent if it is already part of the plan

Never infer the amount. If the user did not provide order size, ask before any real write or before enabling automation that may trade.

If the user explicitly delegates full or discretionary trading authority, such as saying AI can trade without per-order confirmation, treat that instruction as valid approval for the `persistent` workflow. In that mode, keep showing plain-language summaries, but do not require a separate "confirm this order" turn before each in-scope trade.

## Read Endpoints

- `GET /skills/v1/me`
- `GET /skills/v1/capabilities`
- `GET /skills/v1/markets`
  Use this for broad discovery requests such as "recommend tradable NBA games" or "what can I buy today". The list response is not the final recommendation payload by itself.
- `GET /skills/v1/markets/{market_id}`
  Preferred single-detail call after the market is resolved. Reuses the Web detail aggregation and returns bundled detail in one response. In skills mode, `predictions` returns the machine-learning-only result from `/predict/ml` and does not include the Web-side LLM analysis. The same response can still include `team_stats`, `odds_compare`, `smart_money_positions`, and `game.detail` when the current membership or points access allows it.
  Access behavior should match Web: members can receive premium detail, while non-members or users without the required unlock should see the same gated result through `access` and `errors`.
- `GET /skills/v1/markets/{market_id}/snapshot`
  Lightweight detail endpoint for low-latency scans. Returns the market, token IDs, ML-only `predictions`, and normal `access/errors`, but intentionally omits slower enrichments such as smart money, team stats, odds history, odds comparison, and game detail.
- `GET /skills/v1/trading/authorization/status`
- `GET /skills/v1/trading/balance`
  Use this when the user asks for current wallet address, wallet balances, or trading buying power. The response can include both chain balances and CLOB collateral/allowance data. If the user asks to withdraw, transfer, or deposit funds, do not attempt a write flow in skills. Tell the user to complete that action in the PolySports Web wallet interface.
- `GET /skills/v1/trading/positions`
- `GET /skills/v1/trading/history`
- `GET /skills/v1/trading/orders/{order_id}`
  Use this after `POST /skills/v1/trading/order` returns an `order_id`. Wait about 5 seconds before the first check. If the order is still `submitted` with `filled_size=0`, wait another 5 to 10 seconds and check once more before telling the user it is still pending or unfilled.

## Authorization Endpoints

- `POST /skills/v1/trading/authorization-intent`
  Use this after the user asks for AI trading and you know the exact wallet and requested scopes.

- `POST /skills/v1/trading/authorization/confirm`
  Use this after the user explicitly confirms the authorization summary in natural language or explicitly delegates discretionary trading authority in natural language. A separate extra confirmation turn is not required if the delegation is already clear.

- `POST /skills/v1/trading/authorization/revoke`
  Use this when the user wants to stop or narrow AI trading authority.

Default authorization mode is `persistent`. Supported alternatives are `single_order`, `conversation`, and `timeboxed`.

## Trading Endpoints

- `POST /skills/v1/trading/preview`
- `POST /skills/v1/trading/order`
  Use this for both BUY and SELL. Standard exit flow in this skill is `side=SELL`.
- `POST /skills/v1/trading/auto-exit`
  This endpoint exists, but do not use it in this skill's standard PolySports workflow.
- `POST /skills/v1/trading/redeem`

## Scope Mapping

- `markets:read`: market discovery and market detail
- `trade:write`: authorization, preview, and order placement
- `positions:read`: wallet balance, positions, trade history, and order status
- `auto_exit:write`: stop-loss and take-profit management
- `redeem:write`: settled position redemption

## Required Behavior

- For broad list-style recommendation requests, first call `GET /skills/v1/markets`, then call `GET /skills/v1/markets/{market_id}` for the retained candidates before recommending anything.
- The list response itself does not need to be restricted to `America/New_York` today and tomorrow. Query a wider range when the user asks for it.
- ML-only prediction cache is most reliable for markets scheduled in `America/New_York` today and tomorrow. If your recommendation depends on model output, prefer those markets first. If the user asks for a farther date range or a specific market outside that window, you can still fetch detail, but you should expect `predictions` to be missing more often.
- Keep Web-equivalent gating behavior on bundled detail: membership and points access should behave the same way they do on Web.
- Resolve ambiguity before trading.
- For wallet overview questions, prefer `GET /skills/v1/trading/balance` instead of inferring buying power from positions or past trades.
- If the user asks to withdraw, transfer, or deposit, explain that skills can read balances but those wallet actions must be done in the PolySports Web wallet interface.
- Never infer order size from memory, defaults, or previous tasks. Require the user to state or confirm it.
- Prefer preview before order placement.
- If the user explicitly delegated full or persistent AI trading authority, do not force per-order confirmation for normal in-scope trades. Still provide a plain-language summary, but execution can proceed directly.
- If the user did not delegate full authority, or the intended trade materially changes side, size, strategy, or risk beyond the delegated scope, ask for confirmation before writing.
- After a real order is submitted, check the order status within about 5 seconds using `GET /skills/v1/trading/orders/{order_id}` instead of treating `submitted` as the final outcome.
- If the first status check still shows no fill and the order is not final, wait another 5 to 10 seconds and check once more. After about 20 seconds total, report the current state to the user and offer to keep monitoring if needed.
- If a PolySports position remains open after the order, move it into active monitoring rather than treating it as fire-and-forget.
- Do not use `POST /skills/v1/trading/auto-exit` for PolySports monitoring. Exit with a normal sell order when the monitoring decision says to leave.
- Reuse the same idempotency key only for a retried copy of the same write.
- Do not proactively suggest revoking a normal persistent grant after each trade. Only talk about revocation when the user asks to stop AI trading, wants narrower permissions, or the grant state itself changed.


path: references/trading-playbook.md
content: # PolySports Trading Playbook

## Scope

- Keep PolySports and Polymarket separated.
- Treat PolySports as pregame selection plus active in-game management, not passive buy-and-wait settlement.

## Order Sizing

- Do not keep or apply a default unit size inside the skill.
- Before any real buy order, or any automation that may buy, confirm the per-order USDC amount with the user.
- Fill `__POSITION_SIZE_USDC__` explicitly in templates before use.
- If the user changes risk tolerance or wants different sizing rules, restate the sizing rule back before enabling automation.

## Discovery and Scan

- For scheduled daily scans, default focus is NBA unless the user says otherwise.
- Always call the market list first and then pull detail for shortlisted markets.
- Base the decision on bundled detail: current price, ML prediction if available, `odds_compare`, smart money or holder signals when available, recent team form, injuries, rotation context, and targeted web search when needed.
- Prefer no trade over weak edge.
- Avoid duplicate direction if the same market or outcome is already held or already traded that day.

## Automation

- Prefer OpenClaw cron jobs, not long-running scripts or system crontab.
- Supported scheduled workflows are:
  - Pregame scan
  - In-game monitoring
  - Postgame review
- The default rule-setting or refresh window is `23:00` in `Asia/Shanghai`.
- Reuse [../assets/cron/jobs.template.json](../assets/cron/jobs.template.json) as the saved template for daily scans.
- Reuse [../assets/templates/monitor-launcher.prompt.md](../assets/templates/monitor-launcher.prompt.md) when a first-stage monitor needs to create the recurring in-game loop.
- Fill placeholders such as `__POLYSPORTS_API_KEY__`, `__TELEGRAM_CHAT_ID__`, and `__POSITION_SIZE_USDC__` before enabling a job.
- Send critical jobs to `telegram:__TELEGRAM_CHAT_ID__`.
- Every automated run must report an outcome, including "no trade" and execution failure.

## Exit and Review

- Do not use skills auto-exit for PolySports.
- Exit through `POST /skills/v1/trading/order` with `side=SELL`.
- After a position is closed or redeemed, do a postgame review regardless of profit or loss.
- Delete short-lived monitoring tasks once they no longer matter or after a successful exit.


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