| name | tessera-task-workflow |
| description | Работа с задачами Tessera через MCP-тулы (tessera-mcp) — как агенту брать задачи в работу, задавать уточняющие вопросы, прикладывать результаты/скриншоты и возвращать задачу пользователю на проверку. Использовать при любой разработке, управляемой задачами из Tessera (задача назначена на бота Tessera MCP Agent), и когда нужно отчитаться о работе или запросить ревью/тестирование в самой задаче. |
tessera-task-workflow
Как вести разработку, управляемую задачами из Tessera, через MCP-сервер tessera-mcp
(тулы tessera_*). Скилл описывает договорённость о владении задачами и полный цикл:
взять в работу → уточнить → сделать → приложить результаты → вернуть на проверку.
Договорённость о владении (важно)
- Пользователь (
msdnna) создаёт задачи и назначает их на бота Tessera MCP Agent.
Значит агент находит свою работу через задачи, где он — исполнитель.
- Всё, что требует проверки/тестирования пользователем, агент возвращает автору:
переносит в колонку «На рассмотрении» и ставит исполнителем автора задачи
(снимая бота). Пользователь тестирует и либо принимает, либо возвращает с
комментарием.
- Различать, кто что написал в треде, помогает флаг
is_agent в комментариях
(get_task): true — коммент бота, false — сообщение пользователя. Ответы
пользователя на свои вопросы читать как НЕ-свои (is_agent:false) комменты.
Ветка разработки — develop. После завершения кода финализировать релиз через скилл
tessera-ship (bump VERSION + CHANGELOG + conventional-commit; без push/tag).
Цикл работы над задачей
- Найти работу.
tessera_my_tasks (workspace, ранжировано) или tessera_next_task
(одна верхняя actionable; на доске пропускает заблокированные). Токен MCP —
бот-юзера, поэтому «мои задачи» = назначенные на бота.
- Прочитать целиком.
tessera_get_task (по task_id или workspace_id+number):
описание, теги, подзадачи, комментарии (с автором/is_agent), images. Картинки
(скриншоты/схемы в описании и комментах) реально посмотреть — tessera_view_image
(без ref — все картинки задачи; либо конкретный ref из images). Подзадачи —
полноценные задачи: у них свои описание/комменты/картинки, обращаться по их id.
- Взять в работу.
tessera_move_task(task_id, column:"В процессе").
- Уточнить, если неоднозначно. Вопрос — комментом:
tessera_add_comment. Затем
перечитать get_task и взять ответ пользователя (первый is_agent:false коммент
после вопроса). Не гадать по неясным требованиям — спросить.
- Делать работу (код по конвенциям репо — см.
CLAUDE.md, профильные скиллы
tessera-backend-feature и т.п.).
- Приложить результаты в задачу:
- План или итоговый отчёт в описание —
tessera_update_description
(mode:"append" по умолчанию, heading:"План"/"Результаты"; replace только
если явно нужно перезаписать). Остальные поля задачи сохраняются.
- Ход работы / evidence — комментами
tessera_add_comment. Скриншоты тестов
(CDP и пр.) и картинки — через image_paths (локальные пути; MCP-сервер
читает их со своей ФС и встраивает inline). Годится для доказательства, что
фича работает.
- Вернуть на проверку. Когда нужна проверка/тестирование пользователем:
tessera_move_task(task_id, column:"На рассмотрении")tessera_assign_task(task_id, assignees:["author"], replace:true) — вернуть
исполнителем создателя, снять бота.- Кратким комментом резюмировать, что сделано и что проверить.
Если задача полностью закрыта (проверка не нужна) — перенести в done-колонку
(
tessera_list_columns → is_done:true, обычно «Готово»); вход в неё авто-завершает
задачу.
Диагностика и верификация через Sentry
Для задач про ошибки (internal error/5xx/паники) и для проверки, что фикс их убрал,
используй self-hosted Sentry (MCP sentry-self-hosted) — точнее и быстрее, чем
грепать логи: бэкенд шлёт туда любой 5xx и паники фоновых воркеров. Полный порядок
(триаж → анализ Seer → верификация «ошибка больше не воспроизводится» → update_issue)
и гейтинг — в скилле tessera-sentry. Ключевое: Sentry применять только если
он настроен и реально принимает события (иначе — по логам); «200 от relay ≠ долетело»
— проверяй, что событие видно в search_issues, а не что бэкенд его залогировал.
Sentry подтверждает «ошибок нет», но не заменяет функциональную проверку (e2e/CDP из
tessera-e2e).
Побочные / незнакомые ошибки → отдельная задача
Всплыла ошибка не по текущей задаче (незнакомый стек, чужая ручка, странная паника
в Sentry или логах) — не чинить молча и не игнорировать: завести отдельную задачу
tessera_create_task (суть в заголовке; в описании — проект/env Sentry, issue id,
http.route/component, стек/request_id, частота, гипотеза Seer), пометить тегом
(bug/sentry), при связи с текущей — tessera_link_tasks(kind:"relates"). Перед
созданием проверить дубли (tessera_list_tasks). Цель — накапливать и минимизировать
такие ошибки, а не терять их. Детали — в tessera-sentry.
Тулы
| Тул | Назначение |
|---|
tessera_my_tasks / tessera_next_task | Очередь работы (назначенное на бота), ранжированная |
tessera_get_task | Полная деталь: описание, подзадачи, комменты (author/is_agent), images |
tessera_view_image | Показать картинки задачи (описание+комменты+вложения) агенту |
tessera_list_columns | Колонки доски (+флаг is_done) — валидные цели переноса |
tessera_move_task | Перенос по имени колонки («В процессе»/«На рассмотрении»/…) или UUID |
tessera_add_comment | Коммент (Markdown); image_paths — залить+встроить скриншоты |
tessera_update_description | Дописать/заменить описание (план, отчёт) |
tessera_assign_task | Исполнители: email/имя/UUID/author/me; replace — вернуть автору |
Задачи адресуются task_id (id подзадачи тоже подходит) или workspace_id+number
(#252).
Гочи
- Личность = владелец токена. Комменты/назначения авторствуются юзером, на которого
выпущен PAT. Для чистого
is_agent/Q&A токен MCP должен быть бот-юзера
(Tessera MCP Agent), а не личного. Проверить: свой свежий коммент в get_task
должен иметь is_agent:true. Токен задаётся в конфиге MCP-клиента (TESSERA_TOKEN);
для Claude Code CLI это ~/.claude.json → mcpServers.tessera-mcp.env.
- Новые тулы подхватываются после реконнекта MCP-клиента (перезапуск сессии/клиента),
не в текущей сессии, где сервер уже запущен.
image_paths читает MCP-сервер со своей ФС — путь должен быть доступен процессу
сервера (ок, когда сервер и агент на одном хосте).- Не перетирать чужое.
update_description по умолчанию append; менять исполнителей
с replace:true осознанно (снимает остальных).
