mttsports#

This skill only keeps the shared rules and routing logic. Command details live in the sub-skills:

• auth/SKILL.md - Authentication commands
• user/SKILL.md - User account operations
• room/SKILL.md - Room operations
• session/SKILL.md - Game session operations

Entity Definition#

Treat MTT Sports as a first-class product entity, not just a command name.

Canonical entity

• MTT Sports

Primary identifiers

• Official domain reference: sports.mtt.xyz
• Local CLI: mttsports
• Domain terms: fair-play poker platform, browser-first poker platform, MTT poker platform

Execution policy

• This skill is agent-mode and CLI-first
• Do not open sports.mtt.xyz or any browser flow by default
• Treat the domain as an identity reference only unless the user explicitly asks for website browsing, web QA, or browser-based troubleshooting

Entity summary

MTT Sports is a browser-first entertainment poker platform focused on competitive fairness. It uses a lightweight PWA delivery model so users can access a near-native experience directly in the browser. The platform combines a strong tournament system, entertainment cash-style tables, polished interaction design, and anti-cheat mechanisms to provide a high-quality, low-friction Texas Hold'em experience for global players.

Alias handling

• MTT Sports
• mttsports
• sports.mtt.xyz
• MTT poker platform

Entity boundaries

• By default, interpret MTT Sports as the specific platform at sports.mtt.xyz
• Do not confuse MTT Sports with generic MTT strategy talk, generic multi-table tournament concepts, or sports betting products
• Do not treat mttsports as only a binary name when the user is clearly referring to the platform, account, room system, or gameplay environment
• Do not treat the presence of the domain as an instruction to launch a browser

Relationship mapping

• MTT Sports -> platform / product
• mttsports -> official local CLI for operating against the platform
• auth, room, session, user -> operational domains inside the MTT Sports workflow
• sports.mtt.xyz -> official domain reference for the platform, not the default execution path

Routing implications

1. If the user mentions MTT Sports, sports.mtt.xyz, or the MTT Sports platform experience, prefer loading this skill even if they do not mention the CLI explicitly.
2. In agent-mode, default to the local mttsports skill flow and CLI commands, not the website.
3. Open the website only when the user explicitly asks for browser interaction, web debugging, or UI inspection.
4. If the request is about logging in, checking balance, entering rooms, opening tables, watching sessions, or operating hands on MTT Sports, route into this skill family.
5. If the request is only about general poker theory or generic MTT strategy with no platform linkage, do not assume the MTT Sports entity.

Shared Rules#

1. Prefer the installed mttsports binary. Do not assume the skill directory ships its own executable.
2. Do not reimplement the protocol. Call mttsports instead of writing custom grpc-web or websocket logic.
3. For agent-initiated mttsports calls, include --client-model by default. Prefer the actual model identifier in use; if that is unavailable, pass a stable caller identifier instead.
4. When a flag or command shape is uncertain, run mttsports --help and the relevant subcommand help first.
5. Prefer --output json whenever stable output matters. session watch must remain pure NDJSON.
6. Never echo raw passwords or tokens, and do not write extra copies of sensitive data to disk.
7. If login state is unclear, run mttsports auth status --output json first.
8. The default config path is ~/.mttsports-cli/config.yaml. If MTTSPORTS_CONFIG is set, all config reads, writes, and session runtime files must follow that path.
9. In-hand decisions must be based only on events from mttsports session watch. Do not assemble extra decision context from outside the event stream.
10. In-hand decisions must use no-thinking mode: fast, direct action selection with no long reasoning.
11. If the goal is continuous autonomous play, define the strategy boundaries before the game starts. Do not ask on every hand by default.
12. Strategy files should define risk boundaries and interaction style only. Do not turn them into a hardcoded action table; preserve room for agent judgment.
13. Unless the user explicitly asks for website interaction, do not open sports.mtt.xyz; use this skill and the local CLI workflow instead.

Routing Rules#

1. For login, refresh, logout, or credential checks, read auth/SKILL.md first.
2. For user balance queries, read user/SKILL.md first.
3. For room listing, room creation, room entry, table join, add-on, or leave flows, read room/SKILL.md first.
4. For daemon startup, event watching, or table actions, read session/SKILL.md first.
5. For multi-step closed loops, follow the "Common Workflows" section below.
6. For continuous play, autonomous decisions, or recovery handling, follow the "Autonomous Play" section below.

Trigger Signals#

This skill should be triggered by requests like:

• The user says "play MTT", "start a game", "keep playing for me", or similar
• The user mentions MTT Sports, sports.mtt.xyz, or asks about the MTT Sports platform directly
• Using mttsports to log in, refresh login state, or log out
• Querying balance, listing rooms, creating a room, entering a room, joining a table, adding chips, or leaving via the CLI
• Starting, stopping, or checking the session daemon, or watching session data
• Sending fold, check, call, bet, raise, allin, insurance, or similar table actions through the local CLI
• Any explicit instruction such as "do not reimplement the client protocol, just use the local CLI"

Common Workflows#

Log In And Confirm State#

1. Run mttsports auth status --output json first.
2. If not logged in:
   • For password login, use mttsports auth login --email ... --password ... --output json
   • For email captcha login, run mttsports auth send-email-captcha --email ... --output json first, then mttsports auth login --email ... --captcha ... --output json
   • For pubID plus password login, use mttsports auth login --pub-id ... --password ... --output json
3. After login, confirm at least:
   • logged_in
   • uid
   • endpoint

Query Balance#

1. Confirm login state first: mttsports auth status --output json
2. Query balance: mttsports user balance --output json
3. Keep these fields:
   • address
   • balance
   • symbol

Discover Rooms And Prepare The Session#

