Query Writing
Let your deep agent inspect schemas, compose JOIN-heavy SQL, and return capped result sets for product or ops questions.
Overview
query-writing is an agent skill for the Build phase that writes and executes SQL from schema inspection through JOINs and aggregations.
Install
npx skills add https://github.com/langchain-ai/deepagents --skill query-writingWhat is this skill?
- Separate workflows for simple single-table SELECTs versus multi-table JOIN plans
- Mandates `sql_db_schema` before writing and `sql_db_query` to execute
- Complex path uses `write_todos` to decompose tables, keys, aggregations, and JOIN order
- Default LIMIT of 5 rows on exploratory queries to keep agent responses safe
- Includes validated revenue-by-country style JOIN example pattern
- Five-step workflow for simple single-table queries
Adoption & trust: 673 installs on skills.sh; 24.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need answers from your database but the agent writes unsafe SQL, skips schema checks, or returns huge unbounded result sets.
Who is it for?
Builders using Deep Agents with `sql_db_schema` and `sql_db_query` who want repeatable analytics and lookup workflows.
Skip if: Schema design, migrations, or write-heavy ETL where destructive statements should never be auto-generated.
When should I use this skill?
The user asks to query a database, write SQL, run a SELECT, retrieve data, filter records, or generate reports from tables.
What do I get? / Deliverables
You get validated SELECT queries executed via the SQL tools with clearly formatted, limited rows for the question asked.
- Executed SQL queries with formatted tabular answers
- Documented JOIN and GROUP BY plan for multi-table questions
Recommended Skills
Journey fit
Canonical shelf is Build because the skill is about constructing correct SQL against live schemas during product development and reporting features. Backend subphase covers data access layers, ad hoc analytics, and agent-driven reporting against application databases.
How it compares
Read-only SQL assistant skill—not an ORM codegen tool or database admin panel.
Common Questions / FAQ
Who is query-writing for?
Developers and solo founders using LangChain Deep Agents to query relational data without hand-writing every SELECT.
When should I use query-writing?
Use during Build backend feature work when you need reports, filters, or JOIN-based metrics, and during Operate investigations that stay read-only.
Is query-writing safe to install?
It targets read queries with LIMIT defaults; review Security Audits on this page and restrict database credentials to least-privilege read roles.
SKILL.md
READMESKILL.md - Query Writing
# Query Writing Skill ## Workflow for Simple Queries For straightforward questions about a single table: 1. **Identify the table** - Which table has the data? 2. **Get the schema** - Use `sql_db_schema` to see columns 3. **Write the query** - SELECT relevant columns with WHERE/LIMIT/ORDER BY 4. **Execute** - Run with `sql_db_query` 5. **Format answer** - Present results clearly ## Workflow for Complex Queries For questions requiring multiple tables: ### 1. Plan Your Approach **Use `write_todos` to break down the task:** - Identify all tables needed - Map relationships (foreign keys) - Plan JOIN structure - Determine aggregations ### 2. Examine Schemas Use `sql_db_schema` for EACH table to find join columns and needed fields. ### 3. Construct Query - SELECT - Columns and aggregates - FROM/JOIN - Connect tables on FK = PK - WHERE - Filters before aggregation - GROUP BY - All non-aggregate columns - ORDER BY - Sort meaningfully - LIMIT - Default 5 rows ### 4. Validate and Execute Check all JOINs have conditions, GROUP BY is correct, then run query. ## Example: Revenue by Country ```sql SELECT c.Country, ROUND(SUM(i.Total), 2) as TotalRevenue FROM Invoice i INNER JOIN Customer c ON i.CustomerId = c.CustomerId GROUP BY c.Country ORDER BY TotalRevenue DESC LIMIT 5; ``` ## Error Recovery If a query fails or returns unexpected results: 1. **Empty results** — Verify column names and WHERE conditions against the schema; check for case sensitivity or NULL values 2. **Syntax error** — Re-examine JOINs, GROUP BY completeness, and alias references 3. **Timeout** — Add stricter WHERE filters or LIMIT to reduce result set, then refine ## Quality Guidelines - Query only relevant columns (not SELECT *) - Always apply LIMIT (5 default) - Use table aliases for clarity - For complex queries: use write_todos to plan - Never use DML statements (INSERT, UPDATE, DELETE, DROP)