сборкаClaude Code
Стоп-проверка на отговорки «это не входило в задачу»
Когда агент говорит «готово», но ты чувствуешь подвох.
Когда в ответе всплывают фразы «pre-existing», «out of scope», «follow-up», «not blocking».
Как автоматический hook на завершение задачи (можно вшить в Claude Code settings.json).
Ты - JSON-only evaluator. Отвечай ТОЛЬКО raw JSON, без markdown.
Проверь финальный ответ ассистента. Отклони, если:
- Рационализирует незавершённую работу: «pre-existing», «out of scope», «follow-up», «not blocking»
- Перечисляет проблемы, не починив их
- Пропускает падающие тесты / lint с …
↳подборка Артемия
сборка
Фраза-пропуск: код только после моего слова
В самом начале сессии, как часть установочных правил.
Когда агент пытается перейти к коду до того, как план финализирован.
Правило старта реализации.
Тебе ЗАПРЕЩЕНО писать или менять код до тех пор, пока:
1. План финализирован.
2. Все мои аннотации / NOTE-комментарии в плане отработаны.
3. Я явно сказал триггер-фразу: «Implement Phase N according to plan» (или «Реализуй фазу N по плану»). …
↳подборка Артемия
идея
Продумать, что сломается через месяц
На стадии планирования, до начала реализации.
Когда задача кажется простой - именно тут чаще всего вылезают edge cases, которые рушат код через неделю.
До того как написать строчку кода, продумай ВСЕ возможные проблемы заранее.
Задай себе вопросы:
- Что сломается через неделю? Через месяц?
- Что произойдёт под нагрузкой в 100x?
- Что будет, если данных ноль? Если данных миллион?
- Что если пользователь сделает то, чего я не ожидаю? …
↳подборка Артемия
сборка
Код только под задачу, а не ради кода
В начале любой задачи. Вставляй первым сообщением вместе с описанием задачи - задаёт рамку на всю сессию.
Когда агент начал «улучшать» соседний код, который ты не просил трогать.
Когда агент предлагает первое попавшееся решение без сравнения с альтернативами.
Перед любым изменением кода ответь себе на 2 вопроса:
1. Это изменение реально решает поставленную задачу?
2. Это самое эффективное из известных решений?
Если на любой ответ «нет» или «не уверен» - остановись.
Не пиши код. Сначала: исследуй альтернативы, выбери лучшую, объясни почему. …
↳подборка Артемия
идея
Три вопроса к плану до того, как писать код
После того как агент написал план реализации, ДО начала кодинга.
Каждый раз, когда план кажется тебе «вроде ок» - прогони через эти 3 вопроса.
Перед тем как финализировать план, ответь на 3 вопроса:
1. РЕШАЕТ ЛИ ЭТО ПРОБЛЕМУ?
Сопоставь каждый пункт плана с acceptance criteria из спеки.
Если хоть один критерий не покрыт - план неполный.
2. ЭТО САМОЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ?
Найди: кто уже решал эту проблему? Какой подход выбрали? …
↳подборка Артемия
идея
Правки в плане на полях, а не переписывание
Когда агент сделал первый драфт плана / спеки / архитектуры.
Когда у тебя есть конкретные правки, но проще написать их прямо в файле, чем перечислять в чате.
Workflow совместного редактирования плана:
1. Ты драфтишь план / спеку / документ в файл.
2. Я открываю файл в редакторе и добавляю комментарии в формате:
> NOTE: тут не учёл случай X, переделай
> NOTE: эту фазу разнеси на 2 - слишком большая
> NOTE: вместо подхода А используй Б, потому …
↳подборка Артемия
сборка
Докажи, что баг настоящий, или не трогай код
Когда агент начинает «находить и исправлять баги», которые ты его не просил искать.
Когда видишь, что в дифф попадают изменения «для красоты» или «на всякий случай».
При code review ИИ-кода.
Для КАЖДОГО найденного бага ответь:
1. Это РЕАЛЬНЫЙ баг или false positive?
2. Можешь ли ты доказать, что баг воспроизводится? Опиши конкретный сценарий: вход → ожидание → реальное поведение.
3. Если не можешь доказать - это НЕ баг. Не трогай код. …
↳подборка Артемия
идеяClaude Code
Разведка перед кодом: найти, как это уже решали
В самом начале большой задачи, до спецификации и плана.
Когда чувствуешь, что ныряешь в реализацию без понимания «а как вообще принято такое решать».
Режим: только чтение. Никакого кода.
Задача исследования: {опиши задачу}
Действия:
1. Запусти параллельно несколько под-агентов на исследование структуры кодбазы (по одному на область: модели/архитектура, существующие паттерны, зависимости, тесты).
2. …
↳подборка Артемия
сборка
Что мы сломали: проверка перед слиянием ветки
ОБЯЗАТЕЛЬНО перед мержем любой ветки.
После любого изменения, которое затрагивает интерфейсы, API, типы или контракты.
Когда трогаешь файл, от которого зависят другие.
ОБЯЗАТЕЛЬНАЯ ПРОВЕРКА ПЕРЕД МЕРЖЕМ:
1. РЕГРЕССИЯ
Какие модули/функции зависят от изменённых файлов?
Запусти ВСЕ тесты проекта (не только текущей фазы).
Если что-то сломалось - это приоритет №1.
2. SIDE EFFECTS
Изменились ли какие-то контракты/интерфейсы (API, props, типы, схема БД)? …
↳подборка Артемия
сборкаClaude Code
Дисциплина контекста: правило сорока процентов
В начале большой задачи, чтобы задать контекст-дисциплину на всю сессию.
Когда чувствуешь, что качество ответов агента деградировало - это симптом переполненного контекста.
Правила управления контекстом на эту сессию:
1. ПРАВИЛО 40%
Держи контекст в диапазоне 40-60% окна.
В районе 50% делай ручной /compact - не жди автокомпакта.
Если контекст перегружен - сохрани прогресс в handoff-файл, /clear, начни заново.
2. …
↳подборка Артемия
сборка
Самопроверка по спеке перед словом «готово»
Сразу после того, как агент завершил кусок реализации - до того, как сказал «готово».
Перед коммитом / мержем / показом тебе.
Аудит реализации текущей фазы. Свежими глазами.
1. SPEC COMPLIANCE
Открой спеку. Пройдись по каждому acceptance criterion.
Для каждого: реализован? Где именно в коде (файл:строка)?
Если хоть один не покрыт - закончи его сейчас, не оставляй на «потом».
2. …
↳подборка Артемия
сборка
Не спрашивай, а рекомендуй
Постоянно. Это базовое правило взаимодействия.
Когда замечаешь, что агент задаёт вопросы вида «как сделать - А или Б?» без своей рекомендации.
Правило задавания вопросов мне:
Когда тебе нужно решение от меня - не вываливай голый вопрос.
Сначала сам проанализируй варианты, потом задай вопрос с рекомендацией.
Формат вопроса:
«Развилка: А или Б. …
↳подборка Артемия