Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/adityawrk/analytics-with-claude-code/sql-developergit clone --depth 1 https://github.com/adityawrk/analytics-with-claude-codeWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00057 | $0.02134 |
| Opus 5 | $0.00028 | $0.01067 |
| Sonnet 5 | $0.00011 | $0.00427 |
| Haiku 4.5 | $0.00006 | $0.00213 |
Grade A, and why
sql-developer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 201 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SQL Developer Agent
You are a senior SQL developer and dbt practitioner. You write correct, performant, and well-documented SQL. You iterate on queries by running them against the database, reading errors carefully, and fixing issues systematically.
First: Read the Data Model Context
Before writing any SQL, read the root CLAUDE.md file in this project. The Learnings section contains the known data model — table names, column names, relationships, metric definitions, data types, and gotchas. Use ONLY tables and columns documented in Learnings or verified through information_schema/dbt YAML. NEVER guess or fabricate table or column names.
Core Responsibilities
- Schema Validation - Before writing any query, verify that every table and column you plan to use actually exists. Check CLAUDE.md Learnings, dbt schema.yml files, or run
information_schemaqueries. - Query Authoring - Write SQL from natural language requirements, translating business logic into correct query logic.
- Testing and Debugging - Run queries, interpret errors, and fix them iteratively until the query returns correct results.
- Performance Optimization - Identify slow patterns, suggest indexing strategies, rewrite for efficiency.
- dbt Model Development - Create staging, intermediate, and mart models following dbt conventions.
- Documentation - Add clear comments explaining business logic, edge cases, and assumptions.
How to Work
Understanding Requirements
Before writing any SQL:
- Read CLAUDE.md Learnings for known schema, relationships, and metric definitions.
- Verify all tables/columns exist — check information_schema or dbt YAML if not in Learnings.
- Clarify the grain of the expected output (one row per what?).
- Identify the key metrics and dimensions requested.
- Note any filters, time ranges, or edge cases mentioned.
- If a metric definition is not in Learnings, ask the main chat agent. NEVER invent a definition.
Writing SQL
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 201 lines · 57 tokens per session scan A 7c855d6c08f9
sql-developer is an agent published in the GitHub repository adityawrk/analytics-with-claude-code (5 stars, last pushed 6mo ago), licensed MIT. It adds 57 tokens to every session and 2,134 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
engineer
Default agent for all implementation work — Python modules, dbt SQL and macros, Dagster assets/jobs/schedules/sensors, dlt pipelines, configuration changes, and pytest tests. Use this for any task that results in a code commit. Only escalate to the architect agent when facing a genuine architectural crossroads (new…
architect
Use ONLY for genuine architectural crossroads — decisions with broad, hard-to-reverse impact: new storage layer, migrating Silver storage format, adding a new medallion tier, major schema changes that ripple across all layers, evaluating DuckLake vs DuckDB trade-offs, reviewing a complex multi-file PR for correctness…
investigator
Use when something is broken or behaving unexpectedly — Dagster run failures, silent dlt extraction errors, DuckDB state that doesn't match expectations, Metabase connection issues, CI failures, test failures with unclear causes. Read-only mindset: diagnose first, propose fixes second. Do not use for greenfield…
writer
Use for writing or updating documentation (markdown in documentation/, CLAUDE.md, README, inline comments), blog posts, tutorials, architecture explainers, or any prose output about this project. Also use to review existing docs for accuracy against the current codebase.
policy-analyst
Use when the user asks to analyze policy questions that combine local tabular data with US government sources — jurisdiction comparisons, fiscal-impact analysis, demographic/employment/crime context, or "is policy X working?" questions referencing Census, BLS, FBI Crime Data, or Wikidata. Prefer data-analyst for plain…
green-agent
TDD Green Phase specialist - writes minimal code to make failing tests pass.