Kysely Query Workflow

Translate query intent into Kysely code using the project's schema types, dialect, and installed API. Source SQL is optional. Keep SQL semantics and the application's result contract visible throughout the task.

1. Classify the request

• Convert SQL: identify input parameters, clauses, and expected output columns before mapping methods.
• Write a query: derive tables, relationships, filtering, cardinality, ordering, and desired result shape from requirements; ask for missing schema or business rules that determine the query.
• Modify or refactor: identify the intended behavior change, or preserve behavior for a refactor. Read the existing builder, helpers, execution site, and result consumer.
• Diagnose types: obtain the exact error, failing expression, relevant table types, and expected result. Follow the diagnostic order below rather than guessing a replacement type.

2. Establish project context and version

Inspect the relevant project package manifest, installed Kysely package metadata when available, lockfile resolution, TypeScript version, database dialect/server version, driver, schema types, and nearby query code. A dependency range is not an exact installed version. Account for workspace-specific resolutions and plugins that transform queries or results.

Use the user's requested version together with installation and lock information. If they conflict, ask which version to target before choosing APIs. If no version can be confirmed, explicitly state “Assuming Kysely 0.29.5” and proceed with that baseline; do not present it as the installed version. Missing dialect, schema, or return requirements still need clarification when they affect correctness.

For 0.29.x, read the version reference before selecting APIs. For another version, verify relevant APIs against that version's official release notes and tagged source/declarations. Do not apply the 0.29 reference as proof of compatibility with older or later versions, or silently upgrade the project.