编程智能体的四种提示词模式：plan mode、skills 与保存的提示词

Рабочие процессы · 2026-09-10 · 2,545 слов · 12 мин чтения

Четыре шаблона промптов из документации Claude Code, Codex и Gemini CLI — с точными командами и форматами файлов, плюс скрипт, который записывает один сохранённый промпт тремя способами.

промптинг режим планирования навыки слеш-команды Claude Code

Вы получаете четыре шаблона промптов, на которых сейчас сошлась документация трёх инструментов для работы с кодирующими агентами, их же словами: планируй до того, как редактировать; дай агенту проверку, которую он может запустить; позволь ему опросить тебя; сохраняй промпты, которые ты снова и снова набираешь. Для каждого шаблона указаны точная команда, флаг или формат файла в Claude Code, Codex и Gemini CLI по состоянию на 2026-09-10, а также скрипт на Python из стандартной библиотеки, который проверяет сохранённый промпт по общей спецификации навыков и выводит его во всех трёх форматах. Ни один агент в этой сессии не запускался; запускался только скрипт на Python 3.13.12 под Windows, и каждый блок вывода ниже — настоящий. Версии взяты со страниц релизов соответствующих проектов на GitHub за тот же день: Claude Code v2.1.267 (2026-09-09), Codex CLI rust-v0.154.0 (2026-09-09), Gemini CLI v0.59.0 (2026-09-08).

Промпт для одной задачи — спецификация из шести разделов — уже разбирался в статье /posts/spec-first-prompting-coding-agent.html. Эта статья о шаблонах вокруг него: что делать до него, что к нему прикладывать и что делать с ним, когда он заработает.

Шаблон первый: план — это режим, а не просьба

Раньше «сначала составь план» было просто фразой в промпте. Теперь во всех трёх инструментах это режим, который инструмент принудительно включает, и от этого меняется ценность шаблона. На странице режимов доступа Claude Code он определён так: «Режим планирования велит Claude исследовать и предлагать изменения, не внося их. Claude читает файлы, выполняет команды оболочки для изучения и пишет план, но не редактирует ваш исходный код». Войти в него можно через Shift+Tab, добавив /plan перед одним промптом, или через claude --permission-mode plan. Когда план готов, доступны варианты «Да, и использовать автоматический режим», «Да, утверждать правки вручную» и «Нет, продолжать планирование», и на странице прямо сказано: «Утверждение плана выходит из режима планирования и переводит сессию в тот режим доступа, который описан в выбранном варианте утверждения». Ctrl+G открывает план в вашем редакторе до того, как что-либо запустится.

На странице Gemini CLI это называется «среда только для чтения, чтобы проектировать надёжные решения до реализации», и перечислены инструменты, которые остаются доступными, среди них read_file, grep_search, web_fetch, ask_user, а для записи — «write_file и replace разрешены только для файлов .md в директории планов». Вход — /plan [goal], Shift+Tab или gemini --approval-mode=plan; Ctrl+X открывает план во внешнем редакторе; планы попадают в ~/.gemini/tmp/<project>/<session-id>/plans/. На странице промптов Codex сказано: «Для многошаговой задачи введите /plan в композере приложения, когда хотите, чтобы Codex исследовал и предложил подход перед редактированием». В справке по приложению /plan описан как «Переключить режим планирования для многошагового планирования». Страница команд CLI, которую я загрузил, обрывалась до строки с /plan, и ни на одной из этих страниц не сказано, блокируются ли правки, так что эти ячейки в таблице ниже я не смог заполнить по документации.

	Claude Code v2.1.267	Codex rust-v0.154.0	Gemini CLI v0.59.0
Вход	`Shift+Tab`, префикс `/plan`, `--permission-mode plan`	`/plan`	`/plan [goal]`, `Shift+Tab`, `--approval-mode=plan`
Правки заблокированы	да, до утверждения (см. оговорку)	не указано на прочитанных страницах	да; запись только в `.md` в директории планов
Редактировать план	`Ctrl+G`	не указано	`Ctrl+X`
Выйти без утверждения	`Shift+Tab`	не указано	`Shift+Tab`, `Esc` или попросить словами

Оговорка про Claude Code есть в том же документе: «В сессиях, где доступен обход разрешений, Claude Code также не применяет блокировки режима планирования. Claude по-прежнему получает указание планировать без редактирования, но если во время планирования он попытается изменить файл или выполнить команду shell, это выполнится без запроса подтверждения». Режим планирования, запущенный из сессии с обходом, — снова запрос, а не шлагбаум.

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

Есть и исследовательская причина относиться к плану как к артефакту, а не к ощущению. В статье DCAS за август 2026 года (arXiv:2608.06113) о том, почему модели, дообученные под одним CLI-каркасом, деградируют под другим, утверждается: «несущей частью поведения, специфичного для каркаса, является структура планирования — в двух смыслах, которые различает эта работа: явное планирование, то есть план, созданный до выполнения как полноценный артефакт, и неявное планирование — структурные соглашения, которые задают ход выполнения на протяжении всего цикла работы агента». Их контролируемое вмешательство «подтверждает, что качество планирования — компонент с высоким рычагом, и выигрыш от него превышает падение при смене каркаса, которое мы наблюдаем». Файл плана, который вы правите с помощью Ctrl+G или Ctrl+X, — это ровно их явный план; в аннотации нет цифр по каждому каркасу, а полную статью я не читал, поэтому цитирую утверждение, а не число.

Приём второй: проверка, которую агент может запустить сам

Цикл «сначала тесты» был в статье /posts/tests-first-with-an-agent-red-green.html; лежащий в его основе паттерн промпта теперь стал первым разделом страницы лучших практик Claude Code. «Claude останавливается, когда работа выглядит законченной. Без проверки, которую он может запустить, „выглядит законченной“ — единственный доступный сигнал, и циклом верификации становитесь вы: каждая ошибка ждёт, пока вы её заметите». Пример «до и после» на той же странице показывает весь паттерн в одной строке: промпт «добавь тесты для foo.py» превращается в «напиши тест для foo.py, покрывающий крайний случай, когда пользователь вышел из системы. избегай моков». Дальше строгость проверки нарастает в зависимости от того, насколько жёстко она блокирует остановку: в одном промпте — как условие /goal, перепроверяемое «после каждого хода»; как хук Stop, который «не даёт ходу завершиться, пока проверка не пройдёт» (потолок: «8 блокировок подряд»); или через «вспомогательного агента для верификации», чтобы «тот, кто делает работу, не был тем, кто её оценивает». А инструкция, превращающая заявление в доказательство, звучит так: «Пусть Claude показывает доказательства, а не утверждает успех: вывод тестов, выполненную команду и то, что она вернула, или скриншот результата».

На странице Codex тот же паттерн описан скорее как привычка, а не как механизм: «Для важной работы попросите ChatGPT провести финальную проверку — например, убедиться, что у каждого пункта действий есть ответственный и срок, или отметить информацию, которую он не смог подтвердить». Совет по исправлению багов — дать «рецепт воспроизведения плюс файл(ы), которые вы подозреваете», и задать границы вроде «Не меняй форму API. Исправление должно быть минимальным». В справочнике приложения Codex действительно перечислены /goal — «Задать постоянную цель, к которой ChatGPT должен стремиться», — и /review — «Запустить режим код-ревью для проверки незакоммиченных изменений». На страницах Gemini CLI, которые я читал для этой статьи, ни цели, ни механизма stop-хука нет; верификация там — это режим планирования только для чтения плюс любая команда тестов, которую вы назовёте в промпте.

Приём третий: интервью

