@vike-io/cli 0.14.0 → 0.16.0

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # Changelog
 
+## 0.16.0
+
+### Minor Changes
+
+- 0a84307: Fifteen workflow skills (47 in all): playbooks that chain several commands for one question, each naming only commands and flags that exist in this release.
+  
+  - Wallets: `vike-wallet-who-is` (search, labels, ENS, the chain it is active on, `wallet exchange-usage`, counterparties), `vike-follow-the-money` (`call wallet_trace` with `direction: out`, the transfers, labels, stop rules, a live `chain.transfers` watch with `contract=false`), `vike-wallets-related` (labels, `wallet first-funder`, shared counterparties with exchanges and routers removed, a trace, confidence tiers).
+  - Tokens: `vike-token-holder-diligence` (`call token_holders` with `sort: balance` for `supply_pct`, then labels and `token transfers --hide-contracts`), `vike-token-smart-money-trend` (the Ethereum smart-money screener at 24h / 7d / 30d / 90d, differenced into disjoint slices).
+  - Hyperliquid: `vike-hl-cohort-positioning` (cohort metrics, the indices, the biggest positions with `--sort size`, live `hl.cohort_bias`), `vike-hl-cohort-backtest` (point-in-time labels, alignment, seams, controls), `vike-hl-trader-profile` (`hl wallet`, `wallet-trades`, `wallet-activity`, orders, TWAPs, liquidations, a live feed of its fills), `vike-hl-asset-briefing`, `vike-hl-liquidation-radar` (`--min-value-usd`, heatmap, live `hl.liq_risk` and `hl.liquidations`), `vike-hl-builder-intel`.
+  - Perps, Polymarket, cross-market: `vike-perp-crowding` (funding, `call perp_open_interest` net of price, `call perp_long_short` per venue), `vike-pm-market-diligence` (search, order book, tape, trades with wallets, settlement, holders, a live feed), `vike-pm-l2-archive` (archive files, link, settlements to join), `vike-daily-brief`.
+  - Existing skills: Base and HyperEVM on the token and wallet skills (the "Base not covered" hedges are gone; `wallet discover` on base and hyperevm needs `--window all`; `wallet summary` names its `chain` and `call wallet_summary` asks one); `token transfers` lists net buyers or sellers and takes `--hide-contracts`; `wallet balances` covers four chains and prices the native coin; `vike-polymarket-market-detail` describes what the tool returns (holders, trades with wallets, no quote or cohort block); `vike-perp-overview` reaches open interest and long/short with `call`; `search` resolves an ENS name; the umbrella routes every new playbook; eval questions for each.
+
+## 0.15.0
+
+### Minor Changes
+
+- 531c0c8: Every MCP tool is reachable, and the event streams are too.
+  
+  - `vike-data call <tool> --args '{json}'` (or `--args-file`, `--timeout`) calls any MCP tool by name and prints its raw result, so integers above 2^53 stay exact.
+  - A tool that refuses its input now exits 1 in every output mode; before, `--json` and piped output exited 0 with `{"error": ...}` on stdout.
+  - `vike-data stream <hl|hl-cohorts|onchain|polymarket> --channel ... [--filter key=value] [--cursor c]` reads `wss://stream.vike.io/v1/stream/<path>`: the key goes in the `X-API-KEY` header, every ping is answered, `event` and `gap` frames print as NDJSON, and after any drop it reconnects from the last cursor of each subscription. It exits 1, without reconnecting, on `replaced (4410)` (another program took the key's connection), on `HTTP 401` / `4401`, and on a refused subscription. The CLI keeps no channel list: the server decides what each path serves, including the live candles (`stream hl --channel hl.candles --filter coin=BTC --filter interval=1m`) that replace `wss://data.vike.io/v1/stream`. `--filter` sends `true` / `false` as a yes/no. A replay the server cannot read (`catchup_unavailable`) is retried after 1, 2, 4, 8 and 15 s, then the subscription continues from now and names the skipped window; a reconnect after an open connection waits 1 s; a full stdout pauses the socket (pings are still answered); a closed pipe (`| head`) ends with exit 0. New dependency: `ws`.
+  - `vike-data stream info`, `stream check <channel>` (the server's own validator, exit 1 when it refuses), `stream events <channel>` (stored events, 3 days) and `stream connections` (your recent connections) use the stream's MCP tools and open no socket.
+  - `vike-data search <q>`: the vike.io search over tokens, wallets and entities, Hyperliquid traders, vaults and builders, Polymarket wallets and markets.
+  - `vike-data hl`: `cohort-metrics`, `segments`, `wallet`, `wallet-activity`, `wallet-trades`, `leaderboard`, `liquidations`, `market` (with the `hourly` panel), `orders`, `twaps`, `ledger`, `leverage-changes`, `stats`, `hype-holders`, `builders`, `vaults`, `vault`, `archive`; a tool with several views takes `--view`.
+  - `polymarket markets` takes `--view search --query ...` and `--view market --condition-id ...`; `token transfers` takes `--hide-contracts`; `candles hl` takes `--view export` and `--view latest` (the newest bar of every symbol; no symbol, window or limit is sent with it), and sends only the flags given; `perp top-traders --size` now defaults to 20 (max 100) and `perp find-position --limit` to 50 (max 500), as the server tools do, and `--sort` lists `account_value`, `long_pnl`, `short_pnl`. 68 of the server's 70 MCP tools now have a command; `perp_open_interest` and `perp_long_short` are reached with `call`.
+  - `vike-data polymarket`: `market-trades`, `tape`, `orderbook`, `market-stats`, `settlement`, `settlements`, `archive`, `leaderboard`. `vike-data wallet`: `first-funder`, `exchange-usage`.
+  - `vike-data alerts`: `events`, `resend`, `rotate-secret`, `test-webhook`; `create` and `edit` take `--type` (transfer and the five Hyperliquid types), `--address` / `--address-role`, `--wallet`, `--actions`, `--pnl-cohorts`, `--size-cohorts`, `--index`, `--threshold`, `--band`, `--direction`. `--chain` takes eth, bsc, base or hyperevm and no longer defaults to eth on the client (a Hyperliquid alert refuses a chain; the server still defaults a transfer alert to eth). Discord is gone from `--channel`: the server refuses it.
+  - `vike-data whoami` is registered. `doctor` checks Node >= 22.12.0, the `engines` floor. The User-Agent carries the installed version (it said `vike-cli/dev` outside `npm run`) and is sent on `tools/list` and `initialize` too. The `sync-schema` npm script, whose file never existed, is gone.
+  - Skills: a new `vike-stream` skill (32 in all); the umbrella routes the new commands, streams and `call`, and no longer tells agents to deny WebSockets, per-address alerts or a per-wallet Hyperliquid tool; the alert skills cover the Hyperliquid types, address alerts, four chains and no Discord; the webhook check accepts either signature during a secret rotation.
+
 ## 0.14.0
 
 ### Minor Changes

package/README.md

@@ -12,8 +12,8 @@
 positions, fills, funding, liquidations, candles, and hourly long/short positioning by wallet
 cohort), **Polymarket** (markets, the trade and event tape, order-book snapshots, candles and
 on-chain settlements, plus a daily Parquet archive of the full L2 order book since 2026-07-25,
-licensed CC BY 4.0), and **labelled EVM wallets** on Ethereum and BNB Chain, with Base for token
-transfers. The same data is served three ways: an **MCP server** at `https://data.vike.io/mcp` (the one
+licensed CC BY 4.0), and **labelled EVM wallets** on Ethereum and BNB Chain, with Base and HyperEVM
+for the wallet and token tools. The same data is served three ways: an **MCP server** at `https://data.vike.io/mcp` (the one
 this CLI calls), a **REST API** at `https://data.vike.io/v1/`, and the **Parquet archive** at
 `https://data.vike.io/archive/`. A key allows 20,000 requests an hour, and an account can hold up
 to 5 keys; archive downloads are not counted. The archive manifest and a sample market need no key
@@ -55,7 +55,8 @@ The key is read from `VIKE_API_KEY` first, then from `~/.vike/config.json`
 | **Polymarket up/down families** (archive) | The same archive cut per market family, `asset=btc/tenor=5m` and so on, with an `asset=other/tenor=other` catch-all | free key | [polymarket-updown-markets](https://vike.io/data/polymarket-updown-markets) |
 | **Polymarket API** `/v1/polymarket` | Markets, the raw event and trade tape (about 30 days back), order-book snapshots, candles, on-chain settlements | free key | [polymarket](https://vike.io/data/polymarket) |
 | **Hyperliquid cohorts** `/v1/hyperliquid/coins/{coin}/cohort-metrics` | Long vs short per cohort, hourly, up to 8,760 hours in one request. Axes: `size` (account value, shrimp to 4x whale), `tier` (position notional), `pnl` (realized-PnL percentile), `pnl_abs` (PnL in dollars). `labelBasis=point_in_time` grades each hour with the label it had then (from 2026-04-07). | free key | [hl-cohorts](https://vike.io/data/hl-cohorts) |
-| **Hyperliquid API** `/v1/hyperliquid` | Trader rankings and leaderboards, 5-minute position snapshots kept for a year, wallet fills, funding and ledger, liquidations (inferred from snapshots), builders, candles since the start of 2026; closed bars also stream on `wss://vike.io/v1/stream` | free key | [hyperliquid](https://vike.io/data/hyperliquid) |
+| **Hyperliquid API** `/v1/hyperliquid` | Trader rankings and leaderboards, 5-minute position snapshots kept for a year, wallet fills, funding and ledger, liquidations (inferred from snapshots), builders, candles since the start of 2026; closed bars also stream live as the `hl.candles` channel of `wss://stream.vike.io/v1/stream/hl` | free key | [hyperliquid](https://vike.io/data/hyperliquid) |
+| **Event streams** `wss://stream.vike.io/v1/stream/<path>` | Live events with a resume cursor on four paths: `hl` (fills, liquidations, positions, liquidation risk, order walls, candles, TWAPs, ledger, leverage changes, funding), `hl-cohorts` (cohort flow, indices, cohort bias), `onchain` (transfers on eth, bsc, base, hyperevm), `polymarket` (trades, resolutions, price moves, new markets). `vike-data stream` reads them; `vike-data stream info` lists every channel and filter. Connections are not counted against the hourly limit. | free key | [stream channels](https://vike.io/docs/data/reference/stream-channels) |
 | **On-chain API** `/v1/onchain` | Wallet summaries, transactions, counterparties, PnL, address labels with per-source provenance, token holders and transfers. Ethereum on every route, BNB Chain on the wallet and token-flow routes, Base on token transfers. | free key | [onchain](https://vike.io/data/onchain) |
 
 Direct links that need no key:
@@ -137,21 +138,34 @@ Every data command is one `tools/call` to the MCP server. `vike-data <group> --h
 
 | Command | Subcommands | MCP tool |
 |---|---|---|
-| `vike-data token` | `search`, `transfers`, `screener`, `holders` (`--chain ethereum\|bsc\|base`) | `token_search`, `token_transfers`, `token_screener`, `token_holders` |
-| `vike-data wallet` | `summary`, `transactions` (`txs`), `compare`, `trace`, `batch`, `counterparties`, `pnl-history`, `balances`, `ens`, `discover` | `wallet_summary`, `wallet_transactions`, `wallet_compare`, `wallet_trace`, `wallet_batch_labels`, `wallet_counterparties`, `wallet_pnl_history`, `wallet_token_balances`, `wallet_ens`, `wallet_discover` |
+| `vike-data token` | `search`, `transfers`, `screener`, `holders` (`--chain ethereum\|bsc\|base\|hyperevm`) | `token_search`, `token_transfers`, `token_screener`, `token_holders` |
+| `vike-data wallet` | `summary`, `transactions` (`txs`), `compare`, `trace`, `batch`, `counterparties`, `pnl-history`, `balances`, `ens`, `discover`, `first-funder`, `exchange-usage` | `wallet_summary`, `wallet_transactions`, `wallet_compare`, `wallet_trace`, `wallet_batch_labels`, `wallet_counterparties`, `wallet_pnl_history`, `wallet_token_balances`, `wallet_ens`, `wallet_discover`, `wallet_first_funder`, `wallet_exchange_usage` |
 | `vike-data labels <address>` | multi-source label provenance for one wallet | `wallet_label_provenance` |
 | `vike-data perp` | `top-traders`, `find-position` (Hyperliquid); `funding`, `spreads` (cross-venue funding rates and perp-vs-perp price gaps) | `hl_perp_top_traders`, `hl_position_match`, `perp_funding`, `perp_spreads` |
-| `vike-data candles` | `hl <symbol>` (Hyperliquid perp or spot, from executed fills), `polymarket <token_id>` (one outcome token) | `hl_ohlcv`, `polymarket_ohlcv` |
-| `vike-data polymarket` (`pm`) | `markets`, `market <condition_id>`, `wallet <address>`, `smart-money` | `polymarket_markets`, `polymarket_market_detail`, `polymarket_wallet`, `polymarket_smart_money` |
-| `vike-data alerts` | `list`, `channels`, `create`, `edit`, `delete`, `register-webhook` (email, Discord, or an HTTPS webhook, HMAC-signed when you set a secret) | `alerts_*` |
-| setup | `init`, `login`, `logout`, `doctor`, `schema`, `install` | — |
-
-Output is a table on a terminal and JSON with `--json` or whenever stdout is piped:
+| `vike-data hl` | `cohort-metrics <symbol>`, `segments`, `wallet <address>`, `wallet-activity <address>`, `wallet-trades <address>`, `leaderboard`, `liquidations`, `market`, `orders`, `twaps`, `ledger`, `leverage-changes`, `stats`, `hype-holders`, `builders`, `vaults`, `vault <vault>`, `archive`; a tool with several views takes `--view` | `hl_cohort_metrics`, `hl_segments`, `hl_wallet`, `hl_wallet_activity`, `hl_wallet_trades`, `hl_leaderboard`, `hl_liquidations`, `hl_market`, `hl_orders`, `hl_twaps`, `hl_ledger`, `hl_leverage_changes`, `hl_stats`, `hl_hype_holders`, `hl_builders`, `hl_vaults`, `hl_vault`, `hl_archive` |
+| `vike-data candles` | `hl <symbol>` (Hyperliquid perp or spot, from executed fills; `--view export`, or `--view latest` for the newest bar of every symbol), `polymarket <token_id>` (one outcome token); live bars: `stream hl --channel hl.candles` | `hl_ohlcv`, `polymarket_ohlcv` |
+| `vike-data polymarket` (`pm`) | `markets`, `market <condition_id>`, `wallet <address>`, `smart-money`, `leaderboard`, `market-trades <condition_id>`, `tape`, `orderbook <token_id>`, `market-stats <token_id>`, `settlement <condition_id>`, `settlements`, `archive` | `polymarket_markets`, `polymarket_market_detail`, `polymarket_wallet`, `polymarket_smart_money`, `polymarket_leaderboard`, `polymarket_market_trades`, `polymarket_tape`, `polymarket_orderbook`, `polymarket_market_stats`, `polymarket_settlement`, `polymarket_settlements_bulk`, `polymarket_archive` |
+| `vike-data alerts` | `list`, `channels`, `create`, `edit`, `delete`, `events`, `resend`, `register-webhook`, `test-webhook`, `rotate-secret`: transfer alerts (a token or one wallet, on eth, bsc, base, hyperevm) and Hyperliquid alerts (`--type hl_wallet`, `hl_cohort_fill`, `hl_liquidation`, `hl_cohort_bias`, `hl_liq_proximity`), by email or an HTTPS webhook, HMAC-signed | `alerts_*` |
+| `vike-data stream <path>` | live events from `wss://stream.vike.io/v1/stream/<path>` (`hl`, `hl-cohorts`, `onchain`, `polymarket`) as NDJSON: `--channel` (one or more), `--filter key=value`, `--cursor` | WebSocket, not MCP |
+| `vike-data stream` | `info`, `check <channel>` (the server's validator), `events <channel>` (stored events, 3 days), `connections` (yours) | `stream_info`, `stream_check_filter`, `stream_events`, `stream_connections` |
+| `vike-data search <q>` | tokens, wallets and entities, HL traders, vaults, builders, Polymarket wallets and markets by name, symbol, address or ENS name | `search` |
+| `vike-data call <tool>` | any MCP tool by name: `--args '{json}'` or `--args-file`, `--timeout`; prints the raw result | any |
+| setup | `init`, `login`, `logout`, `whoami`, `doctor`, `schema`, `install` | — |
+
+Output is a table on a terminal and JSON with `--json` or whenever stdout is piped. A tool that refuses its input
+exits 1 in every mode:
 
 ```bash
 vike-data token search BTC --json | jq '.'
+vike-data call hl_wallet --args '{"address":"0x...","view":"trades_summary","window":"30d"}'
+vike-data stream hl --channel hl.fills --filter coin=BTC --filter min_usd=100000
 ```
 
+`vike-data stream` answers the server's pings, prints `event` and `gap` frames as they arrive (status on stderr), and
+after any drop reconnects from the last cursor of each subscription. On each path one key holds one connection: a
+second program on the same key takes over, and the first exits with `replaced (4410)` instead of reconnecting. Give
+each program its own key.
+
 ## Examples
 
 [`examples/`](examples/) holds three Python scripts. Each declares its dependencies inline, so
@@ -173,10 +187,14 @@ Downloads go to `./vike-archive/`.
 
 ## For AI agents
 
-This package ships **31 skill playbooks** under [`skills/`](skills/): markdown files an AI coding
+This package ships **47 skill playbooks** under [`skills/`](skills/): markdown files an AI coding
 agent loads so it knows when and how to call each command. [`skills.sh.json`](skills.sh.json) groups
-them by domain (Tokens, Wallets, CEX perps, Hyperliquid perps, Candles, Polymarket, Alerts). The
-entry point is the umbrella skill `vike`, which routes a question to the specialised skill.
+them by domain (Quick start, Tokens, Wallets, CEX perps, Hyperliquid perps, Candles, Polymarket, Alerts, Live streams). The
+entry point is the umbrella skill `vike`, which routes a question to the specialised skill. Per-tool
+skills read one command; the workflow playbooks chain several: who a wallet is, where its money went,
+whether two wallets are related, token holder diligence and the smart-money trend, Hyperliquid cohort
+positioning and how to backtest it, one trader's profile, a symbol briefing, liquidation risk, builder
+codes, perp crowding, a Polymarket market's due diligence, the free L2 archive, a cross-market daily brief.
 
 ```bash
 npx skills add vike-io/vike-data-cli --list    # see them first

package/package.json

@@ -3,7 +3,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "0.14.0",
+  "version": "0.16.0",
   "description": "CLI, agent skills and MCP client for the free Vike Data API: a Polymarket full-L2 order-book archive in Parquet (CC BY 4.0), Hyperliquid positions, fills and cohorts, and labelled Ethereum/BNB wallets",
   "type": "module",
   "main": "src/index.js",
@@ -28,8 +28,7 @@
     "lint:fix": "eslint . --fix",
     "changeset": "changeset",
     "changeset:version": "changeset version",
-    "changeset:publish": "changeset publish",
-    "sync-schema": "node scripts/sync-schema.js"
+    "changeset:publish": "changeset publish"
   },
   "keywords": [
     "vike",
@@ -68,7 +67,8 @@
     "node": ">=22.12.0"
   },
   "dependencies": {
-    "commander": "^15.0.0"
+    "commander": "^15.0.0",
+    "ws": "^8.22.1"
   },
   "devDependencies": {
     "@changesets/cli": "^3.0.3",

package/skills/vike/SKILL.md

@@ -7,7 +7,7 @@ description: "Use this skill whenever the user asks any question about on-chain
 
 This skill is for anyone who asks an AI agent about crypto data: who is buying a token, what a wallet holds, what Hyperliquid or Polymarket traders are doing right now. It tells the agent which vike tool answers which question and how to read the result, so it does not guess or invent numbers. It reads its data from vike.io and needs a free vike API key.
 
-What the platform has: wallet and token analytics on Ethereum and BSC, with Base for token transfers and labels (each tool's chain list is under "What each tool really returns"), multi-source wallet labels, CEX perpetual funding and cross-venue spreads, Hyperliquid top traders / share-card lookup / candles, Polymarket markets, traders and smart-money signals, and transfer alerts. 31 tools in one MCP server.
+What the platform has: wallet and token analytics on Ethereum, BSC, Base and HyperEVM (each tool's chain list is under "What each tool really returns"), multi-source wallet labels, CEX perpetual funding and cross-venue spreads, Hyperliquid wallets, cohorts, leaderboards, liquidations, markets, builders, vaults and candles, Polymarket markets, traders, tape, order books, settlements and the Parquet archive, transfer and Hyperliquid alerts, and live event streams over WebSocket. 70 tools in one MCP server.
 
 **MCP endpoint for all calls:** `https://data.vike.io/mcp` (JSON-RPC 2.0)
 **Or use the CLI:** `npm install -g @vike-io/cli` → `vike-data <command>`
@@ -25,12 +25,12 @@ Hard rules — agents that violate these produce wrong answers. Read once, apply
 1. **Addresses are always full 0x-hex (42 chars).** Never truncate when querying. Never display truncated when the user asks for the address — they'll copy-paste it.
 2. **Perp and Hyperliquid symbols are upper-cased by the server.** Echo back what the user wrote.
 3. **Windows are counted in UTC calendar days, not a rolling 24 hours.** On the token screener `24h` spans yesterday and today; on Hyperliquid `30d` is today plus the previous 30 days.
-4. **Page sizes are small and differ per tool; there is no paging.** Max 20: `wallet_discover` (`size`), `hl_perp_top_traders` (`size`), `polymarket_smart_money`. Max 30: `polymarket_markets`. Max 50: `token_holders`, `wallet_counterparties`, `wallet_compare`, `hl_position_match`. Max 100: `token_screener`, and 100 addresses for `wallet_batch_labels`. Max 500: `wallet_transactions`. `token_transfers` has no limit: it always returns 10 rows. To go deeper, narrow the filter or the window instead of asking for more rows.
-5. **Refresh differs per tool; never promise "minutes".** `wallet_discover` and `wallet_summary` are rebuilt nightly, so a wallet active an hour ago may not show. Transfers are synced block by block. `hl_position_match` only matches positions seen within 15 minutes of the newest snapshot batch. Alerts are checked on a cron, not streamed.
+4. **Page sizes are small and differ per tool; these have no paging.** Max 20: `wallet_discover` (`size`), `polymarket_smart_money`. Max 30: `polymarket_markets`. Max 50: `token_holders`, `wallet_counterparties`, `wallet_compare`. Max 100: `token_screener`, `hl_perp_top_traders` (`size`), and 100 addresses for `wallet_batch_labels`. Max 500: `wallet_transactions`, `hl_position_match`. `token_transfers` has no limit: it always returns 10 rows. To go deeper, narrow the filter or the window instead of asking for more rows. The `hl` commands, `polymarket market-trades`, `tape`, `settlements` and `alerts events` DO page: pass the answer's next cursor back with `--cursor`.
+5. **Refresh differs per tool; never promise "minutes".** `wallet_discover` and `wallet_summary` are rebuilt nightly, so a wallet active an hour ago may not show. Transfers are synced block by block. `hl_position_match` only matches positions seen within 15 minutes of the newest snapshot batch. For events as they happen use `vike-data stream` (`vike-stream`).
 6. **USD amounts are floats in dollars.** `--min-usd 10000` = ten thousand dollars, not micro-USD.
 7. **`--json` is always available** on CLI commands and gives stable machine-readable output. The default (human) format may change; `--json` will not.
 8. **Resolve a token before asking transfer/holder questions.** `token_search` → take the canonical address → pass it to `token_transfers` / `token_holders`. Symbol-only queries lose precision on tickers that collide across chains (e.g. FUN, BEAM, USDC).
-9. **`bought` in `token_transfers` is every inbound transfer**, flash-loan round trips included. Read `net_tokens` (bought − sold) before calling a wallet a buyer.
+9. **`token_transfers` lists the top 10 NET buyers (`tab=bought`) or net sellers, ranked by net USD**, and a net buyer's `net_usd` is negative. A row can still be a pool, vault or router: `--hide-contracts` leaves out the contracts we know of.
 
 ---
 
@@ -77,10 +77,15 @@ Pick by the question, then read the named skill for the recipe and the traps. If
 | Who bought / sold a token (top 10, one side per call) | `vike-data token transfers` / `token_transfers` | `vike-token-transfers` |
 | "Research token X" end to end | search → transfers (both tabs) | `vike-token-research` |
 | Top holders of a token (ranked by net inflow, not balance) | `vike-data token holders` / `token_holders` | `vike-token-holders` |
+| Holder quality: largest balances, share of supply, exchanges / contracts / fresh / flagged wallets | `call token_holders` (`sort: "balance"`) → `wallet batch` | `vike-token-holder-diligence` |
 | Tokens trending / with the biggest inflow / smart-money inflow | `vike-data token screener` / `token_screener` | `vike-token-screener` |
 | "Is smart money buying X?" / alpha wallets | screener `--smart-money-only` → transfers | `vike-smart-money-discovery` |
+| Is smart money entering, holding or exiting X over 24h / 7d / 30d / 90d | screener at four windows, differenced | `vike-token-smart-money-trend` |
 | One wallet's volume / inflow / outflow / tx count by window | `vike-data wallet summary` / `wallet_summary` | `vike-wallet-summary` |
-| Full picture of one wallet ("who is this", "everything about it") | several calls | `vike-wallet-portfolio` |
+| Who is this address, is it an exchange, which exchanges does it use, who funded it | `search` → `labels` → `wallet summary` → `wallet exchange-usage` → `wallet counterparties` | `vike-wallet-who-is` |
+| Full picture of one wallet (holdings, flows, counterparties) | several calls | `vike-wallet-portfolio` |
+| Where did the money go, did it reach an exchange (exploit, scam) | `call wallet_trace` (`direction: "out"`) → `wallet txs` → `wallet batch`; `stream onchain` | `vike-follow-the-money` |
+| Do these wallets share an owner, find a wallet's siblings | `labels` → `wallet first-funder` → `wallet compare` → `wallet trace` | `vike-wallets-related` |
 | Top wallets by volume / flow / tx count | `vike-data wallet discover` / `wallet_discover` | `vike-wallet-discover` |
 | Individual transfers of a wallet | `vike-data wallet transactions` / `wallet_transactions` | `vike-wallet-transactions` |
 | Who a wallet trades with | `vike-data wallet counterparties` / `wallet_counterparties` | `vike-wallet-counterparties` |
@@ -92,32 +97,50 @@ Pick by the question, then read the named skill for the recipe and the traps. If
 | Label many addresses (up to 100) | `vike-data wallet batch` / `wallet_batch_labels` | `vike-wallet-batch` |
 | Why is this wallet labelled X (sources) | `vike-data labels <address>` / `wallet_label_provenance` | `vike-wallet-label-provenance` |
 | Funding rates, funding arb, one symbol across venues | `vike-data perp funding` / `perp_funding` | `vike-perp-funding` |
-| Cross-venue price spread, "perp market overview" | `vike-data perp spreads` + `perp funding` + `perp top-traders` | `vike-perp-overview` |
-| Top Hyperliquid traders; "is this HL address any good" | `vike-data perp top-traders` / `hl_perp_top_traders` | `vike-hl-top-traders` |
+| Cross-venue price spread, "perp market overview"; CEX open interest or long/short of one symbol | `vike-data perp spreads` + `perp funding` + `perp top-traders`; `call perp_open_interest`, `call perp_long_short` | `vike-perp-overview` |
+| Is X crowded: funding, open interest net of price, long/short per venue | `perp funding` + `call perp_open_interest` + `call perp_long_short` + `candles hl` | `vike-perp-crowding` |
+| Top Hyperliquid traders; the full leaderboard | `vike-data perp top-traders` / `hl_perp_top_traders`; `vike-data hl leaderboard` | `vike-hl-top-traders` |
 | HL share card → which wallet holds it | `vike-data perp find-position` / `hl_position_match` | `vike-hl-position-match` |
-| Candles: Hyperliquid perp/spot, Polymarket outcome token | `vike-data candles hl` / `candles polymarket` | `vike-candles` |
+| One HL wallet: equity, positions, cohorts, risk, closed trades, funding, ledger, orders, liquidations | `vike-data hl wallet`, `hl wallet-trades`, `hl wallet-activity` | `vike-hl-trader-profile` |
+| Are whales / smart money long or short X (HL cohorts) | `vike-data hl cohort-metrics <symbol>`, `hl segments`, `hl market --view indices` | `vike-hl-cohort-positioning` |
+| Did cohort positioning lead price (a backtest without look-ahead) | `hl cohort-metrics --label-basis point_in_time` + `candles hl` | `vike-hl-cohort-backtest` |
+| Brief on one HL symbol: price, funding, OI, cohorts, liquidations | several `hl` calls + `perp funding` | `vike-hl-asset-briefing` |
+| Liquidation risk by symbol, liquidation heatmap, recent or live liquidations | `vike-data hl liquidations`; `stream hl --channel hl.liq_risk hl.liquidations` | `vike-hl-liquidation-radar` |
+| Builder codes: fees, users, routed share | `vike-data hl builders` | `vike-hl-builder-intel` |
+| HL open interest, vaults | `vike-data hl market`, `hl vaults`, `hl vault` | this skill |
+| HL orders and order clusters, TWAPs, the ledger, leverage changes, closed trades, venue stats, HYPE holders, the Parquet archive | `vike-data hl orders`, `hl twaps`, `hl ledger`, `hl leverage-changes`, `hl wallet-trades`, `hl stats`, `hl hype-holders`, `hl archive` | this skill |
+| A name, symbol, address, ENS name or polymarket.com link → what it is | `vike-data search <q>` / `search` | this skill |
+| Candles: Hyperliquid perp/spot (history, or the newest bar of every symbol), Polymarket outcome token; live HL bars | `vike-data candles hl` (`--view latest`), `candles polymarket`; `stream hl --channel hl.candles` | `vike-candles` |
 | Trending Polymarket markets (by 24h volume) | `vike-data polymarket markets` / `polymarket_markets` | `vike-polymarket-markets` |
 | One Polymarket market | `vike-data polymarket market <condition_id>` / `polymarket_market_detail` | `vike-polymarket-market-detail` |
 | One Polymarket trader | `vike-data polymarket wallet` / `polymarket_wallet` | `vike-polymarket-trader` |
 | Polymarket smart-money flows / mispricings / overview | `vike-data polymarket smart-money` / `polymarket_smart_money` | `vike-polymarket-smart-money` |
-| Alerts: create / list / edit / delete | `vike-data alerts ...` / `alerts_*` | `vike-alerts-setup` |
-| Alert delivery to an HTTPS webhook | `vike-data alerts register-webhook` | `vike-alerts-webhook` |
+| Polymarket wallet leaderboard | `vike-data polymarket leaderboard` / `polymarket_leaderboard` | this skill |
+| One market's liquidity, trades with wallets, raw tape, order book, tape stats, on-chain resolution | `vike-data polymarket market-trades`, `tape`, `orderbook`, `market-stats`, `settlement` | `vike-pm-market-diligence` |
+| Many resolutions; the Parquet L2 archive | `vike-data polymarket settlements`, `archive` | `vike-pm-l2-archive` |
+| Who funded a wallet; which exchanges it uses | `vike-data wallet first-funder`, `wallet exchange-usage` | `vike-wallet-who-is` |
+| A daily brief across perps, Hyperliquid, Polymarket and on-chain | several calls, cheap first | `vike-daily-brief` |
+| Find Polymarket markets by slug, or one by condition_id | `vike-data polymarket markets --view search --query btc-updown` / `--view market --condition-id 0x...` | this skill |
+| Alerts: create / list / edit / delete / events (transfer and Hyperliquid) | `vike-data alerts ...` / `alerts_*` | `vike-alerts-setup` |
+| Alert delivery to an HTTPS webhook | `vike-data alerts register-webhook`, `test-webhook`, `rotate-secret` | `vike-alerts-webhook` |
+| Live events: HL fills, liquidations, positions, candles, TWAPs, ledger, leverage, funding, cohort flow and bias; on-chain transfers; Polymarket trades and new markets | `vike-data stream <hl\|hl-cohorts\|onchain\|polymarket> --channel ...`; `stream info`, `check`, `events`, `connections` | `vike-stream` |
+| A tool with no command of its own | `vike-data call <tool> --args '{...}'` | this skill |
 | Install, auth, errors, conventions | — | `vike-core` |
 
 **When in doubt, start with `vike-data token search` or `vike-data wallet summary`.** Both are cheap and disambiguate what the user actually meant.
 
 ### Example query routing
 ```
-"Who bought the most PEPE in the last 24h?"          → token_search, then token_transfers (tab=bought, period=24h; 10 rows; rank by net_tokens)
+"Who bought the most PEPE in the last 24h?"          → token_search, then token_transfers (tab=bought, period=24h; the top 10 net buyers)
 "What is 0xd8dA6BF...AbA96 holding?"                  → wallet_token_balances   (+ wallet_summary for flows)
 "Funding rate for BTC across all perp venues"         → perp_funding            (symbol=BTC; raw per-interval rates)
 "Which venue pays the most funding on ETH?"           → perp_funding            (symbol=ETH, normalise to daily yourself)
 "Biggest HL perp PnL last week"                       → hl_perp_top_traders     (window=7d, sort=pnl)
 "What are the hottest crypto prediction markets?"     → polymarket_markets      (category=Crypto) → polymarket_market_detail
 "Why is 0x28C6... labeled 'Binance hot wallet'?"      → wallet_label_provenance (address=0x28C6...)
-"What is the ENS name of 0xd8dA6BF...?"               → wallet_ens              (address=0xd8dA...; name → address is NOT supported)
+"What is the ENS name of 0xd8dA6BF...?"               → wallet_ens              (address=0xd8dA...; name → address is `search`)
 "Alert me on WBTC transfers over $1M"                 → alerts_create           (token_symbol=WBTC, min_value_usd=1000000; fires on ANY such transfer)
-"Trace funds from 0xHACKER 3 hops out"                → wallet_trace            (address=0xHACKER, depth=3)
+"Trace funds from 0xHACKER 3 hops out"                → wallet_trace            (address=0xHACKER, depth=3, direction=out)
 ```
 
 ---
@@ -132,7 +155,12 @@ vike-data wallet summary 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 --json
 vike-data perp funding --symbol BTC --json
 ```
 
-**B) Via an MCP connector (recommended when your client has one).** All 31 tools live at `https://data.vike.io/mcp`. Connect the client to that address with the `X-API-KEY` header above, then call a tool by name with its arguments, for example `wallet_summary` with `address` set to a full 0x address.
+Any MCP tool, including one with no command of its own, is one `call` away; it prints the tool's raw JSON and exits 1 when the tool refuses the input:
+```bash
+vike-data call hl_wallet --args '{"address":"0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045","view":"summary"}'
+```
+
+**B) Via an MCP connector (recommended when your client has one).** All 70 tools live at `https://data.vike.io/mcp`. Connect the client to that address with the `X-API-KEY` header above, then call a tool by name with its arguments, for example `wallet_summary` with `address` set to a full 0x address.
 
 Run `vike-data schema --pretty` (or call MCP `tools/list`) to see the live arg shape for every tool. Always read the schema before constructing arguments — defaults and enum values change.
 
@@ -144,67 +172,79 @@ Run `vike-data schema --pretty` (or call MCP `tools/list`) to see the live arg s
 | Tool | Returns | Not |
 |---|---|---|
 | `token_search` | symbol, name, address, logo for a query | no market cap |
-| `token_transfers` | 10 wallets, one side (`tab` = `bought` or `sold`) per call, period 1h/24h/7d/30d: `address, bought, sold, net_tokens, usd_spent, usd_received, net_usd, chains` | no `--min-usd`; window ends at the token's newest priced row; a net seller has `net_usd > 0` |
-| `token_holders` | wallets ranked by cumulative net inflow USD, with entity/type | not balances, no concentration metric |
+| `token_transfers` | the top 10 net buyers (`tab=bought`) or net sellers, ranked by net USD, period 1h/24h/7d/30d: `address, bought, sold, net_tokens, usd_spent, usd_received, net_usd, chains`; `hide_contracts` drops known pools and routers | no `--min-usd`; window ends at the token's newest priced row; a net seller has `net_usd > 0` |
+| `token_holders` | wallets ranked by cumulative net inflow USD, with entity/type; `sort: "balance"` (via `call`) ranks by on-chain balance and adds `balance`, `value_usd`, `supply_pct` | the balance ranking covers candidate wallets, not every holder, and not every chain |
 | `token_screener` | per-token volume, net/in/out USD, `unique_holders` (wallets ACTIVE in the window, not growth), tx count | no age, liquidity or sector filter; no ascending sort; native coin shows as `0x000…000`; `symbol` is often blank |
 
 ### Wallets
 | Tool | Returns | Not |
 |---|---|---|
-| `wallet_summary` | a dict keyed `all, 90d, 30d, 7d, 24h`, each with `total_volume, total_inflow, total_outflow, net_flow, tx_count, tokens_traded, first_seen, last_active`, for ONE chain (the most recently active; never summed) | no PnL, holdings or labels |
-| `wallet_discover` | `{wallets, total}` ranked by volume / inflow / outflow / net_flow / tx_count / pnl (`size` ≤ 20; ethereum, bsc) | `realized_pnl` is a ranking key only, not a dollar figure; no labels column |
+| `wallet_summary` | a dict keyed `all, 90d, 30d, 7d, 24h`, each with `total_volume, total_inflow, total_outflow, net_flow, tx_count, tokens_traded, first_seen, last_active`, for ONE chain, named in `chain` (the more recently active of ethereum and bsc; never summed) | no PnL, holdings or labels; the command has no `--chain`: `call wallet_summary` with `chain` asks one chain |
+| `wallet_discover` | `{wallets, total}` ranked by volume / inflow / outflow / net_flow / tx_count / pnl (`size` ≤ 20) | `realized_pnl` is a ranking key only, not a dollar figure; no labels column; base and hyperevm serve `window=all` reliably |
 | `wallet_transactions` | single transfers, newest first | no aggregates |
 | `wallet_compare` | shared counterparties + shared tokens of exactly two wallets | not 3+ wallets |
-| `wallet_trace` | nodes + edges; direction lives in each edge's `out_usd` / `in_usd` | `from` is the side expanded first, not the sender |
+| `wallet_trace` | nodes + edges; direction lives in each edge's `out_usd` / `in_usd`; `direction` `out` / `in` (via `call`) expands by where money went / came from | `from` is the side expanded first, not the sender |
 | `wallet_counterparties` | top partners with sent/received USD and labels | |
 | `wallet_pnl_history` | daily net inflow USD (a proxy) | not realized PnL |
-| `wallet_token_balances` | holdings read from the chain at request time (ethereum, bsc); native coin is a row with `usd_value: null` | not a DeFi-position view |
-| `wallet_ens` | name for an address, or `null` | no name → address |
-| `wallet_batch_labels` | entity, type, risk flag + 30-day flow fields per address, in input order | on `bsc` the 30-day fields are `null` |
+| `wallet_token_balances` | holdings read from the chain at request time; the native coin is always listed | not a DeFi-position view; on base and hyperevm only mapped and priced tokens unless `min_usd=0` |
+| `wallet_ens` | name for an address, or `null` | no name → address here (`vike-data search <name.eth>` searches the address a name points to) |
+| `wallet_batch_labels` | entity, type, risk flag + 30-day flow fields per address, in input order, from that chain's tables | the 30-day fields are `null` for an address with no label |
+| `wallet_first_funder`, `wallet_exchange_usage` | the earliest inbound coin and token transfers with the senders' labels; the exchanges a wallet sent to and received from | not proof of who funded it or owns it |
 
-Chains: most token and wallet tools accept `chain` = `ethereum` | `bsc` | `base`, but Base coverage is narrower: it is documented for token transfers and `wallet_batch_labels`, while the per-wallet transfer tools (`wallet_transactions`, `wallet_counterparties`, `wallet_trace`, `wallet_compare`, `wallet_pnl_history`) are documented for Ethereum and BSC. `wallet_discover` takes `ethereum` | `bsc`, `wallet_token_balances` serves `ethereum` | `bsc` (anything else lands in `chain_errors`) and alerts take `eth` | `bsc`. `token_screener` smart-money mode and `smart_inflow` sort are `ethereum` only (a 400 elsewhere). `wallet_label_provenance` is for Ethereum wallets. Arbitrum, Bitcoin, Solana, Tron and other non-EVM chains are not served. When a chain is not covered, say so; an empty Base result means "not covered", not "no activity".
+Chains: every token and wallet tool takes `chain` = `ethereum` | `bsc` | `base` | `hyperevm` (default ethereum; `token_transfers` also `all`), and `wallet_token_balances` scans all four by default. Exceptions: `token_screener` smart-money mode and `smart_inflow` sort are `ethereum` only (a 400 elsewhere); `wallet_label_provenance` reads the Ethereum label table; labels are sparse on hyperevm; alerts and the stream spell Ethereum `eth`. Arbitrum, Bitcoin, Solana, Tron and other non-EVM chains are not served: say so.
 
 ### Labels
-`wallet_label_provenance` returns the raw source labels (at most 6 sources plus our heuristic classifier) and a consensus entity/type. When an answer hinges on "is this really a CEX hot wallet?", call it rather than trusting one source. `found: false` means the wallet is missing from our labelled-wallet table and no source is consulted at all, so it is not proof that nobody labels it, and it is not proof the wallet is clean.
+`wallet_label_provenance` returns the raw source labels (at most 6 sources plus our heuristic classifier) and a consensus entity/type. When an answer hinges on "is this really a CEX hot wallet?", call it rather than trusting one source. Every source is read on every call, and `found` is true when ANY source knows the address; `found: false` means none does and the wallet is not in our label table. It is not proof the wallet is clean.
 
 ### CEX perps
 | Tool | Returns |
 |---|---|
 | `perp_funding` | with `symbol`: raw per-venue `funding_rate` + `interval_h` (daily % = rate × 24 / interval_h × 100); without: up to 5 pre-ranked arb rows (`long_exchange`, `short_exchange`, `spread_daily_pct`) |
 | `perp_spreads` | up to 10 cross-venue price-gap rows (≥ 0.5%); `symbol` only filters that global top 10, so it is often empty |
+| `perp_open_interest` (`call`) | `oi_usd` per venue (USD notional, moves with price), newest print or an hourly series (`hours` 1-168); `stale_venues` are never in a total |
+| `perp_long_short` (`call`) | `long_share`, `short_share` (fractions), `long_short_ratio` per venue, each with its `basis` (what the venue counts); about 40 major symbols |
 
-Neither returns mark prices or bid/ask per venue. "Spread" here is perp vs perp across venues, not spot vs perp.
+These two have no command: `vike-data call perp_open_interest --args '{"symbol":"BTC","hours":24}'`. None returns mark prices or bid/ask per venue. "Spread" here is perp vs perp across venues, not spot vs perp.
 
 ### Hyperliquid
 | Tool | Returns |
 |---|---|
-| `hl_perp_top_traders` | up to 20 wallets: `total_realized_pnl`, `roi_pct`, `win_rate_pct`, `max_drawdown_pct` (all percents; 12.5 = 12.5%), `trade_count`, `total_volume`. ROI = window realized PnL / CURRENT account value; drawdown is account-level and all-time |
+| `hl_perp_top_traders` | up to 100 wallets (`size`, default 20): `total_realized_pnl`, `roi_pct`, `win_rate_pct`, `max_drawdown_pct` (all percents; 12.5 = 12.5%), `trade_count`, `total_volume`. ROI = window realized PnL / CURRENT account value; drawdown is account-level and all-time |
 | `hl_position_match` | wallets whose open position matches a share card (`symbol`, side, leverage, entry) |
 | `hl_ohlcv` | perp or spot candles |
+| `hl_wallet` (`vike-data hl wallet`) | one wallet: equity, open positions, cohort labels, risk metrics, lifetime flow; `--view trades_summary` for closed-trade stats |
+| `hl_wallet_activity` (`hl wallet-activity`) | one wallet's fills, funding, ledger or builder routing, newest first, paged with `--cursor` |
+| `hl_cohort_metrics` (`hl cohort-metrics <symbol>`) | hourly long/short notional per cohort of one symbol; `bias` is a fraction -1..+1. For a backtest pass `--label-basis point_in_time` |
+| `hl_segments` (`hl segments`) | the cohort labels (`--view cohorts`), one cohort now (`summary`), the symbol x cohort board (`heatmap`), one cohort hour by hour (`history`) |
+| `hl_leaderboard` (`hl leaderboard`) | traders on 20 metrics; `--min-win-rate` is a FRACTION here (0.6), a percent in `perp top-traders` |
+| `hl_liquidations`, `hl_market`, `hl_builders`, `hl_vaults`, `hl_vault` | liquidations / risk / heatmap; open interest, symbol series, positions, indices, large fills, an hourly panel of up to 64 symbols; builder codes; vaults |
+| `hl_orders`, `hl_twaps`, `hl_ledger`, `hl_leverage_changes` | resting orders at one instant, one wallet's orders, order clusters; the cross-wallet feeds (follow one with `--order asc` and each `nextCursor`, stop on an empty page) |
+| `hl_wallet_trades`, `hl_stats`, `hl_hype_holders`, `hl_archive` | one wallet's closed trades; hourly venue equity / open interest / volume; HYPE holders; the daily fills and positions Parquet files (`--view url` = a 7-day link) |
 
-There is no per-wallet Hyperliquid profile, no open-interest and no cohort tool in the CLI yet. Say so instead of improvising from the leaderboard.
+Every `hl` command takes `--view` (the first view is the default) and only the flags that view uses: a flag the view does not take is refused by name, not ignored.
 
 ### Candles
-`hl_ohlcv` (Hyperliquid perp or spot, 1m–1d, built from HL's own fills, also HIP-3 builder DEXs) and `polymarket_ohlcv` (ONE outcome token, price = probability 0–1, needs a `token_id`, not a condition_id). There is no candle source for CEX tickers or an arbitrary ERC-20.
+`hl_ohlcv` (Hyperliquid perp or spot, 1m–1d, built from HL's own fills, also HIP-3 builder DEXs) and `polymarket_ohlcv` (ONE outcome token, price = probability 0–1, needs a `token_id`, not a condition_id). `candles hl --view latest` is the newest 1-minute bar of every symbol; live closed bars come from `vike-data stream hl --channel hl.candles --filter coin=BTC --filter interval=1m`. There is no candle source for CEX tickers or an arbitrary ERC-20.
 
 ### Polymarket
 | Tool | Returns |
 |---|---|
 | `polymarket_markets` | markets ranked by 24h volume only (`volume_24h`, `liquidity`, `ended`, `outcomes[]` with `token_id`, `mid`, `bid`, `ask`) |
-| `polymarket_market_detail` | one market: quotes, smart-money cohort flows, top wallets, resolution status |
+| `polymarket_market_detail` | one market: outcomes with `clob_token_ids`, volume, liquidity, an hourly series per outcome, the top 30 holders per side, the last 100 trades with wallets, tape stats, resolution status; no live quote and no smart-money block |
 | `polymarket_wallet` | one trader: realized PnL, volume-weighted `hit_rate`, `resolved_markets`, positions |
 | `polymarket_smart_money` | MARKETS where the profitable-wallet cohort is flowing (`flows`) or bought below the mid (`mispricings`); not a list of top traders |
 
 ### Alerts
-Create + manage on-chain transfer alerts delivered to email, Discord or an HTTPS webhook.
+Create + manage on-chain transfer alerts and Hyperliquid alerts, delivered by email or an HTTPS webhook.
 
 | Tool | Does |
 |---|---|
 | `alerts_list`, `alerts_list_channels` | list rules / enabled channels |
-| `alerts_create`, `alerts_edit`, `alerts_delete` | manage a rule (token symbol + chain `eth`/`bsc` + USD thresholds) |
-| `alerts_register_webhook` | register an HTTPS webhook (HMAC-signed deliveries) |
+| `alerts_create`, `alerts_edit`, `alerts_delete` | manage a rule: transfer (token and/or one `address`, chain `eth`/`bsc`/`base`/`hyperevm`, USD thresholds) or Hyperliquid (`--type hl_wallet`, `hl_cohort_fill`, `hl_liquidation`, `hl_cohort_bias`, `hl_liq_proximity`) |
+| `alerts_events`, `alerts_resend_delivery` | what fired and each delivery's status (15 days); send one again |
+| `alerts_register_webhook`, `alerts_test_webhook`, `alerts_rotate_webhook_secret` | an HTTPS webhook (HMAC-signed deliveries): register, test, rotate its secret |
 
-An alert fires on ANY transfer of the token above the USD threshold on that chain. It cannot watch one address, and there is no price or funding alert. There is no Telegram delivery. Alerts are checked on a cron, not streamed; do not suggest WebSockets.
+A token-wide transfer alert fires on ANY transfer of the token above the USD threshold on that chain; an address alert on every transfer of that wallet. Every match is recorded in `alerts events` (15 days) whatever the channels; a transfer alert left with no enabled channel e-mails the account address. Hyperliquid alerts go to a webhook or are read with `alerts events`; only `hl_wallet` may also use email. There is no price or funding alert, no Discord (off) and no Telegram delivery. For a live feed without a rule, use `vike-data stream`.
 
 ---
 
@@ -213,7 +253,7 @@ An alert fires on ANY transfer of the token above the USD threshold on that chai
 Credits are an accounting figure only; they never block a call. The one limit is 20,000 requests per rolling hour per key, shared by MCP and REST.
 
 - **0 credits:** `token_search`, `alerts_list`, `alerts_list_channels`.
-- **1:** `wallet_ens`, `wallet_label_provenance`, `perp_funding`, `perp_spreads`, `hl_ohlcv`, `polymarket_markets`, `polymarket_ohlcv`.
+- **1:** `wallet_ens`, `wallet_label_provenance`, `perp_funding`, `perp_spreads`, `perp_open_interest`, `perp_long_short`, `search`, every `hl` command, `hl_ohlcv`, `polymarket_markets`, `polymarket_ohlcv`, the Polymarket tape, order book, stats, trades, settlement and archive calls.
 - **2:** most others, `wallet_summary` among them.
 - **3:** `token_screener`, `wallet_compare`, `wallet_token_balances`, `alerts_create`.
 - **4:** `wallet_trace`.
@@ -222,9 +262,7 @@ Credits are an accounting figure only; they never block a call. The one limit is
 
 - **No NFT data** — out of scope by design.
 - **No on-chain trading / signing** — read-only platform, no execution.
-- **No WebSocket / push streaming alerts.**
-- **No ENS name → address**, no per-address alerts, no candles for CEX tickers or arbitrary ERC-20 contracts.
-- **No Hyperliquid per-wallet profile, open interest or cohort positioning** through the CLI yet.
+- **No ENS name → address in `wallet ens`** (`vike-data search <name.eth>` does it), no candles for CEX tickers or arbitrary ERC-20 contracts.
 - **No non-EVM chains** (Bitcoin, Solana, Tron, Monero, Zcash, Dash) and no Arbitrum.
 
 If the user asks for any of the above, say so directly rather than proposing a workaround.

package/skills/vike-alerts-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-alerts-setup
-description: Create, list, edit, and delete on-chain transfer alerts. Alerts fire when a token transfer crosses USD thresholds you set and deliver to email or Discord. Use when the user asks "alert me when X" / "watch for big transfers" / "notify on whale moves".
+description: Create, list, edit, and delete alerts - on-chain transfer alerts (a token, one wallet, USD thresholds; eth, bsc, base, hyperevm) and Hyperliquid alerts (a wallet's fills, cohort fills, liquidations, cohort bias, liquidation proximity) - and read the events they produced. Delivered by email or an HTTPS webhook. Use when the user asks "alert me when X" / "watch for big transfers" / "notify on whale moves" / "tell me when this wallet trades".
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -12,7 +12,7 @@ allowed-tools: Bash(vike-data:*)
 vike-data alerts channels --json
 ```
 
-Returns enabled email + Discord channels. **If a user creates an alert with a channel they haven't verified, the alert is saved but won't fire notifications.** Always check first.
+Returns enabled email + webhook channels. **A channel kind the user has no enabled channel of is dropped from a transfer alert, and a transfer alert left with no channel e-mails the account address.** Whatever the channels, every match is recorded and read with `vike-data alerts events` (kept 15 days). A Hyperliquid alert is delivered by a registered webhook (`vike-alerts-webhook`; asking for one the user has not registered is an error) or only read with `alerts events`; `hl_wallet` alone may also use `--channel email`.
 
 ## CRUD
 
@@ -35,31 +35,63 @@ vike-data alerts create \
   --cooldown 60
 ```
 
-Required: `--label`. Common: `--token`, `--chain eth|bsc`, `--min-usd`, `--channel email|discord` (can repeat).
+Required: `--label`. Transfer alerts: `--token`, `--chain eth|bsc|base|hyperevm` (default eth), `--min-usd`, `--max-usd`, `--address 0x...` with `--address-role any|from|to` to watch ONE wallet, `--channel email webhook`.
+
+```bash
+# One wallet: every transfer it receives on base (no cooldown, no daily cap)
+vike-data alerts create --label "Treasury in" --chain base \
+  --address 0x1111111111111111111111111111111111111111 --address-role to --channel email
+```
+
+Hyperliquid alerts (`--type`; leave out `--chain`, `--address`, `--max-usd`; delivered by `--channel webhook` (`hl_wallet` also `email`, at most one mail per pass), or with no channel read them with `vike-data alerts events`):
+
+| `--type` | Fires on | Flags |
+|---|---|---|
+| `hl_wallet` | every fill of one wallet | `--wallet` (required), `--actions open close flip increase reduce`, `--token`, `--min-usd` |
+| `hl_cohort_fill` | fills by wallets in cohorts | `--pnl-cohorts "3x smart" ...` and/or `--size-cohorts "4x whale" ...` (one required), `--min-usd` >= 10000 (required) |
+| `hl_liquidation` | liquidations | optional `--wallet`, cohorts, `--token`, `--min-usd` |
+| `hl_cohort_bias` | a cohort index crossing a level | `--token` and `--index smi\|wsi\|smart_bias\|whale_bias\|smi_wsi_gap` (required), `--threshold`, `--band`, `--direction up\|down\|both` |
+| `hl_liq_proximity` | a wallet getting close to liquidation | `--wallet` (required), `--threshold` (0-1, default 0.8), `--band` |
+
+```bash
+vike-data alerts create --label "BTC smart money flips" --type hl_cohort_bias \
+  --token BTC --index smi --threshold 0 --band 0.1 --channel webhook
+```
 
 ### Edit (partial update — only fields you pass are changed)
 
 ```bash
 vike-data alerts edit 42 --min-usd 5000000          # raise threshold
 vike-data alerts edit 42 --active false             # pause
-vike-data alerts edit 42 --channel email --channel discord  # add second channel
+vike-data alerts edit 42 --channel email webhook    # both channels
+vike-data alerts edit 42 --address ''               # drop the wallet condition
+```
+
+### Events (what fired, and each delivery's status, kept 15 days)
+
+```bash
+vike-data alerts events --limit 50 --json           # page on with --cursor <next_cursor>
+vike-data alerts events --rule-id 42 --json
+vike-data alerts resend <delivery_id>               # send one delivery again
 ```
 
-### Delete
+### Delete (only when the user explicitly asks)
 
 ```bash
 vike-data alerts delete 42                          # soft-delete (pauses, keeps history)
-vike-data alerts delete 42 --hard                   # permanently remove
+vike-data alerts delete 42 --hard                   # permanently remove: only on an explicit "delete it for good"
 ```
 
+Never delete or hard-delete an alert on your own initiative, to "clean up" or to replace it: pause it with `edit --active false` if the user only wants it quiet.
+
 ## Notes + gotchas
 
-- Currently chains supported: **eth** and **bsc** only. For both, create two alerts.
-- **An alert watches a token, not an address.** It fires on ANY transfer of that token on that chain whose USD value crosses the thresholds. There is no wallet filter, so "alert me when whale 0xABCD sells" cannot be built: say so, and offer the token-wide alert or periodic `vike-data wallet transactions` checks instead. There are no price or funding alerts, and delivery is email, Discord or an HTTPS webhook (no Telegram).
+- Transfer chains: **eth**, **bsc**, **base**, **hyperevm**, one per alert. For several, create several alerts.
+- **A transfer alert watches a token, one wallet, or both.** Without `--address` it fires on ANY transfer of that token on that chain whose USD value crosses the thresholds. With `--address` it fires on every transfer that wallet sent (`from`), received (`to`) or either (`any`); without `--min-usd` that includes dust and unpriced tokens. "Alert me when whale 0xABCD sells" is `--address 0xABCD --address-role from`; on Hyperliquid it is `--type hl_wallet --wallet 0xABCD --actions close reduce`. There are no price or funding alerts, and delivery is email or an HTTPS webhook (Discord is off; no Telegram).
 - Thresholds are in **USD value** of the transfer at fire time, not token quantity.
-- `--cooldown` is per-alert minimum gap between triggers (default 60 min). Useful to avoid spam during high-volume hours.
+- `--cooldown` is the minimum gap between notifications of a token-wide transfer alert (default 60 min). Address alerts and Hyperliquid alerts notify on every event and ignore it.
 - Tokens are matched by symbol (UPPERCASE). For cross-chain symbols like `USDC` that exist on multiple chains, be explicit with `--chain`.
-- Alerts created without a verified channel will be **silently inactive at fire time** — there is no automatic warning. Use `vike-data alerts channels` first.
+- A transfer alert whose channels are not set up is not silent: it falls back to e-mailing the account address, and every match is in `alerts events`. Run `vike-data alerts channels` first so the user gets the delivery they expect.
 
 ## Confirmation flow with the user
 

package/skills/vike-alerts-webhook/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vike-alerts-webhook
-description: Register an HTTPS webhook as an alert delivery channel — get HMAC-signed POST notifications when alerts fire. Use when the user has a server / bot / Slack integration and wants programmatic alert delivery instead of email/Discord.
+description: Register an HTTPS webhook as an alert delivery channel — get HMAC-signed POST notifications when alerts fire (the only channel for Hyperliquid alerts); test it, rotate its secret, resend a delivery. Use when the user has a server / bot / Slack integration and wants programmatic alert delivery instead of email.
 allowed-tools: Bash(vike-data:*)
 ---
 
@@ -14,7 +14,7 @@ vike-data alerts register-webhook <https://your-server.com/vike-hook>
   [--json]
 ```
 
-The secret is **optional but strongly recommended** — without it we still POST, but the recipient has no way to verify it came from us.
+**Every POST is signed** (HMAC-SHA256). `--secret` is optional: without it the server generates one and returns it as `secret` in the answer. Show it to the user right away (it is also under Account → Alerts → channels, Show secret) so the receiver can verify deliveries.
 
 ## Example
 
@@ -29,7 +29,14 @@ vike-data alerts register-webhook https://api.mycoolbot.com/vike-alert \
 # → { "ok": true, "channel_id": 42, "url_preview": "https://api.myc...", "signed": true }
 ```
 
-Then create an alert and reference the channel — webhooks fire alongside email/discord. (Currently the `alerts create` flow doesn't accept channel IDs directly; webhooks fire if they're the user's enabled channels.)
+Then create an alert with `--channel webhook` (alongside `email` if wanted; a Hyperliquid alert takes the webhook only). Registration sends one signed `test` event at once; the channel id is in `vike-data alerts channels`.
+
+```bash
+vike-data alerts test-webhook <channel_id>     # send the signed test event again
+vike-data alerts rotate-secret <channel_id>    # only when the user explicitly asks: new secret, the old one keeps signing for 24 hours
+vike-data alerts events --json                 # what fired, with each delivery's status
+vike-data alerts resend <delivery_id>          # send one delivery again (up to 15 days)
+```
 
 ## What we POST to your URL
 
@@ -49,10 +56,10 @@ X-Vike-Signature: t=1716658923,sig=a3f8b2c...
 import hmac, hashlib, time
 
 def verify(secret, headers, body):
-    sig_header = headers.get("X-Vike-Signature", "")
-    parts = dict(p.split("=", 1) for p in sig_header.split(","))
-    ts, sig = parts.get("t"), parts.get("sig")
-    if not ts or not sig:
+    ts = headers.get("X-Vike-Timestamp", "")
+    # During a secret rotation the header carries TWO sig= values: accept if ANY matches.
+    sigs = [p.split("=", 1)[1] for p in headers.get("X-Vike-Signature", "").split(",") if p.startswith("sig=")]
+    if not ts or not sigs:
         return False
     # Reject replays older than 5 min
     if abs(time.time() - int(ts)) > 300:
@@ -60,12 +67,13 @@ def verify(secret, headers, body):
     expected = hmac.new(
         secret.encode(), f"{ts}.{body.decode()}".encode(), hashlib.sha256
     ).hexdigest()
-    return hmac.compare_digest(expected, sig)
+    return any(hmac.compare_digest(expected, s) for s in sigs)
 ```
 
 ## Anti-patterns
 
-- **Don't** skip the secret. Anyone who knows your webhook URL can spoof alerts without it.
+- **Don't** lose the secret or skip verifying: every delivery is signed with it (yours, or the one the server generated), and without the check anyone who knows the URL can spoof alerts.
+- **Don't** rotate the secret unless the user asks: the receiver must install the new one within 24 hours.
 - **Don't** trust the body without verifying the signature. The URL doesn't authenticate the sender; the HMAC does.
 - **Don't** use HTTP (only HTTPS) in production — the body is sensitive.
 - **Don't** respond slowly — we time out after 10s. If your handler does heavy work, queue it (push to a job queue, return 200 immediately).
@@ -76,7 +84,7 @@ def verify(secret, headers, body):
 2. Reject if `X-Vike-Timestamp` is more than ~5 min old (replay protection)
 3. Return `200` quickly; queue work async
 4. Log full body for unsigned-but-suspicious requests
-5. Rotate the secret if you suspect compromise — re-register a new channel
+5. Rotate the secret if you suspect compromise — `vike-data alerts rotate-secret <channel_id>`
 
 ## Pairs well with