Code review

Skill Alex7develop/my-agent-skills/skills/code-review

Практики senior-разработчика для AI-агентов: спека → TDD → отладка → рефакторинг → ревью → PR. 6 skills для Cursor, Claude Code, Codex и 70+ агентов.

Install

npx -y skills add Alex7develop/my-agent-skills --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Провести структурированное ревью кода по пяти осям (корректность, читаемость, безопасность, производительность, тесты) перед мержем. Используй при запросах "проверь этот код", "сделай ревью", "посмотри на PR", "готово ли это к мержу". Также применяй проактивно после того как сам написал значимый кусок кода, перед тем как показать его как финальный результат.

SKILL.md

3.9 KB, as published. Nobody here has run it

Code Review

Пять осей проверки. Не пытаться "найти хоть что-то" на каждой оси — если ось не даёт находок, честно писать "нет замечаний", это лучше, чем притянутые мелочи.

Пять осей

Корректность. Делает ли код то, что задумано? Обработаны ли граничные случаи (пустой вход, null, переполнение, конкурентный доступ)?
Читаемость. Поймёт ли код человек, не писавший его, без объяснений? Имена, структура, отсутствие "магии".
Безопасность. Валидация входных данных, инъекции, секреты в коде, права доступа, обработка пользовательского ввода.
Производительность. Есть ли очевидные проблемы (N+1 запросы, O(n²) там где легко сделать O(n log n), утечки памяти/хендлов)? Не заниматься микрооптимизацией там, где это не нужно.
Тесты. Покрыты ли изменения тестами? Тестируют ли они поведение, а не только "счастливый путь"?

Процесс

Понять контекст изменения (что и зачем меняется) прежде чем оценивать — спека или описание PR, если есть.
Пройти по каждой из пяти осей отдельно, не смешивая находки.
Разделить находки по серьёзности:
- Блокирует мерж — баги, дырки безопасности, потеря данных
- Стоит исправить — читаемость, дублирование, слабое покрытие тестами
- Опционально / на вкус — стилистические предложения
Для каждой находки — конкретное место (файл/строка) и конкретное предложение, а не общая формулировка вроде "можно лучше".

Формат вывода

## Code Review

### Блокирует мерж
- [файл:строка] ...

### Стоит исправить
- [файл:строка] ...

### Опционально
- ...

### Без замечаний
- <оси, где всё в порядке>

Анти-паттерны, которых нужно избегать

Не придумывать проблемы там, где их нет, только чтобы "было что сказать"
Не давать общие советы без привязки к конкретному коду
Не путать личные стилистические предпочтения с объективными проблемами — явно помечать субъективные замечания как "на вкус"