Code review line

Skill jtprogru/bear-skills/skills/code-review-line

Построчные комментарии к diff или PR: одна находка — одна строка, с уровнем серьёзности и конкретным действием. Никакой похвалы и пересказа изменений. Используй, когда пользователь говорит «отревьюь diff», «посмотри изменения», «что не так в этом PR», «код-ревью», «проверь перед коммитом». Для ревью плана до реализации — code-senior-review, здесь только существующий код.From its SKILL.md

Install

npx -y skills add jtprogru/bear-skills --skill code-review-line

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

One thing to look at

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.

SKILL.md

4.7 KB, as published. Nobody here has run it

code-review-line — Построчное ревью

Формат подобран так, чтобы находку можно было прочитать за секунду и сразу понять, что делать.

Формат

Одна находка — одна строка:

internal/auth/token.go:91: 🔴 bug: exp сравнивается с локальным временем, не UTC. Взять time.Now().UTC().

путь:строка: <эмодзи> <уровень>: <проблема>. <действие>.

Уровни:

	уровень	значение
🔴	`bug`	сломается или уже сломано
🟡	`risk`	работает сейчас, развалится при изменении условий
🔵	`nit`	стиль, именование, читаемость
❓	`q`	непонятно намерение, нужен ответ автора

Последней строкой итог: totals: 1 bug, 2 risk, 3 nit, 1 q.

Нет находок — ответ No issues. целиком. Пустое ревью лучше выдуманного.

Что смотреть и в каком порядке

Порядок отражает цену ошибки:

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

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

Где формат разворачивается

Правило ../../rules/agentops-auto-clarity.md применимо и здесь. Однострочный формат выключается, когда находка касается:

безопасности — уязвимость объясняется целиком, с вектором и последствиями
архитектурного спора — если проблема в подходе, а не в строке, одной строкой её не сформулировать
онбординга — когда автор новичок и ему нужна не пометка, а объяснение

В этих случаях после однострочной находки идёт развёрнутый абзац. Формат — инструмент экономии, а не самоцель.

Чего не делать

Не хвали. «Хорошая декомпозиция» не меняет ни строки кода.
Не пересказывай изменения. Автор их написал.
Не помечай bug то, в чём не уверен: есть risk и q.
Не предлагай переписать всё иначе — для этого отдельный разговор, а не комментарий к строке.
Не собирай находки ради непустого списка.
Не ставь nit там, где в проекте нет соответствующего соглашения: это твой вкус, а не правило.