---
name: kp-prompting
description: Создавай продвинутые промпты, спецификации задач, критерии проверки и настройки Claude Code по методу спецификации / проверяющего механизма / среды Andrej Karpathy. Используй этот навык всякий раз, когда нужно специфицировать задачу или проект, уточнить или переписать промпт, определить критерии проверки или успеха результата агента либо настроить/обновить базу знаний, навык или защитные ограничения агента.
---
Спецификация — что именно требуется, достаточно точно, чтобы модель не гадала
Проверяющий механизм — как ты (или модель) узнаете, что результат действительно верен
Среда — постоянный контекст и защитные ограничения, чтобы агенту не приходилось каждый раз заново узнавать всё с нуля

Общая нить всех трёх: выполнение можно передать, понимание — нет. Каждый слой ниже должен сохранять участие Тома в решениях, требующих реального суждения, а не просто выдавать внешне отточенный результат, скрывающий пробелы, о которых его так и не спросили.
Два режима — определи, в каком ты находишься, прежде чем делать что-либо ещё
Режим консультации (по умолчанию). Том передаёт тебе задачу, черновой промпт или запрос написать инструкции для чего-то конкретного. Уточни его с помощью трёхслойного подхода ниже и верни улучшенную версию в чате — без файлов. Это режим по умолчанию для «помоги написать/улучшить промпт для X».
Режим полной настройки. Том запускает новый проект, инструмент или регулярный рабочий процесс и хочет реальный каркас: документ спецификации, критерии проверки и настройку среды (дополнения CLAUDE.md, защитные ограничения, указатели на базу знаний). Включай этот режим по фразам вроде «составь спецификацию», «настрой среду для», «разверни метод Карпаты для X» или по явному запросу всех трёх слоёв.
Если действительно непонятно, какой режим подходит, задай ОДИН короткий вопрос, а не гадай: создание не того результата тратит больше времени, чем вопрос. В большинстве случаев это можно определить: отдельная задача или черновик промпта → консультация; новый проект/функция без готового промпта → полная настройка.

Слой 1: спецификация
Почему это важно
Пример Карпаты: спроси передовую модель, ехать ли на машине или идти пешком на автомойку в 50 метрах, и она ответит «идти» — упуская очевидный факт, что машину тоже нужно туда доставить. Модели отлично справляются со всем проверяемым и удивительно плохо — с практическими решениями, требующими суждения, потому что именно таких решений недостаёт в чистом обучающем сигнале. Задача спецификации — передать модели суждение, которое она не может самостоятельно вывести, чтобы ей не приходилось гадать о контексте. Поверхностный высокоуровневый промптинг в духе «режима плана» этого не делает — в нём слишком мало содержания для настоящего понимания.
Как её создать

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

Что должна содержать спецификация
Цель (решение/результат, которому это служит, а не просто задача), границы объёма (что явно входит и не входит), решения, требующие суждения, которые нужно отмечать, а не молча принимать, и ограничения, разделённые на обязательные и предпочтительные.

Слой 2: проверяющий механизм
Почему это важно
Формулировка Карпаты: эти модели ближе к «призракам», чем к животным, — статистические симуляторы, а не мотивированные агенты. Крик на модель, уговоры или заверения в исключительной важности чего-то не меняют качество результата. Его меняет наличие чего-то, что действительно может проверить работу. Поэтому же модели сверхчеловечески сильны в коде и математике (чётко проверяемых областях) и ненадёжны во вкусе и суждениях (нет эталона для проверки): чем явнее и проверяемее определено «сделано хорошо» для конкретной задачи, тем больше результату действительно можно доверять, а не бегло просматривать его с усталостью от проверок.
Как его создать

Задай критерии «пройдено/не пройдено» заранее, в самом промпте, а не постфактум. «Сделай отчёт красивым» непроверяемо. «В отчёте три раздела, и каждый заканчивается рекомендацией» — проверяемо. Формулируй критерии как то, что второй читатель — человек или модель — сможет проверить, не читая мысли Тома.
Используй вторую модель как критика, когда это недорого. Другая модель (или та же модель в новом контексте), оценивающая результат первой по спецификации, замечает то, что исходный запуск склонен оправдать и пропустить.
Привлекай реальные внешние сигналы, когда они есть. Для кода: действительно ли он развёртывается, проходят ли тесты? Для нетехнической работы: соответствует ли он формату/тону примеров, уже признанных хорошими? Проверяющий механизм, проверяющий только внутреннюю согласованность, слабее механизма, сверяющего с чем-то реальным.

Что должен содержать проверяющий механизм
Конкретные проверяемые критерии «пройдено/не пройдено» (не впечатления), кто или что проверяет (самопроверка, вторая модель, сигнал развёртывания/тестов) и что происходит при провале (повтор с какой конкретной обратной связью либо передача вопроса Тому).

Слой 3: среда
Почему это важно
Большинство людей каждый сеанс собирает контекст заново: снова объясняют проект, повторяют правила, надеются, что агент помнит, чего нельзя трогать. Сохранённая история чата — не то же самое, что настоящая среда. Мастерская с уже разложенными инструментами лучше повторного объяснения всей мастерской при каждом визите.
Как её создать

CLAUDE.md, который агент читает автоматически. Охвати: что представляет собой это рабочее пространство/репозиторий, какие пользовательские навыки существуют и когда их использовать, где что искать (архитектура знаний), какие правила действуют всегда. Это единственный наиболее действенный элемент, поскольку читается при каждом промпте без повторений со стороны Тома.
Личная база знаний. Структурированное, доступное для поиска место со справочными материалами, откуда агент может брать информацию вместо повторного вывода или галлюцинаций. Накопленные материалы — защитное преимущество; хорошо организованная структура поиска по ним приносит нарастающую пользу при каждом использовании.
Повторно используемые навыки для всего повторяющегося. Если Том делает что-то во второй раз, это должно становиться навыком, а не заново объяснённым разовым заданием.
Защитные ограничения на уровне инструментов, а не только промпта. Инструкция только в промпте вроде «не трогай клиентские шаблоны без вопроса» — пожелание, которое модель может проигнорировать под давлением. То же правило в виде реального ограничения инструмента (заблокированный путь, барьер разрешений) — нет. Раздели правила на три уровня:

Делать всегда — безопасно в автоматическом режиме, спрашивать не нужно
Сначала спросить — перед продолжением нужна короткая сверка
Никогда не делать — жёсткий запрет, а не просто нежелательность



Что должна содержать настройка среды
Предлагаемые дополнения CLAUDE.md (или полный CLAUDE.md, если его нет), короткий список того, что относится к базе знаний и что можно не включать, новые навыки, которые стоит выделить, и уровни защитных ограничений, заполненные для конкретного проекта.

Форматы результатов
Результат в режиме консультации
Верни улучшенный промпт/инструкции прямо в чат, в ограждённом блоке кода, удобном для копирования. Под ним — короткое маркированное примечание (максимум 3–5 строк) о том, что изменилось и к какому слою относится: достаточно, чтобы показать, что улучшение не косметическое, но без лекции. Не создавай файлы в этом режиме, если об этом не просят.
Результат в режиме полной настройки
Создай три небольших документа с помощью create_file:

SPEC.md — цель, объём, решения, требующие суждения, ограничения
VERIFIER.md — критерии «пройдено/не пройдено», кто проверяет, что происходит при провале
Раздел среды — либо новый CLAUDE.md, либо явно обозначенное дополнение к существующему файлу Тома, плюс уровни защитных ограничений

Прежде чем писать их, прочитай references/templates.md с полными шаблонами для заполнения и разобранным примером — не импровизируй структуру с нуля каждый раз.
Представь все три вместе с кратким описанием содержимого каждого и явно отметь все решения, требующие суждения, которые Тому стоит перепроверить, а не принимай их молча за него.

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