Monitoring, briefs and watches
SkillMonitoring & opsHow 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.
No other account needed.
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):
| Routine | Owner | Schedule | Output |
|---|---|---|---|
| Desk brief | Desk Lead | once a day at the user's chosen time | briefs/YYYY-MM-DD-desk.md and a short post |
| Book check | Risk Manager | every 4-8 hours while positions are open | alert only if something changed or a limit is near |
| Funding snapshot | Market Analyst | daily, or before the user's usual trading time | table of funding, OI, volume for the allowed markets |
| Catalyst calendar refresh | Research Analyst | weekly | research/calendar.md |
| Weekly review | Trade Reviewer | weekly | review 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
/infocalls on a short loop from a script under/workspace/trading-desk/watch/(respect rate limits:/inforequests carry weight; a poll every 5-15 seconds per market is plenty for a desk). - WebSocket subscriptions (
allMids,l2Book,trades,candle,userFills,orderUpdates,userEvents) perhyperliquid-websocket. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.
Common watch conditions:
| Watch | Data | Alert to |
|---|---|---|
| Price crosses a level | allMids or candle | user, Desk Lead |
| Funding flips sign or exceeds a threshold | metaAndAssetCtxs funding / predictedFundings | user, Desk Lead |
| Order filled or cancelled | orderUpdates, userFills | Execution Trader, Trade Reviewer |
| Margin ratio above X or liquidation distance below Y | clearinghouseState | user, Risk Manager, Desk Lead |
| Position without a resting stop | clearinghouseState + frontendOpenOrders | Risk Manager, Desk Lead (incident) |
| Daily loss stop approached (80%) or hit | clearinghouseState vs start-of-day equity | user, Risk Manager |
| Exchange unreachable for more than N minutes | any /info call failing | Desk 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>.logwith 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
unavailablealert, 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