Промпт-інжиніринг: 20 готових промтів для розробників

Ти senior [мова/стек] розробник, проводиш код-рев'ю. Ось код: [встав код]. Перевір за списком: логічні помилки і краєві випадки, безпека (ін'єкції, валідація вводу, робота з секретами), продуктивність, читабельність і відповідність конвенціям [мова]. Для кожного зауваження вкажи рядок, серйозність (блокер / варто виправити / справа смаку) і запропонуй виправлення кодом. Якщо в якійсь категорії код чистий, напиши це одним рядком, зауважень не вигадуй.

Відрефактор цю функцію: [встав код]. Мова: [мова], версія: [версія]. Цілі: зменшити складність, прибрати дублювання, покращити іменування. Обмеження: поведінка функції не змінюється, публічний інтерфейс лишається тим самим, нові залежності не додаються. Подай результат у два кроки: спершу список проблем поточної версії, потім новий код з коментарем біля кожної зміненої ділянки, чому так краще.

Напиши юніт-тести для цієї функції: [встав код]. Фреймворк: [Jest / pytest / JUnit / інший]. Покрий: основний сценарій, краєві випадки (порожні значення, межі діапазонів, невалідний ввід), помилки, які функція має кидати. Кожен тест називай так, щоб з назви було зрозуміло, що саме перевіряється. Наприкінці перелічи випадки, які юніт-тестами покрити неможливо, і поясни чому.

Допоможи знайти причину помилки. Стек-трейс: [встав]. Код проблемної ділянки: [встав]. Оточення: [мова, версія, ОС, фреймворк]. Що я вже перевірив: [перелічи]. Дай 3-5 гіпотез, відсортованих за ймовірністю. Для кожної: як швидко її перевірити (конкретна команда, лог або точка зупинки) і як виправити, якщо підтвердиться. Не пропонуй те, що я вже перевірив.

Оптимізуй запит: [встав SQL]. СУБД: [PostgreSQL / MySQL / інша]. Структура таблиць та наявні індекси: [опиши або встав DDL]. Приблизні розміри таблиць: [цифри]. Поясни, що в запиті працює повільно і чому, дай переписаний варіант і потрібні індекси. Окремо вкажи, як перевірити ефект через EXPLAIN і на які рядки плану дивитись.

Напиши регулярний вираз для задачі: [опиши, що треба матчити]. Приклади валідних рядків: [3-5 прикладів]. Приклади невалідних: [3-5 прикладів]. Діалект: [JavaScript / PCRE / Python re]. Розбери вираз почастинно: що робить кожен блок. Прожени всі мої приклади і покажи результат для кожного. Додай 3 підступні рядки, на яких вираз може поводитись неочікувано.

Напиши документацію до цього модуля: [встав код]. Формат: [docstring / розділ README / сторінка вікі]. Аудиторія: розробник, який бачить код уперше і має почати ним користуватись за 10 хвилин. Включи: що робить модуль, приклад використання з реальними значеннями, опис параметрів і значень, що повертаються, типові помилки. Пиши тільки з коду. Якщо призначення якогось параметра з коду неочевидне, познач це місце питанням до мене.

Перепиши цей код з [мова 1] на [мова 2]: [встав код]. Дотримуйся ідіом цільової мови замість дослівного перекладу конструкцій. Після коду дай список місць, де поведінка може відрізнятись: робота з типами, помилками, кодуваннями, конкурентністю. Для кожного такого місця вкажи, що я маю перевірити руками.

Спроєктуй REST API для [фіча, наприклад: коментарі до статей]. Контекст продукту: [опис]. Опиши: ендпоінти з методами, структури запитів і відповідей у JSON, коди статусів включно з помилками, правила пагінації і фільтрації, підхід до авторизації. Для спірних рішень (вкладені ресурси, версіонування) наведи варіанти з плюсами кожного і своє рішення з причиною.

Допоможи ухвалити архітектурне рішення: [опиши вибір, наприклад: моноліт чи окремий сервіс для нового модуля]. Контекст: команда з [розмір] людей, навантаження [цифри або оцінка], стек [стек], дедлайн [строк]. Розпиши 2-3 варіанти: що дає, чого коштує зараз, які ризики через рік. Постав мені 5 питань, відповіді на які могли б змінити рекомендацію. Наприкінці дай рекомендацію під мій контекст з головною причиною.

