review-duplication

review-duplication — навык Google Gemini CLI для проверки кода на повторную реализацию уже существующей функциональности и на пропущенные возможности повторного использования. Его задача начинается с анализа нового фрагмента: нужно выделить базовые алгоритмы, универсальные функции, структуры данных и UI-компоненты, которые добавляет изменение, а затем посмотреть глубже конкретной бизнес-логики. Такой разбор помогает заметить не только буквальное копирование, но и ситуацию, когда новый код решает типовую задачу отдельным способом, хотя в проекте уже есть общий механизм. Следующий шаг — сформулировать гипотезы о месте, где подобная логика могла бы находиться в репозитории. Источник предлагает проверять отдельные области для утилит, компонентов интерфейса, сервисов, конфигурации и основной логики. В качестве примеров путей названы packages/core/src/utils, packages/cli/src/utils, packages/cli/src/ui/components, packages/cli/src/ui, packages/core/src/services, packages/cli/src/services, packages/core/src/config и packages/cli/src/config. Важно дать абсолютные пути от корня репозитория: так рецензент и автор изменения не перепутают несколько похожих каталогов и смогут воспроизвести проверку. Навык отдельно требует прослеживать сторонние зависимости. Если в pull request появился новый импорт библиотеки для утилит, нужно найти, где эта библиотека уже используется в проекте, и проверить наличие общего адаптера или обёртки. Перед тем как критиковать самописный сложный алгоритм, следует прочитать package-файлы и убедиться, что установленная стандартная библиотека уже не предоставляет нужную возможность. Поэтому результатом проверки может стать не предложение добавить новый слой, а рекомендация переиспользовать существующий код и сохранить единый способ обработки краевых случаев. Для глубокой проверки источник предписывает делегировать исследование специализированным sub-agent. Основным исследователем назван codebase_investigator: ему нужно задать конкретные вопросы о структурном сходстве, уже используемых API, именах символов, комментариях и документации, месте централизации логики и способе рефакторинга нового кода. Для длительного семантического сравнения предусмотрен generalist. В очень простых случаях допустим быстрый прямой поиск, например проверка наличия lodash или uuid в package.json, но открытое исследование архитектуры должно оставаться предметным, а не превращаться в общее сканирование. После поиска оцениваются инженерные практики: обработка ошибок, применение стандартных классов ошибок и механизмов журналирования, состояние приложения, централизованные хранилища и соответствие стилистике. Нужно выяснить, не обходит ли изменение существующие соглашения и не закрепляет ли новый шаблон без необходимости. Если проблема найдена, итоговый комментарий должен назвать файл и символ, который стоит переиспользовать, описать способ интеграции и объяснить ценность: меньше дублирования, единое поведение и уже проверенная обработка крайних случаев. Практический результат review-duplication — конструктивное замечание к pull request, а не абстрактное требование «сделать лучше». В нём фиксируются источник найденной логики, конкретное действие по замене или рефакторингу и причина изменения. Навык подходит для code review, когда нужно проверить архитектурное соответствие нового кода, повторное использование утилит и компонентов, а также риск появления нескольких реализаций одной операции. Он не обещает автоматически исправить репозиторий: его роль — направить проверку и сделать решение о переиспользовании проверяемым.