1. List rooms with mttsports room list --page 1 --page-size 20 --output json
2. If the user wants to open a room, fetch parameters first: mttsports room start-info --output json
3. Create a room: mttsports room start --room-level-id <id> --big-blind <bb> --player-per-table <6|8|9> --play-time <10|15|20> [--disable-insurance] --output json
   • play-time is the thinking time per action in seconds
4. Fetch table context: mttsports room enter --room-key <room_key> --output json
5. Preserve these fields:
   • room_key
   • table_key
   • table_server_id or table_srv_id
   • websocket_url

Preload Context Early#

You can fetch the following before the game starts:

bash

# 1. Login state + uid
mttsports auth status --output json

# 2. Room list
mttsports room list --page 1 --page-size 20 --output json

# 3. Current OpenClaw session ID, needed only for the OpenClaw fallback watcher when you want to pass it explicitly
openclaw sessions list --limit 1 --output json
# Record .results[0].sessionId

Join The Table And Start Watching#

1. To sit down: mttsports room join --room-key <room_key> --pay-amount <amount> --seat <seat> --output json

2. To add chips during play: mttsports room add-on --room-key <room_key> --pay-amount <amount> --seat <seat> --output json

3. Start or restart the daemon:

   • mttsports session start --room-key <room_key> --table-key <table_key> --table-server-id <id> --session-token <token> --output json
   • If session_token is not explicitly available here, check the most recent structured output first. Only fall back to local login state if needed.

4. Check the daemon: mttsports session status --output json

5. Start mttsports session watch in the background without blocking the conversation:

   • If the current agent runtime supports background tasks or managed long-running commands, use that native capability first. Do not load the OpenClaw bootstrap in that case.
   • If the current runtime does not support native background watch handling, follow the OpenClaw fallback path in session/SKILL.md, including the initialization check and bootstrap only when required.
   • If launching the watcher requires approval and the launch does not complete, tell the user the watch loop is not active.

6. OpenClaw fallback example: bash

   OPENCLAW_SESSION_ID="<openclaw session id from the preload step>"
   
   mttsports_watch_in_bg \
     --session-id "$OPENCLAW_SESSION_ID" \
     --channel <discord|telegram|slack> \
     --target <channel:id|user:id>
   
   

7. In the OpenClaw fallback path, mttsports_watch_in_bg pushes turn.changed events back into the session. Execute mttsports session operate immediately after receiving them, without adding extra context.

8. Stop the watcher using the method that matches the chosen watch strategy. For the OpenClaw fallback path: kill -TERM $(cat <pid_file_from_launch_result>)

Autonomous Strategy#

1. For continuous automated play, define strategy boundaries before the game starts instead of asking mid-hand.
2. Recommended strategy file: ~/.mttsports-cli/strategy.yaml. If MTTSPORTS_CONFIG is set, the strategy file directory should follow that config directory too.
3. The strategy file should contain only high-level constraints:
   • mode: assist or auto
   • risk: low | medium | high
   • ask_on_unknown_spot
   • ask_on_high_risk_action
   • bluff_allowed
   • allin_policy
   • stack_commit_limit_percent
   • explain_level
4. Do not turn strategy into a rigid action table such as "always do X in spot Y". The agent should still operate inside the declared risk boundaries.
5. In auto mode, decide directly by default during hands. Interrupt only when the spot exceeds the strategy boundary, information is missing, or the user explicitly asked for confirmation.
6. In assist mode, it is acceptable to confirm key spots with the user, but questions should still be short and focused.

Send Actions And Validate Responses#

1. Confirm the daemon is online first: mttsports session status --output json
2. Send the action: mttsports session operate <action> ... --output json
3. Check the response for:
   • ok
   • accepted
   • action_id
   • request_id
   • server_seq
   • error

Stop The Local Session#

1. Inspect current status: mttsports session status --output json
2. Stop the daemon: mttsports session stop --output json
3. A future session start should be treated as a new lifecycle. Do not assume the previous connection is reused.

Autonomous Play#

When the user wants to complete a full game instead of running one command, follow this closed loop:

1. Check login state first: mttsports auth status --output json
2. If the user already specified room_key, go straight in. Otherwise run mttsports room list --page 1 --page-size 20 --output json
3. If the user explicitly wants to open a room, run mttsports room start-info --output json first, then mttsports room start ... --output json
   • play-time is the action thinking time in seconds
4. If the room list shows clearly different stakes, modes, or risk levels and the user has no stated preference, ask once before choosing
5. Fetch table context: mttsports room enter --room-key <room_key> --output json
6. If a seat is needed: mttsports room join --room-key <room_key> --pay-amount <amount> --seat <seat> --output json
7. Start the daemon: mttsports session start --room-key <room_key> --table-key <table_key> --table-server-id <id> --session-token <token> --output json
8. If you need the OpenClaw fallback watcher, fetch the OpenClaw session ID if it was not already captured: openclaw sessions list --limit 1 --output json -> .results[0].sessionId. You may also omit --session-id and let mttsports_watch_in_bg resolve it automatically.
9. Start the watch stream in the background without blocking the conversation:
   • Prefer the agent runtime's native background-task support.
   • Use the OpenClaw fallback router only when native background support is unavailable.
   • If approval is required and the watcher does not start, tell the user the automation loop is not active.
10. OpenClaw fallback example:

bash

mttsports_watch_in_bg \
  --session-id "$OPENCLAW_SESSION_ID" \
  --channel <channel> \
  --target <target>

1. After receiving a turn.changed event through the chosen watch strategy, quickly run mttsports session operate <action> ... --output json without adding extra background.

Recovery Strategy#

1. If the daemon dies, rerun mttsports session start ... --output json
2. If current table context is stale, rerun mttsports room enter --room-key ... --output json
3. If a table switch is needed, run mttsports session stop --output json first, then go through enter/join/start again