home / skills / oimiragieo / agent-studio / drizzle-orm-rules

This skill helps you enforce Drizzle ORM rules in src/lib/db, improving data modeling, validation, and consistent query practices.

npx playbooks add skill oimiragieo/agent-studio --skill drizzle-orm-rules

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

Files (3)
SKILL.md
1.6 KB
---
name: drizzle-orm-rules
description: Rules for using Drizzle ORM within the `src/lib/db` directory. Ensures consistent data modeling and database interactions.
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: src/lib/db/**/*.ts
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Drizzle Orm Rules Skill

<identity>
You are a coding standards expert specializing in drizzle orm rules.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

- Follow best practices for Drizzle ORM usage, including schema definition and query building.
- Ensure proper data validation and error handling when interacting with the database.
  </instructions>

<examples>
Example usage:
```
User: "Review this code for drizzle orm rules compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill enforces rules for using Drizzle ORM inside the src/lib/db directory to keep data models consistent and database interactions safe. It codifies schema, query, validation, and error-handling best practices so teams maintain predictable, maintainable code. The guidance is practical and focused on common pitfalls encountered in JavaScript projects using Drizzle.

How this skill works

The skill inspects schema definitions, migrations, and query code within src/lib/db to detect anti-patterns and missing safeguards. It flags issues such as implicit typing, unsafe raw queries, missing nullability constraints, and lack of transactional boundaries, then suggests concrete refactors and code examples. It also recommends validation and standardized error handling around database operations.

When to use it

  • Adding or updating table schemas and relations under src/lib/db
  • Writing query code or repository functions that interact with the database
  • Reviewing pull requests for database-related changes
  • Refactoring data access logic to improve safety and testability
  • Implementing migrations or schema evolution workflows

Best practices

  • Define schemas explicitly with types and nullability; prefer required columns over implicit assumptions
  • Use typed query builders from Drizzle instead of raw SQL; if raw SQL is necessary, parameterize inputs
  • Centralize validation: validate inputs before database operations and map DB errors to domain errors
  • Wrap multi-step operations in transactions and keep transactions short-lived
  • Return plain objects from repository layers and avoid leaking ORM instances across application boundaries
  • Add clear, testable error handling paths and log contextual metadata for DB failures

Example use cases

  • Review a new users table schema to ensure proper indexed columns and non-null constraints
  • Refactor a service that issues multiple inserts into a single transaction for atomicity
  • Replace raw string concatenation in queries with Drizzle's typed query builder
  • Add validation and explicit error mapping for create/update repository functions
  • Audit repository exports to ensure consumers receive sanitized plain objects

FAQ

What should I do when a third-party library requires raw SQL?

Restrict raw SQL usage to a small, well-tested adapter layer. Parameterize inputs and add unit tests that assert expected results and guard against injection.

How do I handle optional relations and nullable fields?

Model nullability explicitly in schemas, handle optional relations with clear runtime checks, and document the domain meaning of null vs missing.