# Code Senior Review

> Состязательное ревью плана: трактует его как работу джуна, собирает контекст по кодовой базе и текущим практикам через веб-поиск, диагностирует ошибки высоты (план либо туманный там, где сложно, либо утонул в деталях без общей картины) и переписывает. Используй, когда пользователь говорит «отревьюь план как сеньор», «что бы сказал опытный инженер», «плана достаточно?», «перепиши план нормально», а также перед тем как отдавать план в работу агенту.

- Skill: `jtprogru/code-senior-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jtprogru/code-senior-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jtprogru/code-senior-review/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-senior-review

---


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

# code-senior-review — Ревью плана глазами сеньора

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

## Шаг 1. Собери контекст, прежде чем судить

Ревью без контекста превращается в набор общих мест. Нужны два источника.

**Кодовая база.** Как в этом проекте уже решены похожие задачи? Какие библиотеки, слои, соглашения приняты? План, идущий поперёк устоявшихся решений, должен это обосновывать — или он просто их не заметил.

**Текущие практики.** Здесь обязателен веб-поиск. Практики в Go, Kubernetes и вокруг инфраструктуры меняются быстрее, чем обучаются модели: рекомендация, верная на момент cutoff, сегодня может быть устаревшей или прямо вредной. Проверяй актуальность того, что собираешься советовать, особенно если советуешь конкретную библиотеку, флаг или паттерн.

Если веб-поиска нет — скажи об этом прямо и пометь советы, которые опираются на возможно устаревшие знания.

## Шаг 2. Диагностируй ошибку высоты

Самая частая проблема плана — не неправильность, а неверный масштаб. Две зеркальные формы:

**Туман на сложном.** «Реализовать синхронизацию» одной строкой, хотя именно здесь вся сложность: конфликты, порядок, повторные попытки, частичные отказы. План проскочил место, где нужно было думать.

**Утопание в мелочах без общей картины.** Двадцать пунктов про названия полей и структуру каталогов, и ни одного про то, зачем это делается и как пользователь этим воспользуется. План детален там, где детали очевидны.

Часто обе формы соседствуют в одном документе. Назови их явно, с указанием на конкретные пункты.

## Шаг 3. Разбери по существу

Помимо высоты смотри:

- **Что сломается первым.** Не абстрактные риски, а конкретное место, которое отвалится раньше остальных.
- **Чего нет.** Миграция данных, обратная совместимость, откат, наблюдаемость, что видит пользователь при отказе.
- **Что сделано сложнее, чем нужно.** Обобщение под будущие требования, которых может не быть.
- **Порядок работ.** Правильные шаги в неправильном порядке дают состояние, из которого тяжело откатиться.

## Шаг 4. Перепиши

Не ограничивайся списком замечаний — верни переписанный план. Замечания без переписывания перекладывают работу обратно на автора, а он уже показал, что именно здесь ему не хватает опыта.

В переписанном плане:

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

Рядом покажи, что изменилось и почему. Автор должен увидеть логику, а не только результат.

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

- Не советуй библиотеку или паттерн, не проверив, что это актуально сегодня.
- Не переписывай то, что было верно: сохраняй решения автора там, где они хороши, и говори об этом.
- Не подменяй ревью плана ревью кода — кода ещё нет.
- Не превращай план в проектную документацию на тридцать страниц: цель — работоспособность, а не полнота.
- Не смягчай вывод, если план требует переделки по существу. Мягкое ревью плана оплачивается переделкой реализации.