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:

Вердикт: [что это на самом деле - demo story, consultant theater, неполная гипотеза, fragile automation, production-ready plan или другое]
Главная поломка: [одна фраза]
Самый опасный missing layer: [measurement/data/orchestration/economics/etc.]

Затем разбирай слабые места блоками:

Тезис:
Почему ломается в реальности:
Скрытые допущения:
Чего не хватает:
Как развалится в 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-разбора, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании razgrom-plana-na-naivnost было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/razgrom-plana-na-naivnost/usage-feedback.jsonl — лучше через bundled script:

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/<skill-name>/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-результата и не добавил к нему части полного шаблона.