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 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.
/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.4827 ETH, stop 2,900, 0.5% risk stressed (risk-limits v3)
14:29 UTC HG-20260816-01 approval "approve HG-20260816-01" (user)
14:31 UTC HG-20260816-01 sent buy 0.4827 @ 3,000 Gtc + sl 2,900 (normalTpsl); cloid 0x9f3e...; oid 1839201122, sl waitingForFill
16:05 UTC HG-20260816-01 fill 0.4827 @ 3,000.0 maker, fee $0.29
09:12 UTC HG-20260816-01 closed tp 3,089.6, fee $1.44; 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; not on exchange, waited out expiresAfter 11:41, re-checked clean, 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).
Trigger: a proposal reaches closed, or the user asks. Inputs, always listed with timestamps:
userFills / userFillsByTime for the window: price, size, fee, side, crossedhistoricalOrders and orderStatus by cloid: what rested when, what cancelleduserFunding for the holding windowCompute:
| 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:
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.
From the journal, proposals and the exchange record for the week:
portfolio or start/end equityNo recommendations about what to trade. If the user asks, hand strategy questions to the Strategist and sizing questions to the Risk Manager.
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/<id>.md and linked from the daily journal.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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 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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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".
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
How the Strategist works with the user to turn their own trading idea into explicit rules, backtest it honestly on Hyperliquid candle and funding history, and paper-trade it on testnet through the desk lifecycle. Method only - the desk ships no strategies and makes no return claims. Use when the user wants to design, test, compare or paper-trade an idea.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.