5 рабочих промптов под бизнес, маркетинг, sales, код и research. Скопируйте и адаптируйте под свой контекст.
Пишет unit-тесты, начиная с edge cases, а не happy path.
Сгенерируй unit-тесты для функции. Правила: - Начни с 3 edge cases и описания почему каждый важен - Потом happy path (минимум) - Используй фреймворк, который указан в инпуте (например, vitest/pytest) - Не выдумывай поведение, которого нет в коде — если что-то непонятно, спроси Вход: код функции и фреймворк.
Делает code review с акцентом на корректность, читаемость и безопасность.
Сделай code review для следующего диффа. Правила: - Никакого "looks good!" без обоснования - Чёткое разделение: BLOCKERS / SHOULD-FIX / NIT - Под каждым пунктом 1-2 предложения и, если применимо, пример исправления - Особое внимание: security, edge cases, error handling, mutation of shared state - В конце — 1 строка с резюме "merge as-is / merge after fixes / needs rework" <diff>: <…>
Готовит план рефакторинга с шагами, рисками и тестовым покрытием на каждом этапе.
Подготовь план рефакторинга модуля. Структура: - Цель рефакторинга (одно предложение) - Что мы НЕ меняем (поведение, контракт) - Шаги (5-10), каждый — атомарный и независимо релизуемый - Под каждым шагом: какие тесты должны проходить, какие риски - Roll-back план Вход: описание модуля и проблемы.
Объясняет непонятный кусок легаси-кода по слоям: что, зачем, какие зависимости.
Объясни легаси-код по слоям. Структура объяснения: 1. Что эта функция/модуль делает (одно предложение) 2. Какие у неё контракты на входе/выходе 3. Какие внешние зависимости (БД, сеть, файлы) 4. Какие предположения о входных данных и где они могут ломаться 5. Где «бомбы»: код, который выглядит безопасным, но не такой Вход: код.
Превращает «у меня не работает» в репортируемый баг с шагами.
Превратись в QA-инженера. Помоги пользователю написать хороший баг-репорт. Вытащи из инпута: 1. Что именно сломалось (одно предложение) 2. Шаги воспроизведения (нумерованный список) 3. Ожидаемое поведение 4. Фактическое поведение 5. Окружение: OS, версия, браузер, время 6. Логи / скриншоты — список того, что было бы полезно приложить Если данных не хватает — задай 3-5 уточняющих вопросов перед тем, как составить отчёт.