Загрузка данных

01-agent-workflow.mdc
---
description: Процесс работы агента: уточнения, планирование, выполнение
alwaysApply: true
---
# ПРОЦЕСС РАБОТЫ АГЕНТА

## Этап 0: Анализ запроса (ОБЯЗАТЕЛЕН)

Прежде чем писать ЛЮБОЙ код, проведи анализ:

### Если запрос неоднозначный или общий:
Задай уточняющие вопросы. Не стесняйся быть дотошным. Лучше задать 10 вопросов сейчас, чем переписывать код 3 раза потом.

**Обязательные уточнения (если не указаны):**

1. **Цель:** Что именно должен делать этот код? Какую бизнес-задачу решает?
2. **Границы:** Что код НЕ должен делать? Какие сценарии вне scope?
3. **Входные данные:** Какие данные приходят? В каком формате? Есть ли пример?
4. **Выходные данные:** Что должен вернуть/сделать код? Какой формат ответа?
5. **Интеграция:** Как этот код будет использоваться? Кто его вызывает? Куда встраивается?
6. **Ограничения:** Есть ли ограничения по производительности, памяти, времени?
7. **Обработка ошибок:** Что делать при невалидных данных? Как обрабатывать исключения?
8. **Зависимости:** Можно ли использовать сторонние библиотеки? Какие уже есть в проекте?
9. **Совместимость:** С какими версиями языка/фреймворка должен работать код?
10. **Тестирование:** Нужны ли тесты? (По умолчанию — НЕТ, только если явно попросили)

### Если запрос уже детальный:
Проверь, всё ли учтено. Если видишь потенциальные проблемы — укажи на них ДО написания кода.

## Этап 1: План реализации (ОБЯЗАТЕЛЕН)

После уточнений составь план:
ПЛАН:

Изменить файл X — причина, что именно меняем

Создать файл Y — назначение, ключевые функции

Обновить файл Z — интеграция с существующим кодом
...
Потенциальные риски:

Риск 1 — как митигируем

Риск 2 — как митигируем


**Покажи план пользователю и дождись подтверждения** (если пользователь не сказал "делай сразу без плана").

## Этап 2: Реализация

- Следуй плану
- Если в процессе находишь проблему с планом — остановись и сообщи
- Не делай "заодно" дополнительных изменений, которых нет в плане. Исключение: необоснованное дублирование кода

## Этап 3: Саморевью (ОБЯЗАТЕЛЕН)

После написания кода проведи ревью:

### Проверь функциональность:
- [ ] Код делает ровно то, что просили (не больше, не меньше)
- [ ] Все ветвления логики обработаны
- [ ] Нет очевидных багов (off-by-one, null reference, неправильные условия)
- [ ] Обработка ошибок присутствует там, где нужна

### Проверь интеграцию:
- [ ] Импорты корректны и существуют
- [ ] Сигнатуры функций совместимы с вызывающим кодом
- [ ] Нет конфликтов имён
- [ ] Типы данных совместимы

### Проверь чистоту:
- [ ] Нет мёртвого кода
- [ ] Нет закомментированных блоков
- [ ] Нет дублирования (если есть — вынеси в функцию)
- [ ] Нет лишних зависимостей

### Если находишь проблему:
НЕ игнорируй. Исправь сразу или сообщи пользователю.

## Этап 4: Отчёт

После завершения работы предоставь краткий отчёт:
ЧТО СДЕЛАНО:

Файл X: описание изменений

Файл Y: создан, назначение

ЧТО ПРОВЕРЕНО:

Функциональность: OK

Интеграция: OK

Чистота: OK

ВОЗМОЖНЫЕ ПРОБЛЕМЫ:

[Если есть] Описание проблемы и рекомендация

## Важно про тесты
НЕ пиши тесты, если пользователь явно не попросил.
НЕ запускай тесты, даже если они существуют в проекте.
Если считаешь, что тесты нужны — просто упомяни это в отчёте.


## Работа с git (только чтение)

### Когда использовать git:
- **Перед изменением файла** — `git log --oneline -5 <файл>` чтобы понять, как файл менялся
- **При поиске причин багов** — `git blame <файл>` чтобы найти когда и кем внесена строка
- **При анализе контекста** — `git diff HEAD` чтобы увидеть незакоммиченные изменения
- **При изучении связанных изменений** — `git show <commit-hash>` чтобы посмотреть конкретный коммит

### Когда НЕ использовать git:
- Не предлагай сделать commit/push — пользователь сам решит
- Не откатывай изменения через git — только через прямое редактирование
- Не переключай ветки — работай с текущим состоянием




















02-code-quality.mdc
---
description: Стандарты качества кода и архитектурные принципы
alwaysApply: true
---
# СТАНДАРТЫ КАЧЕСТВА КОДА

## Архитектурные принципы

### 1. Единственная ответственность (SRP)
Каждая функция/класс/модуль делает ОДНУ вещь. Если функция делает "X и Y" — разбей на две.

### 2. Минимальная связность
Модули должны зависеть от абстракций, а не конкретных реализаций. Избегай жёстких зависимостей.

### 3. Читаемость > Хитрость
Код должен быть понятен junior-разработчику. Сложные однострочники оправданы только если есть комментарий.
Добавлять всегда аннотицаю, типизациюю, док стринг

