agentleFS
Vo1ganinVo1ganin/dune-skill/SKILL.md

dune

Skill0 starsChanged 3 months agoMITView on GitHub

Expert assistant for querying and analyzing on-chain blockchain data using Dune Analytics. Use whenever the user wants to: analyze blockchain/on-chain data, write SQL for Dune, find wallet activity, track DeFi protocol metrics, analyze NFT trades, monitor token transfers, investigate smart contract events, check token prices on-chain, find top holders, measure DEX volume, or explore any crypto/web3 data. Trigger even if the user doesn't mention "Dune" explicitly — if they want blockchain data insights or on-chain analysis, this skill applies. Also trigger when the user provides a contract address and wants data for it.

  • Reads credentials

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 1

    1. Vo1ganin/crypto-claude-skills★ 2100% same

    Edited · 0

    None found.

    Wrote their own version · 3

    1. TermiX-official/cryptoclaw★ 100same name
    2. duneanalytics/skills★ 53same name
    3. 0xvikram/backboard-skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repositoryOne other file it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 6 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read reference files when you need more depth:

    line 35
  2. Very specific:

    N+1 fetch trap: never fetch results in many small calls — that's the #1 way to quietly burn thousands of credits.

    line 60
  3. Distinctive:

    Auto-switch FREE → PAID: when ONE of these is clearly true:

    line 65
  4. Distinctive:

    All FREE keys hit 402

    line 68
  5. Distinctive:

    Always announce: before the PAID call: *"Using PAID, reason: {one-line}"* — user can abort

    line 70
  6. Distinctive:

    Never silent: If the trigger isn't clearly one of the four, ask the user instead

    line 71
  7. Very specific:

    Check references/tables.md first — covers ~90% of common use cases

    line 83
  8. Very specific:

    If not covered, call searchTables with descriptive keywords (e.g.

    line 84
  9. Very specific:

    If the user gave a contract address, call searchTablesByContractAddress — returns decoded event/call tables for that specific contract

    line 85
  10. Very specific:

    Use templates in references/sql-templates.md as starting points

    line 89
  11. Very specific:

    Call createDuneQuery with your SQL and a descriptive name

    line 97
  12. Very specific:

    Call executeQueryById with the returned query ID

    line 98
  13. Very specific:

    Default to performance: "medium".

    line 99
  14. Very specific:

    Always lowercase: 0xabc...

    line 128
  15. Distinctive:

    All query discovery, creation, execution, visualization, dashboards

    line 159

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dune Analytics Skill

You are an expert in Dune Analytics — a platform for querying live blockchain data using SQL. Dune uses DuneSQL, a dialect based on Trino/PrestoSQL — not standard PostgreSQL or MySQL.

Read reference files when you need more depth:

  • references/tables.md — canonical table names, columns, and which tasks they serve
  • references/sql-templates.md — ready-to-use SQL for common queries
  • references/optimization.md — credit-saving patterns and query optimization
  • references/credits.md — credit budget rules, two-key setup, cost estimation
  • references/paid-endpoints.md — direct HTTP endpoints for bulk downloads with PAID key

🚨 Credit budget rules (MANDATORY)

The user has two Dune API keys — FREE (default) and PAID (for heavy exports only). Treat credits as real money.

Before EVERY execution AND every download — evaluated independently, not summed:

  1. Estimate cost using getTableSize + time/filter analysis + expected result size (see references/credits.md)
  2. Compare against thresholds (applied to each operation on its own):
    • < 500 credits → proceed silently
    • 500–700 credits → tell the user your estimate and the reason before the operation
    • > 700 credits → STOP. Explain, propose cheaper alternative, ask for explicit approval

Examples:

  • Execute 100 cr + Download 600 cr → both under 700, proceed
  • Execute 100 cr + Download 800 cr → STOP before the download, not the execute
  • Execute 800 cr → STOP before executing, regardless of what download would cost

N+1 fetch trap: never fetch results in many small calls — that's the #1 way to quietly burn thousands of credits. One query + paginated export with limit=32000. See references/credits.md "2000-fetches antipattern".

Key rotation & escalation (see references/credits.md "Key loading policy"):

  • Single key loaded → use it, thresholds still apply
  • Multiple FREE keys → rotate automatically on 402 (silent, no money spent)
  • Auto-switch FREE → PAID when ONE of these is clearly true:
    1. PAID is strictly cheaper (3×+ savings, e.g. Plus 2 cr/MB vs Free 20 cr/MB on bulk)
    2. Endpoint is PAID-only
    3. All FREE keys hit 402
    4. Bulk export > 32k rows where PAID pricing beats FREE pagination
  • Always announce before the PAID call: "Using PAID, reason: {one-line}" — user can abort
  • Never silent. If the trigger isn't clearly one of the four, ask the user instead

See references/credits.md for the full rule set and cost estimation tables.


Step-by-step workflow

Step 1 — Understand the request Identify: the blockchain (ethereum? arbitrum? base? solana?), the time range, any contract/wallet addresses, and what metric the user wants (volume, count, holders, prices, etc.).

Step 2 — Find the right table

  • Check references/tables.md first — covers ~90% of common use cases
  • If not covered, call searchTables with descriptive keywords (e.g. "uniswap v3 swap ethereum")
  • If the user gave a contract address, call searchTablesByContractAddress — returns decoded event/call tables for that specific contract
  • For large/unknown tables call getTableSize before writing the query

Step 3 — Write the SQL

  • Use templates in references/sql-templates.md as starting points
  • Always include WHERE block_time >= NOW() - INTERVAL 'N' DAY on large tables (partition pruning — see references/optimization.md)
  • Always include LIMIT unless user explicitly wants the full set
  • Select only the columns you actually need (not SELECT *)
  • Format addresses as lowercase hex with 0x prefix — no quotes around the literal for VARBINARY columns

Step 4 — Estimate cost, then execute

  • Apply the credit budget rules above
  • Call createDuneQuery with your SQL and a descriptive name
  • Call executeQueryById with the returned query ID
  • Default to performance: "medium". Use "large" only when user needs speed on a heavy query (consumes more credits)
  • Poll getExecutionResults — may take 5–60s, keep polling while state is QUERY_STATE_EXECUTING (max 30 min timeout)

Step 5 — Present results

  • Format numbers with commas and units (ETH, USD, count)
  • Summarize key findings in 2–4 bullets before showing the raw table
  • Share the query link: https://dune.com/queries/{query_id}
  • Offer to generateVisualization for time-series or ranking data
  • Report cost if significant: "Query cost: ~N credits"

DuneSQL syntax cheatsheet

These differ from standard SQL — getting them wrong is the #1 cause of errors:

NeedDuneSQL syntax
Time truncationdate_trunc('day', block_time)
Last N daysblock_time >= NOW() - INTERVAL '30' DAY
Specific dateblock_time >= TIMESTAMP '2024-01-01 00:00:00'
Cast to floatTRY_CAST(value AS DOUBLE)
Hex to numberbytearray_to_numeric(value)
String concatCONCAT(str1, str2) — not ||
If/elseIF(cond, a, b) or CASE WHEN ... END
Null safe equalIS NOT DISTINCT FROM
Division (int)CAST(a AS DOUBLE) / b

Address formatting:

  • Always lowercase: 0xabc... not 0xABC...
  • VARBINARY columns: WHERE address = 0xd8da6bf26964af9d7eed9e03e53415d37aa96045 (no quotes)
  • VARCHAR columns: WHERE address = '0xd8da...' (with quotes)

Error handling

"Table not found" / wrong column name: → searchTables with different keywords → check references/tables.md → searchDocs for dataset docs

"Type error" / "Cannot cast": → Wrap in TRY_CAST(col AS DOUBLE) → for uint256 use bytearray_to_numeric(col) → check VARBINARY vs VARCHAR

"Query timeout" / execution hangs: → Tighten block_time filter (7 days instead of 90) → getTableSize to see scan size → LIMIT 1000 if full set not needed

"Execution still running" (state = EXECUTING): → Wait 15s and re-poll. Hard max 30 min timeout, then it fails.

HTTP 402 (quota exceeded): → Stop, check getUsage, report to user. Don't auto-switch to PAID key.

Invalid offset → empty result: → Response has total_row_count — check it's > 0 before concluding "no data"


When to use MCP vs direct HTTP API

MCP (this skill's default) — everything except bulk exports:

  • All query discovery, creation, execution, visualization, dashboards
  • Reading up to ~30k rows of results
  • Uses the FREE key

Direct HTTP API (references/paid-endpoints.md) — for:

  • Downloading > 30k rows (CSV/JSON pagination via X-Dune-Next-Offset)
  • Bulk exports where total MB × (credits/MB for your plan) exceeds FREE headroom
  • Scripted/scheduled ETL flows outside Claude
  • Uses the PAID key (DUNE_API_KEY_PAID env var), announce before switching

Reference files (read when you need detail)

  • references/tables.md — table reference: canonical names, columns, use cases
  • references/sql-templates.md — copy-paste SQL for wallets, holders, DEX, prices, NFTs, etc.
  • references/optimization.md — partition pruning, CTEs, incremental queries, cheap-vs-expensive tables
  • references/credits.md — credit budget rules, cost estimation, engine tiers, FREE/PAID key policy
  • references/paid-endpoints.md — direct HTTP API for bulk downloads

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.