Спроєктуй схему бази даних під фічу: [опис фічі та основних сценаріїв]. СУБД: [назва]. Опиши таблиці з полями і типами, зв'язки, індекси під перелічені сценарії читання, обмеження цілісності. Окремо: які запити будуть найчастішими і як схема їх витримає, де можлива денормалізація і чим вона окупиться. Формат: DDL плюс пояснення до неочевидних рішень.

Декомпозуй задачу: [встав опис фічі або тикета]. Стек: [стек]. Розбий на підзадачі тривалістю до одного дня кожна, у порядку виконання, з залежностями між ними. Для кожної вкажи: результат, який можна перевірити, і головний ризик, який може її роздути. Окремо винеси питання, які треба з'ясувати до старту, і те, що можна викинути з першої версії без втрати сенсу фічі.

Напиши опис pull request. Зміни: [встав diff або перелічи зміни]. Задача: [опис або текст тикета]. Структура: що зроблено і навіщо у двох реченнях, список ключових змін, як тестувати покроково, на що звернути увагу на рев'ю, чи є міграції або зміни конфігурації. Пиши так, щоб рев'юер зрозумів контекст без відкривання тикета.

Допоможи написати post-mortem інциденту. Що сталося: [опиши хронологію]. Вплив: [хто і як постраждав, тривалість]. Як знайшли і полагодили: [опиши]. Оформи за структурою: короткий підсумок, таймлайн, корінна причина за методом п'яти «чому», що спрацювало добре, конкретні дії, щоб не повторилось, з перевірюваним результатом кожної. Тон безоцінний, без пошуку винних.

Поясни технічне рішення [опиши рішення] людині без технічного бекграунду: [хто це]. Без жаргону і абревіатур. Побудуй пояснення через наслідки для бізнесу: строки, гроші, ризики. Обсяг до 120 слів. Додай одну побутову аналогію. Наприкінці дай готову відповідь на найімовірніше питання цієї людини: скільки це займе і що буде, якщо цього не зробити.

Перепиши цей тикет так, щоб розробник міг взяти його в роботу без додаткових питань: [встав поточний текст і все, що знаєш про задачу]. Структура: контекст у двох реченнях, що саме зробити, критерії приймання списком (кожен можна перевірити), що поза скоупом, технічні нотатки. Якщо критичної інформації бракує, познач ці місця конкретними питаннями.

Ось вакансія: [встав текст]. Ось моє резюме: [встав]. Порівняй за трьома списками: які вимоги вже закриті; що з мого досвіду релевантне, але в резюме не показане; яких навичок бракує насправді. Потім перепиши блок досвіду: релевантні проєкти першими, кожен пункт починається з дії і містить технології та результат у цифрах, де вони є (навантаження, швидкість, строки). Досвід не вигадуй.

Ти senior-інтерв'юер на позицію [позиція і рівень]. Мій стек: [стек], досвід: [роки і головні проєкти]. Проведи тренувальну технічну співбесіду: питання по одному, від базових до глибоких, включно з питаннями по моїх проєктах і однією задачею на системний дизайн. Після кожної моєї відповіді розбирай її: що добре, де неточність, як відповів би сильний кандидат.

Ось тестове завдання: [встав умову]. Ось моє рішення: [встав код або опиши структуру репозиторію]. Оціни його очима рев'юера компанії: що спрацює в плюс, що викличе питання, які поширені критерії таких завдань я не закрив (тести, README, обробка помилок, структура проєкту). Дай список правок за пріоритетом з оцінкою часу на кожну.

Оптимізуй мій профіль LinkedIn під позицію [позиція]. Поточний заголовок: [встав]. Розділ About: [встав]. Дай 3 варіанти заголовка до 220 символів з технологіями, за якими рекрутери шукають таких фахівців, і новий About на 4-5 речень: стек, типи продуктів, результати в цифрах, чим корисний команді. Без слів «пристрасний», «мотивований» і «гуру».