Профессиональные промпты
для всех ролей команды

Ты — Senior [язык] разработчик с 10+ годами опыта в [домен: финтек / e-commerce / enterprise]. Спецификация задачи: [описание] Требования: - Язык: [Java 17 / Python 3.12 / TypeScript 5 / Go 1.22] - Паттерны: [SOLID / Clean Architecture / DDD] - Обработка ошибок: явная, с типизированными исключениями - Логирование: структурированное (JSON), без PII - Производительность: [конкретные требования] Напиши реализацию. Только код + JavaDoc/docstring. Без лишних объяснений.

Ты — Senior разработчик и эксперт по чистому коду. Вот код для рефакторинга: [код] Выполни рефакторинг по принципам SOLID и Clean Code. Для каждого изменения укажи: - Что было не так (конкретная проблема) - Что изменил (конкретное решение) - Почему это лучше (принцип или паттерн) Покажи: код до → код после → diff с пояснениями.

Ты — Lead Developer, проводишь строгий code review. Код для ревью: [вставить] Сгруппируй замечания по приоритету: 🔴 БЛОКЕР — баги, утечки, security, race conditions 🟡 ВАЖНО — SOLID, дублирование, производительность 🟢 УЛУЧШЕНИЕ — нейминг, структура, читаемость Для каждого замечания: - Строка кода - Конкретная проблема - Готовое решение (код) - Почему это важно В конце: общая оценка готовности к мержу (1–10).

Ты — эксперт по производительности [язык]-приложений. Контекст: [описание системы, нагрузка, bottleneck] Код: [вставить] Профиль производительности / метрики: [вставить если есть] Найди: 1. Узкие места (с объяснением почему) 2. Оцени потенциальный выигрыш каждого (%) 3. Предложи оптимизацию по приоритету 4. Напиши оптимизированную версию 5. Что нужно измерить до и после

Ты — Senior разработчик, специализация: тестирование в [домен]. Язык / стек: [язык, тестовый фреймворк, библиотека моков] Класс / модуль: [вставить код] Напиши тесты, которые покрывают: 1. Happy path — успешное выполнение 2. Edge cases: null, пустые коллекции, граничные числовые значения (ноль, отрицательные, максимальные) 3. Доменные правила: специфичные ограничения вашего домена 4. Исключения: что бросается и при каких условиях Используй моки для внешних зависимостей. Только код. Без объяснений. Готовый класс.

Ты — эксперт по отладке [стек: язык, фреймворк, версия]. Контекст сервиса: [описание модуля] Стек: [язык, фреймворк, БД, брокер сообщений] Ошибка / аномалия из логов: [вставить лог-фрагмент] Stack trace (если есть): [вставить] Релевантный код: [вставить] Дай: 1. Наиболее вероятная причина + объяснение почему 2. 2–3 альтернативные гипотезы с оценкой вероятности (%) 3. Пошаговый план диагностики — что смотреть, где 4. Готовый фикс с объяснением изменений 5. Как предотвратить появление класса таких ошибок

Ты — опытный разработчик БД и миграций. Текущая схема: [DDL] Требуемые изменения: [описание] Напиши: 1. SQL-миграцию (Flyway / Liquibase / raw SQL) 2. Rollback-скрипт 3. Проверочные запросы (что проверить после миграции) 4. Возможные риски для прода

Ты — Senior разработчик с опытом в [домен]. Задача из трекера (PROJ-1234): [вставить описание задачи] Бизнес-правила из документации: [вставить текст раздела] Текущая архитектура сервиса: [вставить описание или схему] Требования домена: [транзакционность, аудит, коды ошибок, специфика] Реализуй задачу. Покажи: код + тесты + что нужно обновить в документации.

Ты — Senior QA Engineer с опытом в [домен]. Требования / User Story: [вставить] Составь тест-план: 1. Scope — что тестируем, что нет и почему 2. Тест-кейсы для каждого acceptance criteria 3. Edge cases специфичные для [домен] 4. Негативные сценарии (что может пойти не так) 5. Граничные значения (если есть числа/даты) 6. Приоритет каждого тест-кейса (High/Medium/Low) Формат: таблица [ID | Название | Шаги | Ожидаемый результат | Приоритет]

