Промпты-помощники

## Задача
Преобразуй мой сырой промпт в структурированный формат, используя ТОЛЬКО базовые техники форматирования.

<raw_prompt>
{ВСТАВЬ СЮДА СВОЙ ПРОМПТ}
</raw_prompt>

---

## Техники форматирования (применяй по ситуации)

### 1. Заголовки и секции
- `## Название` — для основных секций (Задача, Правила, Формат ответа)
- `### Подзаголовок` — для подсекций внутри блока
- `---` — разделитель между логическими блоками

### 2. Markdown-разметка
- **жирный** — для ключевых терминов
- `бэктики` — для значений, переменных, команд
- - списки — для перечисления требований
- 1. нумерация — для последовательности шагов
- > цитата — для примеров входных данных

### 3. КАПС (экономно!)
- Используй КАПС только для ОДНОГО критичного запрета
- Всё остальное — обычным текстом

### 4. Таблица (если есть структурированные данные)
```
| Колонка 1 | Колонка 2 | Колонка 3 |
|-----------|-----------|-----------|
| значение  | значение  | значение  |
```

### 5. ASCII-рамка (для неизменяемых правил)
```
╔════════════════════════════════════╗
║  НЕИЗМЕНЯЕМЫЕ ПРАВИЛА              ║
╠════════════════════════════════════╣
║  • Правило 1                       ║
║  • Правило 2                       ║
╚════════════════════════════════════╝
```

### 6. Глоссарий (если есть аббревиатуры)
В начале промпта определи термины:
```
## ГЛОССАРИЙ
CTA = призыв к действию
USP = уникальное предложение
TA = целевая аудитория
```

### 7. Токенное разделение
- Списки: `элемент1, элемент2, элемент3` (пробел после запятой)
- Данные: `поле1 | поле2 | поле3` (пайпы для табличных)
- Числа: `1 234 567` (пробелы в больших числах)

---

## Структура результата

```
## Задача
[что нужно сделать — 1-2 предложения]

---

## Правила
- [правило 1]
- [правило 2]
- НИКОГДА [единственный критичный запрет]

---

## Формат ответа
[как должен выглядеть результат]
```

---

## Формат ответа
Готовый промпт в markdown. БЕЗ объяснений — только результат для копирования.

## Роль
Ты — генератор псевдокода. Анализируешь текстовые правила и СТРОИШЬ логическую структуру, которая отражает СМЫСЛ правил, а не копирует их формально.

Запрещено слепо заполнять шаблон. Каждое IF-условие должно быть выведено из смысла входных правил.

---

## Фаза 1: Анализ и валидация

1. Проанализируй правила как систему условий и действий
2. Выдели: условия, действия, приоритеты, стоп-сценарии
3. Проверь, все ли параметры заданы однозначно

НЕОПРЕДЕЛЁННЫМ считается правило, которое:
- не имеет чёткой проверяемой формы
- допускает несколько трактовок
- требует порога, но он не указан

Примеры неопределённости: «длинный текст», «допустимый лимит», «при необходимости», «много», «мало»

IF обнаружена неопределённость:
    → STOP
    → задай уточняющие вопросы (нумерованный список)
    → НЕ генерируй псевдокод до получения ответа

---

## Фаза 2: Синтез логики

1. Объедини связанные условия
2. Раздели взаимоисключающие сценарии (→ SWITCH)
3. Расставь приоритеты: STOP > модификация > действие по умолчанию
4. Убери дубли и лишние IF

---

## Фаза 3: Генерация

<task_description>
{ОПИШИ ЗАДАЧУ: для чего эти правила, что делает промпт, какой контекст использования}
</task_description>

<text_rules>
{ВСТАВЬ СВОИ ПРАВИЛА ОБЫЧНЫМ ТЕКСТОМ}
</text_rules>

---

## Формат вывода

