Навыки receiving-code-review
📦

receiving-code-review

Безопасно

Обработка отзывов код-ревью с технической проверкой

Также доступно от: Cygnusfear,DYAI2025,Cycleaddict,davila7,CodingCossack,obra

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

Поддерживает: Claude Codex Code(CC)
🥉 74 Бронза
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «receiving-code-review». Reviewer: Remove legacy code

Ожидаемый результат:

Проверка требований совместимости... Целевая сборка 10.15+, этот API требует 13+. В текущей реализации неверный bundle ID. Варианты: исправить bundle ID или отказаться от поддержки версий до 13. Что вы предпочитаете?

Использование «receiving-code-review». Reviewer: Implement metrics tracking with database, date filters, CSV export

Ожидаемый результат:

Выполнен поиск по кодовой базе — никакой код не вызывает этот эндпоинт. Рекомендуется удаление по YAGNI. Есть ли ожидаемое использование, о котором мне следует знать?

Использование «receiving-code-review». Partner: Fix items 1-6

Ожидаемый результат:

Я понимаю пункты 1, 2, 3 и 6. Мне нужны разъяснения по пунктам 4 и 5 перед продолжением реализации.

Аудит безопасности

Безопасно
v1 • 2/24/2026

All static analysis findings are false positives. The skill file (SKILL.md) is a markdown documentation file containing instructional text, not executable code. Backticks detected are markdown code block delimiters, not shell command execution. No actual cryptographic operations, network calls, or command injection vectors exist in this skill.

1
Просканировано файлов
214
Проанализировано строк
0
находки
1
Всего аудитов
Проблем безопасности не найдено
Проверено: claude

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
50
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Ответ на многопунктовое ревью

При получении списка из 6+ пунктов отзыва сначала проясните неясные пункты, затем реализуйте в порядке приоритета (сначала блокирующие проблемы), тестируя каждое изменение индивидуально для раннего обнаружения регрессий

Скептицизм к внешним рецензентам

Когда внешние рецензенты предлагают изменения без полного контекста, проверяйте техническую корректность для вашей кодовой базы, проверяйте наличие ломающих изменений и аргументированно возражайте с доказательствами, когда предложение неверно

YAGNI-контроль функций

Когда рецензенты предлагают реализовать функции «правильно» с базой данных, фильтрами и экспортом, сначала выполните grep по кодовой базе для подтверждения фактического использования перед добавлением ненужной сложности

Попробуйте эти промпты

Прояснение неясного отзыва
I received code review feedback with items 1-6. I understand items 1, 2, 3, and 6, but items 4 and 5 are unclear. Before implementing anything, I need clarification on what exactly is expected for items 4 and 5.
Проверка предложения внешнего рецензента
A reviewer suggested changing X to Y. Let me verify: Is this technically correct for this codebase? Does it break existing functionality? What was the reason for the current implementation? I'll check the code and tests before proceeding.
Аргументированное возражение
I understand your suggestion to do X, but this would break Y because of Z. The current implementation handles edge case A and B. If we change this, we need to also update C and D. Should I proceed with the full scope or keep the current approach?
YAGNI-проверка запросов функций
You suggested implementing X with full database support, date filters, and CSV export. I searched the codebase and found no callers of this endpoint. Should I remove it entirely per YAGNI, or is there usage I'm missing?

Лучшие практики

  • Всегда проясняйте все неясные пункты перед реализацией любой части отзыва
  • Проверяйте предложения против фактического поведения кодовой базы, а не только поверхностной логики
  • Возражайте с конкретным техническим обоснованием, а не защитной реакцией или эмоциями

Избегать

  • Говорить «Вы абсолютно правы!» или «Отличный пункт!» перед проверкой
  • Немедленная реализация отзыва без проверки реальности кодовой базы
  • Пакетная реализация нескольких пунктов без индивидуального тестирования каждого изменения

Часто задаваемые вопросы

Что делать, если отзыв о ревью неясен?
Немедленно остановитесь и запросите разъяснения по неясным пунктам перед реализацией чего-либо. Пункты могут быть связаны, и частичное понимание приводит к неверной реализации.
Как возражать против предложения рецензента?
Используйте техническое обоснование с конкретными доказательствами. Ссылайтесь на работающие тесты, поведение кода или требования совместимости. Задавайте конкретные вопросы, а не делайте защитные заявления.
Что если рецензент прав, а я возражал?
Констатируйте исправление фактологически: «Вы были правы — я проверил X, и он действительно делает Y. Реализую сейчас». Избегайте длинных извинений или избыточных объяснений, почему вы возражали.
Должен ли я благодарить рецензентов за их отзывы?
Нет. Дела говорят громче. Просто исправьте проблему и покажите, что изменилось. Если ловите себя на написании «Спасибо», удалите это и вместо этого опишите исправление.
Как обрабатывать предложения реализовать функции «правильно»?
Сначала выполните grep по кодовой базе для фактического использования. Если никакой код не вызывает эндпоинт или функцию, предложите удаление по YAGNI. Реализуйте полностью только при подтверждённом использовании.
В каком порядке реализовывать многопунктовый отзыв?
После прояснения всех пунктов реализуйте в таком порядке: сначала блокирующие проблемы (поломки, безопасность), затем простые исправления (опечатки, импорты), затем сложные исправления (рефакторинг, логика). Тестируйте каждое исправление индивидуально.

Сведения для разработчиков

Автор

ZhanlinCui

Лицензия

MIT

Ссылка

main

Структура файлов

📄 SKILL.md