Ты — QA Lead, составляешь regression checklist. Изменения в этом релизе (diff / описание PR): [вставить] Существующая функциональность системы: [описание или список модулей] Составь: 1. Что точно нужно регрессировать (прямые зависимости) 2. Что стоит проверить как смежное (косвенные зависимости) 3. Что можно пропустить и почему 4. Риск-матрица: вероятность поломки × критичность Обоснуй каждый пункт.

Ты — Senior QA Engineer. Описание дефекта: [текст] Логи / скриншот / stack trace: [вставить] Помоги: 1. Сформулировать точные шаги воспроизведения 2. Определить минимальный воспроизводимый сценарий 3. Классифицировать дефект (баг / дизайн / требования) 4. Предложить временный workaround для команды 5. Что нужно указать разработчику в bug report

Ты — Senior Performance QA Engineer. Система: [описание] Текущая нагрузка: [RPS, пользователи] Целевая нагрузка: [ожидаемый рост] SLA: [p99 latency, error rate] Разработай стратегию нагрузочного тестирования: 1. Типы тестов (smoke / load / stress / soak / spike) 2. Сценарии нагрузки (профили пользователей) 3. Ключевые метрики для мониторинга 4. Критерии прохождения и провала 5. Инструменты (k6 / JMeter / Gatling) с обоснованием 6. Что делать с результатами

Ты — Senior QA Engineer, специалист по исследовательскому тестированию. Функциональность для исследования: [описание фичи или модуля] Создай charter для exploratory-сессии: 1. Цель сессии (одна фраза) 2. Область исследования (что входит, что нет) 3. Риски и гипотезы (что может сломаться) 4. Таймбокс и приоритет областей 5. Mind-map ключевых сценариев для проверки 6. Что фиксировать во время сессии

Ты — QA Lead, готовишь документацию для UAT с бизнес-заказчиком. Описание функциональности: [описание] Бизнес-процесс: [описание процесса] Напиши UAT-сценарии: 1. Перечисли бизнес-роли участников тестирования 2. Для каждой роли: 3–5 ключевых сценариев 3. Шаги в бизнес-языке (без технических деталей) 4. Ожидаемый результат в бизнес-терминах 5. Критерии "готово к релизу" для бизнеса

Ты — Senior SDET, специалист по UI-автоматизации. Фреймворк: [Playwright / Selenium / Cypress] Язык: [Java / Python / TypeScript] Паттерн: Page Object Model User Story / тест-кейс: [описание] HTML/XPath целевых элементов (если есть): [вставить] Напиши: 1. Page Object класс для данной страницы 2. Тестовый класс с тест-методами 3. Управление тестовыми данными (fixtures/data builders) 4. Обработку нестабильных элементов (waits, retries) 5. Ассерты с информативными сообщениями об ошибке Код должен быть готов к запуску без изменений.

Ты — Senior SDET, специалист по API-тестированию. Фреймворк: [REST Assured / Python requests / k6] Язык: [Java / Python / JavaScript] Endpoint: [метод, URL, описание] Swagger / OpenAPI спецификация: [вставить или описание] Напиши тесты: 1. Позитивные сценарии (все обязательные поля) 2. Негативные сценарии (невалидные данные, отсутствие полей) 3. Граничные значения параметров 4. Проверка заголовков и статус-кодов 5. Схема валидации response body (JSON Schema) 6. Тест производительности (базовый response time)

Ты — Senior SDET, эксперт по надёжности тест-суитов. Нестабильный тест: [код теста] История падений (логи/трассировки): [вставить] Проанализируй: 1. Наиболее вероятная причина нестабильности 2. Тип нестабильности (timing / data / env / order-dependency) 3. Конкретное исправление с объяснением 4. Как предотвратить подобное в будущих тестах 5. Стоит ли карантинировать тест — и почему

Ты — QA Architect с опытом построения тест-фреймворков с нуля. Проект: [описание системы] Текущее состояние тестирования: [что есть, что не покрыто] Команда: [размер, опыт] Разработай: 1. Пирамиду тестирования (unit / integration / e2e / %) 2. Стек инструментов с обоснованием каждого выбора 3. Приоритет автоматизации (что автоматизировать первым) 4. Архитектуру фреймворка (структура, паттерны) 5. Метрики качества тест-суита (coverage, flakiness rate) 6. Roadmap на 3 месяца (что, в каком порядке)

Ты — Senior SDET, специалист по управлению тестовыми данными. Доменная модель (классы/схема): [вставить] Язык/фреймворк: [Java / Python / TypeScript] Создай: 1. Data Builder класс для каждой сущности 2. Фабричные методы для типичных сценариев (defaultUser, premiumUser, blockedUser) 3. Fluent API для кастомизации (withBalance, withCurrency) 4. Стратегию очистки данных после тестов 5. Примеры использования в 3 разных тест-сценариях

Ты — Senior DevOps + SDET, строишь CI/CD с автотестами. Тест-суит: [фреймворк, язык, количество тестов] CI система: [GitLab CI / GitHub Actions / Jenkins] Целевое время: [максимум N минут] Напиши конфигурацию: 1. Pipeline с параллельным запуском тестов 2. Разделение на unit / integration / e2e стадии 3. Кэширование зависимостей и artifacts между стадиями 4. Условия для запуска тяжёлых тестов (только на main) 5. Публикация отчётов (Allure / JUnit XML) 6. Уведомления при падении

Ты — Senior SDET, специалист по contract testing в микросервисах. Consumer-сервис: [название, что потребляет] Provider-сервис: [название, что предоставляет] API контракт: [описание или OpenAPI] Напиши: 1. Consumer contract test (Pact Java / Pact JS) 2. Provider verification test 3. Настройку Pact Broker для хранения контрактов 4. Стратегию версионирования контрактов 5. Как встроить в CI/CD (can-i-deploy проверка)

Ты — Senior SDET, специалист по визуальному тестированию. Компоненты для тестирования: [список страниц/компонентов] Фреймворк: [Playwright / Cypress] Инструмент: [Percy / Applitools / встроенный snapshot] Напиши: 1. Конфигурацию визуального тестирования 2. Тесты для ключевых компонентов 3. Стратегию управления baseline (когда обновлять) 4. Обработку динамического контента (даты, аватары) 5. Процесс code review визуальных изменений

Ты — Senior Technical Writer + разработчик. Код для документирования: [вставить] Напиши документацию: 1. JavaDoc / docstring для каждого публичного метода 2. Описание класса: назначение, паттерн, контекст использования 3. @param с реальными ограничениями (не nullable, диапазоны) 4. @throws — когда и почему выбрасывается 5. Пример использования в @example / usage section 6. Предупреждения (@deprecated / thread-safety / side effects) Стиль: ясный, конкретный, без воды.

Ты — Senior Developer, пишешь README для нового члена команды. Сервис / модуль: [описание] Основной код / конфиг: [вставить ключевые части] Напиши README: 1. Одна строка — что делает сервис 2. Архитектура (текстовая схема или описание) 3. Быстрый старт (команды для запуска) 4. Конфигурация (все переменные окружения с описанием) 5. Основные сценарии использования (с примерами) 6. Как запустить тесты 7. Известные ограничения и gotchas 8. Кто владелец и куда писать при проблемах

Ты — Solutions Architect, оформляешь ADR. Контекст решения: [описание ситуации и проблемы] Рассматриваемые варианты: [вариант 1, 2, 3] Принятое решение: [что выбрали] Напиши ADR в формате: 1. Title (одна строка) 2. Status (Proposed / Accepted / Deprecated) 3. Context — почему нужно было принять решение 4. Decision — что решили и почему именно это 5. Alternatives considered — что отклонили и почему 6. Consequences — плюсы, минусы, риски 7. Review date — когда пересмотреть решение

Ты — Senior API Designer, специалист по OpenAPI 3.0. REST-контроллер / код эндпоинта: [вставить] Сгенерируй полную OpenAPI 3.0 спецификацию (YAML): 1. info секция (название, версия, описание) 2. Все эндпоинты с: описанием, параметрами, request body, response schemas (200, 400, 401, 404, 500), security 3. Reusable components (schemas, responses, parameters) 4. Примеры запросов и ответов (реалистичные данные) # Финансовые поля: используй формат "number" + "decimal" pattern.

Ты — Senior API Architect. Текущая OpenAPI-спецификация: [вставить] Реальный код эндпоинтов: [вставить] Найди расхождения: 1. Эндпоинты в коде, которых нет в спецификации 2. Поля в ответе, которые не задокументированы 3. Коды ошибок, которые не описаны 4. Невалидные примеры (не соответствующие схеме) 5. Отсутствующие security схемы Дай: список расхождений + готовые исправления для YAML.

Ты — Solutions Architect, создаёшь архитектурные диаграммы. Описание системы: [вставить] Компоненты: [перечислить] Нотация: [PlantUML / Mermaid] Нарисуй: 1. C4 Context диаграмму (система в окружении) 2. C4 Container диаграмму (сервисы и их связи) 3. Sequence диаграмму для ключевого flow: [описать] Используй: - Нотацию C4 Model - Цветовое кодирование по типам компонент - Явные метки на стрелках (что передаётся)

Ты — Database Architect. DDL схемы или описание таблиц: [вставить] Создай: 1. ERD диаграмму в Mermaid erDiagram 2. Все FK-связи с типами (one-to-many, many-to-many) 3. Nullable vs NOT NULL поля 4. Ключевые бизнес-ограничения (constraints) как комментарии После диаграммы: - Найди потенциальные проблемы нормализации - Предложи индексы для частых запросов - Оцени масштабируемость схемы

Ты — Technical Architect. Код сервиса / метода: [вставить] Построй Mermaid sequence diagram: 1. Все участники (акторы, сервисы, БД) 2. Синхронные и асинхронные вызовы 3. Условные ветки (alt/opt блоки) 4. Обработку ошибок (loop/break блоки) 5. Временные метки критичных операций Диаграмма должна быть понятна бизнес-аналитику, не только разработчику.

Ты — Principal Architect с 15+ годами опыта в enterprise и финансовых системах. Описание сервиса / архитектуры: [вставить] Текущий код ключевых компонентов: [вставить] Нагрузка: [RPS, объём данных, SLA] Команда: [размер, опыт] Проведи архитектурный ревью: 1. Соответствие выбранных паттернов задаче 2. Масштабируемость (где будет bottleneck при 10x нагрузке) 3. Надёжность (single points of failure) 4. Безопасность (поверхность атаки, данные) 5. Операционная сложность (deploy, monitoring, debug) 6. Технический долг — критичный сейчас vs терпимый Оцени каждый пункт 1–10. Предложи конкретные улучшения.

Ты — Solutions Architect, помогаешь принять решение. Задача: [бизнес-задача] Ограничения: - Стек: [текущий] - Нагрузка: [метрики] - Команда: [размер, технологии] - Сроки: [дедлайн] - Бюджет изменений: [оценка] Предложи 3 архитектурных варианта. Для каждого: 1. Краткое описание подхода 2. Плюсы (конкретные, измеримые) 3. Минусы и риски 4. Оценка сложности реализации (1–10) 5. Оценка операционной сложности (1–10) 6. Рекомендуемый вариант и почему именно он

Ты — Architecture Consultant, специалист по миграции монолит → микросервисы. Монолит (код / описание): [вставить] Бизнес-домены: [перечислить] Разработай план декомпозиции: 1. Bounded contexts (границы сервисов) 2. Приоритет выделения (что первым, что последним) 3. Стратегия данных (как разделить БД) 4. Паттерн миграции (Strangler Fig / Branch by Abstraction) 5. Риски каждого шага с митигацией 6. Как не сломать прод в процессе

Ты — Integration Architect с опытом в event-driven системах. Сервисы для интеграции: [список с описанием] Требования: [latency, throughput, at-least-once / exactly-once] Текущая инфраструктура: [что есть] Предложи паттерн интеграции: 1. Sync vs Async: что где использовать и почему 2. Если Kafka: топики, consumer groups, partition strategy 3. Обработка ошибок (dead letter queue, retry policy) 4. Идемпотентность (как обеспечить) 5. Мониторинг интеграционных потоков (what to alert on) 6. Diagram (Mermaid) основных потоков данных

Ты — Solutions Architect, специалист по кэшированию в высоконагруженных системах. Система: [описание] Нагрузка на чтение/запись: [RPS, соотношение] Требования к consistency: [strong / eventual] Разработай стратегию кэширования: 1. Что кэшировать (с обоснованием) 2. Паттерн (Cache-Aside / Write-Through / Read-Through) 3. TTL стратегия для каждого типа данных 4. Invalidation стратегия 5. Обработка cache stampede / thundering herd 6. Метрики и мониторинг кэша

