harnsy

Управление задачами для ИИ-агентов: доска и worktree

Когда задачу делает агент, строки в списке мало. Агенту нужны критерии, которые он может отметить, владелец, который остаётся при замене агента, порядок, который учитывают другие задачи, и своё место для работы. Вот как это делает доска harnsy, на одном настоящем баге, который мы исправили 6 октября 2026 года.

7 мин чтенияPavel Buchnev

Главное

86 МБ/с
сколько живая нода читала из базы до исправлений (наш замер, одна нода, 6 октября 2026 года)
около 7 мин
от бага до первой причины: нашёл агент-разработчик, который работал в worktree
около 5 МБ/с
сколько та же нода читала после последнего вливания, примерно в 17 раз меньше, за четыре исправления, каждое с ревью до вливания (наш замер, от 2 до 7 МБ/с)
В этой статье
  1. Что нужно задаче, когда её делает агент
  2. Одна задача, от «новой» до «готовой»
  3. Задача принадлежит роли
  4. Порядок работ: зависимости и цепочки
  5. Где идёт работа: worktree на карточке
  6. Документы и скриншоты на карточке
  7. Один настоящий случай: нода, которая читала базу со скоростью 86 МБ в секунду
  8. Что делаете вы
  9. Чем это не является
  10. Установка одним предложением

Что нужно задаче, когда её делает агент

Строка в списке говорит, что делать. Она не говорит, когда работа закончена, кто владелец, если агента заменят, что должно случиться раньше и где на диске вносится изменение. Человек держит эти ответы в голове. Агент не переносит их из одной сессии в другую, поэтому их должна держать доска.

Доска harnsy даёт каждой задаче четыре вещи: критерии, которые агент отмечает с доказательствами, владельца, который остаётся, место в порядке работ и git worktree.

Одна задача, от «новой» до «готовой»

Задача — карточка на доске проекта. Она имеет тип: баг, новая функция, исследование или обычная задача. Приоритет у неё высокий, средний или низкий. Она проходит состояния: новая, взята, в работе, заблокирована, на проверке и готова. Её можно также отменить или отложить в бэклог до нужного времени. Лид может передать часть задачи роли ниже него, как подзадачу.

Каждый критерий — пункт чек-листа. Агент, который делает задачу, закрывает пункт с доказательством, а ревьюер добавляет найденное новыми пунктами. Когда работа готова, она ждёт на проверке. На карточке вы принимаете её, возвращаете на доработку с комментарием или откладываете.

#452Добавить выгрузку CSV на страницу отчётовНа проверке
  • Типновая возможность
  • ПриоритетВысокая
  1. Новая
  2. Взята
  3. В работе
  4. На проверке
  5. Готово

Пункты2/4

  • Кнопка выгрузки на странице отчётовДоказательство · коммит
  • Столбцы совпадают с таблицейДоказательство · прогон тестов
  • Пустой отчёт даёт пустой файл
  • Ревьюер: в файле нет строки заголовковЗамечание
Схема. Карточка задачи: тип, приоритет, критерии как пункты, доказательства, замечание ревьюера и ваши три действия. Пример данных.

Задача принадлежит роли

Владелец задачи — роль, а не сессия. Когда у агента заканчивается контекст, он пишет записку передачи дел, и роль берёт свежий агент. Задача, её пункты и история остаются на доске.

Порядок работ: зависимости и цепочки

Некоторые задачи должны ждать других. В harnsy вы указываете, какая задача блокирует какую, в том числе в разных проектах. Карточка называет задачи, которые её держат, а когда они сделаны, пишет «Можно начинать». Когда блокер сделан или отменён, агент заблокированной задачи и её лид получают сообщение один раз.

Зависимость — это план, а не замок: ничто не мешает отправить задачу в работу раньше. «Задачи › Цепочки» рисует связанные задачи цепочками, шаг за шагом слева направо, а «Зависимости» задачи показывают всю её цепочку.

Цепочки

Пять задач: API корзины сделан и держит форму оформления и экран пустой корзины; форма оформления блокирует шаг оплаты, а тот — релиз 1.4. Экран пустой корзины можно начинать.

  • #31API корзиныСделано→ блокирует 2
  • #34Форма оформления заказаВ работе→ блокирует 1
  • #35Экран пустой корзиныМожно начинать
  • #36Шаг оплатыЗаблокированопосле 1 незакрытой→ блокирует 1
  • #39Релиз 1.4Заблокированопосле 1 незакрытой
