Monitoring, briefs and watches

SkillMonitoring & ops

How the desk watches markets and the account between trades using Grok Bot routines and WebSocket or polling watches - the desk brief, book checks, funding and price watches, alert conditions and what a watch may and may not do. Use when the user asks for briefings, alerts, "watch X" or scheduled checks.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Monitoring, briefs and watches skill

What this skill tells your AI

The instructions your AI receives, as published by galleonlabs/hypergrok-trading-desk in skills/desk-monitoring/SKILL.md and read by ahel’s review.

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to /workspace/trading-desk.

Recommended starting set (the user picks; none is on by default):

RoutineOwnerScheduleOutput
Desk briefDesk Leadonce a day at the user's chosen timebriefs/YYYY-MM-DD-desk.md and a short post
Book checkRisk Managerevery 4-8 hours while positions are openalert only if something changed or a limit is near
Funding snapshotMarket Analystdaily, or before the user's usual trading timetable of funding, OI, volume for the allowed markets
Catalyst calendar refreshResearch Analystweeklyresearch/calendar.md
Weekly reviewTrade Reviewerweeklyreview posted by DM

The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def
markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC):
  BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B
  ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B
  SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M
book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0%
research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets
open items: HG-20260816-01 live; no pending tickets

Facts with sources; interpretation, if any, on one clearly labelled line. No trade suggestions.

Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

  • Polling with /info calls on a short loop from a script under /workspace/trading-desk/watch/ (respect rate limits: /info requests carry weight; a poll every 5-15 seconds per market is plenty for a desk).
  • WebSocket subscriptions (allMids, l2Book, trades, candle, userFills, orderUpdates, userEvents) per hyperliquid-websocket. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

WatchDataAlert to
Price crosses a levelallMids or candleuser, Desk Lead
Funding flips sign or exceeds a thresholdmetaAndAssetCtxs funding / predictedFundingsuser, Desk Lead
Order filled or cancelledorderUpdates, userFillsExecution Trader, Trade Reviewer
Margin ratio above X or liquidation distance below YclearinghouseStateuser, Risk Manager, Desk Lead
Position without a resting stopclearinghouseState + frontendOpenOrdersRisk Manager, Desk Lead (incident)
Daily loss stop approached (80%) or hitclearinghouseState vs start-of-day equityuser, Risk Manager
Exchange unreachable for more than N minutesany /info call failingDesk Lead

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

Silence is not an all-clear. A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is unavailable, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

Hygiene

  • Every watch script logs to /workspace/trading-desk/watch/<name>.log with UTC timestamps.
  • A watch that fails silently is worse than none: routines that own a watch check its heartbeat.
  • Do not run more than a few watches at once; each is a process on the shared computer.
  • When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

Never

  • Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket.
  • Never alert with unsourced numbers.
  • Never report a stale or failed read as a condition that did not fire. That is an unavailable alert, not silence.
  • Never poll faster than the desk needs; a rate-limited desk is a blind desk.

Signals

GitHub stars
61
Forks
12
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
desk-monitoring
Source
github.com/galleonlabs/hypergrok-trading-desk