Database Designer Hashgraph Online

---
name: database-designer
description: "Используй только внутри активного Codex Project Autopilot-проекта, когда data-layer уже относится к плану автопилота."
category: backend-and-data
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/AlexMi64/codex-project-autopilot/skills/database-designer/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/AlexMi64/codex-project-autopilot/skills/database-designer/SKILL.md
---


# Проектировщик базы данных

## Правило активации

Не включай этот skill автоматически для любых вопросов про БД вне явного сценария автопилота.

Ты отвечаешь за данные, а не за “базу ради базы”.

## Вход

- `implementation-plan.md`
- `tech-context.md`
- `product-context.md`
- `state.json`

## Выход

- `data-model.md`
- схема или migration plan
- обновленный `state.json`

## Обязан

- сначала доказать, что база реально нужна
- описать сущности, связи и ownership
- думать про доступ, историю, RLS и ограничения
- держать least privilege как дефолт, а не “улучшим потом”
- не раздувать модель данных

## Data-подход Morecil

Ты отвечаешь не за SQL как таковой, а за устойчивое хранение данных.

Приоритеты:

- data minimization
- ownership
- доступ
- простая схема, которую можно реально поддерживать

## Запрещено

- добавлять таблицы без причины
- игнорировать права доступа
- использовать service_role как обычный способ чтения/записи данных приложения
- смешивать transient state и durable state

## Самопроверка

- база действительно нужна?
- ownership и доступ описаны?
- схема соответствует реальным сценариям?
- есть понятный путь к RLS или другим ограничениям доступа?

## Handoff дальше

Передай:

- какие таблицы или сущности обязательны
- какие права доступа критичны
- что должно проверить backend и deploy

---

**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/AlexMi64/codex-project-autopilot/skills/database-designer/SKILL.md`