К основному содержанию
скилл CX Codex

database-schema — скилл для Claude Code: схема БД до кода

Скилл заставляет агента прочитать схему базы и проверить колонки с типами до того, как он напишет запрос или миграцию.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add alinaqi/maggy --skill database-schema -a claude-code
Открыть на GitHub

Что делает database-schema

Скилл включается перед работой с базой: агент открывает файл схемы, сверяет колонки и типы, которые собирается использовать, и ссылается на схему в ответе. Если файла схемы нет, скилл требует создать его до начала работы. Это снимает типовую боль — модель к середине сессии путает имена колонок и забывает поля, а тесты ловят это уже в рантайме.

Внутри — таблица расположения схемы по стекам: Drizzle, Prisma, Supabase, SQLAlchemy, TypeORM, сырой SQL. Для каждого указана команда генерации типов: npx prisma generate, supabase gen types typescript и встроенные типы Drizzle. Есть чек-лист из пяти пунктов, который агент заполняет перед кодом, и шаблон файла _project_specs/schema-reference.md с таблицами колонок, связями и enum.

Скилл не вызывается вручную — в описании стоит user-invocable: false, он подхватывается по путям вроде **/schema.*, **/migrations/**, **/*.prisma. Если у вас в проекте схема лежит не в этих местах, срабатывания придётся ждать впустую.

Какие задачи решает

  • сверить имена колонок со схемой перед написанием запроса
  • сгенерировать типы из Prisma или Supabase и не рассинхронизировать их с кодом
  • заполнить чек-лист проверки схемы для конкретной задачи
  • завести справочный файл схемы с таблицами, связями и enum
  • поймать ошибку в колонке до рантайма, а не в тестах

Примеры запросов агенту

  • прочитай схему из src/db/schema.ts и проверь колонки перед тем, как писать запрос к orders
  • сгенерируй типы из prisma/schema.prisma и используй их в новом эндпоинте
  • создай _project_specs/schema-reference.md по текущим моделям

Как установить database-schema

1Через Skills CLI (Vercel)

npx skills add alinaqi/maggy --skill database-schema -a claude-code

2Вручную: положить файлы

~/.claude/skills/database-schema/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/database-schema/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора32

codex-review Скилл запускает аудит кода через утилиту Codex CLI и модель GPT-5.2-Codex. Пригодится для поиска уязвимостей и багов перед коммитом или в CI/CD. CX Codex +1 328установок web-content Скилл помогает писать страницы, которые и в поиске ранжируются, и попадают в ответы ChatGPT, Perplexity, Claude и Gemini. CX Codex +1 326установок reddit-api Скилл для интеграции Reddit в приложение: посты, комментарии, сабреддиты и данные пользователей через PRAW или Snoowrap. CX Codex +1 316установок team-coordination Организует совместную работу нескольких сессий Claude Code в одном репозитории через синхронизацию задач и статусов в Markdown. Пригодится команде, чтобы избежать конфликтов при параллельной разработке. CX Codex +1 314установок typescript Задаёт агенту правила работы с TypeScript: строгий tsconfig, линт, тесты на Jest и структура проекта. Пригодится, когда в репозитории уже есть .ts и .tsx файлы. CX Codex +1 313установок cloudflare-d1 Помогает агенту писать код под Cloudflare D1: схема Drizzle, миграции через Wrangler и воркер на Hono. Пригодится, когда проект уже крутится на Workers. CX Codex +1 311установок ms-teams-apps Скилл помогает собирать ботов, вкладки и расширения сообщений для Microsoft Teams с подключением LLM. Пригодится, когда нужен агент внутри Teams. CX Codex +1 303установок session-management Скилл ведёт файлы состояния, решений и ориентиров в коде, чтобы работа продолжалась с того же места после перерыва или упора в лимит контекста. CX Codex +1 301установок

Похожие