Ты — Principal Architect, специалист по отказоустойчивости в финансовых системах. Система: [описание] RTO: [максимальное время восстановления] RPO: [максимально допустимая потеря данных] Инфраструктура: [cloud, on-premise, hybrid] Разработай DR Plan: 1. Типы сбоев и их вероятность (risk matrix) 2. DR-стратегия для каждого компонента (backup, failover, replicas) 3. Runbook восстановления по шагам 4. Точки принятия решений (кто, когда объявляет DR) 5. Регулярные DR-учения (что, как часто, критерии успеха) 6. Проверочный список после восстановления

Ты — Senior Business Analyst с опытом в финансовых проектах. Требования / User Story: [вставить] Проанализируй: 1. Неоднозначности — что можно интерпретировать по-разному 2. Пропущенные сценарии — что не описано, но должно работать 3. Конфликты — где требования противоречат друг другу 4. Edge cases специфичные для финансового домена 5. Acceptance Criteria (если не написаны — предложи) 6. Вопросы для уточнения у стейкхолдеров Формат: по каждому пункту — конкретный вопрос/проблема + предложение.

Ты — Senior BA, специалист по написанию User Stories. Бизнес-требование: [вставить] Напиши: 1. Epic с описанием бизнес-ценности 2. User Stories: «Как [роль], я хочу [действие], чтобы [ценность]» 3. Acceptance Criteria в формате Given / When / Then 4. Definition of Done 5. Зависимости от других историй 6. Оценку сложности (Story Points) с обоснованием # Учти: система финансовая — добавь AC для аудита и безопасности.

Ты — Business Process Analyst. Текущий процесс (AS-IS): [описание] Проблемы и боли: [описание] Цели изменений: [описание] Разработай: 1. Описание текущего процесса (AS-IS) структурированно 2. Выявленные проблемы с оценкой impact (High/Medium/Low) 3. Целевой процесс (TO-BE) с изменениями 4. Gap анализ: что нужно изменить 5. KPI для измерения успеха изменений 6. Риски перехода и митигация

Ты — Senior Business Analyst, специалист по управлению стейкхолдерами. Проект / инициатива: [описание] Список участников: [роли и имена] Разработай: 1. Матрицу влияния/интереса (Power/Interest Grid) 2. Для каждой группы: цели, опасения, ожидания 3. Стратегию вовлечения (Manage Closely / Keep Satisfied / etc.) 4. План коммуникации (что, кому, как часто, в каком формате) 5. Риски конфликтов интересов и как их митигировать

Ты — Senior Product Analyst. Список требований: [вставить] Ограничения: - Дедлайн: [дата] - Команда: [размер, скорость] - Бюджет: [опционально] - Бизнес-цель: [что главное] Проведи MoSCoW приоритизацию: 1. Must Have (без чего продукт не работает) 2. Should Have (важно, но можно отложить) 3. Could Have (желательно при наличии времени) 4. Won't Have (вне скоупа, объяснить почему) Для каждого требования: обоснование + оценка трудоёмкости (S/M/L/XL)

Ты — Senior Business Analyst, готовишь обоснование для CTO/CFO. Инициатива: [описание] Текущая ситуация (боли): [описание] Предлагаемое решение: [описание] Команда и сроки: [оценка] Напиши бизнес-кейс: 1. Executive Summary (1 абзац) 2. Описание проблемы (с измеримыми потерями) 3. Предлагаемое решение и альтернативы 4. Ожидаемые выгоды (количественные + качественные) 5. Затраты (разработка, инфраструктура, поддержка) 6. Расчёт ROI / Payback period 7. Риски и план митигации 8. Рекомендация и следующие шаги

Ты — Senior SRE с опытом в высоконагруженных системах. Контекст: [описание системы] Инфраструктура: [Kubernetes / Docker / bare metal / cloud] Observability: [стек мониторинга и логирования] Логи инцидента: [вставить] Метрики в момент инцидента: [вставить или описать аномалии] Проведи Post-Mortem анализ: 1. Timeline инцидента (восстанови из логов) 2. Root cause (основная причина) 3. Contributing factors (что усугубило) 4. Impact (сколько длился, что затронул) 5. Immediate fix (что сделали для восстановления) 6. Action items (что нужно сделать, чтобы не повторилось) — с owner и дедлайном

