Claude Code: короткая команда из 5 частей без потери рабочих правил

Claude Code изначально появился как инструмент командной строки для агентного программирования. Поэтому он умеет работать не только с отдельным вопросом, но и с задачей, где надо читать файлы, менять код и запускать проверки. Проблема начинается, когда в один запрос складывают правила проекта, процедуру, историю решений и просьбы «быть внимательнее».

Сжимать нужно не всё подряд. Я оставляю только то, что меняет результат, недоступно из файлов проекта и может быть проверено после работы.

Что такое короткая команда Claude Code и зачем сжимать промпт?

Короткая команда Claude Code - это не урезанная версия длинного запроса, а рабочий контракт для одной повторяемой задачи: цель, недоступный из проекта контекст, ограничения и критерий готовности. Постоянные правила живут отдельно, а изменяемые параметры подставляются в команду перед запуском.

В длинной инструкции часто смешаны три слоя:

Такой разбор не означает, что правил станет меньше. Удаляются инструкции, необходимость которых больше не подтверждается поведением модели.

Борис Черны описал это прямо:

Мы недавно удалили 80% системного промпта Claude Code.

• Boris Cherny, Building Claude Code (перевод автора)

Смысл не в магическом числе 80%. Команда удаляла старые инструкции и возвращала только те, без которых поведение действительно ухудшалось. Поэтому из короткой команды нельзя выкидывать границы задачи и проверку.

Где хранить постоянные правила: claude code settings или CLAUDE.md?

claude code settings и CLAUDE.md нельзя автоматически считать одним и тем же местом: подтверждённого описания устройства settings в фактуре нет. Для постоянных фактов проекта подходит CLAUDE.md, а инструкции одной операции лучше вынести в отдельный skill или правило с областью действия.

CLAUDE.md - это способ держать в проекте факты, которые нужны в каждой сессии. Например, команды запуска, структуру каталогов и решения, которые нельзя надёжно восстановить по одному файлу.

В CLAUDE.md не стоит складывать всю методику работы. Многошаговую процедуру лучше отделить от постоянного контекста. Для неё подходят скиллы и правила с областью действия. Длинные инструкции можно разложить по отдельным файлам в .claude/rules/.

Я бы разделял содержимое так:

• CLAUDE.md - факты проекта и постоянные ограничения;
• .claude/rules/ - правила для отдельных областей;
• skills - многошаговые процедуры;
• короткая команда - конкретная задача, её параметры и проверка.

Точные места хранения settings здесь я не подменяю догадкой. Их надо сверить с актуальной документацией Claude Code перед настройкой.

Как сократить рабочий промпт и не удалить важные правила?

claude code prompts сокращаются не по числу строк, а по влиянию на результат: оставь цель, недоступный из проекта контекст, ограничения и критерии готовности, а общие просьбы и повторяющиеся запреты убери. После каждого удаления запускай одну и ту же задачу и возвращай только правило, отсутствие которого реально сломало результат.

Сначала я вычёркиваю фразы вроде «будь внимательным», «не спеши», «думай пошагово» и длинные универсальные запреты. Они не задают измеримый результат.

Потом проверяю каждую оставшуюся строку четырьмя вопросами:

1. Модель узнает это из кода или файлов?
2. Это меняет порядок действий?
3. Это ограничивает область правок?
4. Есть способ проверить соблюдение?

Если ответ на все вопросы отрицательный, строка похожа на инструкцию-паразита. Её можно удалить для теста.

Короткие, конкретные и лаконичные инструкции соблюдаются стабильнее. Но «сократить системный промпт на 80%» не значит отказаться от 80% правил. Удаляются только те инструкции, которые больше не нужны для поведения модели.

Оставь в рабочем запросе четыре вещи:

• что должно измениться;
• какие сведения не видны из проекта;
• что запрещено менять;
• по какой команде и условию считать задачу готовой.

Всё остальное сначала отправь на проверку удалением. Не переписывай весь промпт с нуля.

Как не потерять контекст в короткой команде Claude Code?