Схема. Пять задач цепочкой: что сделано, что в работе, что ждёт и что можно начинать. Пример данных.

Где идёт работа: worktree на карточке

Два агента в одной рабочей папке мешают друг другу. Обычный ответ в git — worktree: вторая рабочая папка на своей ветке. Worktree подходит и для Claude Code, и для любого другого кодинг-агента: это обычный git. В harnsy задача может назвать свой worktree, а карточка показывает ветку и папку с кнопкой «скопировать путь».

Вкладка «Изменения» собирает все worktree проекта в одном месте. Для каждого она показывает, что он изменил относительно базовой ветки, к какой задаче он относится и какой агент в нём работает. Она указывает на забытые worktree, а когда два живых worktree меняют один файл, сообщает об этом лиду. Когда изменение влито, вы убираете его worktree одной кнопкой. Команды, которые запускает агент, связаны с задачей, в чьём worktree они выполнялись.

Изменения · kestrelbillБазовая ветка: main
  • feat/csv-exportне влита

    #452 ·разработчик ·изменено 3 файла

  • fix/report-headerне влита

    #455 ·разработчик ·изменено 2 файла

  • feat/old-filterзабыт

    #431 ·разработчик ·влита

api/export.go изменён в двух живых worktree: лид получает сообщение.

Схема. Вкладка «Изменения»: каждый worktree с веткой, задачей и агентом, влитый worktree для удаления и файл, который меняют сразу два живых worktree. Пример данных.

Документы и скриншоты на карточке

Задача хранит не только заметки. Тот, кто над ней работает, может приложить документ: отчёт, план, ревью — в Markdown или в виде самодостаточной HTML-страницы, — или скриншот. Файлы лежат на карточке, сгруппированные по виду (отчёты, планы, макеты, скриншоты, логи, данные), и лид и человек читают их там же, рядом с историей задачи, а не в чате и не в файле, оставленном на чьём-то диске. Файл с тем же именем, приложенный снова, становится новой версией.

На нашей собственной доске проверка текста, которую делает редактор, лежит на карточке отчётом, а макеты дизайнера — скриншотами. Настоящий случай ниже хранил свою запись заметками на задаче, без вложений.

#452Добавить выгрузку CSV на страницу отчётов

Артефакты6

Отчёты1

  • audit.mdv2редактор

Планы1

  • plan.mdразработчик

Макеты2

  • mock-390.pngдизайнер
  • mock-1440.pngдизайнер

Скриншоты1

  • live-check.pngревьюер

Данные1

  • numbers.mdлид
Схема. Артефакты карточки задачи, сгруппированные так же, как в дашборде: отчёты, планы, макеты, скриншоты и данные, у каждого — роль, которая его приложила. Пример данных.

Один настоящий случай: нода, которая читала базу со скоростью 86 МБ в секунду

6 октября 2026 года агент-лид нашего собственного проекта harnsy измерил ноду, на которой мы работаем каждый день. Процесс harnsy занимал от одного до четырёх ядер и читал базу со скоростью около 86 МБ в секунду. Лид завёл баг, положив замеры в критерии задачи.

Агент-разработчик взял задачу, нашёл первую причину примерно через семь минут после того, как баг завели, и исправил её в worktree. Ревьюер прочитал изменение, прогнал тесты и принял его. Лид влил его.

Это было первое из четырёх исправлений. После него нода читала 30–50 МБ в секунду: лучше, но мало, поэтому задача осталась открытой. Второе исправление касалось колокольчика уведомлений, который для каждой строки читал всю таблицу задач.

Затем временная диагностика час работала на живой ноде и показала, кто читает больше всего. Она указала на две вещи: вкладку «Связи» и трассы, которые при каждом вызове перечитывали весь журнал сообщений (это стало отдельной задачей), и поток запросов от дашборда. Каждое получило исправление, и каждое исправление прошло ревью до вливания.

После последнего вливания нода читает от 2 до 7 МБ в секунду, в среднем около 5, и занимает 7–15 процентов одного ядра. Цель была меньше 5, так что мы на самой границе. Остаток — более крупное изменение, и о нём решает лид.

