/db-query

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select db-query from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv db-query, /just-vibe db-query and /jv:db-query in Claude. See shortcut setup and context examples.

What the agent does

1. Define the expected result grain and cardinality.
2. Write a parameterized query, resolving join cardinality and null semantics; test one-to-many joins and nullable predicates.
3. Compare results with hand-computed small fixtures or bounded authorized reads before optimization.

Inputs

• desired result, schema, engine, parameters, and scale. Explicit query execution selects the authorized mode/environment.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Correct SQL/query construction and relevant performance; no broad data repair.

Writes

Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.

Mode

Plan or explain SQL from the desired result and schema; apply for requested query-file repairs and bounded local fixture checks. Live execution needs its resolved environment and scope.

Prerequisites

Actual engine/version, schema/migrations, query workload, and explicitly identified environment. Prefer supplied plans, metadata, and isolated fixtures. Even a SELECT can lock, call mutating functions, or overload a database; inspect semantics before execution. Executing an analyzed query is distinct from reading its plan.

Expected output

• Parameterized query with its assumptions, expected row grain and empty/null/duplicate-boundary verification.

How the work is checked

• One-to-many joins do not silently inflate aggregates; empty/null inputs yield the intended behavior.

When to stop or clarify

• Writes need explicit scope and affected-row checks. Do not run unbounded expensive queries against production for convenience.

Handling missing context

Infer

Read engine/version, ORM/runner, schema and migration history from project artifacts before choosing SQL.

Assume

Prepare local SQL and isolated fixtures without assuming production size, locks or recovery guarantees.

Ask

Ask for environment, downtime or recovery constraints before live/destructive execution when missing; unavailable production access does not block migration files.

Technical guidance

Evidence

Inspect actual schema, parameter binding, join cardinality, null semantics and expected result grain.

Method

Hand-compute a small fixture before optimizing; aggregate each many-side at the correct grain and constrain tenant identity.

Pitfall

Two one-to-many joins can multiply totals; NOT IN with null values can produce unexpected exclusion.

Check

Check no rows, nulls, duplicate children, two tenants and boundary predicates against independently calculated results.

Situational decisions

When joins multiply rows before aggregation: Preaggregate or change the join while preserving semantics; DISTINCT is not a universal repair.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring