Сейчас выстроим набор из 10 универсальных промтов в формате JSON, которые полезно иметь в библиотеке промт‑инженера. Покроем разные сферы: контент, аналитика, продукт, код, бизнес.
Переменные помечаем в двойных угловых скобках <<…>>, чтобы вы могли быстро заменить их под свой кейс.
Рекомендация по использованию: сохраните каждый шаблон как отдельный файл в вашей библиотеке (.md / .prompt), подставляйте значения в переменные, а структуру JSON можно подогнать под ваш стек.
1. Анализ отзывов / фидбэка в JSON
Подходит для App Store/Google Play, NPS‑опросов, форм обратной связи.
Вы выступаете как аналитик продукта. Ваша задача – разобрать пользовательские отзывы и вернуть структурированный анализ в формате JSON.
Контекст продукта: <<**КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА**>>
Целевая аудитория: <<**ОПИСАНИЕ_ЦА**>>
Цель анализа: выявить ключевые темы, боли, пожелания и позитивные инсайты.
Вот список отзывов (один на строку):
<<**СПИСОК_ОТЗЫВОВ_ТЕКСТОМ**>>
Требования к обработке:
1. Объединяйте близкие по смыслу отзывы в общие темы.
2. Разделяйте темы на категории: "bug", "feature_request", "usability", "pricing", "performance", "praise", "other".
3. Для каждой темы указывайте:
– краткое описание темы,
– категория,
– примеры отзывов (1–3 примера),
– оценка важности (1–5) – как сильно это влияет на опыт пользователя,
– предполагаемое влияние на бизнес (низкое/среднее/высокое).
Строго верните результат в корректном JSON.
Формат ответа:
{
"summary": {
"total_reviews": <<ЧИСЛО>>,
"distinct_themes": <<ЧИСЛО>>
},
"themes": [
{
"theme_id": "theme_1",
"title": "Краткое название темы",
"category": "bug | feature_request | usability | pricing | performance | praise | other",
"description": "Краткое описание сути проблемы или инсайта",
"examples": [
"Пример отзыва 1",
"Пример отзыва 2"
],
"user_importance": 4,
"business_impact": "high | medium | low"
}
]
}
2. Генератор контент‑плана (статьи / посты)
Полезно маркетологу, продакту, автору.
Вы – контент‑стратег. Ваша задача – составить контент‑план по заданной теме и целевой аудитории.
Тема: <<**ТЕМА_КОНТЕНТА**>>
Целевая аудитория: <<**ОПИСАНИЕ_ЦА**>>
Цель контента: <<**ЦЕЛЬ_КОНТЕНТА_НАПРИМЕР_ПРИВЛЕЧЕНИЕ_ЛИДОВ_УПАКОВКА_ЭКСПЕРТИЗЫ**>>
Форматы материалов: <<**СПИСОК_ФОРМАТОВ_НАПРИМЕР_СТАТЬИ_ПОСТЫ_ВЕБИНАРЫ**>>
Период планирования (в неделях): <<**КОЛИЧЕСТВО_НЕДЕЛЬ**>>
Требования:
1. Сформируйте список тем на заданный период.
2. Для каждой единицы контента укажите:
– рабочее название,
– формат,
– целевую метрику (что хотим получить),
– ключевой посыл,
– 3–5 тезисов,
– предполагаемый уровень воронки: "top", "middle", "bottom".
3. Строго верните результат в JSON.
Формат ответа:
{
"period_weeks": <<ЧИСЛО>>,
"items": [
{
"id": "content_1",
"title": "Рабочее название материала",
"format": "article | post | webinar | video | other",
"goal_metric": "например: регистрации, клики, сохранения",
"key_message": "Короткий главный посыл",
"funnel_stage": "top | middle | bottom",
"outline": [
"Тезис 1",
"Тезис 2",
"Тезис 3"
]
}
]
}
3. JTBD‑карта по сегментам
Основной шаблон для продуктолога / промт‑инженера в продукте.
Вы – продуктовый аналитик. Ваша задача – сформировать JTBD‑карту по ключевым сегментам целевой аудитории.
Продукт: <<**КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА**>>
Рынок/ниша: <<**НИША_РЫНОК**>>
Сегменты ЦА (перечислите текстом): <<**ОПИСАНИЕ_СЕГМЕНТОВ_ЦА**>>
Используйте формат JTBD:
"Когда я <ситуация>, я хочу <мотивация/действие>, чтобы <результат/ценность>."
Требования:
1. Для каждого сегмента:
– описать контекст (когда, где, в какой ситуации),
– сформулировать 3–5 ключевых JTBD,
– выделить главные боли/риски,
– ожидаемые результаты/критерии успеха.
2. Строго вернуть результат в JSON.
Формат ответа:
{
"product": "<<**КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА**>>",
"segments": [
{
"segment_name": "Название сегмента",
"context_description": "Описание типичной ситуации и окружения",
"jobs": [
{
"job_statement": "Когда я …, я хочу …, чтобы …",
"pains": [
"Боль 1",
"Боль 2"
],
"expected_outcomes": [
"Результат 1",
"Результат 2"
]
}
]
}
]
}
4. Приоритезация фич по RICE
Базовый шаблон для фич‑пайплайна.
Вы – продакт‑менеджер. Ваша задача – провести первичную приоритезацию списка фич по методике RICE.
Продукт: <<**КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА**>>
Целевая аудитория: <<**ОПИСАНИЕ_ЦА**>>
Горизонт планирования (в месяцах): <<**ГОРИЗОНТ_МЕСЯЦЫ**>>
Список фич (одна фича на строку, в свободной форме):
<<**СПИСОК_ФИЧ_ТЕКСТОМ**>>
Объясните, что под RICE мы понимаем:
– Reach: сколько пользователей затронет фича за период (примерно),
– Impact: насколько сильно повлияет на ключевую метрику (0.25/0.5/1/2/3),
– Confidence: насколько уверены в оценках (0–1),
– Effort: трудозатраты (человекоу‑недели).
Требования:
1. Для каждой фичи оценить R, I, C, E с кратким комментарием.
2. Рассчитать RICE‑скор (R * I * C / E).
3. Отсортировать фичи по убыванию RICE.
4. Строго вернуть результат в JSON.
Формат ответа:
{
"time_horizon_months": <<ЧИСЛО>>,
"features": [
{
"name": "Название фичи",
"description": "Краткое описание",
"reach_per_period": <<ЧИСЛО>>,
"impact": <<ЧИСЛО_НАПРИМЕР_0.5_1_2>>,
"confidence": <<ЧИСЛО_ОТ_0_ДО_1>>,
"effort_person_weeks": <<ЧИСЛО>>,
"rice_score": <<ЧИСЛО>>,
"comment": "Краткое обоснование оценок"
}
]
}
5. Шаблон для еженедельного отчёта (автоматизация)
Отличная основа под автоматизацию отчётов через код + LLM.
Вы – аналитик. Ваша задача – на основе сырых метрик подготовить структурированный еженедельный отчёт.
Контекст:
Компания: <<**НАЗВАНИЕ_КОМПАНИИ**>>
Продукт/направление: <<**ОПИСАНИЕ_ПРОДУКТА**>>
Период отчёта: <<**ДАТЫ_ПЕРИОДА**>>
Ключевые метрики: <<**СПИСОК_КЛЮЧЕВЫХ_МЕТРИК_ТЕКСТОМ**>>
Ниже даны агрегированные метрики в формате JSON:
<<**JSON_МЕТРИК_ЗА_НЕДЕЛЮ**>>
Требования:
1. Сформировать:
– краткое резюме (2–4 предложения),
– раздел "Ключевые изменения" (топ‑3 события/изменения),
– раздел "Риски и проблемы",
– раздел "Рекомендации/следующие шаги".
2. Ссылаться только на те изменения, которые видны в данных.
3. Не придумывать несоответствующие фактам причины.
4. Строго вернуть результат в JSON.
Формат ответа:
{
"period": "<<**ДАТЫ_ПЕРИОДА**>>",
"summary": "Краткое резюме недели",
"key_changes": [
{
"title": "Краткое описание изменения",
"metric": "Название метрики",
"delta_description": "Что изменилось и насколько"
}
],
"risks": [
{
"title": "Риск или проблема",
"description": "Краткое описание",
"suggested_action": "Что сделать"
}
],
"recommendations": [
{
"title": "Рекомендация",
"description": "Краткое объяснение, зачем"
}
]
}
6. Код‑ревью и рефакторинг (разработчик)
Базовый промт для ревью кода в структурированном виде.
Вы – сеньор‑разработчик. Ваша задача – провести код‑ревью и предложить улучшения.
Язык: <<**ЯЗЫК_ПРОГРАММИРОВАНИЯ**>>
Контекст проекта: <<**КРАТКИЙ_КОНТЕКСТ_ПРОЕКТА**>>
Требования к стилю: <<**СТИЛЕВЫЕ_ТРЕБОВАНИЯ_НАПРИМЕР_PEP8_ESLINT_GUIDELINES**>>
Вот фрагмент кода:
```<<**ФРАГМЕНТ_КОДА**>>```
Требования:
1. Не выполнять код.
2. Проанализировать:
– читаемость,
– архитектуру/структуру,
– потенциальные баги и крайние случаи,
– производительность (если релевантно),
– безопасность (если релевантно).
3. Предложить улучшенную версию кода.
4. Строго вернуть результат в JSON.
Формат ответа:
{
"summary": "Общее впечатление от кода",
"issues": [
{
"type": "readability | architecture | bug | performance | security | style | other",
"severity": "low | medium | high",
"description": "Суть проблемы",
"location_hint": "Описание, где именно это в коде",
"suggestion": "Краткое предложение по исправлению"
}
],
"improved_code": "Тут полностью улучшенная версия кода",
"notes": "Дополнительные замечания, если есть"
}
7. Генерация тест‑кейсов / юнит‑тестов
Ускорение разработки и QA
Вы – сеньор‑разработчик/QA‑инженер. Ваша задача – на основе описания функции и её кода предложить тест‑кейсы.
Язык: <<**ЯЗЫК_ПРОГРАММИРОВАНИЯ**>>
Фреймворк тестирования: <<**ФРЕЙМВОРК_ТЕСТОВ_НАПРИМЕР_PYTEST_JEST_JUNIT**>>
Назначение функции: <<**КРАТКОЕ_ОПИСАНИЕ_ФУНКЦИИ**>>
Код функции:
```<<**КОД_ФУНКЦИИ**>>```
Требования:
1. Сформировать список тест‑кейсов:
– нормальные случаи,
– граничные случаи,
– некорректные входные данные.
2. Для каждого кейса указать:
– описание,
– входные данные,
– ожидаемый результат.
3. Сгенерировать пример кода тестов под указанный фреймворк.
4. Строго вернуть результат в JSON.
Формат ответа:
{
"test_cases": [
{
"id": "case_1",
"type": "normal | edge | invalid",
"description": "Что проверяем",
"input": "Описание входных данных или структура",
"expected_output": "Ожидаемый результат"
}
],
"test_code_example": "Пример кода с тестами на <<**ФРЕЙМВОРК_ТЕСТОВ_НАПРИМЕР_PYTEST**>>"
}
8. Бизнес‑генератор идей (продукт/фичи/модели монетизации)
Удобен для быстрых брейнштормов, где нужен структурированный выход.
Вы – продукт‑стратег. Ваша задача – сгенерировать структурированный список идей.
Контекст:
Отрасль: <<**ОТРАСЛЬ_НАПРИМЕР_ФИНТЕХ_EDTECH_ECOMMERCE**>>
Тип решения: <<**ТИП_РЕШЕНИЯ_НАПРИМЕР_SAAS_MOBILE_APP_B2B_SERVICE**>>
Целевая аудитория: <<**ОПИСАНИЕ_ЦА**>>
Главные ограничения/условия: <<**ОГРАНИЧЕНИЯ_НАПРИМЕР_GDPR_REGULATION_BUDGET_LTV**>>
Цель: сгенерировать идеи:
– новых продуктов,
– ключевых фич,
– вариантов монетизации.
Требования:
1. Сформировать:
– 3–5 идей продуктов/направлений,
– для каждого – 3–7 ключевых фич,
– варианты монетизации (1–3 на продукт).
2. Для каждой идеи продукта указать:
– целевой сегмент,
– основную ценность,
– ключевые риски.
3. Строго вернуть результат в JSON.
Формат ответа:
{
"context": {
"industry": "<<**ОТРАСЛЬ**>>",
"solution_type": "<<**ТИП_РЕШЕНИЯ**>>"
},
"product_ideas": [
{
"name": "Название продуктовой идеи",
"target_segment": "Кому она нужна",
"core_value": "Главная ценность",
"key_features": [
"Фича 1",
"Фича 2"
],
"monetization_models": [
"Подписка",
"Freemium",
"Разовая оплата"
],
"risks": [
"Риск 1",
"Риск 2"
]
}
]
}
9. Шаблон для структурирования требований (mini‑PRD)
Полезно продакту, аналитику и разработчикам.
Вы – продакт‑менеджер. Ваша задача – на основе текстового описания идеи сформировать структурированные требования (mini‑PRD).
Продукт: <<**КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА**>>
Контекст/бизнес‑цель: <<**БИЗНЕС_ЦЕЛЬ**>>
Описание идеи (сырое, как есть):
<<**ТЕКСТОВОЕ_ОПИСАНИЕ_ИДЕИ**>>
Требования:
1. Структурировать информацию в блоки:
– проблема/контекст,
– целевая аудитория,
– сценарии использования (user stories),
– ключевые фичи/функциональные требования,
– не‑функциональные требования (скорость, безопасность и т.п.),
– риски и допущения,
– метрики успеха.
2. Сформулировать user stories в формате:
"Как <тип пользователя>, я хочу <действие>, чтобы <результат>."
3. Строго вернуть результат в JSON.
Формат ответа:
{
"problem": "Описание проблемы и контекста",
"target_audience": "Краткое описание ЦА",
"user_stories": [
{
"id": "story_1",
"statement": "Как …, я хочу …, чтобы …"
}
],
"functional_requirements": [
"Требование 1",
"Требование 2"
],
"non_functional_requirements": [
"Требование по производительности",
"Требование по безопасности"
],
"risks_and_assumptions": [
"Риск/допущение 1",
"Риск/допущение 2"
],
"success_metrics": [
"Метрика 1",
"Метрика 2"
]
}
10. Универсальный промт‑диагност для улучшения промтов
Метапромт, который помогает вам же улучшать свои запросы.
Вы – сеньор промт‑инженер. Ваша задача – проанализировать данный промт и предложить улучшения.
Роль, в которой должен работать промт: <<**РОЛЬ_НАПРИМЕР_МАРКЕТОЛОГ_РАЗРАБОТЧИК_АНАЛИТИК**>>
Цель промта: <<**ЦЕЛЬ_ПРОМТА_ЧТО_ДОЛЖНО_БЫТЬ_НА_ВЫХОДЕ**>>
Текст промта для анализа:
<<**ТЕКСТ_ПРОМТА_ДЛЯ_АНАЛИЗА**>>
Требования:
1. Оценить промт по критериям:
– ясность роли,
– полнота контекста,
– чёткость задачи,
– определённость формата ответа,
– наличие критериев качества.
2. Предложить:
– улучшенную версию промта,
– рекомендации по дальнейшей адаптации под конкретные кейсы.
3. Строго вернуть результат в JSON.
Формат ответа:
{
"evaluation": {
"role_clarity": {
"score": 1-5,
"comment": "Комментарий"
},
"context_completeness": {
"score": 1-5,
"comment": "Комментарий"
},
"task_clarity": {
"score": 1-5,
"comment": "Комментарий"
},
"output_format_specificity": {
"score": 1-5,
"comment": "Комментарий"
},
"quality_criteria_presence": {
"score": 1-5,
"comment": "Комментарий"
}
},
"improved_prompt": "Переписанный, более чёткий вариант промта",
"recommendations": [
"Рекомендация 1",
"Рекомендация 2"
]
}
ЧЕК‑ЛИСТ ХОРОШЕГО ПРОМТА (МИНИМАЛЬНЫЙ СТАНДАРТ)
Короткий список, который вы держите под рукой и прогоняете каждый раз, когда пишете важный промт:
Роль: я чётко сказал, кто должен говорить? (сеньор‑разработчик, продукт, аналитик, маркетолог и т.д.).
Контекст: модель понимает, для кого и в какой ситуации она работает?
Задача: сформулировано одно конкретное действие, а не “сделай всё”?
Формат ответа: есть жёсткий формат (JSON / таблица / разделы с заголовками)?
Ограничения: указан язык, длина, тон, что нельзя делать (галлюцинации, выдумывать данные и т.п.)?
Критерии качества: модель знает, по каким критериям её ответ будет “хорошим”?
Пример: есть хотя бы один пример правильного ответа (идеально – в том же формате, который вы хотите)?
Это можно оформить отдельным промтом‑напоминалкой, который вы держите открытым и проверяете свои запросы.
2. Универсальный “каркас промта” для любых задач
Шаблон, который вы можете адаптировать под любую сферу:
Роль: вы выступаете как <<РОЛЬ_НАПРИМЕР_СЕНЬОР_РАЗРАБОТЧИК_ПРОДАКТ_МАРКЕТОЛОГ_АНАЛИТИК>>.
Контекст:
– Область/домен: <<ДОМЕН_НАПРИМЕР_ECOMMERCE_FINTECH_EDTECH>>
– Тип задачи: <<ТИП_ЗАДАЧИ_НАПРИМЕР_АНАЛИЗ_КОДА_ГЕНЕРАЦИЯ_КОНТЕНТА_ПРИОРИТИЗАЦИЯ_ФИЧ>>
– Целевая аудитория/пользователь: <<ОПИСАНИЕ_ЦА>>
– Дополнительные ограничения: <<ОГРАНИЧЕНИЯ_НАПРИМЕР_GDPR_ТОН_БРЕНДА_ТЕХНОЛОГИИ>>
Задача:
На основе входных данных выполнить следующее: <<ЧТО_НУЖНО_СДЕЛАТЬ_ОДНИМ_ПРЕДЛОЖЕНИЕМ>>.
Формат ответа:
– Структура: <<JSON_Т_ТАБЛИЦА_Т_РАЗДЕЛЫ>>
– Обязательные разделы/поля: <<СПИСОК_ПОЛЕЙ>>
– Язык ответа: <<ЯЗЫК>>
Критерии качества:
– <<КРИТЕРИЙ_1>>
– <<КРИТЕРИЙ_2>>
– <<КРИТЕРИЙ_3>>
Входные данные:
<<ВСТАВЬТЕ_ТЕКСТ_КОД_ДАННЫЕ>>
Такой каркас вы можете копировать и каждый раз просто заполнять “поля” – как форму.
3. Набор мини‑шаблонов по ролям
Краткие стартовые роли, которые вы добавляете в начало промта и переиспользуете.
Например:
“Вы – сеньор‑разработчик с опытом 10+ лет в <<ЯЗЫК/СТЕК>>, умеете объяснять сложный код простым языком и строго следуете лучшим практикам.”
“Вы – продакт‑менеджер B2B SaaS, привыкли мыслить метриками и бизнес‑ценностью, не увлекаетесь лишним функционалом.”
“Вы – маркетолог‑стратег для <<НИША>>, умеете писать без воды, фокусируясь на выгодах и возражениях ЦА.”
“Вы – аналитик данных, который всегда отделяет факты от гипотез, и если данных не хватает – прямо указывает на это.”
Это удобно хранить как отдельную секцию “Роли” в библиотеке промтов и вставлять в начало любого запроса.
4. Шаблоны “улучши то, что уже есть”
Промт‑инженер часто не создаёт с нуля, а улучшает: текст, код, документацию, гипотезу.
Полезно иметь универсальные промты:
“Сделай понятнее” – переписать текст/код‑комментарии/описание фичи для конкретной аудитории.
“Сделай короче” – ужать без потери смысла, с лимитом по символам/словам.
“Сделай структурированнее” – превратить хаотичный текст в список, план, таблицу, JSON.
“Сделай безопаснее/надёжнее” – для кода и архитектуры.
“Сделай бизнес‑ориентированнее” – для продуктовых идей и фич.
Например, универсальный “сделай понятнее”:
Вы – опытный технический писатель и сеньор‑разработчик.
Целевая аудитория: <<КТО_БУДЕТ_ЧИТАТЬ_НАПРИМЕР_ДЖУН_РАЗРАБОТЧИК_НЕ_ТЕХНИЧЕСКИЙ_МЕНЕДЖЕР>>
Цель: переписать текст так, чтобы он стал понятнее этой аудитории, сохранив техническую точность.
Задача:
1. Кратко переформулировать основной смысл.
2. Упростить формулировки, убрав жаргон, который не обязателен.
3. Сохранить важные термины, но дать им краткое объяснение, если нужно.
Формат ответа:
1) Краткое резюме (1–2 предложения).
2) Переписанный текст.
Исходный текст:
<<ВСТАВИТЕ_ТЕКСТ>>
5. Шаблон “первый проход + уточняющие вопросы”
Очень полезный паттерн: вы просите модель сначала задать вам вопросы, а уже потом решать задачу. Это экономит время на “дорассказывание контекста”.
Шаблон:
Вы – <<РОЛЬ>>.
Задача: <<КРАТКОЕ_ОПИСАНИЕ_ЗАДАЧИ>>.
Сначала:
1. Задайте мне до 10 уточняющих вопросов, чтобы лучше понять задачу и контекст.
2. Дождитесь моих ответов.
После того как я отвечу:
1. Кратко перескажите задачу своими словами.
2. Выполните задачу.
3. Объясните, какие допущения вы сделали.
Формат:
Сейчас верните только список вопросов в JSON:
{
"questions": [
"Вопрос 1",
"Вопрос 2"
]
}
Этот паттерн особенно полезен в сложных аналитических/продуктовых задачах.
6. Шаблон “разбор ошибки/инцидента”
Для разработчика и аналитика инцидентов:
Вы – сеньор‑разработчик / инженер по надежности (SRE).
Контекст системы: <<КРАТКОЕ_ОПИСАНИЕ_СИСТЕМЫ>>
Тип инцидента: <<ТИП_ИНЦИДЕНТА_НАПРИМЕР_ПАДЕНИЕ_API_ДЕГРАДАЦИЯ_ПРОИЗВОДИТЕЛЬНОСТИ>>
Логи / описание инцидента:
<<ТЕКСТ_ЛОГОВ_ИЛИ_ОПИСАНИЕ_СИМПТОМОВ>>
Задача:
1. Структурировать информацию об инциденте.
2. Предложить гипотезы причин.
3. Предложить план расследования и первичных действий.
4. Если возможно – предложить идеи по предотвращению в будущем.
Формат ответа:
{
"summary": "Краткое описание инцидента",
"possible_causes": [
{
"hypothesis": "Гипотеза причины",
"evidence_from_logs": "На что в логах это указывает",
"confidence": "low | medium | high"
}
],
"investigation_plan": [
"Шаг 1",
"Шаг 2"
],
"prevention_ideas": [
"Идея 1",
"Идея 2"
]
}
Такой шаблон можно использовать и для реальных логов, и для тренировок.
7. Шаблон “быстрый ресёрч по нише”
Полезен продактам, маркетологам, создателям продуктов.
Вы – продуктовый аналитик и маркетолог.
Ниша/рынок: <<НИША_НАПРИМЕР_ОНЛАЙН_КУРСЫ_ПО_ЯЗЫКАМ>>
Регион/рынок: <<РЕГИОН_НАПРИМЕР_EU_US_CIS>>
Тип продукта: <<ТИП_ПРОДУКТА_НАПРИМЕР_SAAS_МАРКЕТПЛЕЙС_МОБИЛЬНОЕ_ПРИЛОЖЕНИЕ>>
Задача:
Сделать первичный аналитический обзор ниши.
Требования:
1. Описать 3–5 ключевых сегментов клиентов.
2. Для каждого сегмента:
– главные задачи,
– боли,
– какие решения используют сейчас (типы, не бренды),
– на что обращают внимание при выборе.
3. Выделить 3–7 трендов или сдвигов в поведении/рынке.
4. Сформулировать 3–5 гипотез ценности для продукта в этой нише.
Формат ответа – структурированный список (можно в JSON, если вам так удобнее).
Этот промт можно превратить в JSON‑версию, если вы хотите подавать результат дальше в аналитику.
8. Шаблон “сравнительная таблица”
Когда нужно быстро сравнить варианты: фичи, технологии, вендоров, гипотезы.
Вы – аналитик/архитектор.
Задача:
Сравнить следующие варианты по набору критериев и вернуть результат в виде таблицы (можно в Markdown или JSON).
Варианты:
<<СПИСОК_ВАРИАНТОВ_НАПРИМЕР_TECH_A_TECH_B_TECH_C>>
Критерии:
<<СПИСОК_КРИТЕРИЕВ_НАПРИМЕР_СТОИМОСТЬ_СЛОЖНОСТЬ_ВНЕДРЕНИЯ_МАСШТАБИРУЕМОСТЬ_РИСКИ>>
Требования:
1. Для каждого варианта оценить каждый критерий (качественно, можно добавить шкалу 1–5).
2. Кратко прокомментировать сильные и слабые стороны.
3. Предложить рекомендацию: какой вариант выбрать при приоритете <<ГЛАВНЫЙ_ПРИОРИТЕТ_НАПРИМЕР_БЫСТРОЕ_ВНЕДРЕНИЕ_МИНИМАЛЬНЫЙ_РИСК>>.
Формат ответа:
– Таблица сравнения.
– Краткое текстовое резюме и рекомендация.
9. Шаблон “разбор метрики и поиск причин просадки”
Для продукта, маркетинга, аналитики.
Вы – продуктовый аналитик.
Продукт: <<КРАТКОЕ_ОПИСАНИЕ_ПРОДУКТА>>
Метрика: <<НАЗВАНИЕ_МЕТРИКИ_НАПРИМЕР_CONVERSION_SIGNUP_TO_PAID>>
Период: <<ПЕРИОД_АНАЛИЗА>>
Данные о метрике (текстом или JSON):
<<ДАННЫЕ_ПО_МЕТРИКЕ>>
Задача:
1. Оценить, что происходит с метрикой (рост/падение/стабильность).
2. Предложить возможные причины изменений.
3. Сформулировать 3–7 проверяемых гипотез.
4. Для каждой гипотезы предложить план проверки (какие данные посмотреть, какие разрезы сделать).
Формат ответа:
{
"metric_trend": "up | down | stable",
"trend_comment": "Краткое описание тренда",
"hypotheses": [
{
"name": "Название гипотезы",
"description": "Что предполагаем",
"priority": "high | medium | low",
"validation_plan": [
"Шаг проверки 1",
"Шаг проверки 2"
]
}
]
}
10. Шаблон “личный ассистент промт‑инженера” (мета‑инструмент)
Отдельный промт, который вы можете держать закреплённым и использовать как “IDE‑ассистента”:
Вы – мой помощник‑промт‑инженер и сеньор‑разработчик.
Ваша задача:
1. Помогать мне формулировать, уточнять и улучшать промты под разные задачи.
2. Помогать мне проектировать цепочки промтов и выбирать формат ответа (JSON, таблицы, разделы).
3. Указывать на потенциальные проблемы: нехватка контекста, размытая задача, нет критериев качества.
Правила работы:
– Если мой запрос слишком общий – задавайте уточняющие вопросы.
– Если мой промт можно улучшить – предложите улучшенную версию и объясните, что и зачем вы сменили.
– Если уместно – предложите JSON‑структуру выхода.
Формат ответа:
Всегда:
1) Краткая оценка текущего промта/задачи (что в нём ок, что не ок).
2) Улучшенная версия промта.
3) (Опционально) JSON‑схема ответа или предложение по цепочке промтов.
Мой запрос:
<<МОЙ_ТЕКУЩИЙ_ПРОМТ_ИЛИ_ЗАДАЧА>>
Данное приложение даёт не просто “банк промтов”, а стартовый набор инструментов:
базовый каркас промта;
роли по профессиям;
паттерны “сначала вопросы, потом решение”;
шаблоны для разбора кода, метрик, инцидентов, идей;
мета‑инструменты для улучшения самих промтов.
Вы можете взять их как есть, положить в свою библиотеку, адаптировать под свой стек и постепенно наращивать сверху свои специализированные промты под конкретные проекты и клиентов.