jira

name	jira
description	Генерация названия и описания задачи Jira по коммитам или описанию

Скилл: JIRA

1. Получение данных:

   • Если пользователь предоставил ID коммита или хеш:
     • Попробуй найти его через git show <ID>.
     • Если не найдено, используй поиск: git log --all --grep=<ID> или git log --all --oneline | grep <ID>.
   • Если пользователь предоставил описание изменений, используй его.
   • Если входных данных нет, запроси их у пользователя.

2. Анализ:

   • ВАЖНО: Анализируй код изменений (diff), а не то, что написано в сообщении коммита. Сообщения коммитов часто бывают неточными или неполными.
   • ПРОВЕРЯЙ ВСЕ ФАЙЛЫ: Убедись, что ты просмотрел ВСЕ измененные файлы. Используй git show --stat <ID>, чтобы увидеть полный список файлов, если git show обрезал вывод. Не пропускай файлы только потому, что они не поместились в первый экран вывода.
   • Посмотри, какие файлы были изменены, какие функции добавлены или удалены, как изменилась логика.
   • На основе изменений в коде сформулируй заголовок и описание задачи для Jira.
   • Используй менеджерский язык (какую пользу это приносит, как меняется поведение системы), избегая излишних технических деталей реализации (какие классы созданы, какие методы вызваны), если это не критично для понимания сути.

3. При генерации текста СТРОГО соблюдай следующие правила форматирования:

   Форматирование:

   • ЗАПРЕЩЕНО использовать маркированные или нумерованные списки.
   • Текст должен быть разбит на абзацы.
   • Заголовки внутри текста (если нужны): выделяй жирным, начинай с прописной буквы.
   • Эмодзи: 🎨 Текст, идущий сразу после графического символа, всегда пиши с прописной буквы.
   • Техническая лексика: используй Sentence case (как в обычном предложении).
     • Исключения: сохраняй оригинальный регистр для брендов, языков программирования (PHP, Laravel, Vue.js) и аббревиатур (API, JSON). Используй Title Case для устоявшихся английских терминов (если они необходимы).
   • Типографика: используй обычный дефис (-) вместо длинного тире (-) во всех случаях.
   • ЗАПРЕЩЕНО использовать обратные кавычки (`). Даже для названий переменных, методов или файлов. Пиши их просто текстом.

   Стиль и лексика:

   • Перспектива "Что нужно сделать": Описывай задачу так, как будто она только планируется к выполнению.
     • ПЛОХО: "Разработана команда...", "Добавлена вкладка...", "Внедрена поддержка..." (прошедшее время).
     • ХОРОШО: "Разработать команду...", "Добавить вкладку...", "Внедрить поддержку...", "Реализовать фильтрацию..." (инфинитив или повелительное наклонение).
   • Без канцеляризмов: исключи «роботизированные» обороты, штампы, вводные конструкции.
   • МИНИМУМ технических деталей:
     • ЗАПРЕЩЕНО писать названия классов, методов, переменных, путей к файлам (если это не критично).
     • ЗАПРЕЩЕНО упоминать конкретные правила валидации (например, "max:65535"), если это не влияет на пользовательский опыт напрямую.
     • Вместо "Изменен файл FormMessageRequest.php" пиши "Обновлена обработка формы".
     • Вместо "Заменено правило text на string" пиши "Исправлена проверка типов данных".
   • Живой язык: пиши естественно, понятно для менеджера и пользователя.

4. Выведи результат в следующем формате:

   Заголовок: [Краткая суть одним предложением]

   Описание:

   [Текст описания в виде абзацев. Каждый новый логический блок в новом абзаце.]

   [Еще один абзац, если необходимо.]