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

> Длинную инструкцию Claude Code можно разделить на постоянные правила, контекст задачи и изменяемые параметры. Так в повторяемой команде остаётся только то, что влияет на результат.

Источник: https://vibeceh.ru/guides/claude-code-szhat-rabochiy-prompt-bez-poteri-pravil
Автор: Сергей Мазур · опубликовано 2026-08-03

Запрос **claude code команды** обычно начинается с длинной инструкции на несколько экранов. Её можно разделить на три части: постоянные правила проекта, контекст конкретной задачи и изменяемые параметры. Постоянную часть вынеси в `CLAUDE.md`, а для повторения оставь короткую команду с целью, границами и проверкой результата.

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

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

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

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

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

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

| Слой | Что содержит | Пример |
|---|---|---|
| Постоянные правила | Решения проекта и ограничения, нужные почти в каждой сессии | Стек проекта, структура каталогов, соглашения команды |
| Контекст задачи | Сведения, недоступные из кода | Пути к файлам, команды запуска, изменённый экран |
| Изменяемые параметры | То, что меняется от запуска к запуску | Экран, файл, сценарий, ожидаемый результат |

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

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

> Мы недавно удалили 80% системного промпта Claude Code.
> - Boris Cherny, [Building Claude Code](https://www.youtube.com/watch?v=qyPCVqFUyDo) (перевод автора)

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

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

Постоянные факты проекта храни в `CLAUDE.md`, процедуры отделяй в skills или правила с областью действия, а устройство `claude code settings` сверяй с актуальной документацией.

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

[**CLAUDE.md**](/guides/claude-md-udalit-ili-perepisat) - это способ держать в проекте факты, которые нужны в каждой сессии. Например, команды запуска, структуру каталогов и решения, которые нельзя надёжно восстановить по одному файлу.

В `CLAUDE.md` не стоит складывать всю методику работы. Многошаговую процедуру лучше отделить от постоянного контекста. Для неё подходят [скиллы и правила](/guides/agents-md-odin-fajl-pravil) с областью действия. Длинные инструкции можно разложить по отдельным файлам в `.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](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts) (перевод автора)

Длинный файл [расходует контекст](/guides/kontekst-v-claude-code-zabyvaet-proekt) не только ради стоимости. Prompt caching может снизить стоимость повторной загрузки, но лишний текст всё равно занимает место и конкурирует с файлами задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

Если правило критично, не полагайся только на текстовую инструкцию: закрепи его в hooks, тестах, CI или скриптах, а в команде оставь конкретную проверку и критерий провала.

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

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

> Инструкция вроде «никогда не редактируй `.env`» в `CLAUDE.md` или skill - это просьба, а не гарантия.
> - Anthropic, [Extend Claude Code](https://code.claude.com/docs/en/features-overview?utm_source=openai) (перевод автора)

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

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

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

- scripts;
- hooks;
- tests;
- CI.

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

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

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

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

После 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 правило остаётся тем же: постоянные факты отдельно, конкретная операция отдельно, проверка обязательно.

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

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

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

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

В фактуре нет конкретных правил работы с Git, поэтому универсальный список здесь нельзя подтвердить. Для любой операции оставь только фактическую границу задачи и проверяемое условие. Если нужен конкретный порядок действий с Git, его надо отдельно зафиксировать в проектном правиле или процедуре и проверить на реальном сценарии.

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

Он получает цель, переданные сведения и постоянные инструкции, доступные в текущей работе. В этом и состоят claude code суперpowers: модель удерживает задачу, а не просто отвечает на вопрос. Каждая строка постоянного файла загружается в контекст при каждом запросе, поэтому длинный `CLAUDE.md` может ухудшать соотношение сигнала и шума. В короткой команде оставляй пути, ограничения, команды запуска и проверку.

Для процедур и деталей подойдут отдельные skills, правила с областью действия и файлы в `.claude/rules/`. Но механически копировать чужой рабочий процесс не стоит: в фактуре отдельно сказано, что правильного универсального способа работы нет. Каждый шаблон надо проверять на одной конкретной повторяемой задаче.

Пиши постоянные факты проекта, решения команды и ограничения, которые нужны в каждой сессии. Не превращай файл в длинный workflow. Критичные запреты и проверки дополнительно закрепляй в scripts, hooks, tests или CI, потому что строка в `CLAUDE.md` остаётся просьбой.

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

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

Повтори критичное правило в делегирующем запросе, если работу выполняет Explore или Plan, потому что встроенные агенты пропускают `CLAUDE.md`. После compact попроси заново прочитать файл. Если нарушение критично, перенеси проверку в script, hook, test или CI.

Оформи порядок отдельным этапом с остановкой: сначала выведи план, не читай файлы и не редактируй проект, дождись подтверждения, затем начинай работу. Общей просьбы «сначала ответь на вопрос» может оказаться недостаточно.

- [Boris Cherny: Building Claude Code](https://www.youtube.com/watch?v=qyPCVqFUyDo)
- [How Claude remembers your project](https://docs.anthropic.com/en/docs/claude-code/memory)
- [Claude Code Advanced Patterns: Subagents, MCP, and Scaling to Real Codebases](https://resources.anthropic.com/hubfs/Claude%20Code%20Advanced%20Patterns_%20Subagents%2C%20MCP%2C%20and%20Scaling%20to%20Real%20Codebases.pdf)
- [The Complete Guide to Building Skills for Claude](https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf)
- [Give Claude context: CLAUDE.md and better prompts](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts)
- [Extend Claude Code](https://code.claude.com/docs/en/features-overview?utm_source=openai)
- [Debug your configuration](https://code.claude.com/docs/en/debug-your-config)
- [Question: Does Claude include CLAUDE.md in its own context after compact?](https://github.com/anthropics/claude-code/issues/2714)
- [Claude ignores CLAUDE.md instructions unless explicitly prompted](https://www.reddit.com/r/ClaudeCode/comments/1njm40c/claude_ignores_claude-md_instructions_unless/)
- [Whats even the point of CLAUDE.md](https://www.reddit.com/r/ClaudeCode/comments/1t3fvf9/whats_even_the_point_of_claude-md/)
- [BUG: Claude Doesn't Follow Instructions](https://github.com/anthropics/claude-code/issues/742)