Набор из двенадцати исполнителей и шестнадцати процедур — это не инструмент, а инвентарь. Инструментом он становится, когда на конкретной задаче понятно, что из него достать.
У меня для этого шесть строк в руководстве проекта. Не тридцать, а шесть, и это принципиально.
Таблица
| Задача | Скилл / агент |
|------------------------|--------------------------------------------|
| Публикация поста | publish-workflow |
| Посты, рубрики, SEO | агент content-seo, seo-structured-data |
| Политика / рассылка | legal-pages |
| OG-обложки | generate-blog-image |
| Общий CKEditor | ckeditor-shared-sync, агент ckeditor-sync |
| Интерфейс | frontend-design → visual-qa, a11y-check |Шесть строк покрывают примерно восемьдесят процентов того, что я делаю в блоге. Оставшиеся двадцать — разовые задачи, для которых таблица не нужна, потому что я и так знаю, куда идти.
Заметьте, чего в таблице нет. Нет строки «правка модели» и строки «прогон тестов», хотя агенты под это есть. Причина простая: на этих задачах выбор очевиден и без подсказки. Таблица нужна там, где выбор неочевиден.
Строка, по которой выбор однозначен
Первая версия таблицы у меня была вдвое длиннее и работала хуже. Разница — в формулировках левой колонки.
Плохие строки выглядели так:
| Бэкенд | агент backend-filament |
| Фронтенд | агент blade-ui |
| Контент | агент content-seo |Проблема очевидна, если попробовать применить. Задача «карточка поста в списке рубрики съезжает на мобильном» — это фронтенд или контент? Формально и то и другое: карточка поста и вёрстка.
Рабочая формулировка называет не область, а тип работы:
| Публикация поста | publish-workflow |
| Посты, рубрики, SEO | агент content-seo, seo-structured-data |Разница в том, что «публикация поста» — это узнаваемая ситуация. Я формулирую задачу себе теми же словами, которыми она записана в таблице, и совпадение происходит само.
Проверка левой колонки, которой пользуюсь: можно ли этой строкой начать предложение «мне надо…». «Мне надо опубликовать пост» — да. «Мне надо бэкенд» — нет.
Правая колонка: скилл, агент или оба
Три варианта заполнения правой колонки, и все три встречаются.
Только скилл. Процедура, которую я выполняю сам. Публикация поста — как раз такая: шагов много, зона узкая, делегировать нечего.
Агент и скилл. Работа, которую отдаю целиком, но с указанием процедуры. Посты и рубрики уходят агенту контента, который по дороге читает скилл про разметку для поиска.
Скилл со стрелкой. Порядок из нескольких процедур: сначала правки интерфейса, потом визуальная проверка и доступность. Стрелка означает последовательность и появилась в таблице потому, что последовательность регулярно нарушалась — правки делались, проверка забывалась.
Чего избегаю: перечисления трёх и более адресатов в одной строке. Строка с тремя вариантами — это отсутствие маршрута, оформленное как маршрут.
Проверка десятью задачами
Таблица проверяется не рассуждением, а прогоном. Беру десяток формулировок, которые реально писал за последний месяц, и смотрю, куда каждая попадёт.
Важно брать настоящие формулировки, кривые и неполные, а не причёсанные. Настоящая задача звучит как «пост не появляется в ленте после публикации», а не как «диагностика подсистемы синдикации».
На последнем прогоне из десяти задач семь легли в таблицу однозначно, две потребовали разведки до выбора маршрута, одна не легла никуда. Это нормальное распределение, и оно же — источник правок.
Подробный разбор с примером десятка задач я делал в статье про границы в описаниях агентов. Здесь важно, что проверка одна и та же для описаний и для таблицы: они решают одну задачу с разных сторон.
Задача, которой в таблице нет
Отдельный случай, ради которого стоит завести правило, а не строку.
Моё правило: задачи, которой нет в таблице, идут в общий контур. То есть делаю сам, без делегирования, читая нужные скиллы по ходу.
Не завожу строку после первого раза. Не завожу и после второго. На третьем повторе — та же логика, что и с заведением скиллов: два раза случайность, три раза закономерность.
Такой порядок держит таблицу короткой. Из десятка кандидатов, появившихся за эти месяцы, до строки дожили два: работа с общим модулем редактора и правовые страницы.
Где таблица врёт
Три места, где я на неё не полагаюсь.
Задачи на стыке зон. «Добавить поле „серия“ в модель и вывести на странице поста» — это три строки таблицы сразу. Таблица честно показывает три маршрута, а решение о порядке принимаю я: сначала данные, потом админка, потом вывод.
Задачи, которые начинаются с диагностики. «Пост не появляется в ленте» выглядит как строка про публикацию, но пока непонятно, где рвётся, маршрут выбран неправильно. Тут сначала разведка, потом маршрут.
Задачи, где я знаю больше таблицы. Если я помню, что похожая проблема месяц назад оказалась в кэше публичных списков, я иду туда напрямую. Таблица — подсказка, а не процедура.
Признавать это честнее, чем городить в таблице ветвления. Я пробовал завести строки вида «если проблема в отображении — туда, если в данных — сюда» и получил дерево решений, которым не пользуюсь.
Как таблица не устаревает
Устаревает она медленнее, чем я боялся, и причина в её длине. Шесть строк невозможно не заметить при правке набора: открываешь руководство добавить агента — таблица прямо там, на экране.
Второе, что помогает: строки описывают ситуации, а ситуации меняются реже, чем инструменты. «Публикация поста» останется актуальной строкой, даже если процедура публикации переедет из одного скилла в другой. Правится тогда правая колонка, а левая живёт годами.
Третье, честное: дважды таблица врала. Оба раза потому, что скилл переименовали, а строку не поправили. Ничего страшного не случилось — несуществующее имя обнаруживается сразу. Хуже было бы, если бы имя существовало и указывало не туда.
Что осталось
Шесть строк — самая дешёвая часть всей раскладки и одна из самых полезных. Пишется за десять минут, правится раз в квартал.
Чего в ней не хватает: колонки «что не надо делать». Есть пара ситуаций, где правильный ответ — не звать никого, а посмотреть глазами. Например, «страница выглядит странно» на моём сайте почти всегда означает несобранные стили, и любой маршрут здесь ведёт мимо. Пока такие вещи живут в разделе про частые задачи, но их место, кажется, именно в таблице.
