Prompt Enhancer

---
name: prompt-enhancer
description: "Улучшает и структурирует короткие неструктурированные промпты и постановки задач, превращая их в подробные императивные ТЗ с пронумерованными шагами анализа, явными граничными случаями и описанием формата ожидаемого вывода. Сохраняет все термины и условия исходника, не добавляет новых требований. Используй когда пользователь просит: улучшить промпт, проработать постановку, расширить описание задачи, структурировать ТЗ, оформить заметку в подробную инструкцию, сделать промпт точнее или подробнее, подготовить ТЗ из черновика, причесать задание, преобразовать короткую заметку в понятное ТЗ. Принимает текст в аргументе команды или путь к .md файлу."
argument-hint: "[текст промпта | путь к .md файлу]"
allowed-tools:
  - Read
  - Write
---

# /prompt-enhancer - улучшение промптов и постановок задач

Превращает короткую заметку или неструктурированное задание в подробное императивное ТЗ. Подходит для разработчиков 1С, которым нужно оформить быстро сформулированную мысль в понятную постановку задачи.

## Когда использовать

Вызывай скил по фразам пользователя:

- "улучши промпт", "сделай промпт лучше / точнее / подробнее"
- "проработай постановку", "оформи задачу", "причеши задание"
- "структурируй ТЗ", "подготовь ТЗ из заметки"
- "расширь описание задачи", "преобразуй это в подробную инструкцию"

Скил работает с любой предметной областью, но специально учитывает особенности задач 1С (термины, имена реквизитов, объектов, форм).

## Режимы работы

| Режим | Триггер | Что делает |
|-------|---------|------------|
| Inline | аргумент - произвольный текст | Улучшенный промпт выводится в чат |
| File | аргумент - путь к существующему файлу | Результат сохраняется рядом с суффиксом `-enhanced.md` |
| Interactive | аргумент пустой | Спросить у пользователя текст или путь |

## Алгоритм определения режима

Режим выбирается детерминированно, без эвристики по тексту аргумента:

1. Если аргумент пустой - режим Interactive. Попросить у пользователя текст промпта или путь к файлу обычным сообщением.
2. Иначе попытаться прочитать аргумент через инструмент Read.
   - Если Read вернул содержимое файла - режим File.
   - Если Read вернул ошибку вида "файл не существует / не найден" - это штатный путь, не сбой. Переключиться в Inline: аргумент целиком использовать как текст промпта.
3. Не определять режим по наличию ".md" в тексте. Формулировка "оформи ТЗ про .md генерацию" не должна интерпретироваться как путь. Проверку существования файла делает Read, не парсинг строки.

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

Ядро скила. При каждой генерации возвращайся к этому списку:

1. **Сохранение исходника как источника истины.** Все термины, имена реквизитов, вкладок, объектов, форм, подсистем, числа, перечни переносить буквально. Не заменять "Орг_КодИсточника77" на "служебный реквизит".
2. **Императив вместо описания.** "нужно вывести" превращать в "Выведи", "надо бы проанализировать" в "Проанализируй". Результат это план действий, не рассказ.
3. **Явное выделение граничных случаев.** Условия-исключения выносить отдельным предложением в форме "если ..., то ...", не прятать в скобках. Граничный случай должен бросаться в глаза.
4. **Фиксация ожидаемого вывода.** Добавить раздел "Для каждого элемента укажи" с нумерованным списком полей. Формат результата (таблица, структурированный список, JSON) называть явно.
5. **Без новых требований.** Не добавлять требований, которых не было в исходнике: тесты, документация, роли, откаты, логирование. Улучшение это форма, не содержание.
6. **Нумерация шагов анализа.** Разбить пользовательские пожелания на дискретные проверяемые операции 1..N. Каждый шаг одна операция.
7. **Сохранение намерения, а не дословного текста.** Если в исходнике "подготовь список", а далее перечислены аналитические задачи, сначала идет анализ, потом составление списка. Восстановить правильный порядок.
8. **Нейтральный деловой регистр.** Убрать разговорные и эмоциональные элементы ("надо бы", "как-то так", "хотелось бы"), оставить нейтральную формулировку.
9. **Короткая суть в первой строке.** Перед пошаговым планом одно предложение, передающее цель задачи.
10. **Форматирование по правилам репо.** Без длинных и коротких тире (только обычный дефис), без буквы е с точками, без оценок времени и ROI.

## Шаблон улучшенного промпта

Обязательные блоки результата:

