<название проекта>

Языковые настройки

Все ответы должны быть на русском языке.

Оркестратор скиллов

В самом начале каждого разговора если в проекте есть скилл оркестратор скиллов, вызывай его. Например: skill-orchestrator. Это обязательно.

Обзор проекта

<название проекта> — <одно предложение: что это и зачем>.

Примечание: Если часть ответственности вынесена в другой сервис/модуль — укажи явно, что НЕ входит в этот сервис.

Ключевые функции:

1. <функция 1>
2. <функция 2>
3. <функция 3>

Ключевые технологии

• <Язык/рантайм>: версия и роль
• <Фреймворк>: назначение
• <База данных>: что хранит
• <Внешний сервис>: зачем используется
• <Инструмент сборки/пакетный менеджер>

Архитектура

Архитектурный стиль (Clean Architecture / Hexagonal / MVC / ...) и ключевые принципы разделения.

Слои (если применимо):

1. Слой X (path/to/x/): назначение
2. Слой Y (path/to/y/): назначение
3. Слой Z (path/to/z/): назначение

Поток данных

Заполнять если у проекта есть осмысленный data flow (бэкенд, пайплайн, обработка событий). Для библиотек/CLI/фронта может быть неприменимо.

1. Что приходит и откуда
2. Как обрабатывается
3. Куда уходит

Настройка разработки

Требования

• <Язык/рантайм> версии X.Y
• <Зависимость 1> (зачем)
• <Зависимость 2> (зачем)

Быстрый старт

1. Установка зависимостей:

   <команда установки>

2. Запуск сервиса со всеми зависимостями:

   <команда запуска>

3. Запуск тестов:

   <команда тестов>

Доступные команды

Перечисли все команды из Makefile / Justfile / package.json scripts / taskfile и т.д.:

• <тул> <команда> — что делает
• <тул> <команда> — что делает
• <тул> <команда> — что делает

Структура кода

Ключевые директории и файлы. Для важных файлов — однострочное описание прямо в дереве.

<корень>/
├── <модуль1>/
│   ├── <subdir>/
│   │   ├── <file1.ext>      # назначение
│   │   └── <file2.ext>      # назначение
│   └── <file3.ext>          # назначение
├── <модуль2>/
│   └── ...
└── <config_file>            # назначение

Отдельно выдели файлы, которые сложно найти но важно знать:

• path/to/key_file.ext — <почему важен>
• path/to/another.ext — <почему важен>

Тестирование

Типы тестов

• Юнит-тесты: что покрывают, где лежат
• Интеграционные тесты: что покрывают, какую инфраструктуру поднимают
• E2E / API-тесты: что покрывают

Структура тестов

tests/
├── <зеркало структуры src/>/
│   └── ...
├── conftest.py              # глобальные фикстуры
└── factories.py             # фабрики тестовых объектов (если есть)

Запуск

# Стандартный запуск
<команда>

# С параллелизацией / в CI-режиме (если отличается)
<команда>

Конфигурация

Как конфигурируется проект: переменные окружения, файлы конфига, secrets.

Ключевые группы настроек:

• <SettingsClass1> / <ENV_PREFIX>_*: что настраивает
• <SettingsClass2> / <ENV_PREFIX>_*: что настраивает

Где брать значения для локальной разработки: .env.example, docker-compose.yml, vault, и т.д.

Внешние интерфейсы

<Группа эндпоинтов 1> (базовый путь: /api/v1/...)

• METHOD /path — <одна строка: что делает>. Параметры: param1 (тип, обязательный), param2 (тип, опциональный, default). Особенности: <если есть>.
• METHOD /path/{id} — <одна строка>. Тело: {"field": тип}.

<Группа эндпоинтов 2> (внутренний API, без аутентификации)

• METHOD /path — <одна строка>.

<Consumer / Worker / CLI / Публичный API библиотеки> (если применимо)

• <команда или топик> — <что делает, что потребляет/публикует>.

Аутентификация: <JWT / API key / mTLS / нет> — как работает.

Развертывание

Из каких компонентов состоит при деплое:

• <компонент 1>: назначение (порт/ресурс)
• <компонент 2>: назначение
• <инфра-зависимости>: БД, очередь, кэш и т.д.

Соглашения по разработке

Качество кода

• Статический анализ: <инструмент> (конфиг: <файл>)
• Форматирование: <инструмент>
• Типизация: <инструмент>, строгий / нестрогий режим
• Автофиксы: <что запускается автоматически>

Используемые паттерны

• <Паттерн>: где применяется и зачем
• <Паттерн>: где применяется и зачем

Подводные камни / Что не делать

Вещи, на которые легко наступить и которые сложно понять из самого кода:

• <Ловушка 1>: что происходит если сделать неправильно, как делать правильно
• <Ловушка 2>: аналогично
• Не редактировать сгенерированные файлы в path/to/generated/
• Миграции БД не откатываем — пишем новые

Типичные задачи разработки

<Задача 1, например: Добавление нового эндпоинта>

1. Создать path/to/handler.ext с реализацией <интерфейс>
2. Зарегистрировать в path/to/router.ext
3. Добавить схему в path/to/schemas.ext
4. Написать тест в tests/path/to/test_handler.ext

<Задача 2, например: Добавление миграции БД>

<команда создания миграции "описание">

Затем проверить сгенерированный файл в path/to/migrations/ и применить:

<команда применения>

<Задача 3, например: Изменение бизнес-логики в конкретном слое>

1. Обновить path/to/domain_logic.ext
2. Изменить path/to/infra_adapter.ext если затронут внешний вызов
3. Обновить тесты