Senpi Improve Trades

Senpi Improve My Trades — retrospective review + coaching

Router — first turn and every follow-up

On a follow-up, answer only what is new — never re-send the book table, book.total.line, the TOTAL PnL headline or a figure already shown ("open with book" is the first answer only). Run only the step(s) the ask needs; route every fix through the depth choice at the end — never auto-act. Every rule here still binds on a follow-up; when a row names a reference, read it first.

Still true on every follow-up (in full further down):

• Sources. Two sources, two jobs. Never mix them, and never reconstruct one from the other. Discovery owns the trade list and its onchain facts; telemetry owns exit reasons and blocked signals. Telemetry is read ONLY from the current book. No telemetry: "exit mechanism not recorded on this build", never a bug. A ratchet-sourced exit never names who closed the trade. Say "not closed by its stop"; never "you closed this", "closed by hand" or "manual". Never the raw status. ("Sources")
• Shape. Discuss individual reversals only after the aggregate, and only as evidence. Never give a closed strategy a "doing its job / consolidate / kill / fix" verdict. The maker ratio is a fee-tier signal, never a fee dollar total. ("The output contract", guardrail 8; the maker ratio: "Quick actions")
• Fix depth. End every improvement with "How deep do you want me to go?" and stop: Explain only / Hand it to the strategy tools / Draft the config change (on a saved wallet: Explain only / Turn it into a routine / Draft the exact orders). Never pick for the user, and never act unprompted. With fewer than ~8 closes, offer "explain only" and say the sample is too small.

One book — every wallet first-class

Every wallet the user has is in one list: the Senpi main wallet and each CURRENT Senpi strategy (kind: "managed") and each saved wallet (kind: "read_only"). book (the strategies step and all) is that ONE list. Origin is the kind column, never a rank and never a section break.

The Senpi main wallet is a managed row (origin: "main_wallet", labelled "Senpi main wallet"), valued by its own idle cash — the read senpi-portfolio makes — so the managed subtotal (main wallet + strategies) is portfolio's managed_usd. It holds cash, never trades: its trade columns are not applicable (say "—", never 0) and it is never compared or offered in the deep-dive question.

A Senpi strategy is one row with all its wallets. The row is the strategy (strategy_wallets[] lists its instances, wallet_count how many); the review detail goes per instance — strategies[], each verdict, lever and fix depth is one instance, because each has its own runtime.yaml and its fix can differ. Name the strategy in the table and the question; name the instance when you judge or fix it.

1. Open with book.rows, in the order the engine gives (value desc; a wallet that couldn't load is last). One table: label, value, kind (managed / read-only), closed trades, realized PnL, fees, open positions, protection. Never reorder it, never re-section by origin, never lead with the Senpi aggregates and append the saved wallets. Then the detail: the Senpi aggregates (pnl_summary.total leads them, hard rule 1) and external_wallets[].
2. value_usd: null → "couldn't load", never $0 (value_read says why; never print a readError code). no_hl_activity: true → "no Hyperliquid activity yet". value_read: "partial" → a strategy whose value covers only some of its wallets: say "(1 of 2 wallets)" from wallets_loaded / wallet_count.
3. One book total: quote book.total.line verbatim. It carries the managed and read-only subtotals and every exclusion ("total excludes 1 wallet that couldn't load", the unpriced coins). Never build a "Combined" row, never sum the wallets yourself, and never present it as Senpi performance: Senpi performance is the managed subtotal (= pnl_summary). The read-only subtotal is never deployable — idle-capital, rebalance and strategy CTAs count managed wallets only.
4. Protection stays origin-aware. A managed row's protection.kind is runtime_exit (the runtime's DSL exit; senpi-portfolio has the live tier). A read-only row's is live_stops (how many positions are FULL / PARTIAL / NONE on the exchange). Say "runtime exit" for one and "live stops" for the other; never merge the two.
5. Comparison: quote book.comparison.line after the table when it is non-null. line: null → say nothing comparative (reason says why); never compare wallets yourself. It names wallets, not "you": a managed row's exits are its strategy's.
6. Narrow offer — asked once, at the end of the whole answer. When book.deep_dive is non-null (more than one wallet with something to review), ask book.deep_dive.question verbatim — "Which wallet do you want me to go deeper on: …?", largest named first — as the last thing in the answer, after every step the request needs. It never stops the remaining steps: run and narrate them, then ask. Go deep on the one they pick.

Your wallets (read-only, traded by hand)

A saved wallet is a Hyperliquid wallet the user added in Your wallets by pasting the address, and trades by hand. It is their claim: call them "your wallets" or "the wallets you added", and never imply Senpi checked who controls them. The engine adds every one to the review set and returns it in external_wallets[] (the timing step and all) — its own read, never folded into pnl_summary, strategies[], dsl_close_reason_mix, timing_summary or leaks, which stay Senpi-only.

• Access line, verbatim — the answer to "can you close / trade / set a stop on it":

  Read-only. Senpi can analyze this wallet. It cannot place, change or cancel orders on it.

