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 не видно: сломанные инварианты, места, где новый код противоречит соседнему, обработчики, которые надо было обновить вместе с этим.
Где формат разворачивается
Правило ~/.claude/rules/agentops-auto-clarity.md применимо и здесь. Однострочный формат выключается, когда находка касается:
- безопасности — уязвимость объясняется целиком, с вектором и последствиями
- архитектурного спора — если проблема в подходе, а не в строке, одной строкой её не сформулировать
- онбординга — когда автор новичок и ему нужна не пометка, а объяснение
В этих случаях после однострочной находки идёт развёрнутый абзац. Формат — инструмент экономии, а не самоцель.
Чего не делать
- Не хвали. «Хорошая декомпозиция» не меняет ни строки кода.
- Не пересказывай изменения. Автор их написал.
- Не помечай
bug то, в чём не уверен: есть risk и q.
- Не предлагай переписать всё иначе — для этого отдельный разговор, а не комментарий к строке.
- Не собирай находки ради непустого списка.
- Не ставь
nit там, где в проекте нет соответствующего соглашения: это твой вкус, а не правило.
1---2name: code-review-line-23description: Построчные комментарии к diff или PR: одна находка — одна строка, с уровнем серьёзности и конкретным действием. Никакой похвалы и пересказа изменений. Используй, когда пользователь говорит «отревьюь diff», «посмотри изменения», «что не так в этом PR», «код-ревью», «проверь перед коммитом». Для ревью плана до реализации — code-senior-review, здесь только существующий код.4---56# code-review-line — Построчное ревью78Формат подобран так, чтобы находку можно было прочитать за секунду и сразу понять, что делать.910## Формат1112Одна находка — одна строка:1314```15internal/auth/token.go:91: 🔴 bug: exp сравнивается с локальным временем, не UTC. Взять time.Now().UTC().16```1718`путь:строка: <эмодзи> <уровень>: <проблема>. <действие>.`1920Уровни:2122| | уровень | значение |23|---|---|---|24| 🔴 | `bug` | сломается или уже сломано |25| 🟡 | `risk` | работает сейчас, развалится при изменении условий |26| 🔵 | `nit` | стиль, именование, читаемость |27| ❓ | `q` | непонятно намерение, нужен ответ автора |2829Последней строкой итог: `totals: 1 bug, 2 risk, 3 nit, 1 q`.3031Нет находок — ответ `No issues.` целиком. Пустое ревью лучше выдуманного.3233## Что смотреть и в каком порядке3435Порядок отражает цену ошибки:36371. **Корректность** — делает ли код то, что заявлено382. **Границы** — пустые данные, нули, переполнения, отсутствующие ключи393. **Ошибки** — что происходит на неуспешной ветке, не проглатывается ли исключение404. **Конкурентность** — гонки, дедлоки, общее состояние415. **Безопасность** — данные из недоверенного источника, секреты, права426. **Читаемость** — имена, длина функций, комментарии4344Отдельно ищи то, чего в diff не видно: сломанные инварианты, места, где новый код противоречит соседнему, обработчики, которые надо было обновить вместе с этим.4546## Где формат разворачивается4748Правило `~/.claude/rules/agentops-auto-clarity.md` применимо и здесь. Однострочный формат выключается, когда находка касается:4950- **безопасности** — уязвимость объясняется целиком, с вектором и последствиями51- **архитектурного спора** — если проблема в подходе, а не в строке, одной строкой её не сформулировать52- **онбординга** — когда автор новичок и ему нужна не пометка, а объяснение5354В этих случаях после однострочной находки идёт развёрнутый абзац. Формат — инструмент экономии, а не самоцель.5556## Чего не делать5758- Не хвали. «Хорошая декомпозиция» не меняет ни строки кода.59- Не пересказывай изменения. Автор их написал.60- Не помечай `bug` то, в чём не уверен: есть `risk` и `q`.61- Не предлагай переписать всё иначе — для этого отдельный разговор, а не комментарий к строке.62- Не собирай находки ради непустого списка.63- Не ставь `nit` там, где в проекте нет соответствующего соглашения: это твой вкус, а не правило.
jtprogru