Ticket Filler
Заполняет описание Jira-тикета по единому формату и подтягивает контекст из
ссылок на Slack и GitHub, если они встречаются в тикете.
Когда использовать
- Пишешь новый тикет с нуля.
- Дорабатываешь существующий тикет, у которого есть только заголовок или
обрывочное описание.
- В тикете (или в связанных тикетах/комментариях) есть ссылка на Slack-тред
или GitHub (PR, issue, commit, файл).
Целевая структура описания
Используй заголовки уровня 2.
## Проблема
Что сейчас не так или чего не хватает. 1-3 предложения. Без предлагаемого решения.
## Контекст
Почему всплыло сейчас, кто просил, что уже пробовали. Ссылки на источники
(Slack, GitHub, связанные тикеты) — с кратким пересказом, что там внутри,
а не голым URL.
## Ожидаемый результат (DOD)
Список проверяемых критериев. Каждый пункт — факт, который можно
подтвердить да/нет, а не оценочное состояние ("стало быстрее").
## Вне скоупа
Опционально. Что сознательно не делаем в этом тикете.
## Технические заметки
Опционально. Предлагаемый подход, если он уже понятен и стоит его
зафиксировать.
Проблема / Контекст / DOD — обязательны всегда. Остальные два блока — только
если есть что туда положить; пустые заголовки не создавать.
Порядок работы
Собери исходный материал.
Прочитай существующий тикет (summary, description, комментарии) через
Atlassian:getJiraIssue (fields: summary, description, comment).
Если тикета ещё нет — работай от того, что рассказал пользователь в чате.
Найди ссылки на Slack и GitHub.
Проверь description, комментарии и то, что написал пользователь в чате.
Признаки Slack-ссылки: домен slack.com, пути вида /archives/,
/messages/. Признаки GitHub-ссылки: домен github.com, пути
/pull/, /issues/, /commit/, /blob/.
Сходи по каждой найденной ссылке, прежде чем писать раздел "Контекст".
Не пересказывай ссылку как есть — вытащи из неё суть.
- Slack-тред: используй
slack_read_thread (или slack_read_channel,
если это не тред, а отдельное сообщение) — нужен инструмент из
Slack-коннектора, найди его через tool_search, если он ещё не
загружен. Возьми: кто поднял вопрос, какие решения обсуждались, на чём
сошлись. Не нужно копировать сообщения целиком — 2-3 предложения сути
достаточно.
- GitHub PR / issue / commit: используй GitHub-инструменты, если они
подключены (
tool_search по "github pull request issue"); если
коннектора нет — web_fetch по прямой ссылке (публичный репозиторий).
Возьми: что менялось и почему, текущий статус (open/merged/closed),
ключевые комментарии ревью, если они меняют суть задачи.
- Если ссылка ведёт в приватный ресурс, который недоступен ни одним из
инструментов — не выдумывай содержимое. Скажи пользователю, что не
смог открыть ссылку, и попроси кратко описать, что там.
Собери черновик по структуре выше. Пиши короткими предложениями,
один факт — одно предложение, без канцелярита и вводных конструкций.
DOD — только пункты, которые можно закрыть галочкой.
Покажи черновик пользователю в чате и спроси подтверждение,
прежде чем записывать его в Jira. Обновление тикета (Atlassian:editJiraIssue
или createJiraIssue) — это изменение внешнего документа, делай это
только после явного "да" от пользователя. Не отправляй тикет в статус
"готов к ревью" и не меняй его transition без отдельного запроса.
Если пользователь просит завести сразу несколько тикетов из одного
разговора — обработай их по одному, каждый раз собирая контекст (шаг 1-3)
именно для этого тикета, а не копируя общий контекст на все.
Чего не делать
- Не подставляй раздел "Технические заметки", если решение ещё не обсуждали
— пустое предложение решения хуже, чем его отсутствие.
- Не оставляй в "Контексте" голые ссылки без пересказа — цель ссылки в
тикете дать проверяемый источник, а не заставить читателя переходить по
ней, чтобы понять, о чём тикет.
- Не копируй текст Slack-сообщений или GitHub-комментариев дословно длинными
кусками — пересказывай своими словами.
1---2name: jira-ticket-filler3description: Use this skill whenever the user asks to write, fill in, dополнить, doработать, or enrich a Jira ticket description — especially for the Data Forge team's tickets. Trigger it any time a ticket (existing or new) needs a Problem / Context / Expected Result structure, or when the ticket text or a linked source contains a Slack link (archives, /messages/, thread) or a GitHub link (PR, issue, commit, file, repo). Always use this skill before writing a ticket description from scratch, and always use it when asked to "заполни тикет", "оформи тикет", "допиши контекст в тикет", or similar — don't just paraphrase the raw ticket text without following this structure and without checking linked sources.4---56# Ticket Filler78Заполняет описание Jira-тикета по единому формату и подтягивает контекст из9ссылок на Slack и GitHub, если они встречаются в тикете.1011## Когда использовать1213- Пишешь новый тикет с нуля.14- Дорабатываешь существующий тикет, у которого есть только заголовок или15 обрывочное описание.16- В тикете (или в связанных тикетах/комментариях) есть ссылка на Slack-тред17 или GitHub (PR, issue, commit, файл).1819## Целевая структура описания2021Используй заголовки уровня 2.2223```24## Проблема25Что сейчас не так или чего не хватает. 1-3 предложения. Без предлагаемого решения.2627## Контекст28Почему всплыло сейчас, кто просил, что уже пробовали. Ссылки на источники29(Slack, GitHub, связанные тикеты) — с кратким пересказом, что там внутри,30а не голым URL.3132## Ожидаемый результат (DOD)33Список проверяемых критериев. Каждый пункт — факт, который можно34подтвердить да/нет, а не оценочное состояние ("стало быстрее").3536## Вне скоупа37Опционально. Что сознательно не делаем в этом тикете.3839## Технические заметки40Опционально. Предлагаемый подход, если он уже понятен и стоит его41зафиксировать.42```4344Проблема / Контекст / DOD — обязательны всегда. Остальные два блока — только45если есть что туда положить; пустые заголовки не создавать.4647## Порядок работы48491. **Собери исходный материал.**50 Прочитай существующий тикет (summary, description, комментарии) через51 `Atlassian:getJiraIssue` (fields: `summary`, `description`, `comment`).52 Если тикета ещё нет — работай от того, что рассказал пользователь в чате.53542. **Найди ссылки на Slack и GitHub.**55 Проверь description, комментарии и то, что написал пользователь в чате.56 Признаки Slack-ссылки: домен `slack.com`, пути вида `/archives/`,57 `/messages/`. Признаки GitHub-ссылки: домен `github.com`, пути58 `/pull/`, `/issues/`, `/commit/`, `/blob/`.59603. **Сходи по каждой найденной ссылке**, прежде чем писать раздел "Контекст".61 Не пересказывай ссылку как есть — вытащи из неё суть.6263 - **Slack-тред**: используй `slack_read_thread` (или `slack_read_channel`,64 если это не тред, а отдельное сообщение) — нужен инструмент из65 Slack-коннектора, найди его через `tool_search`, если он ещё не66 загружен. Возьми: кто поднял вопрос, какие решения обсуждались, на чём67 сошлись. Не нужно копировать сообщения целиком — 2-3 предложения сути68 достаточно.69 - **GitHub PR / issue / commit**: используй GitHub-инструменты, если они70 подключены (`tool_search` по "github pull request issue"); если71 коннектора нет — `web_fetch` по прямой ссылке (публичный репозиторий).72 Возьми: что менялось и почему, текущий статус (open/merged/closed),73 ключевые комментарии ревью, если они меняют суть задачи.74 - Если ссылка ведёт в приватный ресурс, который недоступен ни одним из75 инструментов — не выдумывай содержимое. Скажи пользователю, что не76 смог открыть ссылку, и попроси кратко описать, что там.77784. **Собери черновик** по структуре выше. Пиши короткими предложениями,79 один факт — одно предложение, без канцелярита и вводных конструкций.80 DOD — только пункты, которые можно закрыть галочкой.81825. **Покажи черновик пользователю в чате** и спроси подтверждение,83 прежде чем записывать его в Jira. Обновление тикета (`Atlassian:editJiraIssue`84 или `createJiraIssue`) — это изменение внешнего документа, делай это85 только после явного "да" от пользователя. Не отправляй тикет в статус86 "готов к ревью" и не меняй его transition без отдельного запроса.87886. Если пользователь просит завести сразу несколько тикетов из одного89 разговора — обработай их по одному, каждый раз собирая контекст (шаг 1-3)90 именно для этого тикета, а не копируя общий контекст на все.9192## Чего не делать9394- Не подставляй раздел "Технические заметки", если решение ещё не обсуждали95 — пустое предложение решения хуже, чем его отсутствие.96- Не оставляй в "Контексте" голые ссылки без пересказа — цель ссылки в97 тикете дать проверяемый источник, а не заставить читателя переходить по98 ней, чтобы понять, о чём тикет.99- Не копируй текст Slack-сообщений или GitHub-комментариев дословно длинными100 кусками — пересказывай своими словами.
vsevolodbazhan