database-migrations affaan-m Скилл описывает безопасные и обратимые миграции схемы: expand-contract, индексы CONCURRENTLY, батч-бэкфиллы и рабочие процессы для PostgreSQL, Prisma, Drizzle, Kysely, Django и golang-migrate. CX Codex +1 5 200установок database-design spencerpauly Скилл помогает спроектировать реляционную схему базы данных, расставить внешние ключи, индексы и сгенерировать модели для Prisma или Drizzle по требованиям к проекту. CX Codex +1 462установок database-schema-designer Alireza Rezvani Скилл проектирует реляционные схемы по требованиям и готовит ERD, миграции и типы. Пригодится для новой функции или пересмотра существующей структуры базы. 692установок convex-schema-validator waynesutton Проектирует таблицы, валидаторы, индексы и связи в convex/schema.ts. Пригодится при ошибках проверки схемы и развитии модели данных. CX Codex +1 3 000установок planetscale-schema-recommendations-agent-loop planetscale Превращает открытые рекомендации PlanetScale в план, issue, ветку или PR. Продовые изменения сам не применяет. CX Codex +1 1 800установок prisma-database-setup prisma Устаревшее совместимое имя для скилла prisma-orm-setup, который настраивает Prisma и чинит подключения к базе данных. CX Codex +1 390 200установок

Рядом в теме «Данные и базы»

Все скиллы по теме «Данные и базы» →

Вопросы о database-schema

Как установить database-schema в Claude?

Выполните npx skills add alinaqi/maggy --skill database-schema -a claude-code. Скилл встанет в ~/.claude/skills/database-schema/SKILL.md.

Что делает database-schema?

Заставляет агента прочитать файл схемы и проверить колонки с типами до написания кода, который трогает базу. Плюс даёт команды генерации типов для Drizzle, Prisma, Supabase и SQLAlchemy.

Скилл вызывается вручную?