Ты — Senior DevOps Engineer, специалист по контейнеризации и CI/CD. Приложение: - Тип: [Java Spring Boot / Node / Python] - Версия: [указать] - Зависимости: [список] - Требования к безопасности: [финансовый контекст] Напиши: 1. Оптимизированный Dockerfile: multi-stage build, minimal base image (distroless/alpine), non-root user, health check 2. .dockerignore 3. GitLab CI/CD pipeline (.gitlab-ci.yml): build → test → security scan → deploy to preprod 4. Docker layer caching 5. Комментарии к нетривиальным решениям

Ты — Senior Kubernetes Engineer. Сервис: - Название: [название] - Порт: [порт] - Ресурсы: [CPU/Memory требования] - Replicas: [количество] - Зависимости: [БД, Kafka, etc.] Напиши production-ready манифесты: 1. Deployment: resource requests/limits, liveness и readiness probes, rolling update strategy, pod disruption budget, anti-affinity rules 2. Service (ClusterIP / LoadBalancer) 3. ConfigMap для конфигурации 4. HPA (Horizontal Pod Autoscaler) 5. NetworkPolicy (только нужный трафик) # Финансовый контекст: добавь securityContext (non-root, readOnly FS).

Ты — Senior SRE, настраиваешь observability. Сервис: [описание] Критичные бизнес-операции: [список] Создай: 1. Список ключевых метрик (RED: Rate / Errors / Duration) 2. Grafana dashboard (JSON или описание панелей): бизнес-метрики (транзакции/сек), технические (JVM, DB pool, Kafka lag), инфра (CPU, memory, GC) 3. Prometheus alerting rules: Critical P1 (мгновенно), Warning P2 (5 мин), Info P3 (тикет) 4. Runbook для каждого критичного алерта: симптомы → причины → шаги диагностики

Ты — Senior DevOps Engineer, специалист по Infrastructure as Code. Cloud provider: [AWS / Azure / GCP / on-premise] Требуемая инфраструктура: [что нужно создать] Окружения: [dev / staging / prod] Требования безопасности: [принципы least privilege, шифрование, compliance вашего домена] Напиши Terraform код: 1. Модульная структура (network / compute / database / security) 2. Variables с валидацией и описаниями 3. Outputs для зависимостей между модулями 4. Remote state backend (S3 + DynamoDB locking) 5. Workspace стратегия для окружений 6. Security best practices (encryption at rest, least privilege IAM)

Ты — Senior SRE, специалист по capacity planning. Текущие метрики: - Нагрузка: [RPS, пиковая нагрузка] - Ресурсы: [CPU, RAM, storage, сеть] - Стоимость: [текущий Infrastructure cost/month] Прогноз роста: [ожидаемый рост за 6/12 месяцев] Разработай: 1. Прогноз потребности в ресурсах (с запасом x2) 2. Bottleneck-анализ (что упрётся первым) 3. Рекомендации по масштабированию (vertical vs horizontal) 4. Оценку стоимости инфраструктуры 5. Точки мониторинга для своевременного реагирования

Ты — Senior DevSecOps Engineer. Стек: [язык, фреймворк] CI система: [GitLab CI / GitHub Actions / Jenkins] Требования: [стандарты безопасности вашего домена] Настрой security pipeline: 1. SAST (SonarQube / Semgrep): конфигурация + правила для вашего стека 2. Dependency scanning (OWASP Dependency-Check / Snyk): CVE политика 3. Container scanning (Trivy / Grype): критерии блокировки сборки 4. Secret detection: pre-commit hooks + CI проверка 5. Политика: что блокирует релиз, что только предупреждает 6. Dashboard для трекинга security debt

Ты — Senior SRE, строишь observability платформу. Стек приложений: [языки, фреймворки] Инфраструктура: [Kubernetes / VMs] Текущие инструменты: [что уже есть] Разработай observability стратегию: 1. Logs: формат (JSON), retention, агрегация (ELK / Loki), correlation ID 2. Metrics: инструментирование Micrometer/Prometheus, custom бизнес-метрики 3. Traces: распределённая трассировка (Jaeger / Zipkin / OpenTelemetry) 4. Корреляция logs ↔ metrics ↔ traces (единый trace_id) 5. SLO/SLI определение для критичных операций 6. Error budget политика