Встроенные скиллы

Вместе с Veai CLI поставляются два скилла. В списке /skills у них источник builtin. Их не нужно устанавливать или настраивать: модель применяет их, когда задача подходит под описание, а вы можете вызвать любой по имени командой /<имя>.

Скилл	Когда применяется
code-review-orchestrated	вы просите проверить код, PR, дифф, коммит, ветку или файлы
debug-root-cause	вы сообщаете о баге, падении, неверном поведении или нестабильном тесте либо спрашиваете, почему что-то не работает

Что такое скиллы и как создавать свои — на странице «Скиллы».

code-review-orchestrated

Организует ревью: согласует с вами настройки, запускает независимых ревьюеров и публикует один отчёт. Сам код скилл не редактирует.

/code-review-orchestrated проверь изменения в текущей ветке

Как проходит ревью:

1. Что проверять. Если вы не указали, что именно ревьюить (PR, коммит, ветку, файлы или модуль), агент задаёт один вопрос об этом. Открытые в редакторе файлы без вашего подтверждения областью ревью не считаются.
2. Сбор области. Агент сам читает диф и связанный код через git и поиск по проекту.
3. Выбор ревьюеров. По размеру изменений агент предлагает набор ревьюеров и спрашивает, нужна ли проверка замечаний. Для маленького диффа предлагается сокращённый набор и проверка выключена. Пока вы не подтвердите набор, ревью не начинается.
4. Ревью. Каждый ревьюер отвечает за одну роль, и все они работают параллельно как субагенты. Если запустить субагентов нельзя, агент проходит роли сам, по очереди.
5. Проверка замечаний (если включена). Отдельный проверяющий разбирает замечания по одному и ставит каждому отметку: подтверждено, ложное срабатывание или не хватает данных.
6. Отчёт. Подтверждённые замечания объединяются без дублей и выводятся одним отчётом, сгруппированным по важности. У каждого замечания есть файл и строки.

Роли ревьюеров:

Роль	Что ищет
Построчный разбор	ошибки в каждой изменённой строке: перевёрнутые условия, выход за границы, null, забытый await
Удалённое поведение	какие проверки и обработку ошибок диф удалил и не вернул
Связи между файлами	не ломают ли изменения вызывающий и вызываемый код
Повторное использование и упрощение	не изобрёл ли код заново то, что уже есть в проекте, лишняя сложность, дубли, мёртвый код
Эффективность	лишняя работа, блокировки на горячем пути, утечки
Следы генерации моделью	подгонка под тесты, скрытые сбои, лишние обёртки, запутанный поток управления, комментарии-шум
Безопасность (по желанию)	утечки секретов, проверка входных данных, инъекции, небезопасные значения по умолчанию

Кроме них агент может предложить до двух ревьюеров под особенности вашего диффа.

Рабочие заметки ревью (замечания и результаты проверки) агент сохраняет в .tasks/<цель>-review/ в проекте. Это не правки кода. В конце агент сообщает, где они лежат, и предлагает их удалить.

debug-root-cause

Ищет причину бага с доказательствами и только потом чинит. Главное правило скилла: не менять код, пока не доказано, почему он сломан. Формулировка «вероятно, дело в X» доказательством не считается.

/debug-root-cause тест OrderServiceTest иногда падает на CI

Если вы не описали проблему, агент задаёт один вопрос: что именно идёт не так. Всё остальное он выясняет сам по проекту. Если вы спросили только, почему что-то не работает, агент останавливается на причине и предлагает исправление, но код не меняет.

Как проходит поиск:

1. Воспроизведение. Агент добивается, чтобы баг проявился: минимальные шаги, команда, тест или скрипт. Если воспроизвести не удалось, он говорит об этом и перечисляет, что пробовал, а к исправлению вслепую не переходит.
2. Локализация. Сбой сужается до модуля и функции: история изменений, поиск правки, которая всё сломала, сравнение с работающим похожим кодом.
3. Гипотезы. Агент перечисляет гипотезы от самой вероятной и для каждой заранее описывает проверку, которая её опровергнет.
4. Доказательство. Проверки выполняются, опровергнутые гипотезы отбрасываются. Остаться должна одна причина, подкреплённая фактом: выводом команды, тестом, строкой лога. Пока причина не доказана, исправление не предлагается.

Если сообщение об ошибке указывает на одну строку и чтение этой строки объясняет баг, воспроизведения и этой строки достаточно, а фазы 2 и 3 пропускаются.

Дальше:

• Исправление причины, а не симптома. Перед правкой агент формулирует одним предложением: «Баг происходит потому, что…». Пустой catch, as any, @ts-ignore, eslint-disable, увеличенный тайм-аут и подгонка ожидаемого значения в тесте исправлениями не считаются.
• Сначала тест. Агент пишет тест, который воспроизводит баг и падает, затем вносит минимальную правку, после чего запускает этот тест и остальные тесты проекта. Если тестов нет или баг нельзя проверить автоматически, он показывает, как проверить вручную, и приводит фактический вывод.
• Тот же дефект в других местах. Агент описывает класс дефекта, ищет такие же места в проекте и перечисляет их. Исправляет он их, только если это входит в задачу или вы согласились.
• Отчёт. Причина с доказательствами, что изменено, какой тест добавлен и какие проверки прошли, где ещё есть такой дефект, что осталось непроверенным. Если затронута безопасность, об этом сообщается отдельной первой строкой.

Правила написания кода в системном промпте

Отдельно от скиллов в системный промпт агента входят общие правила написания кода. Они действуют для любой модели и всегда включены:

• перед правкой прочитать код и его вызовы, а не писать заново то, что уже есть в проекте;
• вносить минимальное изменение, нужное задаче, и довести его везде, куда оно доходит: до вызывающего кода, тестов и фикстур. Тесты, документацию, аннотации типов, рефакторинг и код «на будущее» добавлять только по просьбе или по инструкциям проекта;
• исправлять причину, а не симптом: перед исправлением бага назвать одним предложением, почему он возникает;
• писать комментарии только о том, чего код сказать не может: почему он сделан так, какое скрытое ограничение, какой обходной путь.

Заменить встроенный скилл

Встроенный скилл хранится внутри установленного продукта: искать и править его там не нужно. Чтобы изменить поведение, создайте скилл с тем же name в любом корне поиска, например <проект>/.veai/skills/debug-root-cause/SKILL.md или ~/.veai/skills/debug-root-cause/SKILL.md. Он заменит встроенный, и встроенный пропадёт из списка. Это единственный случай, когда совпадение имён не делает недоступными оба скилла.

Файл заменяет встроенный скилл, как только удаётся прочитать его name, даже если другое поле неверно. Если name прочитать нельзя, встроенный скилл остаётся.

Отключить встроенный скилл

Добавьте имя в skills.disabledSkills в settings.json:

{
  "skills": {
    "disabledSkills": ["code-review-orchestrated"]
  }
}

Скилл станет недоступен и модели, и вам. Подробнее — в разделе «Скиллы».