Отдельная группа - команды, привязанные к конкретной поверхности: работа с деревьями, сравнение нескольких кандидатов, перенос задачи в облако, сопровождение изменений. Они не обязаны присутствовать в статическом справочнике командной строки и вообще не обязаны существовать везде. Это не недоработка, а следствие того, что поверхности разные: часть процедур имеет смысл только там, где есть соответствующий интерфейс. Сравнение вариантов нужно там, где их можно показать рядом, а работа с деревьями - там, где есть куда переключиться.

Именно поэтому про такие вещи говорят с датой и оговоркой. Проверка безопасности и обзор доступны в определённых версиях и на определённых поверхностях, а поддержка в командной строке может быть заявлена как готовящаяся. Выдавать навык редактора за команду терминала - типичная ошибка, из-за которой автоматизация ломается на чужой машине, где этой поверхности просто нет. И ломается она не сразу: на машине автора всё работает, поэтому причину ищут в окружении коллеги, а не в самой процедуре.

Как это выглядит, стоит представить заранее. Команда описывает у себя в документации шаг обзора перед слиянием и называет конкретную команду. У людей, работающих в приложении, шаг проходит. В автоматическом прогоне на сервере, где есть только командная строка, шага нет: команда неизвестна, вызов заканчивается ничем. Признак, по которому это ловят, неприятный - не ошибка, а тишина: проверка не жалуется, потому что она не выполнялась. Отсюда правило: процедура, от которой зависит решение о слиянии, обязана падать, когда её нельзя выполнить, а не пропускаться.

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

Границу между встроенной процедурой и собственной проводят по знанию о репозитории. Встроенная знает общее устройство задачи и ничего не знает про ваши команды проверки, ваши каталоги и ваши границы. Собственная знает это, но её надо написать и поддерживать. Разумный порядок - начать со встроенной, посмотреть, где она промахивается, и оформить свою только там, где промах повторяется. Копировать встроенную процедуру целиком ради одной правки не стоит: копия перестанет получать обновления, и через несколько версий вы будете сопровождать её вместо того, чтобы пользоваться готовой.

Инженерный вывод: встроенные навыки полезны как быстрый старт и как образец. Даже если вы в итоге напишете свою процедуру, посмотреть встроенную стоит - она показывает ожидаемую структуру и типичные шаги. А для повторяемой работы, специфичной для вашего репозитория, всё равно нужен собственный навык: встроенный не знает ваших команд проверки и ваших границ. Здоровое соотношение выглядит так: встроенные закрывают общее, свои - то, что отличает ваш проект от любого другого.

Типичные провалы предсказуемы. Считать список команд постоянным и перенести его в инструкцию для команды. Выдать навык одной поверхности за команду другой. Строить автоматизацию на команде, доступность которой не проверена, и не заметить пропущенный шаг. Скопировать встроенную процедуру целиком ради одной правки. И игнорировать встроенные процедуры, каждый раз объясняя агенту то, что уже оформлено.