agentleFS
jtprogrujtprogru/bear-skills/skills/code-review-line/SKILL.md

code-review-line

Skill1 starsChanged 3 months agoMITView on GitHub

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

The file

Files
SKILL.md
<!-- СГЕНЕРИРОВАНО 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 там, где в проекте нет соответствующего соглашения: это твой вкус, а не правило.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.