# Code Grill

> Калиброванный допрос плана до реализации: сначала измеряет, насколько глубоко пользователь знает тему и какое давление ему нужно, потом задаёт вопросы по одному, с рекомендованным ответом к каждому. Используй, когда пользователь говорит «покритикуй план», «допроси меня по этому решению», «найди дыры в плане», «prove me wrong», «стоит ли так делать» — и вообще перед реализацией чего-то, что дорого переделывать: архитектурного решения, RFC, ADR, схемы данных.

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

---


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

# code-grill — Допрос плана до реализации

Дешевле всего менять план, пока он план. Этот скилл вытаскивает из него дыры до того, как они станут кодом.

Ключевое отличие от обычной критики: **сначала калибровка, потом вопросы, по одному**.

## Шаг 1. Калибровка

Задай ровно два вопроса и дождись ответов:

1. **Насколько глубоко ты в теме?** Первый раз трогаешь / делал похожее / это твоя основная область.
2. **Какое давление нужно?** Мягко — подсветить слепые зоны. Средне — оспорить решения. Жёстко — искать, где план развалится, и не смягчать формулировки.

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

Если пользователь отвечает «жёстко» — принимай это буквально. Он попросил.

## Шаг 2. Прочитай план и составь список

Ищи в таком порядке:

- **Необоснованные допущения.** Что принято за данность без проверки?
- **Пропущенные состояния.** Что происходит при пустых данных, конкурентном доступе, откате, повторной попытке?
- **Обратимость.** Что случится, если через месяц решение окажется неверным? Сколько стоит откат?
- **Границы.** Где план кончается и начинается «а дальше как-нибудь»?
- **Альтернатива, которую не рассмотрели.** Особенно вариант «не делать этого вообще».
- **Стоимость сопровождения.** Кто будет это чинить в три ночи и хватит ли ему того, что есть в плане?

Список держи при себе. Пользователь его не видит.

## Шаг 3. Задавай по одному

**Один вопрос за ход. Не список.**

Список вопросов человек читает по диагонали и отвечает на самый простой. Один вопрос заставляет ответить именно на него.

К каждому вопросу прикладывай свой предполагаемый ответ:

> **Что происходит, если воркер упадёт между записью в базу и отправкой события?**
>
> Мой вариант: событие потеряется, и данные разъедутся молча. Обычно это лечится outbox-таблицей или идемпотентным консьюмером. Что у тебя?

Рекомендация делает две вещи. Показывает, что вопрос не риторический. И даёт человеку опору, если он о таком не думал, — тогда разговор идёт про решение, а не про его неосведомлённость.

Порядок: сначала то, что дороже всего переделывать. Схема данных и границы сервисов идут раньше выбора библиотеки.

## Шаг 4. Останавливайся вовремя

Допрос закончен, когда выполнено любое:

- вопросы пошли по кругу
- остались только вкусовые
- пользователь сказал «хватит»
- набралось пять-семь содержательных вопросов, и на все есть ответы

Тогда подведи итог: что в плане укрепилось, что изменилось, что осталось открытым и осознанно принято как риск.

Открытый риск, записанный явно, — нормальный результат. Плохо, когда он остался неназванным.

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

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