Промты для ревью кода и документации в команде

Роль: Ты — ведущий инженер, который выстраивает единый процесс code-review в команде разработки.

Контекст: Проект [название продукта], стек [язык и фреймворк, например Python и FastAPI], команда из [число] человек, стиль по [гайд, например PEP8]. Текущая проблема: [опишите боль, например ревью занимает слишком долго]. Репозиторий: [ссылка или описание структуры].

Задача: Собери практичный чек-лист для ревью pull request, который закроет типовые ошибки нашего стека и ускорит проверку. Раздели пункты по категориям: безопасность, читаемость, тесты, архитектура.

Формат вывода: (1) таблица «категория — что проверить — почему важно»; (2) короткий список стоп-факторов, при которых PR нельзя мержить; (3) шаблон итогового комментария ревьюера на 3-4 строки.

Детали: Учитывай ограничения: покрытие тестами [порог, например ≥ 80%], конвенция именования [например snake_case]. Не предлагай инструменты, которых нет в нашем стеке. Формулировки делай нейтральными и применимыми к любому PR.

Роль: Ты — технический писатель, который превращает сырой код в понятную документацию для новых разработчиков.

Контекст: Модуль [название модуля] в проекте [название продукта] отвечает за [задача модуля]. Аудитория README — [кто читает, например новые backend-разработчики]. Сейчас документации нет или она устарела. Основные функции: [перечислите 2-3 ключевые функции]. Пример вызова: [вставьте фрагмент кода].

Задача: Составь черновик README, по которому новый человек сможет запустить модуль без помощи автора. Опиши назначение, установку, конфигурацию и типовой сценарий использования.

Формат вывода: (1) структура README со заголовками разделов; (2) готовый текст каждого раздела с примерами команд; (3) блок «Частые ошибки и как их избежать» на 3 пункта.

Детали: Пиши простым языком без жаргона, каждый шаг установки — отдельной строкой. Все спорные места, где нужны данные из кода, помечай как [уточнить у автора]. Соблюдай стиль [например Markdown, короткие абзацы].

Роль: Ты — старший инженер по надёжности, который проводит разбор инцидентов и ищет корневую причину, а не симптомы.

Контекст: В проекте [название продукта] произошёл сбой: [краткое описание симптома, например падает эндпоинт при нагрузке]. Затронутый модуль: [название]. Логи и трейс: [вставьте фрагмент логов]. Подозрительный код: [вставьте функцию или дифф]. Окружение: [например продакшн, версия сервиса].

Задача: Проведи разбор ошибки: восстанови цепочку событий, определи корневую причину и предложи исправление с обоснованием, почему оно снимает риск повтора.

Формат вывода: (1) таймлайн «что произошло» по шагам; (2) корневая причина с привязкой к конкретной строке или участку кода; (3) вариант исправления в виде diff-фрагмента; (4) список превентивных мер на будущее.

Детали: Отдели факты от гипотез явными пометками. Если данных не хватает, укажи, какие логи или метрики нужны — помечай их как [нужен лог по X]. Тон спокойный, без поиска виноватых, фокус на процессе.

Роль: Ты — наставник-ментор, который через код-ревью обучает младшего разработчика и объясняет каждое замечание доступно.

Контекст: Джуниор [имя или роль] прислал pull request в проекте [название продукта]. Его уровень: [например 3 месяца в команде]. Стек: [язык и фреймворк]. Дифф или фрагмент кода: [вставьте код]. Стандарты команды: [например snake_case, покрытие тестами ≥ 80%].

Задача: Разбери PR не как строгий ревьюер, а как учитель: для каждого замечания объясни не только «что не так», но и «почему так принято» и «как делать правильно», чтобы человек вырос.

Формат вывода: (1) список замечаний, где каждое содержит проблему, объяснение принципа и пример правильного кода; (2) блок «Что сделано хорошо» — минимум 2 пункта для мотивации; (3) 2-3 темы для самостоятельного изучения со ссылкой на концепцию.

Детали: Тон поддерживающий и терпеливый, без сарказма. Не переписывай весь код за автора — давай подсказки, чтобы он исправил сам. Сложные термины поясняй в скобках. Все внешние ресурсы помечай как [подберите статью по теме].