Семнадцать развилок: навыки ai-apps для проектировщика агентов

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

Пакет @dzhechkov/skills-book-ai-apps существует ровно для этого момента. Это 17 навыков моментов решения. Навык (skill) — инструкция для AI-ассистента, которая подгружается, когда твоя задача попадает под её описание. А «момент решения» — конкретная развилка проектирования: «нужен ли агент вообще», «один агент или несколько», «можно ли выкатывать эту версию». Каждый навык включается на своей развилке и даёт критерии, таблицы компромиссов, факты с привязкой к странице и антипаттерны.

Откуда навыки взялись: их машинно выделили из книги Майкла Альбады «Building Applications with AI Agents» (русский перевод) конвейером book-knowledge-digitizer. Важно понимать, ЧТО именно лежит в пакете:

• не текст книги — она остаётся у правообладателей, исходный корпус не распространяется;
• а единицы знания (Knowledge Units, KU) — собственные переформулировки методики с привязкой к странице, и навыки, построенные на них;
• граница проверяется механически: гейт на совпадения нашёл 0 нецитированных дословных отрывков длиной от 8 слов против исходника.

Что это меняет для Тимура: вместо «прочитай 350 страниц и вспомни нужное в среду» ассистент сам применяет методику книги в тот момент, когда Тимур описывает задачу.

Компромисс: ты получаешь методику в точке решения, но не саму книгу — за формулой или примером кода всё равно придётся сходить в источник. И пакет честно помечен trust_tier: 1: машинная выжимка, не выверенная человеком по каждой цитируемой странице (об этом — последняя секция).

💬 Просто попроси. Ассистенту не надо называть имя навыка. Тимур написал: «нам нужен агент для обработки заявок в поддержку, или хватит детерминированного конвейера?» — и нужный навык включился сам. Как именно это происходит — в четвёртой секции.

Хватит вводных — Тимур открыл терминал, открывай и ты.

Пакет опубликован на npm: страница @dzhechkov/skills-book-ai-apps на npmjs.com; исходники лежат в публичном зеркале на GitHub. Ставь версию 0.2.9 или новее: у 0.2.1 и 0.2.2 подпись не совпадает с содержимым README (они помечены как устаревшие), содержимое навыков при этом никогда не было под вопросом.

Самый короткий путь — одна команда, где dz install ставит пакет по имени:

1. dz install @dzhechkov/skills-book-ai-apps --target claude-code — dz сам скачает пакет с npm и разложит навыки под платформу.

Хочешь видеть каждый шаг — явная двухшаговая форма (измерено при установке из архива в чистый проект, вывод ниже — дословный):

1. npm install @dzhechkov/skills-book-ai-apps --save-dev — пакет приезжает в node_modules.
2. dz init --target claude-code --skills-dir node_modules/@dzhechkov/skills-book-ai-apps --project . → 17 skill(s), 51 file(s) written, 0 skipped.

Дальше — проверка, что навыки зарегистрировались, а не просто легли на диск. Это два разных уровня:

• dz verify --skills-dir node_modules/@dzhechkov/skills-book-ai-apps --target claude-code → 17/17 skill(s) valid — структурная проверка файлов (уровень L1);
• dz skills-verify --dir . --expect <17 идентификаторов> --strict → PASS — all 17 expected skill(s) are registered — запускает живую сессию и читает её список навыков (уровень L2). Файл на диске ещё не значит, что ассистент его видит.

Грабли Тимура — не повторяй: он сначала подал dz install путь к архиву .tgz. Команда принимает имя npm-пакета и ищет его в node_modules/<имя>; на путь она падает с ошибкой package not found (код выхода 1).

Компромисс: одна команда dz install быстрее, но прячет два шага; двухшаговая форма длиннее, зато ты видишь, что именно легло в проект и сколько файлов записано.

💬 Просто попроси. «Поставь пакет навыков ai-apps для Claude Code» → ассистент выполнит dz install; «проверь, что все 17 навыков зарегистрировались» → dz skills-verify --strict. Тимур команды не набирал — только читал их в ответах ассистента.

Тимур открыл README и увидел таблицу на 17 строк. Первая реакция — «я это не запомню». Не надо запоминать: надо понять один принцип, по которому таблица построена.

Принцип: навык владеет ровно одним решением. У каждого навыка есть описание-триггер, и в нём две половины: «ЧТО я решаю» и «чего я НЕ решаю — иди к соседу». Например, aiagents-single-vs-multi-agent решает, сколько агентов и как они координируются, но явно отказывается от транспорта и брокеров — это владение aiagents-multi-agent-infrastructure. Такие отказы — не занудство: они и есть причина, по которой два похожих навыка не перехватывают запросы друг у друга.

Навыки пришли двумя волнами (измерено по sources.json): 8 в первой, 9 во второй. Вторая волна закрыла все тематические кластеры, которые нашёл этап свёртки книги; третьей волны не будет — остались только 18 словарных KU, из которых навык не вырастает.

Как читать карту — по группам решений:

1. Ещё до кода: нужен ли агент и какая модель (agent-fit-and-model-choice), один агент или несколько (single-vs-multi-agent).
2. Форма и начинка: архетип управления и топология (orchestration-and-planning), транспорт и брокер под готовую форму (multi-agent-infrastructure), контракт инструментов и их выбор (tool-design-and-selection), знания против памяти (knowledge-and-memory), что попадает в окно ЭТОГО вызова (context-engineering), нужно ли обучение и какого класса (learning-strategy).
3. Проверка и выпуск: построить оценку (evaluation-design), тестировать недетерминированный слой (probabilistic-behaviour-checks), можно ли выкатывать и сколько трафика (release-gates-and-rollout).
4. Эксплуатация: телеметрия и дрейф (observability-and-drift), цикл улучшений после релиза (improvement-loops), уровень автономии и эскалация к человеку (human-in-the-loop).
5. Люди и компания: поверхность взаимодействия (agent-ux), полномочия и аудит внутри организации (org-adoption-and-governance), защита (agent-security).

Каждый навык внутри устроен одинаково: выход, когда применять и когда нет, критерии решения с номерами KU, ключевые факты и формулы, антипаттерны, смежные решения, источник, самопроверка, примеры. Открой любой SKILL.md — и ты уже знаешь, где что искать.

Компромисс: узкое владение делает навыки предсказуемыми, но реальная задача Тимура почти всегда цепляет два-три навыка подряд — цепочки передач между ними разберём в шестой секции.

💬 Просто попроси. «Что решает навык про наблюдаемость и чего он не решает?» → ассистент прочитает описание aiagents-observability-and-drift и перескажет обе половины. Тимур так прошёлся по всем семнадцати за один вечер.

Тимур ждал, что придётся писать что-то вроде «/aiagents-agent-fit-and-model-choice». Не пришлось. Он описал задачу обычными словами — и навык включился сам. Это и есть маршрутизация по описанию задачи: ассистент сравнивает твою фразу с описаниями-триггерами всех установленных навыков и подгружает подходящий.

Насколько это надёжно — измерено, а не обещано. Гейт маршрутизации (в пакете он называется CP3.5) на полном каталоге из 17 навыков показал:

• 97,7 % срабатываний — 216 из 221 положительных запросов подняли нужный навык;
• 1,8 % перехвата — доля случаев, когда вместо нужного навыка сработал сосед;
• 0 из 152 нарушений на «жёстких отрицательных» запросах — фразах, на которые ни один навык срабатывать не должен;
• пороги гейта: не меньше 80 % срабатываний и не больше 10 % перехвата.

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

Отсюда практическое правило:

1. Опиши задачу так, как рассказал бы коллеге: «у агента 30 инструментов, он стал вызывать не те — делить на агентов или чинить выбор?».
2. Фраза «используй нужные скиллы из набора ai-apps для решения задачи: …» тоже работает, но нужна редко — описания уже несут триггеры.
3. Если хочешь поставить один навык под одно решение: dz init --target claude-code --select aiagents-agent-security.

Что гейт доказывает, а что нет — ключевая честность пакета. Он доказывает, что навыки *срабатывают на правильных запросах*. Он НЕ доказывает, что каждое число внутри навыка верно; за это отвечает отдельная проверка KU (о ней — в последней секции).

Компромисс: маршрутизация по описанию избавляет от заучивания имён, но 2,3 % запросов навык всё же пропустил — если ассистент явно не применил методику, назови навык по имени.

💬 Просто попроси. Именно так: попроси. Тимур за всю неделю ни разу не написал идентификатор навыка — он писал задачи.

Вернёмся к понедельнику. Продакт сказал «сделаем агента», и Тимур описал задачу ассистенту. Сработал aiagents-agent-fit-and-model-choice — и первое, что он сделал, это НЕ согласился с постановкой. Он предложил лестницу из четырёх ступеней и правило: поднимайся только настолько, насколько заставляет задача.

Прежде чем читать дальше, реши за Тимура сам. Заявки в поддержку приходят свободным текстом на почту; в ответ надо понять намерение, найти ответ в базе знаний, написать черновик и при необходимости передать человеку. Какая ступень? Запомни ответ — сейчас сверим.

Ступени, снизу вверх:

1. Простой код — когда ввод полностью предсказуем и каждый исход описывается заранее, нужна миллисекундная задержка или жёстко регулируемая область. Навык хранит формулировку книги с её силой: при таких условиях обычный код «почти всегда лучше фундаментальной модели» — почти, не всегда.
2. Детерминированный рабочий поток — логика укладывается в конечную последовательность шагов и ветвлений, и ты заранее знаешь, где вмешивается человек. Пример из навыка: счета в трёх известных форматах, разводимые по парсерам.
3. Чат-бот / RAG — нужны ответы на вопросы по базе знаний. Жёсткий потолок: RAG находит, но не решает о дальнейших действиях — не заводит тикет, не назначает звонок.
4. Автономный агент — ввод нельзя описать заранее, план строится в несколько шагов и перестраивается по промежуточным итогам, или система должна улучшаться по обратной связи.

Четыре фактора, которые двигают выбор: изменчивость ввода, сложность рассуждения, ограничения по производительности и соответствию, бремя сопровождения. Числовых порогов навык не даёт и честно об этом пишет — критерии качественные.

А на воротах перед четвёртой ступенью стоят пять вопросов, на которые надо ответить письменно: ввод неструктурирован? нужно многошаговое планирование с перестройкой? хватит ли пользователям выдачи документов, или система обязана сама решать и действовать? должна ли она улучшаться почти без людей? готовы ли вы мириться с задержкой и стоимостью модели? Третий вопрос разделяет RAG и агента; пятый — тот, который команды пропускают и за который платят потом.

Сверь свой выбор. Тимур получил четвёртую ступень — но не потому что «продакт так сказал», а потому что ввод свободный, а система обязана действовать (черновик, эскалация). Если ты выбрал третью — посмотри на третий вопрос ворот: одной выдачи документов здесь недостаточно.

Компромисс: лестница экономит месяцы на переусложнённой системе, но требует честно ответить на пять вопросов — а ответ «нет» на четвёртой ступени иногда неприятен продакту.

💬 Просто попроси. «Нам нужен агент для X, или хватит детерминированного конвейера?» — этой фразы достаточно, чтобы навык провёл тебя по лестнице и воротам.

Агент одобрен. Теперь Тимур должен выбрать инструменты, память и топологию — и сделать это до того, как архитектура застынет. Здесь впервые проявляется главная особенность пакета: одна реальная задача — это цепочка передач между навыками, и порядок в ней не случаен. Каждый навык, закончив, передаёт следующему ограничение, которое сам наложил.

Сценарий из README «спроектировать агента с нуля» проходит так:

1. aiagents-tool-design-and-selection — контракт инструмента: имя и описание (то, что модель реально читает), строгие схемы входа и выхода, контракт ошибок, наименьшие привилегии для инструментов с состоянием, локальный / API / MCP-тип, режим выбора инструмента на вызов, лестница выбора «стандартный → семантический → иерархический». Передаёт дальше: сколько инструментов и как они сгруппированы.
2. aiagents-knowledge-and-memory — знания (RAG) против памяти (собственная история агента), деление на краткосрочную и долгосрочную, какое хранилище получает каждый слой, и как далеко подниматься по лестнице от скользящего окна до графа знаний. Передаёт дальше: какие хранилища и какой объём координации они требуют.
3. aiagents-single-vs-multi-agent — порог перехода, цена перехода (координация, коммуникация, токены, конфликты), шесть принципов добавления агента и тест бережливости, схема координации.

Есть и вторая цепочка — для потока, который перерос свою форму (сценарий 7 в README):

• aiagents-orchestration-and-planning сначала решает форму: архетип (рефлекс, ReAct, планировщик-исполнитель, декомпозиция, рефлексия перед необратимыми операциями), режим исполнения (один вызов, параллель, цепочка, граф) и пределы глубины;
• aiagents-multi-agent-infrastructure берёт форму как данность и подбирает несущее: транспорт (внутрипроцессные вызовы → протокол A2A → брокер), сам брокер, среду исполнения (монолит, шина, акторы, движок рабочих потоков), где живёт общее состояние.

Ключевое: ни один навык не пересматривает решение соседа. Инфраструктурный навык не спорит о форме; навык памяти не спорит о контракте инструментов. Именно поэтому порядок важен: перепутай — и следующему навыку нечего принимать на вход.

Компромисс: цепочка даёт согласованную архитектуру, но требует пройти три-пять навыков подряд, а не один; попытка «спросить всё сразу» размывает ограничения, которые навыки передают друг другу.

💬 Просто попроси. «Проектирую агента для анализа логов: какие инструменты дать, как он их выберет, нужна ли память, когда это станет мультиагенткой?» — одна фраза, и Тимур получил цепочку из трёх навыков в правильном порядке.

Через месяц агент Тимура вырос: 30 инструментов. И стал промахиваться — вызывать возврат вместо отмены, искать не там. Коллега предложил очевидное: «разделим на несколько агентов». Тимур описал ситуацию ассистенту — и получил два навыка, которые вместе держат одно правило: дешёвое лечение раньше дорогого.

Открытый вопрос, на который нет одного ответа, — зато есть порядок проверки. Что ты сделал бы первым: разделил на агентов, переписал описания инструментов или включил семантический выбор? Подумай, потом читай.

Сначала aiagents-tool-design-and-selection исчерпывает лестницу ВНУТРИ одного агента:

1. Стандартный выбор — все описания идут модели, она выбирает. Просто, без инфраструктуры; плохо масштабируется, когда инструментов много.
2. Семантический выбор — описания инструментов превращаются в векторы и индексируются; поиск сужает кандидатов, модель делает финальный выбор. Навык называет это самым распространённым образцом и рекомендует для большинства сценариев; цена — похожие описания сталкиваются.
3. Иерархический выбор — инструменты сгруппированы, сначала выбирается группа, потом инструмент внутри. Точность куплена задержкой и трудом на поддержание групп; держи для действительно большого набора.

Числового порога «мало / много» навык не даёт — границу ты находишь опытным путём, и навык говорит об этом прямо.

Только если лестница исчерпана, слово берёт aiagents-single-vs-multi-agent — и первым делом применяет тест бережливости к рефлексу «добавим агента»: проверь, не берут ли эту задачу уже существующие узлы, напрямую или после расширения. Причина названа: неоправданный рост числа агентов усложняет сопровождение и создаёт узкие места. Три системных цены перехода — сложность координации, стоимость коммуникации и расход токенов, конфликты между агентами — ты платишь всегда, а не «если не повезёт».

Что Тимур сделал. Переписал описания (модель читает именно их), включил семантический выбор — промахи ушли. Второй агент не понадобился. Если ты выбрал «разделить» — не ошибка, а дорогой путь: ты заплатил бы координацией за то, что лечится индексом описаний.

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

💬 Просто попроси. «У агента 30 инструментов, он стал вызывать не те. Делить на агентов или чинить выбор?» — оба навыка включаются в правильном порядке.

«Как оценивать нашего агента?» — спросил Тимур, когда текущая «оценка» состояла из того, что кто-то прокликивал три промпта. Ответ пакета оказался неожиданным: это не один вопрос, а три, и у каждого свой навык. Три навыка оценки с разными границами — и каждый явно отказывается от чужой работы.

1. Построить прибор — aiagents-evaluation-design. Метрики выводятся из измеримых целей (количественные, качественные, семантическая близость). Оценочный набор — живая спецификация, а не одноразовый файл. Каждый кейс имеет форму «состояние на входе + диалог + ожидаемое конечное состояние»: список ожидаемых вызовов инструментов с параметрами и фразы, которые обязан содержать финальный ответ. Планировщик оценивается тремя числами: полнота по инструментам (не потерял ли вызовы), точность по инструментам (не добавил ли лишних), точность параметров. Навык честно указывает ограничения этих формул: метрики над множеством имён, порядок вызовов не оценивается, параметры сравниваются строгим равенством.

2. Проверить вероятностный слой — aiagents-probabilistic-behaviour-checks. Там, где один и тот же ввод законно даёт разный вывод, сравнивать байты бессмысленно. Вместо этого — инварианты поведения (обязательный шаг, который агент делает при любой формулировке), связность длинного диалога (без самопротиворечий и ухода от темы), устойчивость к неожиданному вводу с критерием «уточни — деградируй — эскалируй», а не «упади или выдумай». И правило триажа: неудачный результат перезапускается три-пять раз; частота сбоев выше 80 % — систематическая ошибка, иначе — законный разброс. Навык отмечает, какие из порогов книга вводит словом «например» — их калибруй на своих данных.

3. Решить о выпуске — aiagents-release-gates-and-rollout. Может ли эта версия вообще выкатываться и сколько живого трафика ей дать — следующая секция целиком об этом.

А живой дрейф в проде — четвёртый владелец, aiagents-observability-and-drift (секция 10). Навык оценки прямо перечисляет, кому что отдаёт: гейты и канарейку — выпуску, дрейф — наблюдаемости, недетерминизм — вероятностным проверкам.

Компромисс: три навыка вместо одного — это три границы, которые надо помнить; зато «оценка на глазок» становится невозможной: у каждого вопроса есть владелец с критериями.

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

Новая версия агента Тимура — переписанный промпт и новый инструмент — прошла оценку локально. Продакт спрашивает: «выкатываем?». «Выглядело нормально в трёх ручных прогонах» — не решение о выпуске, и aiagents-release-gates-and-rollout начинает с этого.

Сначала гейт готовности. Готовность — целостная оценка, что система будет работать безопасно и стабильно в реальной среде; прохождение тестов — не то же самое. Гейт — автоматическая или человеческая проверка, которая блокирует продвижение, когда требование не выполнено: регрессия на оценочном наборе, отсутствие явного одобрения после пилота. Навык различает две формы гейта: закрывающийся (требование не выполнено → стоп) и эскалирующий (результат неоднозначен → решает человек). Число из примера книги — «не меньше 95 % полноты выбора инструмента на потоках возврата и отмены» — навык приводит как один возможный критерий для одного агента, а не как всеобщую планку; свою цифру бери из прибора, который построил aiagents-evaluation-design.

Потом — механизм выдачи трафика. Тимур ждал единой инструкции; навык честен: книга упорядочивает только первый шаг («процесс часто начинается со staging / RC»), остальные механизмы перечисляет рядом, не ранжируя. Поэтому лестница выкатки от staging до канарейки ниже — это порядок по доле живых пользователей, которые видят результат, а не закон из книги:

1. Staging / RC — изолированная копия прода; пользователей ноль. Предел: контролируемая среда скрывает, как ведут себя реальные люди.
2. Теневой режим — новая версия работает параллельно на живом вводе, её вывод пишется в журнал и никогда не доходит до пользователя. Предел: не даёт сигнала о реакции человека; тонкий сдвиг характера взаимодействия тень не увидит — за ним книга отправляет к A/B.
3. Канарейка — новая версия открыта малой доле реальных пользователей, в книге это 1–5 % трафика, с меткой версии, без которой сравнение «канарейка против базы» невозможно. Откат немедленный и дешёвый.
4. A/B на живом трафике — 50/50 между контролем и вариантом с четырьмя условиями постановки и ловушкой долгоживущего состояния агента (или адаптивный байесовский бандит).
5. Полная выкатка — сине-зелёная, поэтапная или пилотное расширение; и заранее написанный путь отката.

Что бы канарейка ни подняла, это уходит в aiagents-improvement-loops — секция 10.

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

💬 Просто попроси. «Готова новая версия. Можно ли её выкатывать, сколько трафика дать и что делать с тем, что вылезет на канарейке?» — навык проведёт по гейту и лестнице.

Через два месяца после выкатки Тимур получил самый неприятный тикет: «агент стал хуже». Частота ошибок ровная, в логах ничего. Два навыка — aiagents-observability-and-drift и aiagents-improvement-loops — дают ему три теста дрейфа и четыре шага RCA.

Остановись и подумай о своём агенте: что ты сегодня измеряешь, кроме частоты ошибок? Если ответ «ничего» — эта секция про тебя.

Что мерить. Навык раскладывает метрики по уровням — инфраструктура, рабочий поток, качество вывода, обратная связь пользователей — и для каждой метрики называет действие, которое она обязана вызвать. Метрика без действия — это шум на дашборде.

Три теста дрейфа — и почему их нельзя сливать в один балл. Дрейф — это когда распределение того, что приходит агенту или выходит из него, уехало от исторической базы. Навык даёт три разных инструмента, и каждый отвечает на свой вопрос:

1. Колмогоров — Смирнов — для непрерывных величин: длина запроса, задержка, числовые метрики.
2. KL-дивергенция — для распределения токенов на входе: смена языка пользователей, новая терминология. Она несимметрична: KL(P‖Q) ≠ KL(Q‖P), где P — история, Q — текущие данные.
3. PSI (индекс стабильности выборки) — для категорий и групп: доли категорий использования инструментов вроде «возврат / отмена / изменение».

Объединить три в один «балл дрейфа» — значит выбросить ровно ту информацию, которая говорит, ЧТО сдвинулось. И навык фиксирует две несогласованности источника, которые ты обязан знать до того, как вшить пороги: PSI в одной главе — триггер вмешательства при > 0,1, а в другой полоса 0,1–0,25 — «только наблюдать»; у KL — «< 0,2 — ожидаемое отклонение» и «> 0,5 — концептуальный сдвиг», а середина не определена. Выбери одно чтение сознательно и запиши, какое.

Четыре шага RCA. Обнаружение — не диагноз. Когда детектор поднял проблему, aiagents-improvement-loops ведёт по цепочке: трассировка рабочего потока (восстановить цепочку решений и вызовов) → локализация сбоя (какой компонент) → распознавание закономерностей (единичный случай или повторяющийся) → оценка последствий (частота и критичность). Выход RCA — список возможностей улучшения, а не виновный: сбои агентных систем часто вообще не технические — размытая постановка, изменившиеся ожидания пользователей.

Дальше — рычаги исправления (уточнение промпта с его гейтом проверки, автоматическая оптимизация промпта, доработка инструментов) и один общий бэклог, приоритизированный по пяти осям: частота, критичность, осуществимость, соответствие стратегии, риск повторения.

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

💬 Просто попроси. «Агент деградировал, ошибок в логах нет — что мониторить и как поймать дрейф?» — Тимур получил и уровни метрик, и три теста с их чтениями.

В навыках Тимур постоянно встречал пометки вроде «KU: ch08-p193-ku08» и «см. источник». Куда они ведут? На этом месте пакет раскрывает вторую половину себя: 17 навыков — это поведение, а за ними стоят 223 единицы знания (KU) — это знание, и оно тоже приезжает с установкой.

Три уровня, на которых «см. источник» разрешается (пакет объявляет их честно в sources.json):

1. references/ внутри пакета — всегда. Каждый навык везёт свои KU целиком в <навык>/references/knowledge-units.md; всего 207 ссылок по пакету, каждая с привязкой к странице и меткой проверки (190 «true», 17 «partial»). Работает на любой машине и любой платформе — файл уже лежит рядом.
2. Brain — после одной команды. Brain — это твоё личное кросс-проектное хранилище знаний в ~/.dz/brain. Пакет везёт срез brain/ai-apps.sqlite — все 223 KU канона. Команда dz brain add --from-pack @dzhechkov/skills-book-ai-apps загружает срез к тебе: это идемпотентная вставка-обновление по ключу (книга, ku_id, версия корпуса), так что повторная установка заменяет, а не дублирует; векторы пересчитываются локально.
3. Корпус страниц — только у владельца, в рабочем пространстве оцифровки. Не распространяется.

После загрузки Тимур спрашивает brain из ЛЮБОГО проекта, не только из того, где ставил пакет:

• dz brain query "один агент или несколько" --source ai-apps → [ai-apps гл.2 с.57-208] (decision-framework) Один агент или несколько: критерии выбора и цена каждого варианта;
• dz brain primer ai-apps — карточка возможностей: гистограмма типов KU и главные моменты решения;
• dz brain ground "<вопрос>" — для размытых, естественных вопросов.

Грабли Тимура — не повторяй: он набрал dz recall --books --book ai-apps и получил 0 KU hit(s). Это проектное хранилище (.dz/memory/books.sqlite текущего проекта), а не brain; из свежей папки оно пусто, тогда как dz brain query из той же папки вернул хиты (измерено 2026-08-19). Кросс-проектные глаголы — dz brain query / ground / primer.

Второе ограничение: срез лексический — поиск по префиксам через И, без морфологии и синонимов. Длинный вопрос естественным языком может дать 0, а его ключевые слова — хиты. Размытые вопросы веди через dz brain ground.

Компромисс: brain делает знание книги доступным в любом проекте одной командой, но лексический поиск требует думать ключевыми словами; за точной страницей всё равно идёшь в references/.

💬 Просто попроси. «Загрузи знания из пакета ai-apps в мой brain» → dz brain add --from-pack …; «что книга говорит про выбор между одним и несколькими агентами?» → dz brain query.

Коллега Тимура работает в GitHub Copilot и попросил «поставь мне тот же пакет». Тимур почти сделал это — и вовремя открыл раздел README про Copilot. Там его ждал сюрприз с конкретной ценой.

На Copilot каждый файл инструкций загружается на каждый запрос. Нет ленивой подгрузки: всё, что установлено, резидентно всегда. Теперь размер. Семнадцать тел SKILL.md вместе весят 763 183 байта / 727 835 символов (измерено: cat aiagents-*/SKILL.md | wc -c; папки references/ на Copilot не загружаются и не считаются). При константе оцифровщика 2,1 символа на токен это оценка ≈ 347 тысяч токенов на запрос, если поставить все 17 — оценка из измеренного размера, а не измеренный счётчик токенов. Вторая волна примерно удвоила резидентную стоимость: у восьми тел версии 0.1.0 было 354 846 байт.

Это и есть цена постоянно загруженных тел навыков — и пакет её не прячет:

• самое маленькое тело — 29 187 байт (aiagents-context-engineering), самое большое — 63 936 байт (aiagents-agent-security);
• пять тел превышают порог харнеса в 50 000 байт на тело: безопасность, инфраструктура мультиагенток, наблюдаемость, петли улучшений, внедрение в организации;
• и это ровно те же пять навыков, что получили оценку B в эталонном тесте dz benchmark: все 12 навыков с оценкой A набирают 18/20, все 5 с оценкой B — 17/20, разница в одной проверке. Размер тела — весь разрыв между этим пакетом и «сплошь A», и он показан открыто.

Отсюда правило: на Copilot ставь только навыки под текущую работу, не пакет целиком — --select <имя> из четвёртой секции. На Claude Code пакет целиком в порядке: резидентно только описание каждого навыка, тело подгружается при срабатывании.

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

💬 Просто попроси. «Поставь коллеге на Copilot только навык про безопасность агентов» → ассистент выполнит dz init --target copilot --select aiagents-agent-security и не притащит остальные 16 тел.

Последняя секция — ты в роли Тимура, и решения принимаешь сам. Он пишет проектный документ и хочет вписать в него числа из навыков: «канарейка 1–5 %», «PSI > 0,1», «95 % полноты выбора инструмента». Можно ли? Ответ пакета — не «да» и не «нет», а уровень доверия trust_tier 1 и список того, что доказано, а что нет.

Что доказано измерением (гейты 2026-08-18/19, на содержимом версии 0.2.2; 0.2.9 везёт то же содержимое, гейты не перегонялись):

1. Верификация KU. Канон из 223 KU проверен кросс-семейным судьёй (gpt-5.6-sol): 202 «true», 21 «partial», 0 «false». Копии в references/ по 207 ссылкам: 190 «true», 17 «partial». «Partial» означает, что страница поддерживает утверждение не полностью — и такие KU помечены, а не выброшены.
2. IP / совпадения. Гейт по 8-словным окнам: 0 нецитированных дословных отрывков — и на сборке, и повторно перед самой публикацией на точных байтах, которые ушли на npm.
3. Маршрутизация. 97,7 % срабатываний, 1,8 % перехвата, 0/152 на жёстких отрицательных.
4. Эталонный тест и регистрация. dz benchmark: 89 % (301/340), 12 A / 5 B; dz verify 17/17; живая сессия — все 17 зарегистрированы.

Что НЕ доказано — и пакет говорит это первым предложением README: навыки машинно выделены и не проверены человеком по цитируемым страницам. Гейт маршрутизации доказывает, что навык срабатывает на нужном запросе, а не что каждое его число верно. Отсюда правило: сверяй со страницей, прежде чем полагаться на конкретное число.

Как выглядит честный навык изнутри — Тимур увидел это в трёх местах:

• пороги, которые книга вводит словом «например» (оценка > 0,8, KL < 0,2), навык помечает как примеры для калибровки, а «3–5 повторов, > 80 %» — как утверждение без оговорки;
• когда две страницы одной главы дают PSI два разных чтения, навык не сглаживает — он записывает обе и требует выбрать сознательно;
• когда в примере книги номер заказа в ожидании не совпадает с номером в данных, навык пишет: «копируй форму, не это значение».

Что Тимур вписал в документ. «Канарейка 1–5 % [книга, с. 271-272]; порог 95 % — пример книги для её агента поддержки, наш порог — из нашего оценочного набора; PSI-порог: выбираем чтение 0,1–0,25 = наблюдать, записано здесь». Числа со страницей, примеры — как примеры, двоящиеся пороги — с выбором.

Компромисс: trust_tier 1 честно снижает силу каждого числа — зато ты точно знаешь, где граница между «измерено гейтом» и «сверь сам». Пакет — указатель на методику, не замена книге; хочешь текста — купи книгу.

💬 Просто попроси. «Из какой страницы это число и насколько ему можно верить?» — ассистент откроет references/knowledge-units.md навыка и покажет KU с меткой проверки.