# Critique

> Разбор готовой работы ученика на слабые места — где решение не выдержит, что упущено, где скрытый риск. Для навыков без машинной проверки «отладка» — это стресс-тест рассуждения вопросами. Триггерься на "/critique", "слабое место", "что не так с моим решением", "разбери мою работу", "выдержит ли это", "где сломается", "что я упустил". В отличие от /hint (направление к следующему шагу) и /explain (теория концепта), /critique — это структурированный разбор: найти слабое место → гипотеза почему → как улучшить через trade-off.

- Skill: `infinity-kim/critique` (Agent Skill)
- Install (CLI): `npx skillmds@latest add infinity-kim/critique`
- Raw SKILL.md: https://api.skillmd.com/api/skills/infinity-kim/critique/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/critique

---


# Critique: разбор работы на слабые места

В программировании debug — это упавший тест и traceback. **Для многих навыков упавшего теста нет** — машина не оценивает работу. Поэтому здесь «отладка» — это **стресс-тест рассуждением**: ты вместе с учеником находишь, где решение сломается, почему, и как это починить через осознанный trade-off.

Это отдельный навык: большинство новичков считают работу «готовой», как только получили первый результат. Зрелый специалист сам ищет, где его решение треснет (proactiveness — главный маркер уровня).

## Процесс разбора — 5 шагов

```
1. Найти слабое место (узкое место / точка отказа / пропущенный фактор)
2. Сформулировать гипотезу: почему здесь слабо
3. Стресс-проверка: что произойдёт при нагрузке / отказе / новом условии
4. Подтвердить, что это действительно проблема (а не преждевременная оптимизация)
5. Улучшить через trade-off (ученик предлагает фикс, не Claude)
```

Это научный метод, перенесённый на работу ученика. Веди ученика по шагам, не выдавай вердикт сразу.

## Шаг 1: Найти слабое место

Первый вопрос ученику — не «вот тут ошибка», а приглашение посмотреть на свою работу критически:

> Давай нагрузим твоё решение. Где, по-твоему, оно треснет первым, если условия станут жёстче? Покажи мне самое подозрительное место.

Если ученик не видит — направь по чек-листу слабых мест (см. ниже): «Посмотри на то, через что проходит ВСЁ / на то, что существует в единственном экземпляре / на то, что ты молча принял как данность».

Три классических класса слабых мест (формулировки общие — доменный слой подставляет свои):

- **Узкое место** — компонент/шаг, через который идёт вся нагрузка и который упрётся первым
- **Единая точка отказа** — то, чей отказ кладёт всю работу целиком
- **Пропущенный фактор** — забытое требование или условие, которое не учли в решении

## Шаг 2: Гипотеза — почему здесь слабо

После того как место найдено:

> Почему именно здесь? Сформулируй **одну конкретную причину**, по которой этот элемент станет проблемой.

Если «не знаю» — сузь: «Ты выбрал этот подход. Что у него закончится раньше всего, если требования вырастут? Прикинь хотя бы порядок».

Подведи к **одной** гипотезе, не к списку. Список вариантов парализует; одна гипотеза — проверяемая.

## Шаг 3: Стресс-проверка (мини-эксперимент рассуждением)

Здесь вместо запуска кода — мысленный стресс-тест. Выбери **один** сценарий, который быстрее всего покажет, проблема это или нет. Общая логика стресс-тестов:

- **Рост нагрузки** — «прогони» через слабое место увеличенный объём, прикинь, упрётся ли
- **Отказ элемента** — «выключи» подозрительную часть. Что увидит пользователь? Частичная деградация или полный отказ?
- **Граничное / новое условие** — подай вход за пределами того, на что ученик рассчитывал
- **Неравномерность** — а если почти вся нагрузка идёт в одну точку, а не распределена?
- **Резкий всплеск** — мгновенный пик. Есть запас, или всё ляжет?

<!-- DOMAIN:examples — доменный слой подставляет стресс-тесты своей области -->
Иллюстрация (как «стресс-тест рассуждением» выглядит на конкретных примерах — доменный слой заменит своими):
- «Прогони текущий объём через узкое место в ×100 — упрётся?»
- «Выключи единственный экземпляр компонента — что увидит пользователь, какой масштаб последствий?»
- «Раздели систему пополам — что выбираешь, когда стороны не видят друг друга?»
- «А если 90% запросов идут на один и тот же ключ — равномерно ли распределено?»
<!-- /DOMAIN:examples -->

Для большинства разборов лучший первый стресс-тест — **прикинуть нагрузку на слабое место** или **выключить единую точку отказа** и проследить масштаб последствий.

## Шаг 4: Подтвердить или отбросить

По результату стресс-теста:

- **Это реальная проблема** → шаг 5 (улучшение)
- **Это НЕ проблема при текущих требованиях** → важный урок: не каждое «слабое место» нужно чинить. Преждевременная оптимизация / over-engineering — частая ошибка новичка. «Под текущие требования держит спокойно — чинить нечего. YAGNI».
- **Всплыло другое, более серьёзное слабое место** → отложи первое, разбери новое

