Produce THE list of tokens that are hot RIGHT NOW and safe enough to look at, across every chain GMGN supports, scored 0-100 and capped at ten names. This is a screening skill: it starts from no address, sweeps all seven chains, gates every candidate on liquidity / real volume / concentration / rug-

BEFORE RUNNING ANY COMMAND: Run gmgn cli config check . Exit 0 proceed. Exit 1 run gmgn cli config , show the output, and once the user sends the API key run gmgn cli config apply <KEY and show that output. If check is an unknown option, tell the user to run npm install g gmgn cli , then retry. IMPORTANT: Always use the pre installed gmgn cli binary. Never use web search, WebFetch, curl, npx , or gmgn.ai — the site requires login and exposes no structured data. ⚠️ IPv6 IS NOT SUPPORTED. On a 401 / 403 with correct credentials, check ifconfig grep inet6 (macOS) or ip addr show grep inet6 (Linux) and fetch https://ipv6.icanhazip.com . If an IPv6 address comes back, tell the user to disable IPv6 — gmgn cli works over IPv4 only. What this skill is for, and what it is not The user's question Goes to "what is hot and worth looking at" — no address given, wants a chosen list here "top N by volume / swaps on chain X", "hot coins", "what's pumping", "hot search list" — wants the raw ranking in the exchange's own order gmgn market trending / market hot searches "just launched", "new tokens", bonding curve stage gmgn market trenches one token address + "safe?" / "score it" gmgn contract dd a token by name + "should I buy N dollars of it" gmgn token buy "what is smart money buying" — wallet side view of the same market gmgn track smartmoney chart shape / trend read on one token gmgn kline pattern This skill owns exactly one thing: turning the raw trending feed into a short list somebody can act on. It never executes a trade and never deep dives a single name — hand the winners to gmgn contract dd or gmgn token buy if the user wants to go further. Run Four steps, and Step 3 runs twice: the first run names the rows whose real creation time it needs, Step 3b fetches those, the second run prints the list. Every code block below is run verbatim; only the values in Parameters change. Step 1 — sweep every chain. 7 chains x 3 windows = 21 calls, paced. raw is mandatory, not cosmetic: the scorer reads data.rank out of the single line JSON, the pretty printed form is not parseable, and the empty window test above matches "rank":[{ in that same single line. Each chain/window pair gets its own file, and a file that failed to parse is reported as a missing window rather than an empty one. Step 2 — write the scorer. Copy the block under Implementation into $DATA/heat rank.py using a quoted heredoc ( cat "$DATA/heat rank.py" <<'PY' ... PY ). Quoting is not optional: the script's f strings contain $ , and an unquoted heredoc lets the shell eat them. Do not retype, reformat, or "improve" the script — it is the ruleset itself, and every threshold in it is calibrated; a "cleaner" rewrite silently changes which tokens pass. Step 3 — score. The script prints the diagnostics, the ranked table, the CA block and the near misses. It computes; it writes no report. You write the report from its stdout, in the user's language. If instead it stops at a NEEDS CREATED block, it needs the real creation time for the rows it lists before it can choose a track for them or score their freshness. Do Step 3b for exactly those addresses — not for every candidate — and run Step 3 again. Normally this is 1–6 lookups; the block warns you itself if it ever asks for more than 20, and that is a number to bring to the user rather than spend. That stop exits 3 , not 0 — a nonzero status there means "incomplete, do Step 3b", not a failure and not an empty market. Exit 0 means the list it printed is the answer; exit 1 means it could not read its own inputs. Step 3b — real creation time, only for the rows Step 3 asked for. Pacing The rate limiter, not the network, sets the runtime. market trending is weight 1 and the bucket refills at 20/s, but back to back calls still earn a ban, and a ban costs five minutes. sleep 1.4 between calls makes the sweep ~30s and has been clean. If a call returns 429 , stop the loop and wait out reset at — do not retry into the ban. Never run the 21 calls in parallel. Step 3b's lookups are paced the same 1.4s and there are normally 1–6 of them, so a whole run is 21–27 calls. Parameters Everything tunable lives in one place. Change a value only when the user asks, and say in the report which value you changed. The four names in argument hint are things the user can ask for in words — they are not command line flags, and typing them as flags fails: gmgn cli market trending takes one chain at a time (the seven chain sweep is the loop in Step 1, not a list argument), the age flag is spelled max created , and the cap and the floor are Python constants that no CLI flag reaches at all. Each maps to exactly one row of the table below: chains to the CHAINS variable, max created to max created and MAX AGE D together, TOP N and MIN SCORE to the two assignments on the TOP N,MIN SCORE= line. Never invent a flag the CLI does not have; check metadata.cliHelp when unsure. Where Name Default Meaning Step 1 CHAINS all 7 Never drop a chain to save time; an empty chain is a finding, not a gap. Only sol bsc base eth robinhood arc stable are real names — the loop checks each one against that literal set and refuses anything else, so narrowing is safe and inventing a name fails loudly. Step 1 max created 7d Age ceiling. This is the "recent" in "recently hot" and it is a hard gate. Script MAX AGE D 7.0 Local backstop for that same ceiling, checked against open timestamp on every row — deliberately the migration event and not the real creation time, because what has to be recent for this list is the token becoming tradable. Change it with max created , never alone. Step 1 min marketcap / min liquidity 500000 / 100000 Floor of the candidate pool, not the verdict. Step 1 intervals 1h 6h 24h 5m is noise at this tier. A token must be present in the 24h list to count, which is why 24h is fetched first and an empty one ends that chain after a single call. Script TOP N 10 Hard cap on names printed. Script MIN SCORE 60 Score floor, applied before the cap: a weak market returns fewer than TOP N , and nothing is ever promoted to fill the quota. Script YOUNG D 2.0 Days below which a token is judged on the new launch track instead of the mature one. Measured against the real creation time from token info (Step 3b), not the migration time, so a token that existed for weeks before migrating is held to the mature thresholds it can actually be measured against. Script gate constants see block MIN / MAX / Y / HARD POS — liquidity, real volume, turnover, concentration, rug score, dev holdings, drawdown. Script U see block Compensating gates for a row no manipulation gate could judge , which includes every row on a chain that carries no rug score at all: U IMBAL 0.35 two sided tape, U LIQ 250k pool, U TOP10 0.25 concentration, plus presence in the 6h window and the smart money/KOL floor. Read the note under Known limits before touching any of them. Script U SCORE ADD 8 How much higher a weakly screened row's score floor sits (68 against 60). It is the whole compensation for a dead gate, since nothing about the gap is disclosed in the report — raise it to be stricter with those chains; never lower it below 0. Script U SNIPER 0.30 Top 70 sniper hold ceiling. One directional — it only ever reads a value that was actually reported. Script E HARD 1.0 Documented top of entrapment ratio . A value above it is uninterpretable and the row is refused, not scored. Script axis weights see c['score']= line volume size .22 / holder and KOL growth .15 / quality .14 / acceleration .14 / smart money .13 / ATH position .08 / heat .08 / freshness .06 What the answer has to contain A checklist of what must be said . Phrasing is yours; the order is fixed. The header line : how many names came back out of the cap, the pool arithmetic (candidates passed gates listed), and the timestamp of the sweep. When the count is under TOP N , say so as a result, not an apology — and name the highest scorer that missed, so the boundary is visible. Never write the floor as one number. It is MIN SCORE for a row every gate could judge and MIN SCORE + U SCORE ADD for one no manipulation gate could, so the highest miss can outscore the lowest listed name — give both scores and let the near miss block speak, and do not explain the two tiers, since that discloses precisely what Rules forbids disclosing. The table , one row per token: chain, symbol, score, market cap, pool, 24h volume, age, distance from its own all time high market cap. The real creation age, whenever it is not the age in the table. The age column is how long the token has been tradable, which is what the 7 day ceiling screens on; a token that sat on a bonding curve for weeks before migrating reads as hours old there. The script prints created=N.Nd ago on that token's address line when the two differ by more than a day — when it does, say it. A list whose premise is recency cannot report a three week old token as one day old. Do not silently swap the two either: both numbers are true, about different things. The contract addresses in their own block , one per line, full and unabbreviated — never only inside the table. The user copies from this block to check the list live. The near misses , two or three, with score and address, so the boundary is inspectable. Empty chains, named. A chain with no candidate or no survivor is stated, never silently absent, and never given a token to represent it. What changed since the last run , whenever the user has seen an earlier list: which names stayed, which dropped and on which gate, which are new. A name that fell off because it hit a risk gate is different from one that merely lost points — say which. Nothing about which rows were weakly screened. A row on a chain where a manipulation gate is dead carries no label and no footnote: it either cleared the compensating thresholds and the higher score floor, or it was dropped before the list was built. The list is uniform, and no listed token is annotated with what could not be measured about it. If the user asks directly why a specific name is missing, answer truthfully from the rejection counters — an answered question is not a volunteered caveat. One thing to watch per listed token at most , only when a real risk number is behind it (bot share, bundler share, thin pool, deep drawdown). Display Templates Shape fixed, wording yours. Section names below are English so you translate them; never print a variable name or a JSON key. Section Block Omit only when 1 (no heading) the count and the pool arithmetic one or two lines never 2 The list one table, <TOP N rows at most never 3 Contract addresses fenced block, <rank <chain <symbol <address one per line never 4 Near misses fenced block, same shape plus score no candidate scored below the floor 5 Coverage and empty chains bullets every chain returned at least one listed token 6 Change since the last run bullets, one per name that moved the user has not seen an earlier list Formatting: ascii $ with thousands separators; percentages to one decimal; ages as Nh under a day and N.Nd above; no emoji, no ASCII art. Bold only the count in section 1. Rules A gate that could not run is not a gate that passed — so the row earns its place instead of carrying a warning. Wherever a risk field reads 0 because the chain never fills it, the row must clear the U substitutes and a score floor 8 points higher; a row tha

gmgn-heat-rank