Процедуру ревью хочется перенести из Laravel-проекта в Symfony-проект. В первом она запускает artisan, ищет Blade-шаблоны и проверяет обработчики модели. Во втором такие указания ведут не туда. Но выбрасывать весь накопленный порядок проверки тоже не нужно.
Переносимое ядро — это решения, которые остаются осмысленными после замены проекта. Разберём, как выделить его на примере ревью изменения поиска. Количество skills здесь не является целью: полезен минимальный набор процедур, для которых есть повторяемая задача и проверяемый результат.
Начните с общего вопроса ревью
Патч меняет поиск статей. Ревьюеру нужно понять ожидаемое поведение, проследить путь пользовательского запроса, проверить ограничения доступа и оценить тесты. Эти вопросы сохраняют смысл на разных стеках.
А указание «открой BlogController» переносимым не является. Оно полезно в конкретном приложении и должно находиться в его карте или адаптере. Если переименовать контроллер, общий порядок ревью не изменится.
Общая процедура ревью
1. Сопоставь задачу и фактический diff.
2. Найди вход изменения и его потребителей.
3. Проверь изменённое поведение и соседние ограничения.
4. Оцени, какие утверждения подтверждены проверками.
5. Верни замечания с местом, последствием и способом воспроизведения.
Данные проекта
- где находятся маршруты и публичные обработчики;
- как запускаются проверки;
- какие данные не должны попадать в поиск;
- где описаны ограничения HTML и кэша.Верхняя часть — кандидат в общий skill. Нижняя заполняется для репозитория. Между ними должен быть явный договор: если команда проверки не найдена, исполнитель сообщает об этом, а не подставляет команду соседнего проекта.
Избегайте ядра из общих пожеланий
«Пиши качественный код» не становится полезной процедурой после копирования в десять репозиториев. Ядро должно задавать конкретный способ работы: например, для каждого замечания показать путь от входного действия к неверному результату.
В поиске это может быть запрос анонимного посетителя, который получает черновик. Ревьюер указывает условие выборки и объясняет, какой материал станет доступен. Замечание проверяемо без знакомства с автором skill.
Если всё содержимое сводится к общеизвестным советам, сначала улучшите один рабочий процесс. Обобщение имеет смысл после того, как появилась полезная процедура, а не вместо неё. При этом не нужно выдавать учебный пример за собственную статистику использования.
Команды и полномочия остаются локальными
В almdev PHP-проверки выполняются внутри сервиса webserver. Это установленное правило данного репозитория. Оно не должно превращаться в предположение, что у любого проекта сервис называется так же.
С правами ещё строже. Разрешение создавать локальные файлы не означает разрешение отправлять коммиты или изменять production. Общий skill ревью может требовать описать риск развёртывания, но не должен сам запускать развёртывание, потому что в одном исходном проекте это было удобно.
Хороший локальный адаптер небольшой: команда, рабочая директория, место конфигурации и область разрешённых действий. Он не пересказывает весь общий skill. Тогда изменение контейнера затрагивает один источник, а уточнение метода ревью — ядро.
Проверьте перенос на разных условиях
Возьмите две учебные задачи одинакового класса. Например, фильтрацию неопубликованных записей в двух приложениях. Сначала убедитесь, что исполнитель находит локальный путь запроса. Затем проверьте, что он использует локальную команду проверки и не предлагает менять архитектуру ради сходства со знакомым стеком.
Третья задача должна выходить за область skill. Просьба написать текст для главной не должна запускать полный кодовый аудит только потому, что рядом лежит процедура ревью. Переносимость включает правильный выбор, а не только отсутствие слова Laravel в теле.
Сохраняйте примеры ожидаемого результата рядом с версией ядра. Это могут быть несколько коротких сценариев и критерии приёмки. Они покажут регрессию после правки описания лучше, чем сравнение числа строк.
Когда разделить общую процедуру
Если проверка публичного интерфейса требует браузера, тем и клавиатуры, её можно выделить из общего ревью. Но только если граница понятна: кодовый ревьюер находит изменение UI и передаёт его на отдельную проверку либо явно отмечает, что она не выполнена.
Не создавайте пять почти одинаковых skills с описанием «проверка качества». Они будут конкурировать за одни запросы. Названия должны отражать результат: проверить доступность формы, проверить поведение поиска, оценить готовность изменения к выпуску.
Для более сильных моделей прежняя подробная последовательность может оказаться лишней. OpenAI рекомендует пересматривать накопленные инструкции, а не переносить их неизменно между поколениями моделей. Практический вывод для ядра — сохранять обязательные результаты и ограничения, а случайные привычки старого инструмента перепроверять.
Общее ядро тоже выпускается версиями
После изменения процедуры выберите один проект для пробного применения. Проверьте полезный результат и посторонний сценарий, затем переносите версию дальше. Проект может остаться на предыдущей версии с записанной причиной, если новый процесс требует отсутствующего инструмента.
Это отделяет метод работы от механики доставки файлов. Как сверять версии и сохранять локальные изменения, разобрано в статье об обновлении skills. Само ядро считается удачным, когда оно помогает получить проверяемое ревью в разных проектах, не стирая их различия.