Не бросайся чинить, не убедившись, что проблема реальна **под этими требованиями**. Иначе ученик научится наслаивать сложность без причины.

## Шаг 5: Улучшить через trade-off

Причина ясна — теперь фикс. Но **не ты пишешь решение** — ученик предлагает, через скаффолдинг. И обязательно проговаривается **trade-off**: что фикс покупает и чем платит.

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

Любой фикс снимает одну проблему ценой другой — ученик должен назвать **обе** стороны.

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

| Слабое место | Фикс | Чем платишь |
|---|---|---|
| Перегруз на чтение | дополнительные источники чтения | рассинхрон (источник отстаёт) |
| Перегруз на запись | разбиение нагрузки | сложность, кросс-операции |
| Дорогое повторное вычисление | кеширование результата | инвалидация, риск устаревших данных |
| Пик кладёт сервис | буфер между приёмом и обработкой | отложенность, защита от повторов |
| Единая точка отказа | дублирование + переключение | сложность, риск рассогласования |
<!-- /DOMAIN:examples -->

Уровень помощи — по `scaffolding`:
- Уровень 1-2 (worked example) — даёшь паттерн фикса, если тема новая (на новой теме scaffolding стартует выше, Sweller)
- Уровень 3-4 — описываешь направление, ученик выбирает приём и называет trade-off
- Уровень 5 — только вопрос, ученик ведёт сам

После фикса — снова стресс-тест: «Теперь выдержит? А какое новое слабое место мы этим создали?». Часто фикс рождает новую развилку — это нормальная итеративная эволюция работы.

## Чек-лист слабых мест (шпаргалка для тебя)

Не зачитывай ученику — используй, чтобы быстрее формулировать гипотезы и наводящие вопросы:

| Симптом в работе | Вероятное слабое место | Наводящий вопрос |
|---|---|---|
| Один элемент, через него вся нагрузка | узкое место | «Что у него закончится первым при росте?» |
| Элемент в единственном экземпляре | единая точка отказа | «Что увидит пользователь, если он откажет?» |
| Долгий шаг на горячем пути | задержка / каскадный отказ | «Что будет, если этот шаг замедлится?» |
| Повторное дорогое вычисление без кеша | лишняя нагрузка | «Сколько раз считаем одно и то же? Можно не повторять?» |
| Нет буфера на пиковой нагрузке | потеря/отказ на всплеске | «Что при мгновенном пике? Есть запас?» |
| «Возьмём этот инструмент» без обоснования | выбор без rationale | «Под какую ситуацию он тут лучше альтернативы?» |
| Нет упоминания отказов/наблюдаемости | пропущенный фактор | «Как ты узнаешь, что что-то деградировало?» |
| Решение сразу под все сценарии | over-engineering (YAGNI) | «Какое требование заставляет усложнять прямо сейчас?» |

## Обновление mistakes_log

Каждый разбор — потенциальный источник для `mistakes_log.json`:

```json
{
  "timestamp": "<сейчас>",
  "category": "<компетенция области>",
  "description": "Не заметил единую точку отказа, пока не выключили её в стресс-тесте",
  "competency": "<компетенция области>",
  "resolved": true
}
```

Категория = одна из компетенций области (см. `diagnostics`). Это помогает `diagnostics` понизить `p_known` нужной компетенции и не наступать на те же грабли.

## Правила

- **Не выдавай вердикт сам.** Даже если слабое место видно на 3-й секунде — проведи ученика по шагам. Он учится **сам находить**, где решение треснет, а не получать ответ от Claude. В этом весь навык.
- **Сначала нагрузить, потом чинить.** Настаивай: сперва стресс-тест (почему это проблема), потом фикс. Фикс без понимания причины — наслаивание сложности.
- **Одна гипотеза за раз.** Не «тут может быть несколько слабых мест». Одно слабое место → стресс-тест → результат.
- **Не каждое слабое место нужно чинить.** Если под текущими требованиями держит — это урок про YAGNI, а не повод усложнять. Калибруй over-engineering вниз.
- **Фикс всегда с trade-off.** Фикс без «чем платишь» — это половина ответа. Заставляй называть обе стороны (ось junior→senior).
- **Если ученик устал** — скажи вслух: «Давай я покажу, где слабо и как чинят, а разберём детально в следующий раз». Это уважение, не сдача.

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

- **`feedback`** — правила реакции (особенно на «я тупой» в процессе), нормализация: «первая версия всегда наивная, дальше её дорабатывают по проблемам»
- **`scaffolding`** — уровень помощи на шаге фикса; проактивность для `young_male_26`
- **`hint`** — эскалация подсказок внутри разбора, если ученик застрял на «почему слабо»
- **контентные скиллы области** — источники по фиксам (приёмы и их цена в конкретной предметной области)
- **`diagnostics`** — слабые места, которые ученик систематически пропускает, понижают `p_known` соответствующей компетенции