Скил cta-format — одно рекомендованное действие каждый раз
Как скил cta-format задаёт единый формат блока «Следующий шаг» в конце каждой команды пайплайна, устраняя необходимость держать в голове связку ID задачи и следующей команды.
Каждая команда /dr-* заканчивается одним и тем же вопросом: что запускать дальше? Без фиксированного формата ответ каждый раз выглядит по-разному — иногда проза, иногда список, иногда вообще ничего. Скил cta-format определяет единственную каноническую форму для этого ответа и требует её от каждой команды пайплайна.
Как выглядит блок
Вывод — пронумерованный список между двумя горизонтальными разделителями Markdown. Один пункт несёт маркер рекомендуется — ровно один, никогда ноль, никогда два. Каждый пункт называет конкретную команду с ID задачи прямо в строке, чтобы оператор мог скопировать и вставить её в терминал. Заголовок стадии в первой строке каждого ответа сообщает, к какой задаче относится вывод: при 40+ параллельных задачах контекст без него неоднозначен.
Формат существует в трёх вариантах. Стандартный вариант — для одной активной задачи. Когда активных задач несколько, второй раздел перечисляет рекомендованную следующую команду для каждой из них. Когда QA или compliance-проверка заваливается, вариант fail-routing меняет заголовок: в нём указывается самый ранний упавший слой и нужная команда для исправления.
Почему потолок — пять пунктов
Жёсткий потолок на количество пронумерованных пунктов — пять. Обоснование ссылается на закон Миллера, закон Хика и Chernev (2015): когнитивная цена выбора растёт с числом вариантов. Оптимальное число по скилу — три. Всё, что выше пяти, исключается как паралич выбора.
Маркер рекомендованного действия решает смежную задачу. Оператор, ведущий несколько задач параллельно, не должен перечитывать весь блок, чтобы найти рекомендованный путь. Жирный маркер делает его заметным с первого взгляда.
Маршрутизация при ошибке
Когда /dr-qa возвращает BLOCKED или /dr-compliance возвращает NON-COMPLIANT, блок меняет форму. Заголовок называет самый ранний упавший слой — Layer 1 (PRD), Layer 3 (Plan), Layer 4 (Code) и так далее — а основной пункт указывает на соответствующую команду исправления. Соответствие слоёв командам зафиксировано в скиле, поэтому маршрутизация детерминирована независимо от того, какой агент эмитирует блок.
Специальный вариант Expectations-BLOCKED несёт аргумент --focus-items прямо в строке основного пункта. Аргумент перечисляет только те wish-ID, которые не прошли, чтобы разработчик мог зайти в /dr-do с прицелом именно на эти пункты, не перезапуская всю реализацию.
Сохранение снапшота
После появления CTA-блока каждая команда /dr-* сохраняет финальный ответ, видимый оператору, в файл datarim/snapshots/{TASK-ID}.snapshot.md через обёрточный скрипт с разрешённым путём. Снапшот служит основным контекстом для /dr-next после закрытия терминала или выполнения /clear — команда читает снапшот до того, как обратиться к файлу описания задачи.
Опциональный Stop-хук Claude Code проверяет наличие заголовка стадии в каждом ответе: пропуск при первом появлении блокирует вывод; второй пропуск понижается до предупреждения в stderr. Хук подключается вручную и описан в docs/how-to/dr-output-hook.md.
Полная картина пайплайна — в посте что такое Datarim; то, как снапшоты используются при возобновлении, описано в статье о команде /dr-next.