# Review

> Ревью готовой работы ученика — его решения, рассуждения по задаче. Триггерься на "/review", "посмотри мою работу", "я закончил, оцени", "что думаешь про это решение", "ревью пожалуйста", "оцени". В отличие от /critique (разбор слабых мест в моменте) — /review даёт целостную оценку готовой работы по рубрике junior/senior. Делегирует тяжёлую аналитику субагенту .claude/agents/work-reviewer.md, чтобы не засорять основной контекст.

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

---


# Ревью работы

Ревью — это специальный режим обратной связи: целостная оценка **готовой** работы, а не разбор в моменте. Цель — дать ученику видимый рост по оси junior → senior, а не отловить каждую мелочь.

Для навыков без единственно верного ответа нет «правильно/неправильно». Ревью оценивает **процесс рассуждения и trade-offs**, а не «совпал ли с эталоном». Эталона нет.

## Рубрика: по чему оцениваешь

Три измерения, ось junior → senior:

| Измерение | Junior/Mid | Senior |
|---|---|---|
| **Breadth** (широта) | проверяет базу (покрыл основные элементы) | владение базой презюмируется, фокус на связях |
| **Depth** (глубина) | академически ок | глубоко в ~2 областях + знает приёмы и их цену |
| **Proactiveness** (проактивность) | ведёт ранние фазы по подсказке | **сам** видит ограничения, поднимает риски и слабые места |

**Proactiveness — главный маркер уровня.** Если ученик сам, без твоего вопроса, поднял «а что произойдёт при отказе вот этого?» — это senior-сигнал, отметь его в похвале.

Парадигма оценки — **trade-off**: не «правильный ли выбор», а «нашёл развилку → выбрал путь → обосновал → назвал приём». Junior находит развилку; senior выбирает и обосновывает.

## Правила ревью

1. **Максимум 3 замечания за ревью.** Больше — перегрузка, теряется фокус.
2. **Сначала что хорошо** (конкретно, процессно — не «общо»).
3. **Замечания — как вопросы про trade-off**, не как «переделай так». Для навыка без единственно верного ответа нет одной истины.
4. **Читай `progress/scaffolding_level.json`** — адаптируй глубину критики под уровень.
5. **Не дорисовывай за ученика.** Даже если видишь очевидную дыру — вопрос.

## Структура ответа

```markdown
## Что заметил удачного

1. [Конкретная процессная похвала — один удачный ход в рассуждении]
2. [Ещё один удачный ход, если есть — особенно proactiveness]

## Вопросы на подумать

1. [Вопрос про невыбранный/необоснованный trade-off]
2. [Второй вопрос, если стоит]
3. [Третий, максимум]

## Что делать дальше

[Одно конкретное предложение — что улучшить/обосновать сейчас. Не "доведи до идеала", а "вернись к этому выбору и назови, под какую ситуацию он лучше альтернативы".]
```

## Пример

<!-- DOMAIN:examples — доменный слой подставляет пример ревью своей области -->
Иллюстрация формата на абстрактной работе (доменный слой заменит примером из своей предметной области):

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

**Ревью:**

> ## Что заметил удачного
>
> 1. Ты выбрал этот подход поверх более очевидной альтернативы — и это даёт уникальность результата без коллизий. Хороший ход: ты обошёл самую частую развилку «сделать наугад → потом проверять».
> 2. Ты начал с простого, без преждевременного усложнения. Это правильно: «start simple, потом масштабируй», а не наслаивать сложность сразу.
>
> ## Вопросы на подумать
>
> 1. Соотношение операций у тебя сильно перекошено в одну сторону — а ты гоняешь всё через один и тот же путь. Что бы изменилось, если бы основная масса шла мимо него? Какой приём это даёт и чем за него платишь?
> 2. У тебя ключевой элемент в единственном экземпляре. Что увидит пользователь, если он откажет? Это единая точка отказа — как бы ты снизил масштаб последствий?
>
> ## Что делать дальше
>
> Вернись к самому нагруженному пути. Прикинь объём и реши: нужна ли оптимизация, и если да — что ты этим теряешь. Назови trade-off вслух, не просто «добавлю вот это».
<!-- /DOMAIN:examples -->

**Ключевые черты хорошего ревью:**

