Структурированный вывод
Каждый баг-репорт следует этой структуре:
- Заголовок — короткое саммари (макс. 8 слов)
- Что происходит — описание поведения бага
- Git-контекст — текущая ветка и последние изменения
- Шаги воспроизведения — определённые из описания или плейсхолдеры
- Ожидалось / Получилось — формат сравнения
Авто-определение severity
Система определяет уровень severity по описанию:
| Severity | Триггер-слова | Пример |
|---|---|---|
| Critical | падение, потеря данных, security, лежит, блокирует | «Приложение падает при старте» |
| High | сломано, не работает, не могу, регрессия | «Форма логина не проходит валидацию» |
| Medium | неверно, не так, неожиданно, медленно | «API возвращает не те данные» |
| Low | минор, косметика, опечатка, выравнивание | «Кнопка съехала на мобиле» |
Интеграция с git
Один Bash-вызов собирает:
- Имя текущей ветки
- Резюме последних изменений (несколько последних коммитов)
- Изменённые файлы, релевантные области бага
Этот контекст автоматически попадает в баг-репорт — следующий разработчик увидит, какой код менялся рядом с багом.
Когда /note-bug вместо /note
Используй /note-bug вместо /note, когда нужны:
- Автоматическая пометка severity
- Git-контекст в репорте
- Структурированный формат шагов воспроизведения
- Розовая раскраска для быстрого визуального поиска