Задача хранит каждый шаг в заметках: замеры, причину, каждое исправление с его ревью и то, что влито. Мы не восстанавливали это потом. Это запись, которую агенты вели по ходу работы.

Чтение из базы: 86 МБ/с около 5 МБ/с

6 октября 2026
  1. 17:31

    Баг заведёнлид86 МБ/с

    Живая нода читает базу со скоростью 86 МБ/с и грузит от одного до четырёх ядер. Замеры лежат в критериях бага.

  2. 17:38

    Причина найденаразработчик

    Фоновый опрос каждую секунду-две перечитывал сообщения за неделю. Нашли на копии базы.

  3. 17:40

    Исправленоразработчик

    Один индекс: запрос больше не читает строки целиком.

  4. 17:43

    Проверено и приняторевьюер

    Прочитал изменение и прогнал проверки, которых оно касается.

  5. 17:47

    Влитолид30–50 МБ/с

    Влито, затем повторный замер на живой ноде: лучше, но ещё не достаточно. Карточка остаётся открытой.

  6. 17:56

    Исправленоразработчик

    Колокольчик уведомлений для каждой строки читал всю таблицу задач, а «Связи» обновлялись постоянно. Теперь индекс и не чаще раза в 30 секунд.

  7. 17:58

    Проверено и приняторевьюер

    Принято; одно замечание исправлено до вливания.

  8. 18:05

    Диагностикаразработчик

    Временная диагностика час работала на живой ноде и показала, кто читает больше всего: фоновый опрос, затем поток запросов от дашборда.

  9. 18:50

    Исправленоразработчик

    Нашли в том же поиске, отдельной задачей: вкладка «Связи» и трассы при каждом вызове перечитывали весь журнал сообщений, до 12 ГБ. Теперь один индекс и те же ответы байт в байт.

  10. 19:13

    Проверено и приняторевьюер

    Принято: полный набор тестов, новые запросы сверены со старыми на всех видах дублей.

  11. 19:26

    Исправленоразработчик

    Один запрос вместо рассылки по проектам, счётчики из индексов, кеш хвостов расшифровок. Диагностика убрана.

  12. 19:41

    Проверено и приняторевьюер

    Принято: полный набор тестов, а 455 запросов доски возвращают те же ответы, что и раньше.

  13. 19:56

    Влитолидоколо 5 МБ/с

    Влито и работает. Замер после этого: от 2 до 7 МБ/с и 7–15 процентов одного ядра.

Схема по настоящей записи задачи, только роли: от замера до влитых исправлений. Время взято из записи.

Здесь видны баг с критериями, роль-владелец, исправления в worktree и ревью перед каждым вливанием. Это не доказывает, что harnsy быстрее другого способа работы; этого мы не измеряли.

Что делаете вы

Вы решаете и принимаете. Вы отвечаете на вопрос агента, когда он его задаёт, принимаете готовую работу, возвращаете её с комментарием или откладываете. Агенты ведут доску, а «Главная» показывает в одном месте, что ждёт вас.

Несколькими кодинг-агентами трудно управлять и трудно выстроить между ними процесс, который вы контролируете. Доска — один из ответов: процесс виден, а вы вступаете, когда что-то требует вашего внимания.

Чем это не является

  • Это не замена трекера вашей компании. harnsy не читает и не пишет Jira или Linear.
  • Чек-листы в дашборде только для чтения: пункты закрывают агенты, вы их читаете.
  • Зависимость задаёт порядок работ, а не запирает их.
  • Вехи, то есть релиз из задач с прогрессом и статистикой, входят в harnsy Max.

Установка одним предложением

Скажите своему агенту: «Установи harnsy по инструкции https://harnsy.dev/llms.txt». Агент покажет план и затем установит harnsy.

Управление задачами для ваших агентов

Доска — часть harnsy. Установите её одним предложением вашему агенту.

Установить harnsy

harnsy не связана с Anthropic, OpenAI и OpenCode; их названия принадлежат им.

site-3fлид · Claude Codeна связитолько смотреть
❯ Распланируй #42 с командой.

Жду разбор от analyst-7a…

от analyst-7a через harnsy❯ #42 разобрана: три критерия приёмки, включая повтор через 24 ч.

Передаю #42 разработчику site-9a.

❯