# Промптинг KP ## Файл: SKILL.md --- 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 с полными шаблонами для заполнения и разобранным примером — не импровизируй структуру с нуля каждый раз. Представь все три вместе с кратким описанием содержимого каждого и явно отметь все решения, требующие суждения, которые Тому стоит перепроверить, а не принимай их молча за него. Весь смысл Не позволяй ничему из перечисленного превращаться в бессмысленную занятость, создающую впечатляющие документы, пока реальное понимание проекта Томом остаётся поверхностным. Цель всех трёх слоёв — чтобы именно Том по-прежнему понимал, почему проект важен и как выглядит «хорошо»; слои лишь делают это знание достаточно понятным для надёжных действий агента. Если документ спецификации, проверки или среды заполняет место, а не фиксирует реальное решение, которое действительно принял бы Том, убери его. ## Файл: templates.md Шаблоны режима полной настройки Нужны только когда kp-prompting работает в режиме полной настройки (см. SKILL.md). Заполни их по реальному проекту — не оставляй скобочные заполнители в выдаваемых документах. Шаблон SPEC.md markdown# Спецификация: [Project/Task Name] ## Цель [The actual decision or outcome this serves — not just the task description. E.g. not "add day-parting to the bid logic" but "cut wasted spend during historically low-conversion hours without also cutting volume during hours that convert but just look slow at a glance."] ## Объём **Входит в объём:** - [...] **Не входит в объём (пока):** - [...] ## Решения, требующие суждения: отмечать, а не молча принимать - [Specific ambiguous point — e.g. "what happens on a campaign with under 2 weeks of data: apply category benchmarks immediately, or wait for campaign-specific data?"] - [...] ## Ограничения **Обязательные:** - [...] **Предпочтения (допускают компромиссы):** - [...] ## Контрольные этапы [If scope is large: 2-4 points where Tom reviews before continuing, rather than one big handoff at the end] 1. [...] 2. [...] Шаблон VERIFIER.md markdown# Проверяющий механизм: [Project/Task Name] ## Критерии «пройдено/не пройдено» [Specific and checkable — not "looks good" or "cut the bad hours." E.g. "an hour is only flagged for reduced bidding if it has at least N leads of history and a CPA more than X% above the account average."] - [ ] [criterion 1] - [ ] [criterion 2] ## Кто проверяет - [ ] Самопроверка агента по приведённым выше критериям - [ ] Проверка второй моделью-критиком (другая модель или новый контекст, оценивание по спецификации) - [ ] Внешний сигнал: [deployment success / test suite / matches a known- good historical example] ## При провале [What happens if a criterion fails — retry with what specific feedback, or stop and flag to Tom before proceeding] Шаблон дополнения среды / CLAUDE.md markdown## [Project/Feature Name] **Что это:** [one or two sentences] **Где что находится:** [file paths, data sources, related docs] **Связанные навыки:** [existing skills to use, or "candidate for a new skill: X"] **Правила:** - Делать всегда: [...] - Сначала спросить: [...] - Никогда не делать: [...] Разобранный пример Задача: Том просит «составить спецификацию добавления автоматических правил распределения по времени суток в навык оптимизации кампаний». Выдержка из SPEC.md: Цель: не «добавить функцию распределения по времени суток» — реальная цель в сокращении бесполезных расходов в исторически низкоконверсионные часы без одновременного снижения объёма в часы, которые дают конверсии, но лишь выглядят слабыми при поверхностном взгляде. Отмеченное решение, требующее суждения: что происходит с совсем новой кампанией, у которой меньше 2 недель данных. Спецификация явно указывает, применяется ли распределение по времени суток сразу по отраслевым ориентирам или ожидается достаточная собственная история кампании, вместо того чтобы позволять агенту молча выбрать вариант. Контрольный этап: логику правила проверяют на одном реальном (уже известном) аккаунте, прежде чем подключить автоматическое применение к действующим кампаниям. Выдержка из VERIFIER.md: Критерий: «час помечается для снижения ставки, только если в его истории не менее 15 лидов и CPA более чем на 25% выше среднего по аккаунту» — это проверяемо, а не «убери плохие часы». Проверка: вторая модель-критик проверяет предложенное правило на 2–3 известных аккаунтах на ложные срабатывания (часы, которые выглядят плохо только по объёму, но нормальны по CPA), прежде чем предлагать его для действующего клиента. Выдержка из дополнения CLAUDE.md: Делать всегда: получать и обобщать почасовые данные эффективности, отмечать часы, пересекающие порог Сначала спросить: впервые применять новое правило распределения по времени суток к действующей клиентской кампании Никогда не делать: менять коэффициенты ставок в клиентском аккаунте без предварительного прохождения критериев проверяющего механизма и одобрения Тома Обрати внимание на назначение примера: он не раздувает документ общими шаблонными фразами («обеспечь высокое качество», «следуй лучшим практикам»). Каждая строка — конкретное решение, которое иначе было бы принято молча и неверно. Именно в этом настоящая работа всех трёх слоёв вместе. --- Источник: prompts.chat. Текст: CC0 1.0 Universal. Русская версия: Kvantora.