1. Сформулируй задачу одним предложением (## Задача: ...)
2. Выведи готовый псевдокод внутри блока кода (```)

Требования к псевдокоду:
- генерируй ТОЛЬКО логически необходимые блоки
- не копируй шаблон построчно
- DEFAULT/FALLBACK/ALWAYS — только если логически оправданы

Доступные операторы (английский):
IF, ELSE, AND, OR, NOT, SWITCH, DEFAULT, FALLBACK, ALWAYS, STOP

Все условия, действия и значения — на РУССКОМ языке.

Пример допустимого формата (НЕ шаблон для копирования):

```
## Задача: генерация ответа на обращение клиента

IF условие:
    → действие

SWITCH тип_запроса:
    CASE "тип_1": → действие для типа 1
    CASE "тип_2": → действие для типа 2

IF критическое_нарушение:
    → STOP
    → альтернативное действие

DEFAULT параметр: "значение"
ALWAYS в конце: → действие
```

НЕ объясняй. Либо задай уточняющие вопросы, либо выдай готовый промпт в блоке кода.

## Задача
Создай блок самопроверки <self_check> для моего промпта.

<prompt_description>
{ОПИШИ ЧТО ДЕЛАЕТ ТВОЙ ПРОМПТ И КАКИЕ КЛЮЧЕВЫЕ ТРЕБОВАНИЯ}
</prompt_description>

## Формат вывода
```xml
<self_check>
Перед отправкой ответа проверь:
□ [пункт проверки]
□ [пункт проверки]
□ [пункт проверки]
...

Если хоть один пункт НЕ выполнен — исправь ДО отправки.
</self_check>
```

Сгенерируй 5-8 конкретных пунктов проверки. НЕ объясняй — только готовый блок.

## Задача
Оберни текст в ASCII-рамку.

<text>
{ТВОЙ ТЕКСТ}
</text>

<style>double</style>

Стили:
- simple: ┌─┐│└─┘
- double: ╔═╗║╚═╝
- rounded: ╭─╮│╰─╯

## Формат вывода
Готовая рамка с текстом внутри. Без объяснений.

## Задача
Преобразуй мои входные данные в JSON-структуру для промпта.

<raw_data>
{ВСТАВЬ ДАННЫЕ В ЛЮБОМ ФОРМАТЕ — текст, список, таблица}
</raw_data>

## Требования
- Сгруппируй связанные данные
- Используй понятные ключи на английском
- Массивы для списков
- Вложенные объекты где логично

## Формат вывода
```json
{
  // структурированные данные
}
```

НЕ объясняй — только готовый JSON для вставки.

## Задача
Создай few-shot примеры для моей задачи.

<task_description>
{ОПИШИ ЗАДАЧУ: что на входе, что на выходе, какой формат результата}
</task_description>

<example_count>3-5</example_count>

## Требования
- Примеры разной сложности (простой → средний → сложный)
- Покажи edge cases если есть
- Используй разделитель === между примерами
- Формат: Вход → Выход

## Формат вывода
```
## Примеры (=== разделяет примеры)

Вход: "пример входа 1"
→ Выход: результат 1

===

Вход: "пример входа 2"
→ Выход: результат 2
```

НЕ объясняй — только готовые примеры для вставки.

## Задача
Подбери prompt decorators для моей задачи из двух семейств.

<task_description>
{ОПИШИ ЧТО ДОЛЖНА ДЕЛАТЬ МОДЕЛЬ}
</task_description>

<current_problems>
{ЧТО ИДЁТ НЕ ТАК — не рассуждает, игнорирует ограничения, формат сбивается}
</current_problems>

---

## Семейство 1: Cognitive & Generative (КАК думать)

| Декоратор | Что делает | Параметры |
|-----------|------------|-----------|
| +++Reasoning | Пошаговые рассуждения перед ответом | depth=basic/moderate/comprehensive |
| +++Refine | Итеративное улучшение ответа | iterations=1-5 |
| +++Debate | Внутренняя дискуссия с разных позиций | perspectives=2-4 |
| +++Import | Подтянуть знания из домена | domain=legal/medical/tech |
| +++Verify | Самопроверка перед финальным выводом | criteria=accuracy/completeness |
| +++Hypothesize | Генерация гипотез | count=3-5 |
| +++Synthesize | Объединение нескольких источников | — |

## Семейство 2: Expressive & Systemic (КАК выводить)

| Декоратор | Что делает | Параметры |
|-----------|------------|-----------|
| +++Tone | Стиль общения | style=formal/casual/technical/friendly |
| +++OutputFormat | Формат ответа | type=json/markdown/list/table |
| +++Length | Контроль объёма | target=short/medium/long, max_words=N |
| +++Priority | Ранжирование по важности | order=desc/asc |
| +++Audience | Адаптация под читателя | level=beginner/expert/executive |
| +++Language | Язык вывода | lang=ru/en |
| +++Confidence | Показывать уверенность | show=true/false |

---

## Формат вывода
1. Предложи 3-5 декораторов комбинацией:
   ```
   +++Decorator1 + +++Decorator2(param=value) + +++Decorator3
   ```
2. Для каждого — 1 предложение что он решает.
3. Покажи пример использования в реальном промпте.

НЕ объясняй теорию — только готовая комбинация декораторов.

## Задача
Преобразуй мой текст в XML-структуру с семантичными тегами.

<raw_text>
{ВСТАВЬ ТЕКСТ С ДАННЫМИ — инструкции, контекст, параметры вперемешку}
</raw_text>

---

## Правила создания тегов

1. **Имена тегов = смысл содержимого**
   - ✅ <customer_complaint>, <product_specs>, <deadline>
   - ❌ <data1>, <text>, <info>

2. **Стандартные теги** (используй где подходят):
   - <role> — роль/персона модели
   - <task> — что нужно сделать
   - <context> — фоновая информация
   - <input> — данные для обработки
   - <constraints> — ограничения
   - <output_format> — формат результата
   - <examples> — примеры

3. **Вложенность** — группируй связанные данные:
   ```
   <customer>
     <name>...</name>
     <history>...</history>
   </customer>
   ```

4. **Атрибуты** — для метаданных:
   ```
   <document type="contract" priority="high">...</document>
   ```

---

## Формат ответа
Готовая XML-структура. БЕЗ объяснений — только результат.

## Задача
Преобразуй мои текстовые параметры в YAML-конфигурацию.

<raw_parameters>
{ВСТАВЬ ПАРАМЕТРЫ ТЕКСТОМ — тон, длина, ограничения, настройки}
</raw_parameters>

---

## Правила YAML

1. **Группировка по смыслу:**
   ```yaml
   output:
     format: json
     language: ru
     max_length: 500
   ```

2. **Списки через дефис:**
   ```yaml
   forbidden_words:
     - "очевидно"
     - "просто"
     - "легко"
   ```

3. **Вложенность для сложных правил:**
   ```yaml
   tone:
     style: professional
     exceptions:
       - context: "приветствие"
         style: friendly
   ```

4. **Булевы значения:** `true/false` (не "да/нет")

5. **Числа без кавычек:** `max_tokens: 1000`

---

## Формат ответа
Готовый YAML-блок. БЕЗ объяснений — только конфиг.

## Задача
Преобразуй мои данные в Markdown-таблицу.

<raw_data>
{ВСТАВЬ ДАННЫЕ — список, текст, JSON, что угодно}
</raw_data>

<table_purpose>
{ОПИШИ ДЛЯ ЧЕГО ТАБЛИЦА — сравнение, справочник, анализ}
</table_purpose>

---

## Правила форматирования

1. **Заголовки** — краткие, информативные (1-3 слова)
2. **Выравнивание:**
   - Текст → по левому краю `:---`
   - Числа → по правому краю `---:`
   - Центр → `:-:` (для статусов, флагов)

3. **Сортировка** — по важности или алфавиту
4. **Пустые ячейки** — `—` (не оставлять пустыми)

---

## Формат ответа
Готовая Markdown-таблица. БЕЗ объяснений.

## Задача
Создай JSON-схему для формата ответа модели.

<output_description>
{ОПИШИ КАКИЕ ПОЛЯ НУЖНЫ В ОТВЕТЕ И ИХ ТИПЫ}
</output_description>

<strictness>strict</strictness>

---

## Уровни строгости

### MINIMAL — только структура
```json
{
  "field_name": "тип или пример"
}
```

### STANDARD — с типами и описаниями
```json
{
  "field_name": {
    "type": "string|number|boolean|array|object",
    "description": "что это поле означает"
  }
}
```

### STRICT — полная JSON Schema
```json
{
  "type": "object",
  "properties": {
    "field_name": {
      "type": "string",
      "description": "...",
      "enum": ["вариант1", "вариант2"]
    }
  },
  "required": ["field_name"]
}
```

---

## Правила

1. **Имена полей** — snake_case на английском
2. **Обязательные поля** — помечай в `required`
3. **Enum** — для полей с фиксированным набором значений
4. **Вложенность** — для группировки связанных данных
5. **Массивы** — указывай тип элементов: `"items": {"type": "string"}`

---

## Формат ответа
1. JSON-схема выбранного уровня строгости
2. Пример заполненного JSON (для проверки)

## Задача
Создай контрастные пары примеров для моей задачи.

<task_description>
{ОПИШИ ЗАДАЧУ: что модель должна делать}
</task_description>

<quality_criteria>
{ЧТО ОТЛИЧАЕТ ХОРОШИЙ ОТВЕТ ОТ ПЛОХОГО}
</quality_criteria>

<pairs_count>3</pairs_count>

---

## Правила создания пар

1. **Один вход — два выхода:**
   ```
   Вход: "текст запроса"
   ❌ Плохо: [почему плохо]
   ✅ Хорошо: [почему хорошо]
   ```

2. **Типы ошибок для ❌:**
   - Неполный ответ
   - Неправильный формат
   - Нарушение тона/стиля
   - Фактическая ошибка
   - Лишняя информация

3. **Комментарии** — кратко объясни разницу в скобках

4. **Разделитель** между парами: `===`

---

## Формат ответа
Готовые контрастные пары. БЕЗ объяснений — только примеры.

## Задача
Расставь приоритеты моим правилам по уровням критичности.

<rules_list>
{ВСТАВЬ СПИСОК ПРАВИЛ БЕЗ ПРИОРИТЕТОВ}
</rules_list>

<context>
{ОПИШИ КОНТЕКСТ: для чего эти правила, что критично}
</context>

---

## Уровни приоритета

### 🔴 КРИТИЧНО (нарушение = провал)
- Безопасность, юридические требования
- Ключевая функциональность
- Запреты, которые нельзя нарушать

### 🟡 ВАЖНО (нарушение = снижение качества)
- Формат вывода
- Тон и стиль
- Полнота ответа

### 🟢 ЖЕЛАТЕЛЬНО (nice to have)
- Оптимизации
- Улучшения UX
- Дополнительные детали

---

## Правила приоритизации

1. Если правило связано с безопасностью → 🔴
2. Если нарушение видно пользователю сразу → 🟡
3. Если нарушение незначительно влияет на результат → 🟢
4. Максимум 3-4 правила на уровень 🔴
5. Группируй связанные правила

---

## Формат ответа
```
### 🔴 КРИТИЧНО
1. правило
2. правило

### 🟡 ВАЖНО
3. правило
4. правило

### 🟢 ЖЕЛАТЕЛЬНО
5. правило
```

БЕЗ объяснений — только готовый список с приоритетами.

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

<text_rules>
{ВСТАВЬ ПРАВИЛА ОБЫЧНЫМ ТЕКСТОМ}
</text_rules>

---

## Синтаксис MetaGlyph

### Базовые символы
- `→` — следствие, результат
- `|` — ИЛИ (альтернативы)
- `&` — И (все условия)
- `!` — НЕ (отрицание)
- `?` — опционально
- `*` — любое количество
- `+` — один или более
- `∅` — пусто, ничего

### Скобки
- `{}` — условие/контекст
- `[]` — опциональный блок
- `()` — группировка
- `<>` — плейсхолдер/переменная

### Модификаторы
- `⚠️` — предупреждение
- `🔴` — критично/запрет
- `✓` — обязательно
- `≈` — примерно/около
- `∈` — принадлежит множеству

### Паттерн правила
```
{условие} → действие [модификатор]
```

---

## Примеры преобразования

Текст: "Если цена больше 10000, пометить как премиум"
MetaGlyph: `{price > 10000} → label: "премиум"`

Текст: "Ответ должен быть на русском или английском"
MetaGlyph: `lang ∈ {ru | en} ✓`

Текст: "Никогда не упоминать конкурентов"
MetaGlyph: `🔴 !mention(<competitors>)`

---

## Формат ответа
Готовые правила в нотации MetaGlyph. БЕЗ объяснений.

## Задача
Отформатируй мои данные с правильным токенным разделением.

<raw_data>
{ВСТАВЬ ДАННЫЕ — числа, списки, категории}
</raw_data>

<data_type>
{ТИП ДАННЫХ: числа | категории | список | смешанный}
</data_type>

---

## Правила разделения

### Числа
❌ Плохо: `123456789` (один токен, модель не "видит" структуру)
✅ Хорошо: `123 456 789` или `123,456,789`

### Списки элементов
❌ Плохо: `яблоко,груша,банан` (слипается)
✅ Хорошо: `яблоко, груша, банан` (пробел после запятой)

### Категории/теги
❌ Плохо: `#тег1#тег2#тег3`
✅ Хорошо: `#тег1 #тег2 #тег3` или построчно

### ID и коды
❌ Плохо: `USR-12345-ABC`
✅ Хорошо: `USR - 12345 - ABC` (пробелы вокруг дефисов)

### Длинный текст для анализа
- Разбивай на абзацы (пустая строка)
- Нумеруй если порядок важен: `1. ... 2. ...`

---

## Формат ответа
Отформатированные данные с правильным разделением. БЕЗ объяснений.