The end-to-end procedure for one trade on the HyperGrok desk - from an idea to a reviewed, journaled result - with the ticket format, who owns each stage, and what "done" looks like. Use whenever the user wants to open, adjust or close a position, or whenever any Bot is about to touch the exchange write path.
Coding
HyperGrok Desk Post Trade Review
Try itThe Trade Reviewer's procedure for journaling desk activity and reviewing trades from the exchange record - process graded separately from outcome, execution costs measured, one repeatable finding per review, plus the weekly desk review. Use after any send, when a trade closes, on the weekly routine, or when the user asks "how did that go".
What it does
The Trade Reviewer's procedure for journaling desk activity and reviewing trades from the exchange record - process graded separately from outcome, execution costs measured, one repeatable finding per review, plus the weekly desk review. Use after any send, when a trade closes, on the weekly routine, or when the user asks "how did that go".
The skill document
Journal and post-trade review
The journal is the desk's memory; the review is how the desk learns. Both come from the exchange record first and chat second, and both keep process and outcome apart.
1. Journal
/workspace/trading-desk/journal/YYYY-MM-DD.md, one file per active day, appended in time order. Entry types:
14:02 UTC HG-20260816-01 opened ETH-PERP long idea (user); status evidence
14:12 UTC HG-20260816-01 risk PASS 0.51 ETH, stop 2,900, 0.5% risk (risk-limits v3)
14:29 UTC HG-20260816-01 approval "approve HG-20260816-01" (user)
14:31 UTC HG-20260816-01 sent buy 0.51 @ 3,000 Gtc + sl 2,900 (normalTpsl); cloid 0x9f3e...; oid 1839201122, sl waitingForFill
16:05 UTC HG-20260816-01 fill 0.51 @ 3,000.0 maker, fee $0.31
09:12 UTC HG-20260816-01 closed tp 3,089.6, fee $1.52; position flat; sl 2,900 cancelled 09:13
10:00 UTC limits risk-limits v3 -> v4: max positions 3 -> 4 (user, reason: adding HYPE)
11:40 UTC incident INC-20260817-01 send timeout on HG-20260817-02, reconciled not-on-exchange, re-approved and sent 11:47
18:00 UTC note maker entries at 10 bps depth filled within 2h on both attempts this week
Rules: append only; corrections are new lines with correction:; every line has a UTC time and an id where one exists; no opinions in the journal (those go in reviews).
2. Trade review
Trigger: a proposal reaches closed, or the user asks. Inputs, always listed with timestamps:
- the proposal file (ticket, PASS, approval, execution, reconciliation)
userFills/userFillsByTimefor the window: price, size, fee, side,crossedhistoricalOrdersandorderStatusby cloid: what rested when, what cancelleduserFundingfor the holding window- optionally the Market Analyst's depth read at send time for expected slippage
Compute:
| Measure | How |
|---|---|
| Entry slippage | (fill avg - ticket price) / ticket price in bps, signed against the trade |
| Exit slippage | same for the exit versus its ticket or trigger price |
| Fees | sum of fill fees in USD and as bps of notional; note maker vs taker |
| Funding | sum of funding payments over the window, USD |
| Net result | realised PnL after fees and funding, in USD and in R (R from the ticket) |
| Protection | was a reduce-only stop resting on the exchange for the entire life of the position? gaps in minutes |
| Lifecycle | each stage present, in order, with timestamps; approval by id; single send; reconciled |
| Holding time | fill to flat |
Grade:
- Process: clean / minor break / major break, with the specific stage named. A major break is any send without PASS or approval by id, any missing protection, any resend on unknown result, or any limit breached.
- Outcome: result in R and USD, stated without adjectives.
Then one thing: a leak, a control that worked, or a break, chosen because it is repeatable. Not a list.
Write the review under ## review in the proposal file and send the block (format in agents/trade-reviewer.md) by DM to the Desk Lead and the user. Set status: closed.
3. Weekly desk review
From the journal, proposals and the exchange record for the week:
- proposals opened / rejected / voided / executed / closed
- trades closed: count, hit rate, average win and loss in R, expectancy in R (mean of results), largest loss, largest drawdown in equity terms from
portfolioor start/end equity - costs: fees and funding in USD and as a share of gross PnL
- process: number of breaks by type; incidents and their status
- limits: any changes and why
- one pattern worth the user's attention, stated as a fact pattern
No recommendations about what to trade. If the user asks, hand strategy questions to the Strategist and sizing questions to the Risk Manager.
4. Incident review
For each INC-YYYYMMDD-NN: timeline (journal + exchange record), what the desk did, what the controls did, exposure during the incident, root cause where knowable, one corrective action with an owner and a date. Blameless in tone, exact in fact. Written to /workspace/trading-desk/journal/incidents/.md and linked from the daily journal.
Pitfalls
- Reviewing from chat memory rather than fills. Chat says what people meant; fills say what happened.
- Letting the outcome colour the process grade. Grade process first, then look at the outcome.
- Counterfactuals ("if we had held..."). Not evidence.
- Ten findings per review. Nobody acts on ten.
- Editing old journal lines. Append a correction.
Related skills
How the HyperGrok trading desk works as a team of Grok Bots - roles, seats, shared workspace, evidence standard, approval model and handoff format. Use when setting up the desk, when a Bot is unsure who owns something, or when a request does not fit the normal trade lifecycle.
What the desk does when something goes wrong on Hyperliquid - unknown send results, unexpected fills or positions, unprotected positions, stuck or orphaned orders, API outages, rate limiting, and suspected API wallet compromise. Contain first, reconcile from the exchange record, act only through approved tickets, then review. Use the moment anything does not match the ticket.
How the Risk Manager writes the desk's risk limits with the user, sizes every proposed trade from live account state and Hyperliquid's real constraints, checks the book, and issues a PASS or REJECT with exact ticket fields. Use for setting up or changing limits, sizing any trade, and answering "how's the book".
The Execution Trader's procedure for turning an approved ticket into one Hyperliquid action and reconciling it - the pre-send checklist, order construction rules, single-send discipline, unknown-result handling and the execution report. Use before and after every send, cancel, modify, leverage change or close.
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.