Когда задачи для разработки начали регулярно готовиться вместе с AI-агентами, обычная форма "создать задачу и вручную вставить описание" стала лишним промежуточным действием. Текст уже существует в виде структурированного Markdown. Возник простой вопрос: зачем переписывать его в трекер, если файл уже является законченной постановкой?
Файл становится переносимой единицей работы
Мы закрепили правило: один MD-файл равен одной задаче в backlog. Файл содержит название, контекст, требования, ограничения и критерии приемки. Его можно прочитать отдельно от трекера, отправить другому агенту, положить в архив проекта или импортировать обратно.
Так задача перестает быть записью, привязанной к одному интерфейсу. У нее появляется переносимый исходник.
Пакетная загрузка меняет сам процесс декомпозиции
Если трекер умеет принять сразу несколько Markdown-файлов и превратить каждый в отдельную задачу, проект можно декомпозировать до импорта. Например, сначала подготовить десять независимых постановок, проверить их как набор, а потом одной операцией отправить в backlog.
Это особенно удобно в работе с AI: модель может подготовить пакет файлов, но решение о составе задач остается на стороне человека до загрузки.
У задачи должна быть понятная граница
Правило "1 файл = 1 задача" полезно еще и тем, что заставляет не смешивать несколько независимых результатов в одной постановке. Если описание разрастается до нескольких разных изменений, естественно возникает вопрос, не должны ли это быть разные файлы.
Формат сам подталкивает к более чистой декомпозиции, не вводя сложную методологию.
Связи можно хранить в самом тексте
Для серии задач нам часто нужен Epic. Здесь важно использовать стабильный ключ вроде TT-EPIC-2, а не только человекочитаемое название. Такой идентификатор легче обрабатывать автоматически и безопаснее передавать между системами.
При этом сам Markdown остается понятным человеку: технический ключ можно указать одной строкой, не превращая постановку в конфигурационный файл.
Автоматизация не должна придумывать содержание
Импорт отвечает только за превращение подготовленного файла в сущность трекера. Он не должен сам решать, как объединять задачи, какой Epic выбрать или что автор "наверное имел в виду". Чем предсказуемее это преобразование, тем проще ему доверять.
Мы вообще стараемся строить подобные внутренние инструменты по принципу: автоматизировать механическую работу, но не прятать решения пользователя внутри магии.
Связка Markdown и Task Tracker оказалась удобной не потому, что MD модный формат, а потому, что он достаточно простой, читаемый и независимый от конкретной системы. Один файл хранит одну мысль, а трекер берет на себя уже управление потоком этих мыслей.