build-report

Build Report — это Agent Skill для создания законченных аналитических отчётов для руководителей, продуктовых, бизнес- и технических команд. Он нужен тогда, когда результатом должен стать долговечный отчёт с понятным выводом, доказательными находками, таблицами или визуализациями, оговорками и контекстом источников. Skill отделяет такой отчёт от dashboard, ноутбука, временного вывода в чате и локального URL: выбранная поверхность отчёта должна существовать как артефакт, а если это невозможно, нужно зафиксировать конкретный blocker. Работа начинается с определения reporting job: вопроса пользователя, решения, которому должен помочь отчёт, аудитории, периода, точки сравнения и критерия полезности. Затем выбирается одна аудитория и формируется каркас истории. В нём должны быть вопрос, ответ, определения метрики, когорта, знаменатель, временное окно и база сравнения, выводы по сегментам или драйверам, проверки чувствительности там, где сравнение может быть неожиданным, ограничения, следующий шаг и открытый вопрос. Такой порядок заставляет отделить решение от оформления и заранее выявить отсутствие данных, неоднозначный знаменатель или неподтверждённую причинную интерпретацию. Для reader-facing поверхности skill требует видимый заголовок и executive summary перед доказательными разделами. Каждый крупный раздел должен иметь собственный заголовок, утверждение, подтверждающие данные, интерпретацию и практическое следствие. Числа нужно объяснять простым языком и связывать с периодом, когортой, фильтрами и базой сравнения. Визуализация не должна быть декоративной: ей нужен конкретный вопрос, соседний абзац с главным выводом и понятное объяснение того, как читать график или таблицу. Если расширенный график не поддерживается данными, его следует заменить более честной таблицей, KPI или кратким сравнением, а не добавлять форму ради вида. Отдельная часть workflow посвящена доказательствам и источникам. Важные утверждения должны опираться на сохранённые данные, код, запросы, документы или проверенные артефакты. Для HTML-поверхности числовые значения получают источник через единый tooltip-паттерн; для графика источник должен быть доступен через отдельную видимую affordance, а статическое представление должно оставаться читаемым без скриптов. Исходный SQL, пути к временным файлам и технические идентификаторы относятся к source metadata, если пользователь не просит показать методику. Визуализации проходят отдельный маршрут выбора графика и финальную проверку контекста, чтобы не скрывать смысл в заголовке или легенде. Skill также задаёт ограничения на доставку. Для каждого запуска выбирается ровно один режим: на Codex desktop по умолчанию используется MCP app, а HTML подходит для переносимого артефакта или поверхностей, где MCP-рендеринг недоступен. Режим нельзя смешивать без отдельного запроса. При исправлении уже существующего отчёта нужно сохранять его разделы, визуализации, таблицы, источники, caveats и порядок чтения, меняя только затронутую часть. Перед handoff проверяется именно отрендеренный результат: он должен отвечать на вопрос сверху, иметь видимые заголовки, связывать выводы с доказательствами и сохранять оговорки. Практический сценарий — аналитический отчёт, который должен пережить исходный разговор и быть понятен следующему читателю. Ограничение — этот skill не создаёт факты и не исправляет отсутствие источника: если нет надёжных данных, поддержки для требуемого среза или возможности доставить выбранную поверхность, результатом должен быть честный blocker. Он также не превращает любой набор графиков в отчёт: без ответа, интерпретации, ограничений и следующего действия артефакт остаётся недостаточным.