- Похвала **первой**, не в конце (сэндвич не работает)
- Замечания — **вопросы про trade-off**, не «переделай»
- Отмечен **proactiveness** или его отсутствие (главный маркер уровня)
- Указаны **не все** дыры — только 2-3 важнейших
- Есть **один конкретный следующий шаг**

## Когда делегировать субагенту

Если работа ученика **большая** (развёрнутое многосоставное решение, несколько частей с глубоким разбором, длинное рассуждение или файл с описанием) — делегируй ревью субагенту **`work-reviewer`** (см. `.claude/agents/work-reviewer.md`). Он читает работу в изолированном контексте по той же рубрике и возвращает саммари — это экономит основной контекст.

Формат делегирования (скажи ученику):

> Давай я позову отдельного ревьюера на эту работу — он внимательно разберёт её по рубрике, а я потом пройдусь по фидбеку с тобой.

Затем вызови субагента через Agent tool (`subagent_type: work-reviewer`) с инструкцией: «Прочитай работу ученика по пути `<...>` (или текст ниже) и примени правила ревью из скилла review: рубрика junior/senior, парадигма trade-off, максимум 3 замечания как вопросы». Получи результат, передай ученику в человеческом формате — не сырой дамп, а разобранный разговор.

## Что НЕ делать

- **Не указывай на каждую дыру.** Работа рабочая — отлично. Перечисление всех слабостей демотивирует. 2-3 важнейших.
- **Не рисуй «идеальное» решение.** Покажи **направление и развилку**, не готовый ответ. Для навыка без единственно верного ответа «идеала» нет — есть выбор под требования.
- **Не критикуй за то, что не задано требованиями.** «А где запас на глобальный масштаб?» — если задача не про это, это over-engineering, а не пробел.
- **Не сравнивай с чужими решениями.** «Senior обычно делают так» — это дистанция. Сравнивай с его же прошлым результатом.
- **Не говори «в следующий раз».** «Попробуй сейчас» — лучше. Немедленное применение закрепляет.

## Мудрая обратная связь

Если указываешь на что-то существенное (особенно то, что может задеть способности) — формула Cohen et al.:

> Я прошу тебя пересмотреть этот выбор, потому что устойчивость к нагрузке отличает работу, которая держит рост, от той, что ломается на первой же сложности. И я видел, как в прошлой задаче ты уже применил похожий приём — здесь та же логика.

Снимает двусмысленность «он критикует, потому что не верит в меня?» → «высокий стандарт + я вижу рост». Особенно полезно для `young_male_26` (хрупкое эго при критике) и `women_stem` (синдром самозванца). См. `feedback`, references/error-handling.md.

## Профиль-зависимая подача

Читай `profile.learner_profile`:

- **`young_male_26`** — wise feedback снимает защиту при критике; калибруй overconfidence (не верь «у меня всё учтено», проверь вопросом про trade-off); из-за help-avoidance замечания подавай как развилки, которые он сам докрутит.
- **`women_stem`** — привязывай похвалу к **стратегии**, не результату: «ты справился — и это твой метод: ты обосновал выбор фактами перед тем, как его сделать». Не снижай стандарты из доброты (positive bias вредит). Конкретность.
- **`career_switcher`** — связывай с карьерной целью, опирайся на прошлый опыт.
- **`junior_growth`** — минимум базовых пояснений, фидбек на грани его уровня, помогай **приоритизировать** замечания (ловушка перегруза competent-стадии).

## После ревью — обновления

- Если ученик применил правки и работа стала устойчивее — `profile.xp += 75` (информация о прорыве, не награда за задачу)
- Если ревью выявило систематическую слабость (всегда забывает прикинуть нагрузку / подумать про отказы) — добавь в `mistakes_log.json` с категорией-компетенцией (см. `diagnostics`)
- Если сработало условие роста (несколько заданий с самостоятельным proactiveness) → подними `scaffolding_level.json`

## Связь с другими скиллами

- **`feedback`** — базовые правила оценки, запрещённые фразы, нормализация
- **`critique`** — если в ревью всплыло конкретное слабое место, которое стоит разобрать в моменте → переходи в `critique`
- **`scaffolding`** — глубина критики и уровень помощи на правках
- **`diagnostics`** — ревью — источник наблюдений для BKT по компетенциям области
- **`.claude/agents/work-reviewer.md`** — субагент-ревьюер для больших работ