Add reverse lookup recipe, fix pagination bug

[digodefi]

Summary

• New skill recipe: reverse-lookup wallets behind Hyperliquid PnL share cards using the /positions endpoint
• 5 example prompts covering: full card match, partial info (no entry price), closed positions, cohort attribution, and "biggest money behind this trade" reframe
• Python code pattern (find_positions_matching_card() + lookup_wallet()) with tolerance guidance and disambiguation heuristics
• 2 new troubleshooting rows for reverse lookup edge cases
• Fixes pre-existing pagination bug: query param is nextCursor, not cursor (API silently ignores cursor and returns page 1 forever)

Verified against live API

• TAO short 5x (entry 328.28): 5 matches, exact entry-price wallet confirmed
• ETH short 25x (entry 2249.4): 11 matches at 0.05 tolerance, mark-price tiebreaker identified the card author (0x1092c3..., Fish + Exit Liquidity, ROI 76.93% vs card's 76.0%)
• Pagination, wallet lookup, cohort decoding, ROI formula (both long and short) all tested end-to-end
• 3 independent agent reviews: Swagger accuracy audit, LLM readability review, live integration tests

Test plan

• Verify reverse lookup works with a fresh PnL card not used during development
• Confirm pagination fix doesn't break existing cursor-based queries
• DJ/Avi review for product accuracy

🤖 Generated with Claude Code

[PavloPetrina]

Suggested change

**GET /positions** — Historic positions. Params: `start` (required), `end`, `coin`, `segmentId` (filter by cohort ID), `address` (single address, e.g. `address=0x...`), `open`, `limit`, `nextCursor`. Historical from April 2025. Returns tens of thousands of positions per call with pre-computed data (PnL segments, size segments, leverage, liquidation progress, funding, entry price, unrealized PnL). Can also be used for reverse-lookups: given a coin, side, leverage, and entry price from a Hyperliquid PnL share card or screenshot, filter open positions to identify matching wallets (see Reverse Lookup prompts and code pattern below).

`address` (single address, e.g. `address=0x...`),

@digodefi what I wrote before probably confused you sorry

It should accept the array indeed (in the sence of multiple strings as get params) and not be limited by this validation hence it's still a GET parameter in the URL, which is not required.
So the user should be able to query with a single address but not ONLY with multiple as it's validated

So indeed this endpoint can and should make a query with multiple addresses - each is a new get parameter in the url. So the bug is that now this endpoint is not allowing to apply single (just one address), hence requires multiple, so @TarasKalyniiAc has fixed that now in DEV only.

In practical terms:
if you do with single address - it fails with validation - which is NOT ok - fix is done

if you do with multiple addresses - all were OK

So just mention something with multiple addresses query params can be applied

[digodefi]

thanks @PavloPetrina — just pushed a fix. updated all 6 skill files to say address accepts one or more (repeat the param for multiple, e.g. address=0x...&address=0x...). lmk if that reads right