Самый полезный промпт на странице Claude Code — тот, который выдаёт спецификацию, а не код. В разделе «Пусть Claude проведёт с вами интервью» сказано: «Хочу собрать [краткое описание]. Проведи со мной подробное интервью с помощью инструмента AskUserQuestion. Спрашивай о технической реализации, UI/UX, крайних случаях, возможных проблемах и компромиссах. Не задавай очевидных вопросов — копай в сложные места, о которых я мог не подумать. Продолжай интервью, пока не разберём всё, а потом напиши полную спецификацию в SPEC.md». Следующий шаг не менее важен: «Когда спецификация будет готова, начни новую сессию, чтобы её выполнить». Причина, которую приводит страница, — контекст: «Чистая сессия с более удачным промптом почти всегда даёт лучший результат, чем длинная сессия с накопленными правками».

Страница промптов Codex приходит к тому же с другого конца: «Начинайте с результата, а не с подробного списка шагов» и «Первый промпт не обязан быть идеальным. Посмотрите на результат, а затем попросите конкретное изменение, которое вам нужно». В режиме планирования Gemini CLI в списке разрешённых инструментов остаётся ask_user — тот же приём: агент может расспрашивать вас, но не может редактировать. Ни одна из трёх страниц не утверждает, что интервью даёт лучший код; они утверждают, что оно даёт спецификацию, которую можно прочитать до появления кода, — и вот это утверждение я готов поддержать.

На странице Claude Code защищают и обратное: «Размытые промпты бывают полезны, когда вы исследуете задачу и можете позволить себе корректировать курс». Это не принцип «всегда указывай всё»; это принцип «указывай, когда уже знаешь, чего хочешь».

Паттерн четвёртый: сохранённый промпт

Любой промпт, который вы набрали трижды, — это файл. У всех трёх харнессов теперь есть для него формат, и два из трёх форматов — один и тот же файл.

Страница навыков Claude Code: «Пользовательские команды объединены в навыки. Файл в .claude/commands/deploy.md и навык в .claude/skills/deploy/SKILL.md оба создают /deploy и работают одинаково». Предпочесть навык абзацу в контекстном файле стоит из-за стоимости: «В отличие от содержимого CLAUDE.md, тело навыка загружается только при его использовании, поэтому длинный справочный материал почти ничего не стоит, пока он не понадобится». Frontmatter определяет, кому можно его запускать. disable-model-invocation: true — для «рабочих процессов с побочными эффектами, которые вы хотите запускать вручную», и в документации сказано, что произойдёт, если модель попробует: «Claude Code блокирует вызов и даёт указание не воспроизводить шаги развёртывания другим способом». allowed-tools заранее одобряет «инструменты, которыми Claude может пользоваться без запроса разрешения в течение хода, вызывающего этот навык. Разрешение сбрасывается, когда вы отправляете следующее сообщение». Аргументы приходят через $ARGUMENTS, либо позиционно — $0, $1, либо по имени из списка arguments:. Строка, начинающаяся с !, сначала выполняет команду оболочки: «Claude Code выполняет команду и заменяет строку её выводом до того, как Claude увидит содержимое навыка», а «неудачная команда прерывает весь вызов навыка». Названы два лимита: в списке, который показывают модели, суммарный текст описаний обрезается «на 1,536 символах», а после компакции каждый заново подключённый навык сохраняет «первые 5,000 токенов» при «общем бюджете в 25,000 токенов».

Страница Codex про навыки: «Навык — это директория с файлом SKILL.md и необязательными скриптами и ссылками». Поиск идёт по $CWD/.agents/skills, $REPO_ROOT/.agents/skills, $HOME/.agents/skills, /etc/codex/skills, затем по встроенным навыкам; вызвать конкретный навык можно явно командой $skill-name в CLI, а «ChatGPT или Codex могут выбрать навык, если ваша задача соответствует навыку description». Навык не удаляется, а отключается записью [[skills.config]] в ~/.codex/config.toml, где задаётся enabled = false. Бюджет описания заявлен как «не более 2% контекстного окна модели или 8,000 символов, если контекстное окно неизвестно». Старый механизм всё ещё на месте: страница пользовательских промптов с пометкой «Устарела в пользу навыков» описывает Markdown-файлы в ~/.codex/prompts/, которые вызываются как /prompts:filename, с $1–$9, $ARGUMENTS, именованными значениями в стиле $FILE, передаваемыми как KEY=value, и $$ для буквального знака доллара. На этой странице сказано перезапустить Codex после редактирования файла промпта.

В Gemini CLI два механизма. Пользовательские команды — это TOML: обязательный prompt, необязательный description, в ~/.gemini/commands/ для пользователя или <project>/.gemini/commands/ для проекта, причём «если команда в директории проекта называется так же, как команда в директории пользователя, всегда будет использоваться команда проекта». Поддиректории становятся пространствами имён через двоеточие. {{args}} подставляет то, что вы ввели; без него «CLI добавит полную введённую команду в конец промпта, разделив их двумя переводами строки». Инъекция шелла через !{...} теперь под контролем: «Gemini CLI запросит подтверждение, прежде чем продолжить». Второй механизм — навыки, «основанные на открытом стандарте Agent Skills»; они обнаруживаются в ~/.gemini/skills/ или псевдониме ~/.agents/skills/ и в .gemini/skills/ или .agents/skills/; в начале сессии CLI «вставляет имя и описание всех включённых навыков в системный промпт», модель вызывает activate_skill, когда задача совпадает, а «в интерфейсе появится запрос на подтверждение с именем навыка, его назначением и путём к директории, к которой он получит доступ».

	Claude Code	Codex	Gemini CLI
Файл	`.claude/skills/<name>/SKILL.md`	`.agents/skills/<name>/SKILL.md`	`.gemini/commands/<name>.toml` или `.agents/skills/<name>/SKILL.md`
Плейсхолдер аргумента	`$ARGUMENTS`, `$0`, `$name`	для навыков не документировано; `$1`–`$9`, `$ARGUMENTS` в устаревших промптах	`{{args}}` в командах
Шелл до того, как его увидит модель	префикс `!`, при сбое — прерывание	не документировано	`!{...}`, запрос на подтверждение
Чтобы модель не запускала его автоматически	`disable-model-invocation: true`	`enabled = false` в конфиге	команды вводятся только пользователем; навыкам нужно согласие
Явный вызов	`/name`	`$name`	`/name`

Общий файл — спецификация Agent Skills, на которую ссылаются и Codex, и Gemini: name «Максимум 64 символов. Только строчные буквы, цифры и дефисы. Не должен начинаться или заканчиваться дефисом» и совпадать с именем директории; description «Максимум 1024 символов»; рекомендуемое тело — меньше 500 строк; а модель загрузки такая: «Поля name и description загружаются при старте для всех навыков», а тело — только при активации. Навык, соответствующий спецификации, без изменений работает и как навык Codex, и как навык Gemini, а как навык Claude Code — с двумя дополнительными строками.

Один промпт, три файла

Скрипт из поставки делает две вещи и не вызывает никаких харнессов. validate <dir> проверяет SKILL.md на соответствие ограничениям спецификации. emit принимает имя, описание, файл промпта и директорию вывода и записывает навык Claude Code, навык Codex и команду Gemini. Промпт, который я использовал, — это рабочий процесс исправления issue из примера выше, с $ARGUMENTS на месте номера issue.

def validate(skill_dir: str) -> list[str]:
    errors: list[str] = []
    fm, body = parse_frontmatter(open(os.path.join(skill_dir, "SKILL.md"), encoding="utf-8").read())
    name = fm.get("name", "")
    dirname = os.path.basename(os.path.abspath(skill_dir))
    if not 1 <= len(name) <= 64:
        errors.append(f"name: {len(name)} chars (spec: 1-64)")
    if not NAME_RE.match(name):          # ^[a-z0-9]+(-[a-z0-9]+)*$
        errors.append(f"name: {name!r} must be lowercase a-z, 0-9 and single hyphens, not at the ends")
    if name != dirname:
        errors.append(f"name: {name!r} does not match directory {dirname!r} (spec: must match)")
    desc = fm.get("description", "")
    if not desc or len(desc) > 1024:
        errors.append("description: required, 1-1024 chars")
    if body.count("\n") + 1 > 500:
        errors.append("body: over 500 lines (spec recommends under 500)")
    return errors

Запуск, дословно:

> python prompt-patterns-coding-agents-plan-mode-skills.py emit fix-issue "Fix a GitHub issue by number: reproduce with a failing test, then the minimal change" prompt.md out
wrote out\claude\.claude\skills\fix-issue\SKILL.md
wrote out\codex\.agents\skills\fix-issue\SKILL.md
wrote out\gemini\.gemini\commands\fix-issue.toml
exit=0
> python prompt-patterns-coding-agents-plan-mode-skills.py validate out/claude/.claude/skills/fix-issue
out/claude/.claude/skills/fix-issue: OK
exit=0
> python prompt-patterns-coding-agents-plan-mode-skills.py validate bad/Fix_Issue
error: name: 'Fix--Issue' must be lowercase a-z, 0-9 and single hyphens, not at the ends
error: name: 'Fix--Issue' does not match directory 'Fix_Issue' (spec: must match)
error: description: required
bad/Fix_Issue: 3 error(s)
exit=1

Файл Gemini, который он записал и который Python-функция tomllib разобрала обратно с двумя ожидаемыми ключами:

description = "Fix a GitHub issue by number: reproduce with a failing test, then the minimal change"
prompt = """
Fix the issue {{args}} in this repository.

1. Read the issue text and restate the expected behaviour in one sentence.
2. Write a failing test that reproduces it before changing any code.
3. Make the smallest change that turns the test green.
4. Run the whole test suite and report the command and its exit code.
5. Stop and ask before touching any file outside the module the issue names.
"""

В первой версии скрипта описание записывалось без кавычек, а описание с двоеточием в таком месте — невалидный YAML. Такой дефект валидатор найдёт, только если скормить ему собственный вывод, поэтому теперь скрипт берёт это поле в кавычки, и запуск выше — уже исправленный. В копии для Codex вместо $ARGUMENTS стоит обычное предложение: на странице навыков Codex никакого плейсхолдера не описано — номер issue вы вводите после $fix-issue, а промпт подсказывает модели, где его искать.

О чём страницы умалчивают

Ни на одной из прочитанных мной страниц ничего из этого не измеряется. Нет цифр, как часто режим планирования меняет результат, сколько экономит сохранённый промпт и даёт ли интервью более качественную спецификацию, чем если написать её самому; единственное количественное утверждение здесь — абстракт DCAS, но он про тренировочные каркасы, а не про то, как вы вводите /plan. Страница команд Codex CLI оказалась настолько длинной, что fetch оборвался до строки с /plan, так что описанный выше режим планирования Codex опирается на страницу промптинга и справку приложения, и я не нашёл утверждения, что Codex блокирует правки в этом режиме. Приёмы с ключевыми словами для расширенного мышления не встречаются ни на одной из страниц, которые я читал сегодня, поэтому в статье их нет. На странице навыков Gemini CLI не было таблицы frontmatter; я применил спецификацию Agent Skills, которой он, как заявлено, следует. Скрипт проверяет синтаксис, а не то, хорош ли навык, и в этой сессии он ни разу не запускался внутри харнесса.

Сказать я могу меньше, зато это проверяемо: на 2026-09-10 все три харнесса поставляются с режимом планирования и горячей клавишей, два из них — с хуком редактора для файла плана, все три читают одну и ту же раскладку SKILL.md из каталога .agents/skills или его эквивалента, а один уже отказался от старого формата файлов промптов в её пользу. Сохранённый промпт в блоке code/ — тот, с которого я бы начал.

Код и данные

prompt-patterns-coding-agents-plan-mode-skills.py — полный листинг, использованный в этой статье.