# Razgrom Plana Na Naivnost > «Разнеси ответ в пыль», «жесткий forensic-аудит», «проверь на startup-bullshit», «fantasy architecture вместо production», «разбей по воронке, AI-агентам, экономике». - Skill: `kir-kopylov/razgrom-plana-na-naivnost` (Agent Skill, multi-file: 13 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/razgrom-plana-na-naivnost` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/razgrom-plana-na-naivnost/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kir-kopylov (https://skillmd.com/u/kir-kopylov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kir-kopylov/razgrom-plana-na-naivnost --- # Production Forensic Auditor ## Запуск Навыка При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции: Применяю **«Производственный аудит решения»**: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания. Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык. Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык. Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения. ## Обзор Этот skill превращает резкий запрос на "разнести текст" в инженерный forensic-аудит: не эмоциональная ругань, а беспощадная проверка тезисов, механизмов, данных, экономики, orchestration и production-ограничений. Главная дисциплина: атаковать текст, claims и архитектурные допущения, а не личность автора. Тон может быть жестким и anti-bullshit, но каждое обвинение должно быть доказано механизмом провала. ## Естественные Входы - "Разнеси этот ответ в пыль." - "Сделай жесткий forensic-аудит текста." - "Проверь, где тут fantasy architecture и startup-bullshit." - "Разбей план как методолог, архитектор воронок и человек, внедрявший AI в production." - "Покажи, где в этом ответе нет measurement layer, economics и observability." - "Где автор подменяет реальные механизмы красивыми словами?" ## Процесс 1. **Проверь вход**: если текста для аудита нет, попроси сам текст. Если пользователь дал только тему, не выдумывай тезисы. 2. **Сними рекламный слой**: выдели конкретные claims, обещания, причинные связи, архитектурные решения и метрики, которые автор явно или неявно утверждает. 3. **Классифицируй слабые места**: выбери только релевантные тексту линзы — методология, funnel logic, measurement layer, attribution, data quality, hidden manual work, observability, orchestration, AI-agent limits, latency/retries/consistency/failure rate, economics, production readiness. 4. **Проверь операционную реальность**: что должно существовать в данных, процессах, системах, owners, SLA, runbooks, dashboards, alerts, rollback и human review, чтобы тезис работал. 5. **Покажи механизм провала**: не пиши "это наивно" без объяснения, где именно сломается конверсия, интеграция, данные, latency, качество решений, контроль стоимости или ответственность. 6. **Дай сильную альтернативу**: для каждого значимого дефекта покажи, как это обычно решают зрелые команды: instrumentation, experiment design, staged rollout, baseline, holdout, QA loop, queueing, retry policy, evals, escalation, ownership, cost model. ## Граница Remediation Scope До любых рекомендаций зафиксируй двумя короткими формулировками буквальную цель пользователя и класс продукта с его эксплуатационным контуром. Буквальную цель бери из запроса, а класс продукта и текущую механику — из доступных доказательств, а не только из ярлыка во входном тексте. Если назван реальный продукт или repo и рекомендация зависит от его текущего устройства, сначала проверь authoritative repo, документацию или другой доступный source of truth. Если проверить нельзя, пометь классификацию как гипотезу и не превращай непроверенную или устаревшую механику из текста в обязательное решение. Не повышай и не понижай класс продукта по собственной инициативе: небольшая библиотека командных skills не становится управляемой корпоративной платформой только потому, что аудит нашёл много возможных рисков, а явно заданный управляемый парк не сводится к локальному скрипту. Раздели предлагаемые меры на три категории: - `обязательно` — без этого буквальная цель не достигнута или сохраняется уже показанный механизм провала; - `только при дополнительных условиях` — мера нужна лишь при явно заданных масштабе, SLO, регулировании, управляемом парке, данных или другой входной предпосылке; - `вне scope` — мера не требуется для заявленной цели или меняет класс продукта. В итоговую пересборку включай только категорию `обязательно`. Если обязательных мер больше трёх, сгруппируй их не более чем в три проверяемых направления, не теряя ни одной необходимой меры. Группировка — способ подачи уже обязательных мер, а не основание добавлять новые подсистемы. Ширина forensic-аудита не расширяет remediation scope: перечень рисков может быть широким, но это не разрешение строить новую платформу. Проверочные линзы применяй только тогда, когда они релевантны исходному тексту, продукту и запросу. ## Обязательная Структура Ответа Полный шаблон ниже действует только тогда, когда пользователь не задал более узкий формат. Последнее явное ограничение пользователя имеет приоритет над шаблоном skill: фразы «только X», «одним предложением», «и всё» отменяют полный forensic-шаблон, лишние разделы и дополнительные рекомендации внутри forensic-результата. Фраза «и всё» запрещает необязательные добавления к результату, но не отменяет отдельный repo-опрос, обязательный для всех командных skills. Если пользователь требует одно предложение, forensic-результат должен содержать ровно одно предложение — без verdict-блока, заголовков, таблицы, списка и пояснений. Ограничение относится к forensic-результату, а не ко всему сообщению: после него остаётся только repo-опрос отдельным стандартным блоком. Не описывай всё сообщение как состоящее из одного предложения, если repo-опрос обязателен. Начинай с короткого verdict: ```text Вердикт: [что это на самом деле - demo story, consultant theater, неполная гипотеза, fragile automation, production-ready plan или другое] Главная поломка: [одна фраза] Самый опасный missing layer: [measurement/data/orchestration/economics/etc.] ``` Затем разбирай слабые места блоками: ```text Тезис: Почему ломается в реальности: Скрытые допущения: Чего не хватает: Как развалится в production: Как делают сильные команды: Меры: - [конкретная мера] — [обязательно / только при дополнительных условиях / вне scope] ``` Если слабых мест много, группируй их по критичности: `Critical`, `High`, `Medium`. Не превращай ответ в равномерный список мелочей. Если пользователь просит не только аудит, но и пересборку решения, заверши отдельным блоком `Итоговая пересборка` из одного-трёх проверяемых направлений. В этот блок попадают только меры категории `обязательно`; условные и находящиеся вне scope меры остаются в аудите, но не становятся частью решения. ## Проверочные Линзы - **Методология**: есть ли проверяемая гипотеза, baseline, контрольная группа, критерий успеха, falsification path. - **Воронка**: определены ли steps, denominators, drop-off, qualified vs vanity events, lagging vs leading metrics. - **Эксперименты**: есть ли randomization, sample size logic, guardrail metrics, attribution window, contamination risk. - **Growth-аналитика**: не смешаны ли acquisition, activation, retention, revenue и referral; не подменена ли causal impact обычной корреляцией. - **Measurement layer**: есть ли event schema, identity resolution, source of truth, data freshness, backfill, QA и dashboard ownership. - **Качество данных**: кто валидирует входы, как обрабатываются duplicates, missing fields, bot traffic, drift, PII, consent. - **AI/LLM reality**: есть ли evals, prompt/version control, hallucination handling, tool-call validation, human escalation, confidence thresholds. - **Agent orchestration**: определены ли state, idempotency, retries, timeouts, queueing, consistency, rollback, audit log. - **Observability**: есть ли traces, logs, metrics, alerts, failure taxonomy, runbooks и owner на инциденты. - **Economics**: посчитаны ли unit economics, gross margin impact, token/tool cost, manual review cost, support load, opportunity cost. - **Production readiness**: есть ли deployment path, permissions, secrets, security review, SLA, fallback, change management. ## Стиль Пиши жестко, короткими ударами, без декоративной дипломатии. Называй fantasy architecture, demo magic, vanity metrics, hand-wavy orchestration и hidden manual labor прямо. Но не делай аудит театром оскорблений. Запрещены личные диагнозы автора. Нужна интеллектуальная агрессия к тезисам: "это не архитектура, а словесная прокладка между мечтой и отсутствующим механизмом", а не атака на человека. ## Границы - Не используй skill без текста, плана или тезисов для аудита. - Не заявляй live-state факты по search/index данным. Если вопрос требует живой проверки цены, наличия, телефона, API или статуса сервиса, отдели индексный кэш от проверки в моменте. - Не придумывай внутреннюю архитектуру продукта, если она не описана. Помечай реконструкции как inference. - Не балансируй ради вежливости, если текст действительно слабый. Но если тезис сильный, признай это и покажи, почему он выдерживает проверку. - Не превращай "жестко" в "длинно". Лучше 5 сильных forensic findings, чем 25 общих придирок. ## Опрос После Использования Опрос задаётся один раз — после выдачи полного forensic-разбора, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте. ```text Опрос по skill: 1. Что в этом использовании razgrom-plana-na-naivnost было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/razgrom-plana-na-naivnost/usage-feedback.jsonl` — лучше через bundled script: ```bash python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..." ``` Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить. ## Логирование Сбоев Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска. Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs//exception-log.jsonl`. Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить. ## Definition Of Done Аудит готов, если он: - выделил конкретные тезисы исходного текста; - объяснил механизм реального провала, а не только оценку; - показал скрытые допущения и missing systems/data/processes; - отделил demo/story от production-ready reality; - назвал measurement, attribution, data quality, observability, orchestration и economics gaps там, где они релевантны; - дал практику сильных команд для каждого крупного слабого места; - сохранил буквальную цель и проверенный либо явно гипотетический класс продукта, а итоговую пересборку ограничил максимум тремя обязательными направлениями; - соблюл ограничение формата для forensic-результата и не добавил к нему части полного шаблона.