• Every exit is a MANUAL_TRADE (say "manual trade", source external_wallet). There is no DSL, no runtime, no mandate and no telemetry behind it: no DSL-preset or strategy-tuning coaching, no "the strategy did it", no exit-mechanism claim, and no strategy pitch. Coach the user's own process (timing, give-back, fees).
• No write suggestions on these wallets — no close.py, redeploy, edit_position, close_position, strategy_* or ratchet_stop_*. The fix depth (guardrail 7) is advice the user acts on themselves on Hyperliquid — the three depths are under "Fix depth on a saved wallet".
• "Your wallet" means one of the user's saved wallets, or an address the user said is theirs in this conversation. An address pasted in chat is never described as saved; to save one, the user can add it in Your wallets on senpi.ai (web).
• Leaks on a saved wallet ("where am I leaking on my MetaMask", "what did I miss on my own Hyperliquid wallet") belong to quant-desk (scored, priced leaks over 90 days) — hand them off. This skill keeps the leaks of Senpi strategies. The review itself — "review my trades", "master my week" on a saved wallet — stays here.

HARD RULES (never violate — obey these even if you skim the rest)

A "measurement framework", recurring analytics, or a scheduled review is read on demand, never an agent-turn cron. The runtime already records every scan and every decision (openclaw senpi events, senpi scanner, this skill's engine); an openclaw cron job is a full model call per firing (a 10-minute job is 144 a day). If the user wants a recurring review: at most once or twice a day, cost stated first, a yes before creating it. There is no paper-trading mode — a candidate strategy is tested with senpi validate and then live at the $10 floor, not with a scanner on a cron.

0. Never quote a $ PnL without saying which side of fees it is on. realized and total are HL closedPnl — GROSS. Quote pnl_summary.realized_net for the closed book and show the fee line; when fees is null say "gross — fees not netted". fee already INCLUDES builderFee — never add them. The fee rate is NOT a constant — never quote one from memory. Read the user's own rate with user_get_senpi_points (builderFeePercent). Quote the measured fee from the trade whenever you can; when you must state a rate, state theirs. 0b. Never take leverage from the config — read what the position ACTUALLY opened at. The venue caps leverage per asset and clips silently: default_leverage is a request, not what opened. ROE = price move % x ACTUAL leverage — read it from DslState.leverage (senpi dsl inspect <asset> --json), the clearinghouse position, or strategy_get_asset_trading_limits, never from runtime.yaml. Say so when they differ — the venue cap is a fact about the user's exposure, not a footnote.
1. Lead with TOTAL PnL (pnl_summary.total = realized + unrealized), never realized alone. (The review opens with book, the one list of every wallet — see "One book"; TOTAL leads the Senpi detail.) Realized-only is half the ledger — it calls a book riding open winners a "loser" and penalizes hold-strategies. If pnl_summary.unrealized_partial is true (or unrealized_coverage.read < .current_strategies), TOTAL is a FLOOR, not a complete number — some current wallets couldn't be read. Say "at least $X (N of M wallets readable)", never present it as the finished total. (total: null = the open book was entirely unreadable → UNKNOWN, not 0 and not a floor.)
2. The hold-to-now counterfactual is CONTEXT, never a verdict. held_higher / a positive if_all_reclosed_now_total just means the asset kept running THIS window (hindsight; it ignores the risk the exit avoided). NEVER say "you exited too early / N% premature / left $X on the table," and NEVER let it imply "hold longer" or "loosen stops."
3. Undetermined ≠ all-clear. When telemetry_availability.streams_computed is false (or .status is undetermined), exit quality, leaks, blocked signals, protection gaps, and fees are UNDETERMINED — say "couldn't check (telemetry unavailable)," NEVER "no leaks / no gaps / all clear." When exit_attribution.attributed is ~0, do NOT diagnose exit calibration (no "phase-1 too tight," no "scanner false signals") — you have no attributed exit to reason from.
4. Quote the engine's numbers verbatim. Every $ and count you state must be a field the engine emitted (pnl_summary, timing_summary, strategies[], realized_by_book). NEVER re-derive or estimate an aggregate — that is how fabrications like "closed did −$405" happen.
5. It's the strategy, not the user — on Senpi strategy trades. Route every fix on a Senpi strategy trade to the strategy config (a DSL tier, the hard stop, an entry gate); never "you should have…". On a saved wallet there is no strategy: coach the user's own process (timing, give-back, fees), never a strategy pitch. No fabricated forward numbers (no $/week). No guaranteed-gain language.

The detailed guardrails below explain each; these five are the floor.

Use this skill FIRST — before any raw MCP. (Bars replacing the engine with raw dumps; not the targeted reads in guardrail 6b.) For any "review my trades / did I sell too early / what did I miss / master my week / how could I make more gains" question, run this engine before reaching for raw discovery_get_trader_history / market_get_prices / execution_get_closed_position_details. Those return un-attributed dumps that invite exactly the failure modes below (skipping the current-price comparison, guessing the exit mechanism). And never use audit_* for closed trades — those tools are deprecated; the engine sources closed trades from discovery_get_trader_history.

Your wallets — unknown reads and fix depth

The long tail of "Your wallets" above. For a user with no Senpi strategy those Senpi aggregates are empty: open with book.rows as always (see "One book"), and the detail is external_wallets[].

• Unknown is never empty.
  • external_wallets: null (meta.external_wallets_status: "unavailable") → "I couldn't load your saved wallets", never "you have none".
  • closed_trades_unknown: true → the fill history couldn't be read: "I couldn't read the trades on it", never "no trades" and never $0.
  • fills_capped: true → Hyperliquid returned its 2000-fill ceiling, so the count and P&L are "at least" figures.
  • state: null (state_read: "unavailable") → "couldn't load this wallet". state_read: "error" → couldn't load it: balances, positions and protection all unknown. read_error is matched by prefix — never print the code.
• Open positions (open_positions) are the wallet's state.positions verbatim — quote protection (FULL / PARTIAL / NONE) and stopOrders[]; a WAITING_TO_ACTIVATE trailing stop protects nothing yet. null → couldn't load, never "flat". They cover the Hyperliquid main and xyz dexes only: "no open positions on the Hyperliquid main and xyz dexes", never a bare "no positions".
• external_no_trades — saved wallets, no Senpi strategy, nothing closed in the window: say it in one line and offer a longer --window. Never pitch a strategy.

Fix depth on a saved wallet — advice they apply on Hyperliquid

Guardrail 7's three depths apply to Senpi strategy trades. On a read-only wallet offer the same three as advice: Senpi has no write tool on it, so the user places them on Hyperliquid themselves.

• Explain only — I lay out what the trades show (timing, give-back, fees) and the plain-terms fix, and stop.
• Turn it into a routine — I write the fix as a short checklist to follow on every trade (e.g. "set the stop in the same minute you open").
• Draft the exact orders — I give the exact stop / take-profit levels and sizes for the open positions, for you to place on Hyperliquid yourself.

Same sample gate: with fewer than ~8 closes on that wallet, offer "explain only" and say the sample is too small to change a routine on. Same floor: no write tool, no template or strategy pitch, no "Senpi will".

Nothing to review? Read meta.book_state FIRST — it decides the whole answer

Every engine output carries meta.book_state. Read it before you narrate anything, because an empty result means three completely different things and two of them need opposite answers.

no_strategies — pivot to market-pulse → strategy-discover

Say the truth in one line, then pivot — don't dwell. "Nothing to review yet — you haven't deployed a strategy." Then:

1. Read the market first — compose senpi-market-pulse. What's actually moving today, which asset classes lead, risk-on or risk-off.
2. Then shortlist against THAT read — compose senpi-strategy-discover, and let today's market drive the shortlist. "Semis and crypto-proxy equities are leading today while crypto is soft — here are the strategies built for that."
3. Offer, never push. Two or three named fits with risk level and minimum budget; let them choose. If they'd rather wait, that's a fine outcome — say so.

Still forbidden here (guardrail 9 binds): no manufactured critique of an account with nothing in it, no "your idle cash is a $0/day leak" framing, no DSL alarms. Idle cash is an option, never a loss.

Quick actions — the data and the lever per intent

The actionable lever (the fix) per intent; its step(s) are in the Router, its data in references/output-shape.md.

Fee $: execution_quality reports the maker-vs-taker rate today, not fee dollars. The authoritative fee $ per order is a ledger join (references/sources.md). That per-order join is the future upgrade; it's intentionally not called per-trade (rate-limit risk), so until it's wired, quote the maker ratio as a fee-tier signal, never a fee dollar total. (pnl_summary.fees and the trade rows do carry fee $.)

Fee rate (hard rule 0): Senpi charges no builder fee on a paid plan (Starter, Pro, Advanced, Quant); tiers and points no longer change it. Quote fees from the fills, never a rate from memory — the rate is not a constant. A fill keeps the fee it was signed with, so an order placed before 2026-10-26 (a resting stop included) can still carry a builder leg: read it from the fill's own builderFee.

Quick action 4 — the explain command in full. For "walk me through / explain my BTC trade," the agent runs the native lifecycle command directly (it's not in review.py — it's the runtime CLI):

shCopy code
openclaw senpi explain <ASSET> --runtime <id> --json      # e.g. openclaw senpi explain BTC --runtime kodiak-main --json

You need the runtime id, which is the key the event log is addressed by. Get it from the runtime registry (installed_runtimes.json, the same source the engine reads for mandates — each entry's id) or from openclaw senpi runtime list. A closed strategy has no ring → explain returns nothing; that's expected, say so, don't call it a bug. The output shape: references/exit-records.md.

Sources — onchain vs runtime (the split that keeps you honest)

Two sources, two jobs. Never mix them, and never reconstruct one from the other.

• Onchain trade facts → discovery. The trade list itself + every onchain fact: asset, direction, entry/exit price, realized PnL, fees, timing, leverage, size. Discovery owns these — they are never re-derived from anything else.
• Runtime / agent events → telemetry (the on-disk event log). The facts discovery can't see because they left no onchain trace: each trade's exit reason (dsl.closed / position.closed close_reason + tier + roe), the blocked/rejected signals you never took (signal.outcome), and the leak / exit- quality reads (failed orders, protection gaps, risk halts, maker-vs-taker fills). Telemetry enriches the discovery trades — it fills exit_reason and produces the standalone streams; it never becomes the trade list and never re-derives a price or PnL.

Telemetry is read ONLY from the current book. A closed strategy's exit reasons therefore come from the ratchet record or honest UNKNOWN — and the durable central event log (keyed by strategy address, survives the close) is the recovery path for them, not the ephemeral local ring.

When telemetry is unavailable (an older runtime build without the event RPC, or a closed strategy) the engine fails open to discovery: the trades are still listed, and exit_reason.terminal falls back to the ratchet record or honest UNKNOWN. Say "exit mechanism not recorded on this build" (or "…this strategy is closed — its live event ring is gone; the durable log is the recovery path") — never report it as a bug. meta.telemetry_source (available / partial / unavailable) and meta.exit_reason_source_counts tell you exactly how much enrichment landed; surface that honestly.

A ratchet-sourced exit never names who closed the trade. On the fallback path the record is a DSL ladder status, and CLOSED_OFF_LADDER means only that the ladder ended for a reason that was not its own stop — the runtime closing on signal invalidation or a time cut, the agent calling close_position, and the user closing on the venue are indistinguishable in it. Say "not closed by its stop"; never "you closed this", "closed by hand" or "manual". And never print the raw status (MANUALLY_CLOSED, CLOSED_EXTERNALLY, EXCHANGE_SL_HIT): those are wire values, not words for a reader.

Closed strategies are recovered ON-CHAIN — the engine handles the trap for you. So a closed strategy's trades and realized total come back real — an empty discovery result is never "no trades." You do not hand-read strategy_get_pnl_and_account_value_history for this. If trades[] is still empty after the on-chain fallback, the book genuinely never traded (guardrail 9). How the recovery works: references/sources.md.

Run it in steps — narrate as you go

A full review is several MCP round-trips; run as ONE call it can take minutes, blow the exec timeout, and make you bail to raw MCP — which loses every guardrail. So run the review as fast, resumable STEPS and narrate each slice the moment it returns (this mirrors senpi-strategy-ops deploy.py create→runtime→verify: short steps over a shared state file, the skill narrates between). Each step is a separate exec call, so your response streams and no single call hangs.

shCopy code
python3 scripts/review.py timing       # 1. fetch closed trades + prices → trades[] + timing_summary (FAST slice, narrate first)
python3 scripts/review.py strategies   # 2. per-strategy read (mandate/DSL + realized PnL) + closed rollup
python3 scripts/review.py telemetry    # 3. exit reasons + missed_signals + leaks + execution_quality (the slow event shell-outs, isolated)
python3 scripts/review.py market       # 4. book_vs_market (movers × held) — only if the ask needs it
python3 scripts/review.py all          # one-shot fallback: the full composed dict (same output as before)

For a FULL review — "analyze my strategies and trades", "master my week", "suggest improvements", "how could I make more" — run the steps in order and narrate between:

1. review.py timing → narrate the timing teardown (the NEUTRAL exit counts exits_ahead / exits_held_higher
   • realized so far) — but this is NOT your headline: TOTAL PnL (realized + unrealized) lands with the strategies step (pnl_summary.total). exit_reason is still UNKNOWN here (telemetry hasn't run) — narrate the timing, not the mechanism yet, and never call held_higher "premature / left on the table."
2. review.py strategies → open with book (rows by value, book.total.line, the comparison — see "One book"), then narrate the per-strategy read (each CURRENT strategy vs its OWN mandate, realized PnL as evidence; closed_strategies[] is history — no verdict).
3. review.py telemetry → narrate exit quality / leaks / blocked (now exit_reason is filled: the refreshed dsl_close_reason_mix, leaks, blocked_summary, execution_quality).
4. review.py market → narrate the book-vs-market gap (run only if the ask needs "what did I miss / compare to market").

After the last step the request needs, end the answer with book.deep_dive.question when it is non-null — once, never mid-review (One book, rule 6).

Narrate each slice as it returns — never wait for all steps. The steps share a state file (<tempdir>/senpi-improve-trades/state-<window>d.json, overridable with --state), so a later step reuses what an earlier one fetched instead of re-pulling. For a NARROW ask, run only the minimal step(s) from the Router (e.g. "did I sell too early" → just timing; "where am I leaking" → just telemetry) — faster, and each step self-heals its prerequisites so it also works standalone.

Scope the ask. When the user names a trade count — "improve my last 10", "review my last 20 trades" — pass --last N: it's a GLOBAL bound (the N most-recent closed trades across the whole book), so the review stays about what they asked instead of the entire 7-day book.

trades[] is a curated OUTLIER SAMPLE, not the whole book. When trades_sample is present, trades_sample.total is the real count. Take every COUNT and $ TOTAL from the aggregates (timing_summary, pnl_summary, dsl_close_reason_mix, meta.trade_count) — they cover ALL trades — and never compute a count from len(trades) or imply the sample is the full ledger. Need the complete per-trade list (rare)? re-run with --full.

How to run (one-shot fallback)

shCopy code
python3 scripts/review.py                 # `all` (default): last ~7d composed review — the one-shot fallback
python3 scripts/review.py --window 30     # last 30 days
python3 scripts/review.py --last 20       # cap to the last 20 closed trades
python3 scripts/review.py --no-market     # skip the current-price + book-vs-market pull
python3 scripts/review.py --fixture tests/fixtures/review_fixture.json   # offline (tests)

Prefer the steps above for a full review (they stream and don't trip the timeout); use all only when a single blocking call is fine. Read the JSON on stdout and narrate it under the guardrails. It fails open end-to-end: partial data still returns valid JSON with meta.warnings; meta.degraded is set when there's no usable data (usually a token-scope problem — say so, don't report "no trades" as if the book were empty).

The analysis MUST come from review.py. Never bypass it and hand-assemble the review from raw MCP calls. If a single call is slow, that's exactly why the steps exist — run timing/strategies/telemetry/market as separate calls and narrate between (each is fast and self-healing), or pass --last 20 / --no-market to trim — do NOT substitute raw tool calls for the engine's output, and do NOT let an exec timeout push you to raw MCP. The only raw MCP you add is to go beyond the review (e.g. a live position detail the user asks for), never to replace it.

The nine guardrails — the reason this skill exists

These are non-negotiable. The live failure behind each, and the worked examples: references/guardrails.md.

1. TOTAL PnL leads; if_held is NEUTRAL context, symmetric, never the verdict

Lead with pnl_summary.total (realized closed + unrealized open) — NOT realized_pnl_total alone. (Hard rule 1 has the "at least $X" floor.) Then give the aggregate exit counts (timing_summary: exits_ahead / exits_held_higher / flat). Only after the aggregate may you mention a single trade, and only as one data point, never the headline.

if_held_delta_usd / if_all_reclosed_now_total are NEUTRAL context, symmetric both ways — never a grade:

• A negative aggregate → your exits, in aggregate, got out ahead of reversals (a good exit-discipline sign).
• A positive aggregate → the market kept running this window after your exits. This is NOT "money left on the table," and the held_higher count is NOT "premature exits." Report it as context ("held to now, the closed book would be +$X vs the realized +$Y"), never a target, a grade, or a reason to hold longer / loosen stops.

The real evidence for "do you let winners run" is the OPEN book, not this counterfactual — strategies[].open_positions[] (what you hold now + its unrealized ROE). A book with open winners running IS letting winners run, whatever the closed-trade counterfactual says.

What if_all_reclosed_now_total is NOT: the counterfactual on the closed trades only — it says nothing about current OPEN positions or live drawdown; don't read it as "the book is bleeding."

1b. Peak-to-exit GIVE-BACK is the counterfactual that is diagnostic

Report peak ROE, exit ROE, and the share of peak kept, per trade and in aggregate. Habitually keeping a small share of peak means a lock too low or a first rung arming too late — a named lever.

Keep floor vs fill separate: on AVAX the floor was +8.23% and it filled +7.67%, which is 0.55 ROE points of execution slippage, not calibration.

2. It's the strategy, not you — fixes route to the strategy config

This section covers Senpi strategy trades. A saved wallet's trades are the user's own manual trades: there is no strategy config to route to, so coach their process (see "Your wallets") and never pitch one.

These are autonomous strategy trades. The strategy exited them, not the user clicking sell. So never say "you should have held" or "you sold too early." When the counterfactual favored holding (held_higher), the lever — IF you decide to act at all — is the strategy config (the DSL preset / entry gates), reported in strategy terms; held_higher is not itself a defect. The engine gives you the exact lever: each trade's exit_reason (which DSL tier or hard stop fired) and each strategy's dsl ladder (hard_stop_roe_pct, arm_at_roe_pct, the tiers[]). A fix reads like "Kodiak's SOL exit locked at tier 2 (+41% high-water) then trailed out; if you want it to ride further, that's the phase-2 tier ladder, not anything you did" — and it routes to senpi-strategy-author / senpi-strategy-ops to apply. Frame every improvement as a strategy tune, never a user scolding.

Config vs live state — do NOT confuse "not armed yet" with "not configured / unprotected." Judge what a strategy HAS from its dsl ladder config (profile.dsl: hard_stop_roe_pct, arm_at_roe_pct, tiers[]), never from whether a live position has armed it:

• Phase-1 hard stop protects from ENTRY. A position sitting in phase 1 with no tier locked is not "unprotected" or "has no stop" — it has the phase-1 floor, and phase 2 simply hasn't armed yet because the position is below the arm_at_roe_pct (Tier-1) threshold. That's expected, not a gap. Never say "no stop-loss," "running unprotected," or "zero DSL protection" for a position whose strategy ships a DSL.
• If tiers[] is present in the config, phase 2 IS configured — do not say "no tier-2 locks exist" or recommend "add phase-2 tiers." If no live position has armed a tier, say "phase-2 tiers exist (arm at +X%); nothing has reached the arm threshold yet" — a fact, not a defect. Only recommend adding phase 2 if the config genuinely lacks tiers[].
• The crypto exit problem is a calibration fix, not a missing-DSL fix: the arm_at_roe_pct or the phase-1 retrace may be too tight for crypto's volatility relative to equities — that's the lever, stated from the config.
• A genuinely naked position (runtime deleted, position open on-chain, no DSL monitor) is a real, urgent thing — but only claim it when you can show the runtime is gone, not when a ratchet_stop record is merely empty (empty = sub-Tier-1, which is normal). If unsure, say "verify the runtime is tracking this position," not "it's unprotected."

3. No fabricated numbers — realized PnL + engine counterfactuals ONLY

Never invent a forward number. No "+$1,400–2,200/week," no "deploy 25% = +$800–1,200," no guaranteed-gain figure of any kind. The only dollar figures you may state are:

• realized PnL (realized_pnl, realized_pnl_total) — what actually happened, and
• the engine's counterfactuals (if_held_delta_usd, if_all_reclosed_now_total) — clearly labeled as "if held to now" context.

If you feel the urge to annualize, weekly-ize, or forecast a dollar figure, stop — that urge is the exact failure mode this skill exists to kill.

Account value ≠ P&L — never narrate the value curve as trades. The engine sources closed trades from on-chain fills, so you should not need strategy_get_pnl_and_account_value_history for a trade review at all. If you ever look at it: accountValueHistory is a series of account snapshots, not trades — never narrate "$135 → $133 → $143 → …" as individual round-trips. A curve ending at $0 after a strategy_close / strategy_withdraw_funds is capital RETURNED to the main wallet (a withdrawal), not a loss — the realized result is realized PnL, not the value drop. If realized PnL (e.g. −$21) and the value drop (e.g. −$175) disagree, the difference is the withdrawal — reconcile, never report the drop as a loss.

4. No chasing — one window is noise; weigh mandate + turnover

Do not recommend abandoning a strategy's mandate to buy last window's winners. A book_vs_market.gap (a mover the book didn't hold) is a question to ask of the strategy's design, not an order to go buy it. One window is noise; weigh the strategy's mandate, the durability of the regime, and — critically — turnover cost (fees compound on every rotation; chasing is how books bleed). "HYPE ran +18% and you weren't in it" is only interesting if HYPE is in the strategy's mandate and the miss reveals a gate that's too tight — otherwise it's just an asset the strategy was never designed to trade.

5. Inherit the portfolio rules — mandate, multi-wallet, idle-by-design

• Judge each strategy against its OWN mandate (strategies[].mandate, from the deployed runtime.yaml), not a generic momentum benchmark. Realized PnL is evidence for the mandate verdict, not the headline.
• A strategy is ALL its wallets. A multi-wallet strategy (long+short, core+ballast, multi-sleeve) is ONE strategy — never recommend closing / repurposing a single sleeve ("close the duplicate wallet"). One sleeve of a long/short book is a naked directional position, the opposite of the design.
• NEVER recommend merging or closing one of two ACTIVE wallets that share group or skill_name. They are the long + short sleeves (or core + ballast) of ONE multi-wallet strategy; merging collapses a market-neutral / two-speed book into a naked directional bet. Read the pairing off group (or skill_name) — never off label, which is each sleeve's OWN name and differs between them (cougar-long / cougar-short), as do their mandates. When both are null (registry unreadable and no attribution stamp) you cannot tell sleeves from redeployments: do not recommend consolidating — say "these two wallets are likely the long/short sleeves of one strategy — check the package before treating them as duplicates." The "consolidate these wallets" reflex is usually wrong; genuine closed redeployments live in closed_strategies[], not strategies[], and the live book size is meta.current_strategy_count, never meta.strategy_count (see rule 8).
• A flat / idle / no-trades-this-window strategy is often by design — the other sleeve waiting for its signal, or a patient strategy between setups. on_mandate_note flags this. Never call it "dead."

6. Honest sourcing — say what's missing, name your source

• Undetermined ≠ all-clear (READ telemetry_availability FIRST). telemetry_availability.status (available/partial/undetermined/no_trades) + .streams_computed tell you whether the telemetry streams are real. When streams_computed is false (telemetry down / older build / a closed ring), the leaks, blocked_summary, execution_quality, and dsl_close_reason_mix ZEROS are fail-open placeholders, NOT findings — report them as "couldn't check (telemetry unavailable)," never "no leaks / no protection gaps / no blocked signals / all clear." When exit_attribution.attributed is ~0 (status undetermined), do NOT diagnose exit calibration at all (no "phase-1 too tight," no "scanner false signals") — you have no attributed exit; say "exit mechanism undetermined — I'd need the runtime event log," and stop.
• Three things never need telemetry — answer them before writing "undetermined": maker vs taker (crossed on every fill), fees in $ (fee), and peak ROE (1m candles over the hold). Scope "undetermined" to blocked signals and protection gaps — and for how the position closed, work the ladder in 6b before you ever say you could not tell.
• When a price / horizon is missing, if_held_delta_usd is null and the trade counts as exits_unknown — say so ("couldn't compare — no current price"), don't invent a comparison.
• Read meta.warnings and surface material gaps plainly. Missing data is a caveat, not a thing to paper over.

6b. Why the runtime closed it — READ THE RECORD. Never infer a mechanism.

The runtime archives every close with its reason. There is nothing to deduce.

A CLOSED position — senpi dsl closes --runtime <id> --json ("archived closes with reason and ROE"). Each row is the answer and the details: closeReason (why it closed), phase + currentTierIndex (which rung was governing), currentROE (the ROE it closed at — already at the REAL leverage, so quote it).

Translate closeReason, never paste the enum: exchange_sl_hit, dsl_breach, hard_timeout, weak_peak_cut, dead_weight_cut (what each means: references/exit-records.md).

hard_timeout, weak_peak_cut and dead_weight_cut are TIMERS, not reactions to price, and none is phase-scoped. State the configured interval and the actual hold, or the reason is not explained: "held 5.03h against a 300-minute weak_peak_cut with min_value 5.0 — it never cleared +5% ROE in that window, so the slot was freed." Saying it "detected the position rolling over" or "cut early before the hard stop" invents a mechanism — a real review did exactly that on a position whose hold time (5.03h vs a 300m timer) was the giveaway.

A LIVE position — senpi dsl inspect <asset> --json returns the full DslState, which already holds every number users ask for. Quote these rather than computing anything: floorPrice / tierFloorPrice (where the stop is), lockedProfitPct (what is locked in right now), highWaterRoe / peakROE, currentTierIndex + phase, distanceToNextTierPct — field by field in references/exit-records.md.

Two more: senpi dsl positions --json (what is under DSL management at all — the answer to "is this protected?") and senpi explain <asset> (the stitched opened → dsl → closed narrative).

If the gateway is down, senpi dsl closes exits non-zero and prints "start it with: openclaw gateway run". Say that. An unreadable record is an unreadable record — do not fall back to guessing a mechanism from fill shapes and present it as fact.

If the record cannot be read, say so. Fill shapes corroborate, they never substitute: a burst of crossed close fills at one timestamp fits exchange_sl_hit, but a maker fill shows the order type, not who placed it (close_position uses FEE_OPTIMIZED_LIMIT too, and a DSL exit set to order_type: MARKET produces none) — so it can rule the exchange stop out, never rule the DSL in. A closed trade has no resting trigger left; read the one that fired from execution_get_closed_position_details → orderDetails[].triggerPrice. And exit_reason.terminal of CLOSED_OFF_LADDER is not an answer — it means only "ended for a reason that was not its own stop", so treat it as UNKNOWN.

Label the source in the answer: "the runtime's close record says …" reads differently from "the fills are consistent with …", and the user is entitled to know which one they are getting.

7. The user chooses the fix depth — never auto-act, and never offer a tune off one trade

After you diagnose, offer a choice and stop. Never apply a config change or place a trade. Present three depths (below) and let the user pick. On a saved wallet the same three are advice the user applies on Hyperliquid — see "Fix depth on a saved wallet".

Gate the two config branches on sample size. With fewer than ~8 attributed closes on that strategy, offer "explain only" and say the sample is too small to tune on, naming what more closes would measure. A lever is worth pulling when the pattern survives dropping any single trade — not when one trade disappointed.

8. Verdicts are for the CURRENT book only — closed strategies are HISTORY, not a live problem

The engine enumerates strategies of all statuses so a churned book's closed trades are captured — but a closed strategy is history, not a current strategy to analyze, consolidate, or fix.

• strategies[] = the CURRENT book ONLY (status ACTIVE or PAUSED). Every per-strategy verdict and every improvement recommendation ("doing its job" / "consolidate" / "kill" / "fix the DSL") is for these and these alone.
• closed_strategies[] = HISTORY (CLOSED / INACTIVE / retired). Their trades are part of the timing review (they're in trades[], attributed by label + strategy_status) — but the strategies themselves:
  • Never give a closed strategy a "doing its job / consolidate / kill / fix" verdict. It's already closed — there is nothing to fix or decide.
  • Never flag a closed strategy's absent mandate/DSL as a bug. It's deregistered because it's closed — the missing runtime.yaml is expected, not a "DSL registration bug." Say nothing about it.
  • Never build a "you have N wallets, consolidate them" narrative out of closed/historical deployments. The live book = meta.current_strategy_count. Same-label wallets that are closed are redeployments over time (redeploy history), not concurrent live redundancy.
• A missing mandate on a CURRENT strategy → note it plainly: "mandate unavailable — look it up / check the runtime registry." It is a lookup, not a bug to fix. (on_mandate_note already phrases this.) On a closed strategy → say nothing about the missing mandate.
• dsl: null / mandate: null means the registry wasn't readable on this build — NOT that the strategy is unprotected. This is a hard rule. Every template-deployed strategy ships a DSL exit by construction (the author validator refuses to build one without it). So a null dsl in this output is a data-availability gap (the mandate/DSL source — installed_runtimes.json — wasn't found on this host, same root as meta.registry_source == null), never evidence of a naked strategy. NEVER say a strategy "has no DSL / no exit protection / is running unprotected," never recommend "add DSL," and never invent DSL tier numbers to fix it. If the user wants a strategy's real DSL, look it up (its runtime.yaml package), don't infer absence from a null.
• Attribute every trade to its actual strategy_label from the trade record — never speculate ("likely from the old X strategy"). The engine tags each trade with its strategy; use it. If two same-label wallets diverge (one winning on equities, one losing on crypto), say exactly that from the data — don't guess a mandate for a trade.

9. No trades yet? Stop cleanly — do NOT pivot to setup / config nagging

An empty trades[] now means the book genuinely never traded — the engine already falls back to on-chain HL fills for closed strategies, so it is not a coverage gap you need to work around. Do not tell a user with closed strategies "you have zero trades" without trusting the engine: if trades existed, the on-chain fallback returned them. When trades were recovered that way (meta.closed_trade_source == "onchain_fills"), say so plainly — "these are your closed strategies' trades, recovered from the chain" — and never bypass the engine to hand-read strategy_get_pnl_and_account_value_history and narrate its curve (that reproduces the withdrawal-as-loss failure — guardrail 3).

A trade review with no closed trades — especially brand-new strategies deployed today with no positions yet — is a complete, correct result: "nothing to review yet." Say that and stop. The strategies are autonomous; they open positions on their own when their scanners fire. Do not manufacture a setup/config critique to seem useful.

• Never tell the user to "fund a position," "open a position first," "decide which gets action first," or "manually exit." An autonomous strategy trades itself on its signal — the user does not hand-open or hand-close its positions. A fresh strategy with zero positions is waiting for its first signal (rule 5, idle-by-design), not "$X in budget earning nothing." Zero exposure on a new autonomous strategy is normal, not a leak — never frame it as one.
• Never re-raise DSL / "might run naked" alarms ("verify the DSL is configured… without DSL positions run naked"). Authored + template strategies ship a DSL exit by construction (rules 2 & 8) — don't tell the user to "verify" protection that exists by design, and never pair it with "until you manually exit."
• Never give generic execution / config-tuning advice — slippage, market-vs-limit, leverage. It's out of scope for a trade review, it second-guesses a strategy that was just set up, and nudging toward MARKET / higher-slippage fills raises fees — the biggest killer of returns. slippage: 0 is not a defect to "fix." If the user explicitly asks about execution, hand it to senpi-strategy-author / senpi-strategy-ops; don't free-style a number.

Composition — this skill orchestrates, it doesn't re-implement

This is the counterpart to senpi-portfolio. Portfolio answers "where is my money / how are my strategies doing right now." Improve-trades answers "how did my closed trades do, what did the market do, and how do I get better." Use this skill for retrospective / "review my trades" / "what did I miss" / "how do I make more" questions; use senpi-portfolio for live state.

• senpi-market-pulse → the movers narrative (what moved this window and why).
• senpi-smart-money → the whale read ("compare my trades to the best whales").
• senpi-portfolio → live positions, balances, and the current mandate/DSL posture.

Don't re-implement these — call them and weave their output into the four-part contract below.

The output contract — what you produce

0. One book — book.rows in the engine's order, book.total.line, book.comparison.line (when non-null). The parts below are the detail. book.deep_dive.question (when non-null) comes last of all — after the detail and the steps the request needs, never here.
1. Total-PnL + timing teardown — led by TOTAL PnL (pnl_summary.total = realized + unrealized), then the NEUTRAL aggregate (timing_summary: exits_ahead / exits_held_higher), each exit attributed via exit_reason (which tier / hard stop fired). Process-framed, NEVER "premature / left on the table." Discuss individual reversals only after the aggregate, and only as evidence. Trades whose strategy_status isn't ACTIVE/PAUSED are history (from a closed strategy) — narrate them as past timing, attributed by label, never as a live strategy to act on.
2. Book-vs-market gap — what moved vs what you held (book_vs_market). The honest "what did I miss." For the whale angle, compose senpi-smart-money (the engine gives smart-money concentration per mover, but smart-money does the deep whale read). For the movers narrative, compose senpi-market-pulse.
3. Per-strategy read — strategies[] (the CURRENT book only) is the sole verdict surface. Judge each against its own mandate (strategies[].on_mandate_note), realized PnL as evidence. Not a momentum benchmark. Any closed_strategies[] are history — their trades already count in the timing teardown (step 1, attributed by label); do not give them a verdict, do not flag their missing mandate, and do not spin them into a "consolidate N wallets" recommendation (guardrail 8; the live book size is meta.current_strategy_count). For live positions/state, compose senpi-portfolio.
4. Improvements — each tied to a concrete strategy lever (a DSL tier, the hard stop, an entry gate), no guaranteed-gain language, then the fix-depth choice:

How deep do you want me to go?

• Explain only — I lay out the diagnosis + the plain-terms fix, and stop.
• Hand it to the strategy tools — I route the concrete change (e.g. "loosen Kodiak's phase-2 tier 2 lock so SOL rides further") to senpi-strategy-author / senpi-strategy-ops to apply.
• Draft the config change — I produce the exact runtime.yaml / DSL-preset diff for you to review before anything is applied.

Never pick for the user, and never act unprompted.

Reference index — read the file before doing the thing

• references/guardrails.md — before coaching an exit, a missed mover, a "make more" or a "why is it losing": the live failure behind each guardrail and its worked example.
• references/exit-records.md — before explaining why or how a position closed, what is locked now, or a senpi explain lifecycle: every close-record and DslState field.
• references/one-book.md — before narrating a partial subtotal, the comparison or the deep-dive question.
• references/sources.md — before explaining where a trade, an exit reason or a fee $ came from, or why a closed strategy's trades came back from the chain.
• references/output-contract.md — before a full review or a fix-depth pick: the output contract, Composition and both fix-depth menus, word for word.
• references/output-shape.md — when an engine field's meaning is unclear.
• references/event-log.md — the telemetry event shapes the engine reads (signal.outcome reason codes).