Что получится
ИИ-агент для Jira и Linear помогает разбирать задачи, искать дубликаты, предлагать labels, собирать статус по проекту, создавать тикеты из чата, готовить sprint report и объяснять, где застрял backlog.
Безопасная первая версия читает задачи и предлагает изменения. Создание, массовое обновление, смена статусов, перенос между спринтами и закрытие задач должны идти через подтверждение человека.
Где такой агент полезен
- Product management: привести backlog в порядок.
- Разработка: найти задачи без описания, owner или acceptance criteria.
- Поддержка: превратить обращение в задачу с правильным компонентом.
- Руководители: получить статус проекта без ручного опроса.
- QA: собрать баги по версии, компоненту или приоритету.
- Delivery: увидеть заблокированные задачи и риски спринта.
Шаг 1. Выберите роль агента
Не запускайте агента сразу как “автоматического project manager”. Начните с одной роли.
Безопасные варианты:
- backlog reviewer;
- issue triage;
- sprint reporter;
- duplicate finder;
- task creator из Slack/Teams;
- acceptance criteria assistant;
- blocker monitor.
Для MVP достаточно сценария “прочитать задачи проекта, найти проблемы и предложить правки”.
Шаг 2. Подключите Jira или Linear
В Jira Cloud используют REST API и JQL для поиска задач. JQL позволяет выбирать work items по проекту, статусу, исполнителю, типу, priority, sprint, labels и другим полям.
В Linear используется GraphQL API. Через него можно читать issues, teams, projects, cycles, labels, comments и создавать или обновлять задачи.
Сразу решите:
- агент работает только с одним проектом или несколькими;
- какие поля можно читать;
- какие поля можно менять;
- кто может вызывать команды;
- нужны ли webhooks для новых задач и изменений.
Шаг 3. Настройте минимальные права
Для первой версии достаточно read-only.
Минимальные права:
- читать задачи выбранного проекта или команды;
- читать комментарии, если они нужны для контекста;
- читать labels, components, statuses и users;
- создавать комментарии с предложением;
- не менять статусы без approval;
- не удалять и не архивировать задачи;
- не выполнять bulk update без review.
Если агент создает задачи из чата, выдайте ему отдельное право на create, но не на администрирование проекта.
Шаг 4. Опишите модель данных
Модель должна понимать, что в вашей команде означает задача.
Соберите schema context:
- типы задач: bug, task, story, epic;
- статусы workflow;
- приоритеты;
- компоненты;
- labels;
- правила assignment;
- definition of ready;
- definition of done;
- sprint/cycle правила;
- обязательные поля.
Без этого агент будет предлагать красивые, но бесполезные изменения.
Шаг 5. Сделайте поиск задач
В Jira агент может превращать вопрос в JQL. Например: “покажи критичные баги без исполнителя в текущем спринте”.
Для Linear агент строит GraphQL query с фильтрами по team, project, state, assignee, labels и cycle.
Важно: не отдавайте модели право выполнять произвольные запросы без проверки.
Проверяйте:
- проект или команда разрешены;
- нет слишком широкого запроса;
- есть limit/pagination;
- выбраны только нужные поля;
- запрос не раскрывает приватные проекты;
- пользователь имеет право видеть результат.
Шаг 6. Настройте issue triage
Triage-агент может предложить:
- тип задачи;
- компонент;
- приоритет;
- labels;
- похожие задачи;
- missing fields;
- ответственного;
- следующий шаг.
На старте лучше оставлять комментарий:
Предлагаю: priority High, component Billing, label regression. Не хватает шагов воспроизведения и expected result.
После проверки можно разрешить автоприменение labels для низкорисковых проектов.
Шаг 7. Добавьте проверку качества задач
Backlog часто страдает не от количества задач, а от плохих описаний.
Агент может проверять:
- есть ли проблема;
- есть ли expected result;
- есть ли actual result для багов;
- есть ли acceptance criteria;
- есть ли link на макет, лог или клиента;
- понятно ли, кто владелец;
- не устарела ли задача;
- нет ли дубликата.
Это полезнее, чем автоматическая генерация длинных описаний.
Шаг 8. Создавайте задачи через approval
Если агент создает задачу из Slack, письма или звонка, сначала покажите черновик.
Карточка должна содержать:
- title;
- description;
- project/team;
- type;
- priority;
- labels;
- assignee;
- links на источник;
- acceptance criteria;
- кнопки “создать”, “изменить”, “отмена”.
Так агент не засоряет backlog сырыми задачами.
Шаг 9. Собирайте отчеты
Отчеты - один из самых безопасных и полезных сценариев.
Агент может отвечать:
- что изменилось за неделю;
- какие задачи заблокированы;
- что в риске по срокам;
- какие баги появились по версии;
- какие задачи без владельца;
- что ушло из спринта;
- какие PR связаны с задачами.
Хороший отчет содержит ссылки на задачи и явно пишет, какие фильтры использованы.
Шаг 10. Обрабатывайте статусы осторожно
Смена статуса - это действие, влияющее на процесс команды. Не позволяйте агенту свободно двигать задачи по workflow.
Правила:
- read-only анализ можно делать автоматически;
- комментарии с предложениями можно делать после проверки прав;
- смена статуса требует approval;
- закрытие задачи требует ссылки на PR, релиз или подтверждение владельца;
- bulk move запрещен для первой версии;
- изменение sprint/cycle только через подтверждение.
Шаг 11. Логируйте все действия
Сохраняйте:
- пользователя;
- команду;
- проект или team;
- запрос;
- JQL или GraphQL query;
- найденные задачи;
- предложенные изменения;
- примененные изменения;
- ошибки API;
- версию промпта и модели.
Это помогает разбирать, почему агент предложил приоритет, label или перенос.
Шаг 12. Проверьте на реальном backlog
Соберите тестовый набор:
- новая сырая задача;
- баг без шагов воспроизведения;
- дубликат;
- задача без владельца;
- заблокированная задача;
- запрос широкого отчета;
- пользователь без прав;
- попытка массового изменения;
- конфликт между статусом и комментариями;
- задача с чувствительными данными.
Проверяйте не только текст ответа, но и то, какие действия агент попытался выполнить.
Минимальная архитектура
ИИ-агент для Jira и Linear состоит из восьми блоков.
- Task connector: Jira REST API/JQL или Linear GraphQL API.
- Webhook receiver: новые задачи, комментарии, статусы и изменения.
- Query builder: безопасный JQL или GraphQL.
- Schema context: workflow, поля, labels, priorities и правила команды.
- Triage engine: тип, приоритет, дубликаты и missing fields.
- Action layer: комментарий, create issue, update labels, report.
- Approval layer: подтверждение write-действий.
- Audit layer: запросы, API calls, изменения и ошибки.
Модель помогает понять задачу и написать предложение. API-действия, права и массовые изменения контролирует код.
Частые вопросы
Что лучше автоматизировать первым?
Начните с read-only отчетов и triage-предложений. Это дает пользу без риска испортить backlog или workflow команды.
Можно ли агенту самому закрывать задачи?
Для первой версии нет. Закрытие задачи должно требовать подтверждение человека и ссылку на PR, релиз, тест или другое основание.
Как избежать мусора в backlog?
Создавайте задачи через черновик и approval. Агент должен проверить title, description, acceptance criteria, источник и проект перед созданием.
Что важнее: JQL/GraphQL или промпт?
Оба важны, но бизнес-правила и проверка запросов должны быть в коде. Промпт не защитит от слишком широкого поиска, лишних полей или массовых изменений.
Можно ли связать агента с GitHub и Slack?
Да. Slack/Teams удобны для команд, GitHub - для PR и CI, Jira/Linear - для задач. Главное - сохранять ссылки между источниками и проверять права в каждой системе отдельно.