### 4. Принцип наименьшего удивления
Код должен вести себя так, как ожидает читающий. Никаких скрытых сайд-эффектов. Никаких финтов или использований неявных следствий

## Код-стиль

### Именование:
- Функции: глагол + существительное (`get_user_by_id`, `validate_token`)
- Переменные: существительное, отражающее содержимое (`user_list`, `is_valid`)
- Булевы: начинаются с `is`, `has`, `should`, `can`
- Константы: UPPER_SNAKE_CASE
- Классы/типы: PascalCase

### Функции:
- Максимум 50-70 строк (если больше — разбивай)
- Максимум 4-5 параметров (если больше — передавай объект)
- Один уровень абстракции на функцию
- Ранний возврат вместо вложенных if

### Комментарии:
- НЕ комментируй "что" (код сам говорит)
- Комментируй "почему" (объясняй неочевидные решения)
- Опсиание функций с упором на причинно-следственные связи
- Добавляй в описания капельку теории
- TODO/FIXME — только с описанием контекста

## Обработка ошибок

### Правила:
1. НЕ игнорируй ошибки (если поймал — обработай или пробрось)
2. НЕ используй `catch {}` без обработки
3. Сообщения об ошибках должны быть информативными (не "Error", а "Failed to parse user data: field 'email' is missing")
4. Используй типизированные ошибки, где возможно
5. Валидируй входные данные на границах системы

## Безопасность (базовый минимум)

- НЕ хардкодь секреты (пароли, ключи, токены) — используй конфигурацию
- Экранируй пользовательский ввод (SQL injection, XSS)
- Проверяй права доступа там, где это нужно
- НЕ выводи чувствительные данные в логи

## Производительность (базовый минимум)

- НЕ оптимизируй преждевременно
- НО избегай очевидных проблем: N+1 запросы, бесконечные циклы, утечки памяти
- Используй подходящие структуры данных
- Кэшируй только если это реально нужно

## Про запрещённые паттерны

- НЕ используй `any` (TypeScript) без крайней необходимости
- НЕ используй глобальные переменные
- НЕ создавай god-классы/функции (всё в одном)
- НЕ используй магические числа — выноси в именованные константы
- НЕ игнорируй предупреждения линтера без причины



























03-global-guard.mdc
---
description: Стандарты качества кода и архитектурные принципы
alwaysApply: true
---
# СТАНДАРТЫ КАЧЕСТВА КОДА

## Архитектурные принципы

### 1. Единственная ответственность (SRP)
Каждая функция/класс/модуль делает ОДНУ вещь. Если функция делает "X и Y" — разбей на две.

### 2. Минимальная связность
Модули должны зависеть от абстракций, а не конкретных реализаций. Избегай жёстких зависимостей.

### 3. Читаемость > Хитрость
Код должен быть понятен junior-разработчику. Сложные однострочники оправданы только если есть комментарий.
Добавлять всегда аннотицаю, типизациюю, док стринг

### 4. Принцип наименьшего удивления
Код должен вести себя так, как ожидает читающий. Никаких скрытых сайд-эффектов. Никаких финтов или использований неявных следствий

## Код-стиль

### Именование:
- Функции: глагол + существительное (`get_user_by_id`, `validate_token`)
- Переменные: существительное, отражающее содержимое (`user_list`, `is_valid`)
- Булевы: начинаются с `is`, `has`, `should`, `can`
- Константы: UPPER_SNAKE_CASE
- Классы/типы: PascalCase

### Функции:
- Максимум 50-70 строк (если больше — разбивай)
- Максимум 4-5 параметров (если больше — передавай объект)
- Один уровень абстракции на функцию
- Ранний возврат вместо вложенных if

### Комментарии:
- НЕ комментируй "что" (код сам говорит)
- Комментируй "почему" (объясняй неочевидные решения)
- Опсиание функций с упором на причинно-следственные связи
- Добавляй в описания капельку теории
- TODO/FIXME — только с описанием контекста

## Обработка ошибок

### Правила:
1. НЕ игнорируй ошибки (если поймал — обработай или пробрось)
2. НЕ используй `catch {}` без обработки
3. Сообщения об ошибках должны быть информативными (не "Error", а "Failed to parse user data: field 'email' is missing")
4. Используй типизированные ошибки, где возможно
5. Валидируй входные данные на границах системы

## Безопасность (базовый минимум)

- НЕ хардкодь секреты (пароли, ключи, токены) — используй конфигурацию
- Экранируй пользовательский ввод (SQL injection, XSS)
- Проверяй права доступа там, где это нужно
- НЕ выводи чувствительные данные в логи

## Производительность (базовый минимум)

- НЕ оптимизируй преждевременно
- НО избегай очевидных проблем: N+1 запросы, бесконечные циклы, утечки памяти
- Используй подходящие структуры данных
- Кэшируй только если это реально нужно

## Про запрещённые паттерны

- НЕ используй `any` (TypeScript) без крайней необходимости
- НЕ используй глобальные переменные
- НЕ создавай god-классы/функции (всё в одном)
- НЕ используй магические числа — выноси в именованные константы
- НЕ игнорируй предупреждения линтера без причины