1. **Цель** - одно предложение, что нужно сделать.
2. **Шаги анализа** - нумерованный список императивов (Проанализируй, Изучи, Определи, Выведи).
3. **Граничные случаи** - явные условия "если ..., то ..." с конкретными именами и значениями из исходника.
4. **Формат вывода** - название формата (таблица / структурированный список / JSON) и перечень полей, которые должны быть в результате.
5. **Дополнительные уточнения** (опционально) - детали, если в исходнике были указаны сроки, ответственные, зависимости.

## Пример "до/после"

**Исходный промпт (короткий, неструктурированный):**

> Задача - все нетиповые реквизиты в типовых объектах вывести на вкладку "Доп. реквизиты Орг". Вкладку разместить самой последней. Если добавлен только один реквизит, Орг_КодИсточника77, то ничего не делаем. Подготовь список объектов, проанализируй формы элементов, определи, куда и как добавить вкладку.

**Улучшенный промпт (структурированный, подробный):**

> Проанализируй все типовые объекты конфигурации и подготовь список тех, в которых присутствуют нетиповые реквизиты. Изучи формы элементов этих объектов. Добавь в каждую форму новую вкладку "Доп. реквизиты Орг" последней по порядку. Перенеси на вкладку все нетиповые реквизиты, кроме случая, когда единственный нетиповой реквизит это Орг_КодИсточника77 (тогда изменения не вносятся). Для каждого объекта укажи:
>
> 1. Наименование объекта.
> 2. Список нетиповых реквизитов.
> 3. Название используемой формы элемента и текущую структуру вкладок.
> 4. Рекомендуемые изменения по размещению вкладки и переносу реквизитов с учетом логики интерфейса.
>
> Сформируй вывод в виде удобной таблицы или структурированного списка для дальнейшего внедрения.

Дополнительные кейсы смотри в `examples/`.

## DO / DON'T

**DO:**
- Сохранять имена объектов, реквизитов, вкладок, констант, перечисления буквально.
- Превращать просьбы в императивы, добавлять структуру и нумерацию.
- Выносить исключения и граничные случаи отдельным предложением.
- Указывать формат ожидаемого результата явно.
- Добавлять короткую суть первой строкой перед пошаговым планом.

**DON'T:**
- Придумывать новые требования, которых не было в исходнике (роли, тесты, откат, печать, логирование).
- Заменять конкретные термины обобщениями.
- Добавлять технические решения ("используй БСП", "сделай через HTTP сервис"), если они не упомянуты в исходнике.
- Использовать длинное тире, короткое тире, двойной дефис, букву е с точками.
- Оценивать трудозатраты в часах, днях, неделях, стоимость в деньгах.

## Сохранение файла (file-режим)

- Имя результата: `<имя исходного файла без расширения>-enhanced.md`. Если оригинал `postanovka.md`, результат `postanovka-enhanced.md` в той же папке.
- Кодировка: utf-8.
- Оригинал не перезаписывать, не удалять, не переименовывать.
- Если файл-результат уже существует, перезаписать без спроса (это повторный запуск скила).

## Обработка кодировки

Исходные файлы читаются как utf-8. Если Read возвращает явный mojibake (нечитаемая кириллица вида "ж©", "­", квадраты), сообщи пользователю, что файл похоже в cp1251 или другой кодировке, и попроси сохранить в utf-8. Автоопределение кодировки в скиле не реализовано намеренно - это осознанное упрощение первой версии.

## Фразы-триггеры (для надежности срабатывания)

Скил должен распознавать эти формулировки пользователя как триггеры, даже если команда `/prompt-enhancer` не указана явно:

- улучши / улучшить промпт
- расширь / проработай / оформи постановку (задачи, ТЗ)
- структурируй ТЗ / задание
- сделай промпт подробнее / точнее / лучше
- подготовь подробное ТЗ из заметки / черновика
- причеши задание / постановку
- преобразуй в понятное ТЗ / в подробную инструкцию

## Ограничения

- Скил переписывает форму, не содержание. Если исходный промпт логически противоречив или неполон, результат тоже будет неполным (см. принцип 5 - без новых требований).
- Для очень длинных исходных текстов (2000+ слов) обработка может упустить детали. В таком случае разбивай текст на логические блоки и обрабатывай по частям.
- Скил не предполагает знаний предметной области за пределами исходника. Если нужны уточнения про 1С-специфику, дополнительно используй `/1c-config-router`, `/composing-1c-queries` и смежные скилы репозитория.