claude code контекст должен содержать только сведения, которые Claude Code не может надёжно получить сам: пути, команды запуска, ограничения проекта и условия проверки. Постоянный файл тоже расходует контекст: каждый токен загружается в каждый запрос, поэтому длинный текст снижает соотношение сигнала и шума.

Для CLAUDE.md Anthropic даёт ориентир: меньше 200 строк. Это не жёсткая граница, после которой файл ломается. Это сигнал проверить содержимое и убрать детали, которые нужны только одной операции.

В документации формулировка ещё прямее:

Каждая строка загружается в контекст при каждом запросе, поэтому каждая строка должна стоить затраченного места.

• Anthropic, Give Claude context: CLAUDE.md and better prompts (перевод автора)

Длинный файл расходует контекст не только ради стоимости. Prompt caching может снизить стоимость повторной загрузки, но лишний текст всё равно занимает место и конкурирует с файлами задачи.

В короткой команде укажи:

• точный путь к экрану или файлу;
• команду запуска;
• ограничения проекта;
• команду проверки;
• критерий, при котором задача считается готовой.

Если подробности нужны редко, вынеси их в отдельный файл. В постоянном тексте оставь маршрут: для какой операции открыть этот файл и в какой момент это сделать.

На практикуме по вайб-кодингу эту связку можно пройти руками: постоянные правила, контекст задачи и проверка результата собираются в одну рабочую систему.

Как описать повторяемую задачу Claude Code коротко: готовый шаблон

Короткая команда для повторяемой задачи должна пройти семь проверок: одна цель, явный контекст, конкретные действия, границы, проверка, удаление лишнего и тестирование после удаления; если результат сломался, возвращается только правило, которое защищало этот результат. Финальная команда проверки и условие готовности обязательны.

1. Выбери одну повторяемую задачу.

   Не сокращай инструкцию целиком. Возьми одну операцию, например проверку интерфейса после изменения.

   Задача должна иметь понятный результат. «Поработай над проектом» слишком широко. «Проверь изменённый экран и исправь связанные с ним проблемы» уже можно проверить.

2. Выпиши недоступный из кода контекст.

   Укажи путь к экрану, команду запуска и проектные ограничения.

   • основной экран: src/pages/dashboard;
   • запуск приложения: npm run dev;
   • проверка тестами: npm test.

   Не добавляй сведения, которые Claude Code может найти сам в файлах.

3. Оставь только действия.

   Запиши, что именно надо сделать с результатом проверки.

   • открыть изменённый экран;
   • сравнить его с задачей пользователя;
   • исправить только проблемы, связанные с этим изменением.

4. Задай границы правок.

   Отдельно напиши, что нельзя менять. Граница защищает рабочую часть проекта от случайного расширения задачи.

   Не добавляй в шаблон общую просьбу «не ломай проект». Укажи конкретную область: исправлять только проблемы изменённого экрана.

5. Добавь проверку и готовность.

   Назови команду и условие, при котором работа считается законченной.

   Проверка интерфейса после измененияСкопировать промпт

   Проверь изменённый экран в браузере.
   
   Контекст:
   - приложение запускается через `npm run dev`;
   - основной экран находится в `src/pages/dashboard`.
   
   Сделай:
   1. Открой изменённый экран в браузере.
   2. Сравни результат с задачей пользователя.
   3. Исправь только проблемы, связанные с этим изменением.
   
   Проверь:
   - экран открывается без ошибок в консоли;
   - основной пользовательский сценарий работает;
   - команда `npm test` проходит.
   
   Считай задачу готовой только после успешной проверки. В конце перечисли, что проверено и что изменено.

6. Удали лишние инструкции.

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

   В коротком шаблоне не нужны фразы «будь экспертом», «рассуждай подробно» и «не забывай проверять». Команда проверки уже задаёт нужное действие.

7. Протестируй и верни сломавшееся.

   Запусти задачу с сокращённым вариантом. Если правило больше не соблюдается, верни только его и повтори проверку.

   Такой цикл отделяет рабочее ограничение от привычной перестраховки. У тебя остаётся минимальный набор правил, который влияет на результат.

