home / skills / langchain-ai / deepagents / query-writing

This skill helps you write and execute SQL queries across simple and complex scenarios, delivering accurate results and clear answers.

npx playbooks add skill langchain-ai/deepagents --skill query-writing

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.8 KB
---
name: query-writing
description: For writing and executing SQL queries - from simple single-table queries to complex multi-table JOINs and aggregations
---

# Query Writing Skill

## When to Use This Skill

Use this skill when you need to answer a question by writing and executing a SQL query.

## 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;
```

## 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)

Overview

This skill helps write and execute SQL queries for tasks ranging from simple single-table lookups to complex multi-table JOINs and aggregations. It guides query planning, schema inspection, safe execution, and result formatting so you can deliver precise, auditable answers from a database.

How this skill works

The skill inspects table schemas using a schema inspection tool, drafts SQL with clear aliases and constraints, and executes read-only SELECT queries with a safe default LIMIT. For complex tasks it provides a step-by-step todo plan to map joins, choose aggregates, and validate GROUP BY and WHERE logic before execution.

When to use it

  • Answer a question that requires fetching data from a database
  • Compute aggregates like totals, averages, or counts across tables
  • Combine related tables using JOINs to produce consolidated reports
  • Validate assumptions about relationships or foreign keys before analysis
  • Produce a reproducible, read-only query to share with others

Best practices

  • Identify the relevant table(s) and inspect schemas before writing SQL
  • Select only necessary columns; avoid SELECT * to reduce overhead
  • Alias tables for readability and reference join conditions explicitly
  • Apply WHERE filters before aggregation and include GROUP BY for non-aggregated columns
  • Always use a LIMIT (default 5) when previewing results and never run data-modifying statements

Example use cases

  • List top 5 customers by revenue with an Invoice -> Customer join and SUM aggregation
  • Count active users per region using GROUP BY and proper WHERE filters
  • Compare month-over-month sales by joining Orders and OrderItems and aggregating by date
  • Validate foreign-key relationships by inspecting schemas and running small JOIN queries
  • Extract a sample of rows from a table for quick schema verification

FAQ

Can this skill modify data?

No. It is designed for read-only queries. It never executes DML statements like INSERT, UPDATE, DELETE, or DROP.

What if multiple tables share similar column names?

Use explicit table aliases and qualify column names (alias.column) to avoid ambiguity and ensure correct JOINs.