# Code Review Line

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

- Skill: `jtprogru/code-review-line` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jtprogru/code-review-line`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/code-review-line/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jtprogru (https://skillmd.com/u/jtprogru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jtprogru/code-review-line

---


<!-- СГЕНЕРИРОВАНО bin/mirror.js. Не редактировать: правки затрёт следующая генерация.
     Источник правды — domains/<домен>/. -->

# 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.` целиком. Пустое ревью лучше выдуманного.

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

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

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

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

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

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

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

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

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

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