Что делать, если Claude Code не соблюдает правило?

Строка в CLAUDE.md или skill - это просьба, а не гарантия исполнения. Если ограничение критично, например нельзя менять файл или пропускать проверку, вынеси защиту из текста в hooks, тесты, CI или скрипты, а в короткой команде оставь ссылку на конкретную проверку и критерий провала.

Anthropic приводит жёсткий пример:

Инструкция вроде «никогда не редактируй .env» в CLAUDE.md или skill - это просьба, а не гарантия.

• Anthropic, Extend Claude Code (перевод автора)

Поэтому разделяй два класса правил:

• ориентир для модели - что читать, какой файл менять, в каком порядке работать;
• механическая защита - что нельзя пропустить или нарушить.

Для второго класса подходят:

• scripts;
• hooks;
• tests;
• CI.

Если Claude всё равно нарушает правило, не наращивай текст бесконечными повторами. Сначала проверь, можно ли превратить правило в команду с наблюдаемым результатом.

Например, вместо «не сообщай о готовности без проверки» напиши: запусти npm test, а задачу считай готовой только при успешном завершении команды.

Почему Claude Code пропускает CLAUDE.md после compact?

После compact корневой CLAUDE.md перечитывается с диска, но path-scoped правила и вложенные CLAUDE.md теряются до следующего чтения файла, поэтому короткая задача должна иметь явный финальный чек-лист. Если сессия уже пережила compact, повтори критичные критерии в запросе или попроси Claude Code заново прочитать нужный файл перед продолжением работы.

Проблема не в том, что compact удаляет CLAUDE.md: документация подтверждает обратное, корневой файл перечитывается с диска. Но после сжатия истории модели может быть доступен пересказ предыдущей работы, а не тот же набор исходных инструкций, поэтому критичные критерии из истории сессии стоит повторить в запросе.

Практическая защита простая:

1. Не оставляй единственную копию критичного критерия в длинной истории.
2. Заверши короткую задачу отдельным чек-листом.
3. После compact попроси заново прочитать CLAUDE.md, если продолжение зависит от его правил.
4. Повтори в запросе запрет или критерий, нарушение которого дорого исправлять.

Это особенно важно для финальной проверки. Фраза «проверь всё по правилам проекта» слабее, чем конкретная команда и условие готовности.

Что делать, если короткая команда всё равно запускает неверный сценарий?

Если короткая команда ссылается на отложенную документацию, добавь обязательный триггер чтения: сначала открой каталог, затем прочитай нужный файл, после этого выполняй действие. Встроенные Explore и Plan могут пропускать CLAUDE.md, а Claude Code иногда запускает инструменты до ответа на вопрос, поэтому критичный порядок оформляй отдельным этапом с остановкой.

Случай с документацией выглядит так: в CLAUDE.md написано, что подробности находятся в docs/, но Claude не открывает нужный файл и действует по общим знаниям. Для специфичного фреймворка этого может хватить, чтобы создать неверную структуру.

Рабочая формулировка должна называть действие:

1. Открой каталог docs.
2. Прочитай нужный файл.
3. Только после этого создавай или меняй объект.

Одна ссылка здесь не заменяет команду.

Встроенные Explore и Plan тоже требуют отдельной осторожности. Они пропускают CLAUDE.md, поэтому критичное правило иногда надо повторить в делегирующем запросе. Если используется собственный субагент, инструкция должна находиться в его agent-файле.

Есть и другой сбой: Claude Code может начать читать файлы или менять проект до ответа на вопрос. Если сначала нужен план, пиши это как отдельный этап:

Сначала выведи план действий и дождись моего подтверждения.
Не читай файлы, не запускай инструменты и не редактируй проект до подтверждения.
После подтверждения выполни план и запусти указанную проверку.

В конце длинного запроса про commands, review, design, git, tools, context, skills, CLAUDE.md, settings или повторяемые tasks правило остаётся тем же: постоянные факты отдельно, конкретная операция отдельно, проверка обязательно.

Вопросы и ответы