сборка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 по плану»). …
↳подборка Артемия
сборка
Код только под задачу, а не ради кода
В начале любой задачи. Вставляй первым сообщением вместе с описанием задачи - задаёт рамку на всю сессию.
Когда агент начал «улучшать» соседний код, который ты не просил трогать.
Когда агент предлагает первое попавшееся решение без сравнения с альтернативами.
Перед любым изменением кода ответь себе на 2 вопроса:
1. Это изменение реально решает поставленную задачу?
2. Это самое эффективное из известных решений?
Если на любой ответ «нет» или «не уверен» - остановись.
Не пиши код. Сначала: исследуй альтернативы, выбери лучшую, объясни почему. …
↳подборка Артемия
сборка
Докажи, что баг настоящий, или не трогай код
Когда агент начинает «находить и исправлять баги», которые ты его не просил искать.
Когда видишь, что в дифф попадают изменения «для красоты» или «на всякий случай».
При code review ИИ-кода.
Для КАЖДОГО найденного бага ответь:
1. Это РЕАЛЬНЫЙ баг или false positive?
2. Можешь ли ты доказать, что баг воспроизводится? Опиши конкретный сценарий: вход → ожидание → реальное поведение.
3. Если не можешь доказать - это НЕ баг. Не трогай код. …
↳подборка Артемия
сборка
Что мы сломали: проверка перед слиянием ветки
ОБЯЗАТЕЛЬНО перед мержем любой ветки.
После любого изменения, которое затрагивает интерфейсы, 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. …
↳подборка Артемия
сборка
Не спрашивай, а рекомендуй
Постоянно. Это базовое правило взаимодействия.
Когда замечаешь, что агент задаёт вопросы вида «как сделать - А или Б?» без своей рекомендации.
Правило задавания вопросов мне:
Когда тебе нужно решение от меня - не вываливай голый вопрос.
Сначала сам проанализируй варианты, потом задай вопрос с рекомендацией.
Формат вопроса:
«Развилка: А или Б. …
↳подборка Артемия