Нет, в описании стоит user-invocable: false. Он подключается сам по путям файлов: **/schema.*, **/migrations/**, **/models/**, **/*.prisma, **/drizzle/**.

Исходный текст

SKILL.md · MIT
---
name: database-schema
description: Schema awareness - read before coding, type generation, prevent column errors
when-to-use: Before writing any database queries or modifying data models
user-invocable: false
paths: ["**/schema.*", "**/migrations/**", "**/models/**", "**/*.prisma", "**/drizzle/**"]
effort: medium
---

# Database Schema Awareness Skill


**Problem:** Claude forgets schema details mid-session - wrong column names, missing fields, incorrect types. TDD catches this at runtime, but we can prevent it earlier.

---

## Core Rule: Read Schema Before Writing Database Code

**MANDATORY: Before writing ANY code that touches the database:**

```
┌─────────────────────────────────────────────────────────────┐
│  1. READ the schema file (see locations below)              │
│  2. VERIFY columns/types you're about to use exist          │
│  3. REFERENCE schema in your response when writing queries  │
│  4. TYPE-CHECK using generated types (Drizzle/Prisma/etc)   │
└─────────────────────────────────────────────────────────────┘
```

**If schema file doesn't exist → CREATE IT before proceeding.**

---

## Schema File Locations (By Stack)

| Stack | Schema Location | Type Generation |
|-------|-----------------|-----------------|
| **Drizzle** | `src/db/schema.ts` or `drizzle/schema.ts` | Built-in TypeScript |
| **Prisma** | `prisma/schema.prisma` | `npx prisma generate` |
| **Supabase** | `supabase/migrations/*.sql` + types | `supabase gen types typescript` |
| **SQLAlchemy** | `app/models/*.py` or `src/models.py` | Pydantic models |
| **TypeORM** | `src/entities/*.ts` | Decorators = types |
| **Raw SQL** | `schema.sql` or `migrations/` | Manual types required |

### Schema Reference File (Recommended)

Create `_project_specs/schema-reference.md` for quick lookup:

```markdown
# Database Schema Reference

*Auto-generated or manually maintained. Claude: READ THIS before database work.*

## Tables

### users
| Column | Type | Nullable | Default | Notes |
|--------|------|----------|---------|-------|
| id | uuid | NO | gen_random_uuid() | PK |
| email | text | NO | - | Unique |
| name | text | YES | - | Display name |
| created_at | timestamptz | NO | now() | - |
| updated_at | timestamptz | NO | now() | - |

### orders
| Column | Type | Nullable | Default | Notes |
|--------|------|----------|---------|-------|
| id | uuid | NO | gen_random_uuid() | PK |
| user_id | uuid | NO | - | FK → users.id |
| status | text | NO | 'pending' | enum: pending/paid/shipped/delivered |
| total_cents | integer | NO | - | Amount in cents |
| created_at | timestamptz | NO | now() | - |

## Relationships
- users 1:N orders (user_id)

## Enums
- order_status: pending, paid, shipped, delivered
```

---

## Pre-Code Checklist (Database Work)

Before writing any database code, Claude MUST:

```markdown
### Schema Verification Checklist
- [ ] Read schema file: `[path to schema]`
- [ ] Columns I'm using exist: [list columns]
- [ ] Types match my code: [list type mappings]
- [ ] Relationships are correct: [list FKs]
- [ ] Nullable fields handled: [list nullable columns]
```

**Example in practice:**

```markdown
### Schema Verification for TODO-042 (Add order history endpoint)

- [x] Read schema: `src/db/schema.ts`
- [x] Columns exist: orders.id, orders.user_id, orders.status, orders.total_cents, orders.created_at
- [x] Types: id=uuid→string, total_cents=integer→number, status=text→OrderStatus enum
- [x] Relationships: orders.user_id → users.id (many-to-one)
- [x] Nullable: none of these columns are nullable
```

---

## Type Generation Commands

### Drizzle (TypeScript)

```typescript
// Schema defines types automatically
// src/db/schema.ts
import { pgTable, uuid, text, integer, timestamp } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: uuid('id').primaryKey().defaultRandom(),
  email: text('email').notNull().unique(),
  name: text('name'),
  createdAt: timestamp('created_at').notNull().defaultNow(),
});

export const orders = pgTable('orders', {
  id: uuid('id').primaryKey().defaultRandom(),
  userId: uuid('user_id').notNull().references(() => users.id),
  status: text('status').notNull().default('pending'),
  totalCents: integer('total_cents').notNull(),
  createdAt: timestamp('created_at').notNull().defaultNow(),
});

// Inferred types - USE THESE
export type User = typeof users.$inferSelect;
export type NewUser = typeof users.$inferInsert;
export type Order = typeof orders.$inferSelect;
export type NewOrder = typeof orders.$inferInsert;
```

### Prisma

```prisma
// prisma/schema.prisma
model User {
  id        String   @id @default(uuid())
  email     String   @unique
  name      String?
  orders    Order[]
  createdAt DateTime @default(now()) @map("created_at")

  @@map("users")
}

model Order {
  id         String   @id @default(uuid())
  userId     String   @map("user_id")
  user       User     @relation(fields: [userId], references: [id])
  status     String   @default("pending")
  totalCents Int      @map("total_cents")
  createdAt  DateTime @default(now()) @map("created_at")

  @@map("orders")
}
```

```bash
# Generate types after schema changes
npx prisma generate
```

### Supabase

```bash
# Generate TypeScript types from live database
supabase gen types typescript --local > src/types/database.ts

# Or from remote
supabase gen types typescript --project-id your-project-id > src/types/database.ts
```

```typescript
// Use generated types
import { Database } from '@/types/database';

type User = Database['public']['Tables']['users']['Row'];
type NewUser = Database['public']['Tables']['users']['Insert'];
type Order = Database['public']['Tables']['orders']['Row'];
```

### SQLAlchemy (Python)

```python
# app/models/user.py
from sqlalchemy import Column, String, DateTime
from sqlalchemy.dialects.postgresql import UUID
from sqlalchemy.sql import func
from app.db import Base
import uuid

class User(Base):
    __tablename__ = "users"

    id = Column(UUID(as_uuid=True), primary_key=True, default=uuid.uuid4)
    email = Column(String, nullable=False, unique=True)
    name = Column(String, nullable=True)
    created_at = Column(DateTime(timezone=True), server_default=func.now())

    # Relationships
    orders = relationship("Order", back_populates="user")
```

```python
# app/schemas/user.py - Pydantic for API validation
from pydantic import BaseModel, EmailStr
from uuid import UUID
from datetime import datetime

class UserBase(BaseModel):
    email: EmailStr
    name: str | None = None

class UserCreate(UserBase):
    pass

class User(UserBase):
    id: UUID
    created_at: datetime

    class Config:
        from_attributes = True
```

---

## Schema-Aware TDD Workflow

Extend the standard TDD workflow for database work:

```
┌─────────────────────────────────────────────────────────────┐
│  0. SCHEMA: Read and verify schema before anything else     │
│     └─ Read schema file                                     │
│     └─ Complete Schema Verification Checklist               │
│     └─ Note any missing columns/tables needed               │
├─────────────────────────────────────────────────────────────┤
│  1. RED: Write tests that use correct column names          │
│     └─ Import generated types                               │
│     └─ Use type-safe queries in tests                       │
│     └─ Tests should fail on logic, NOT schema errors        │
├─────────────────────────────────────────────────────────────┤
│  2. GREEN: Implement with type-safe queries                 │
│     └─ Use ORM types, not raw strings                       │
│     └─ TypeScript/mypy catches column mismatches            │
├─────────────────────────────────────────────────────────────┤
│  3. VALIDATE: Type check catches schema drift               │
│     └─ tsc --noEmit / mypy catches wrong columns            │
│     └─ Tests validate runtime behavior                      │
└─────────────────────────────────────────────────────────────┘
```

---

## Common Schema Mistakes (And How to Prevent)

| Mistake | Example | Prevention |
|---------|---------|------------|
| Wrong column name | `user.userName` vs `user.name` | Read schema, use generated types |
| Wrong type | `totalCents` as string | Type generation catches this |
| Missing nullable check | `user.name!` when nullable | Schema shows nullable fields |
| Wrong FK relationship | `order.userId` vs `order.user_id` | Check schema column names |
| Missing column | Using `user.avatar` that doesn't exist | Read schema before coding |
| Wrong enum value | `status: 'complete'` vs `'completed'` | Document enums in schema reference |

### Type-Safe Query Examples

**Drizzle (catches errors at compile time):**
```typescript
// ✅ Correct - uses schema-defined columns
const user = await db.select().from(users).where(eq(users.email, email));

// ❌ Wrong - TypeScript error: 'userName' doesn't exist
const user = await db.select().from(users).where(eq(users.userName, email));
```

**Prisma (catches errors at compile time):**
```typescript
// ✅ Correct
const user = await prisma.user.findUnique({ where: { email } });

// ❌ Wrong - TypeScript error
const user = await prisma.user.findUnique({ where: { userName: email } });
```

**Raw SQL (NO protection - avoid):**
```typescript
// ❌ Dangerous - no type checking, easy to get wrong
const result = await db.query('SELECT * FROM users WHERE user_name = $1', [email]);
// Should be 'email' not 'user_name' - won't catch until runtime
```

---

## Migration Workflow

When schema changes are needed:

```
┌─────────────────────────────────────────────────────────────┐
│  1. Update schema file (Drizzle/Prisma/SQLAlchemy)          │
├─────────────────────────────────────────────────────────────┤
│  2. Generate migration                                       │
│     └─ Drizzle: npx drizzle-kit generate                    │
│     └─ Prisma: npx prisma migrate dev --name add_column     │
│     └─ Supabase: supabase migration new add_column          │
├─────────────────────────────────────────────────────────────┤
│  3. Regenerate types                                         │
│     └─ Prisma: npx prisma generate                          │
│     └─ Supabase: supabase gen types typescript              │
├─────────────────────────────────────────────────────────────┤
│  4. Update schema-reference.md                               │
├─────────────────────────────────────────────────────────────┤
│  5. Run type check - find all broken code                    │
│     └─ npm run typecheck                                    │
├─────────────────────────────────────────────────────────────┤
│  6. Fix type errors, update tests, run full validation       │
└─────────────────────────────────────────────────────────────┘
```

---

## Session Start Protocol

**When starting a session that involves database work:**

1. Read schema file immediately
2. Read `_project_specs/schema-reference.md` if exists
3. Note in session state what tables/columns are relevant
4. Reference schema explicitly when writing code

**Session state example:**
```markdown
## Current Session - Database Context

**Schema read:** ✓ src/db/schema.ts
**Tables in scope:** users, orders, order_items
**Key columns:**
- users: id, email, name, created_at
- orders: id, user_id, status, total_cents
- order_items: id, order_id, product_id, quantity, price_cents
```

---

## Anti-Patterns

- ❌ **Guessing column names** - Always read schema first
- ❌ **Using raw SQL strings** - Use ORM with type generation
- ❌ **Hardcoding without verification** - Check schema before using any column
- ❌ **Ignoring type errors** - Schema drift shows up as type errors
- ❌ **Not regenerating types** - After migration, always regenerate
- ❌ **Assuming nullable** - Check schema for nullable columns

---

## Checklist

### Setup
- [ ] Schema file exists in standard location
- [ ] Type generation configured
- [ ] `_project_specs/schema-reference.md` created
- [ ] Types regenerate on schema change

### Per-Task
- [ ] Schema read before writing database code
- [ ] Schema Verification Checklist completed
- [ ] Using generated types (not raw strings)
- [ ] Type check passes (catches column errors)
- [ ] Tests use correct schema

© alinaqi · MIT · alinaqi/maggy

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой