Analyst Manual: анализ, за который можно поручиться

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

Первый её порыв был таким же, как у тебя: открыть чат и спросить «какую цену ставить?». Ответ пришёл красивый, уверенный и совершенно непроверяемый.

Здесь и начинается пакет @dzhechkov/skills-analyst-manual. Вместо одного ответа он ставит конвейер из трёх фаз, и каждая фаза оставляет после себя документ:

1. Explore — задачу проясняют вопросами и превращают в бриф (01_task_brief.md).
2. Verified Research — исследование с планировщиком GOAP и подписями Ed25519 (02_research_findings.md).
3. Solve — разбор задачи по девяти модулям, включая ТРИЗ (03_solution.md).

Потом идёт сборка: 04_final_summary.md — резюме для того самого комитета.

Слово MANUAL в названии — не украшение. Между фазами конвейер останавливается на контрольной точке и ждёт твоего слова: «ок», «скорректируй X» или «стоп». Он не решает за тебя, куда идти дальше.

Страница пакета на npm: @dzhechkov/skills-analyst-manual, исходники — в публичном репозитории.

Компромисс: конвейер с остановками стоит дороже одного вопроса в чате — и по времени, и по вниманию. Он окупается ровно тогда, когда за ответ придётся отвечать перед кем-то ещё.

Хватит теории — Марго уже открыла терминал, открывай и ты.

Пакет самодостаточен: внутри и оркестратор, и три атомарных скилла, и слэш-команда. Ставить что-то отдельно не нужно.

1. Разверни пакет в проекте: npx @dzhechkov/skills-analyst-manual init — эта команда разворачивает шаблоны в .claude/ текущей директории.
2. Проверь установку: npx @dzhechkov/skills-analyst-manual doctor — проверка здоровья: на месте ли файлы из манифеста и папка скилла analyst-manual-full.
3. Запусти в Claude Code: /analyst-manual цена корпоративного тарифа для enterprise-рынка.

Остальные три команды: update — обновить шаблоны до свежих, list — показать установленные компоненты, remove — снять установку.

Грабли Марго — не повторяй: первый init она запустила в домашней папке. Файлы кладутся относительно текущей директории, поэтому сначала cd в проект, и только потом init.

Приятная деталь: если в проекте уже стоит @dzhechkov/keysarium, установщик это замечает и переиспользует общие .claude/commands и skills — дублей не будет.

💬 Просто попроси. В Claude Code достаточно сказать: «разверни здесь analyst-manual и проверь установку» — ассистент выполнит init, а затем doctor. Марго за первую неделю не набрала руками ни одной команды: она читала их в ответах ассистента и постепенно запомнила сама.

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

«Раз есть фаза с вопросами — значит, меня опять будут допрашивать», — вздохнула Марго. Не обязательно: перед первой фазой стоит гейт ясности задачи.

Гейт делает ровно одну вещь: смотрит на формулировку и решает, есть ли что прояснять.

• Задача ясна — фазу explore пропускают, бриф собирают прямо из запроса, и ты видишь честное уведомление: «⚡ Фаза Explore пропущена — задача достаточно ясна».
• Задача не ясна — идёт полноценная фаза вопросов.

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

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

Компромисс: пропуск экономит три-семь ходов диалога, но переносит ответственность за формулировку на тебя — проверять придётся глазами, на CHECKPOINT 1.

Фаза Explore — не допрос, а адаптивный разбор. Марго ждала двадцати вопросов подряд; на деле правило другое: один вопрос за ход, три-семь ходов, и стоп, как только ясности достаточно.

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

У Марго задача «обосновать цену» — это тип Decision Making, поэтому первыми пойдут критерии, компромиссы, сроки и обратимость решения, а вовсе не «кто ваши пользователи».

Красные флаги, на которые скилл давит специально:

• цель звучит обобщённо («сделать лучше») — за ней почти всегда прячется настоящая;
• ограничений «нет» — обычно значит, что они есть, но не названы;
• критерии успеха размыты («все будут довольны») — цель поедет прямо по ходу работы.

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

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

Марго решила, что порядок вопросов — дело вкуса. Не дело вкуса: у него есть логика, и каждый следующий шаг сужает то, что осталось выяснять.

1. Настоящая цель — идёт первой, потому что вскрывает больше всего: заявленная цель часто оказывается средством для другой.
2. Ограничения — вторыми: они сужают пространство решений, и половина вариантов отпадает без обсуждения.
3. Критерии успеха — третьими: они определяют, что вообще значит «готово».
4. Добор недостающего — ресурсы, сроки, аудитория; спрашивают только то, что ещё не прояснилось.

Потом фаза собирает Task Brief: цель, контекст, критерии успеха, ограничения, доступные ресурсы, сроки, ключевые допущения и явное «вне области». И задаёт последний вопрос: «Это отражает то, что тебе нужно? Что добавить или поправить?»

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

Бриф ложится на диск как 01_task_brief.md и становится входом всей второй фазы.

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

Вот сюрприз, которого Марго не ждала: строгость исследования выбирают до исследования, а не после. Режим верификации назначают на CHECKPOINT 1 — вместе с подтверждением брифа.

Режимов три:

• moderate — порог 0.85, ответ на контрольной точке: «ок»;
• strict — порог 0.95, ответ: «режим strict»;
• paranoid — порог 0.99, ответ: «режим paranoid».

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

Остановок всего три: после брифа, после исследования и после решения. На каждой у тебя есть словарь ответов:

| Ответ | Что произойдёт |
|---|---|
| «ок», «продолжай» | следующая фаза |
| «режим strict» / «режим paranoid» | сменить порог (на CHECKPOINT 1) |
| «скорректируй X» | поправить артефакт |
| «исследуй глубже X» | доисследовать (на CHECKPOINT 2) |
| «повысь confidence для X» | искать ещё источники (на CHECKPOINT 2) |
| «альтернатива для X» | другое решение (на CHECKPOINT 3) |
| «стоп» | пауза с сохранением |

Заметь важное: «повысь confidence для X» существует именно потому, что порог назначают заранее. Точечно поднять планку по одному больному месту можно и на второй остановке — это дешевле, чем переигрывать весь режим.

Компромисс: paranoid даёт самый защищённый отчёт и самый короткий: чем выше порог, тем больше находок отсеется как недостаточно подтверждённые, и часть из них была бы полезной.

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

Подпись Ed25519 даёт происхождение и признак неизменности при закреплённых (pinned) ключах издателей. Она доказывает две вещи: что подписанный текст подписал именно этот закреплённый ключ и что байты после подписи не меняли.

Классов доверия три:

• ISSUER_SIGNED — подпись проверяется закреплённым ключом заявленного издателя. Потолок уверенности 0.95.
• SELF_ATTESTED — подпись самого исследователя: доказывает только то, что запись не меняли после самоподписи. Потолок 0.60.
• UNVERIFIED — неизвестный издатель, отсутствующая привязка ключа, отозванный или несовпавший ключ, битая подпись. Значение 0.0.

Есть отдельное правило, которое ловит самую частую подмену понятий: строка домена сама по себе не даёт доверия никогда. Доверенным издатель становится только через явное сопоставление «издатель → закреплённый открытый ключ».

> ⚠️ Врезка, которую нельзя пропускать. Ed25519 не доказывает, что утверждение верно, не защищает от плагиата и не заменяет обычную оценку источника. Подпись — про происхождение и целостность байтов, а не про правду.

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

Вопрос, на котором Марго споткнулась: подпись сошлась — значит ли это, что источник кто-то открывал?

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

• FETCH_VERIFIED — скрипт выполнил запрос и получил тело с кодом 2xx: известны хеш байтов, статус и дата. Потолок 1.0.
• LISTING_ONLY — ссылку взяли из выдачи, текст принесли руками или запрос не удался: источник через инструмент никто не открывал. Потолок 0.50.
• ASSERTED — сказано по памяти модели, источник не открывали. Про источник не доказано ничего: 0.0.
• Класс отсутствует — факт старше этой оси: доказательство неизвестно, ни утверждено, ни проверено.

Вот та самая опасная комбинация: факт может быть одновременно ISSUER_SIGNED и ASSERTED — криптографически безупречная запись пересказа по памяти. Такое сочетание законно, выразимо и опаснее любого честного «не проверено».

Поэтому FETCH_VERIFIED нельзя объявить о себе самому: его выдаёт только фабрика, требующая запись о реальном запросе — хеш байтов, HTTP-статус и дату. Ручные конструкторы физически не могут его произвести: ограничение живёт в форме интерфейса, а не в дисциплине автора.

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

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

Теория про классы стоит ровно столько, сколько стоит проверка. Поэтому у скилла есть исполняемый гейт отчёта:

python3 scripts/check_report_evidence.py --report 02_research_findings.md --facts facts.json --profile profile.json

Правила, которые он проверяет, короткие:

• утверждения класса ASSERTED не должны появляться в отчёте вообще;
• утверждения LISTING_ONLY допустимы только с видимой пометкой рядом с самим утверждением.

И главное свойство: это код возврата, а не совет. Выход 1 — нарушение. Выход 2 — входные данные не удалось прочитать, и это отдельный, честный исход: гейт, который не смог оценить, ничего не очистил. Молчание не считается разрешением.

Флаг --profile необязателен. Без него часть проверок применимости просто не может отработать, и гейт печатает об этом прямо — «population applicability: NOT CHECKED — no --profile supplied» — вместо того чтобы тихо пройти. Проверки, которым профиль не нужен, срабатывают в любом случае.

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

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

Третья мерка, помимо подписи и доказательства, — тир источника. Он задаёт потолок доверия для целого класса доменов, а не для конкретного текста.

• A — 0.90: органы, выпускающие руководства, ВОЗ, реестры.
• B — 0.80: рецензируемая литература.
• C — 0.60: препринты и регистры исследований.
• D — 0.40: всё остальное, включая любой неизвестный домен.

Посмотри на лестницу в диаграмме и задержись на нижней ступени: неизвестный домен попадает не «мимо шкалы», а в D. У незнакомого сайта есть потолок, и он низкий — это осознанное решение, а не пробел.

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

И отдельно, крупными буквами: тир — это утверждение о классе домена, а не криптографическое утверждение. Марго в черновике написала «источник тира A, значит подписан» — так нельзя. Тир, класс доверия и класс доказательства меряют три разные вещи и не заменяют друг друга.

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

Третья фаза — разбор задачи по девяти модулям: первые принципы, пять «почему», SCQA, теория игр, эффекты второго порядка, противоречия по ТРИЗ, дизайн-мышление, петля OODA и синтез решения.

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

Порядок работы обратный привычному:

1. Сначала ИКР — идеальный конечный результат. Как выглядела бы система, где нужная функция есть, а вредного действия и лишних затрат нет? ИКР формулируют до ограничений — иначе психологическая инерция срежет решение раньше, чем оно появится.
2. Потом называют противоречие. Административное — «нужно X, не знаем как» — сигнал, что разбор не закончен. Техническое — «улучшаем A, ухудшается B». Физическое — «элемент должен быть и A, и не-A».
3. И только потом ищут разрешение — разделением требований во времени, в пространстве, по условию или по уровню системы.

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

Здесь решаешь ты. Правильного ответа, записанного в скилле, нет: сформулируй ИКР для своей задачи и проверь, остаётся ли противоречие после разделения по времени, пространству, условию и уровню.

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

Самое ценное, что производит исследование, — момент, когда вывод оказался неверным. Скилл умеет такие моменты записывать, если в системе есть dz; если его нет, всё работает как раньше и об этом говорится один раз, без обмана.

У Марго такой момент случился на второй день: она отбросила выгодный сегмент, опираясь на цифру из карточки поисковой выдачи, а открытый источник эту цифру не подтвердил. Обидно — но это и есть материал для урока.

Протокол записи — три шага, и первый решает всё:

1. Пиши правило, а не случай. Тест механический: сможешь сформулировать общее правило без конкретного показателя? Если нет — у тебя пока не урок, а находка, и записывать нечего.
2. Перечитай, ища одного человека. Опасны не цифры, а редкое сочетание, узнающая роль, привязка ко времени — их не поймает ни один шаблон, в любом языке.
3. Запиши и отвечай за это. Флаг --confirm-method — твоё утверждение, что шаги 1 и 2 выполнены. Инструмент это не проверяет и не делает вид, что проверяет.

Четыре момента, когда урок точно есть: вывод отозвали; проверка применимости перевернула вывод; преданалитическая деталь объяснила тревожное значение; открытый вопрос закрылся. И отдельно — вспоминай уроки в начале работы, а не в конце.

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

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

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

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

1. 01_task_brief.md — прояснённые цели, ограничения, критерии успеха.
2. 02_research_findings.md — находки с цепочкой цитирования и подписями.
3. 03_solution.md — стратегия с разрешёнными противоречиями по ТРИЗ.
4. 04_final_summary.md — резюме для руководителя и следующие шаги.

Каждый документ выкладывается в двух форматах: .md для работы и .docx для тех, кто читает документы, а не репозитории.

Перед сборкой конвейер проверяет себя по короткому списку готовности:

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

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

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