visualize-data

Скилл visualize-data от OpenAI рассматривает количественный график как доказательство конкретного вывода, а не как декоративную картинку. Он предназначен для создания, пересмотра и проверки визуализаций в ответе, отчёте, записке, презентации, dashboard, notebook, widget или HTML-артефакте. Перед выбором формы нужно сформулировать аналитический вопрос и одно предложение с главным выводом, определить, что именно сравнивает читатель, и указать контекст, без которого график может ввести в заблуждение. Если существующая диаграмма привлекательна, но слабо подтверждает тезис, её следует переделать; если она технически верна, но плохо читается, её нужно упростить и проверить в реальном окружении. Главное правило выбора — начинать с отношения в данных. Для временного ряда подходит line, когда важна форма движения; для сравнения категорий — bar, для ранжирования — компактный leaderboard или ranked bar, для распределения — histogram или box plot, для взаимосвязи двух числовых показателей — scatter, для матрицы — heatmap, для аддитивного перехода от начального значения к конечному — waterfall, а для последовательного отсева — funnel. Pie допустима только как вариант для грубой оценки части целого при небольшом числе сегментов. Внутри одной семьи лучше сначала менять вариант, например переходить от line к small multiples или от bar к dot/lollipop, чем изобретать новый тип без аналитической необходимости. Скилл задаёт минимальную проверку достаточности данных. Для графиков тренда по умолчанию следует стремиться к 8–12 временным точкам; если их меньше, можно запросить более мелкий интервал или расширить период, а при невозможности честнее использовать KPI, таблицу или сравнение отдельных периодов. Для scatter рекомендуется примерно 12–20 осмысленных наблюдений; меньше восьми обычно означает, что нужна таблица, bar, dot или подписанные отдельные точки. Все точки должны иметь одинаковый уровень детализации, общий период, фильтры, знаменатель и единицы измерения. При необходимости нужно сохранить объём, denominator или sample size, чтобы читатель мог оценить надёжность вывода. До реализации составляется компактный chart contract. В него входят аналитический вопрос, вывод, семейство и конкретный вариант, ожидаемое число строк или временных точек, уровень данных, целевая поверхность, запасной вариант при разреженном наборе, политика палитры, способ различать серии без одной только цветовой кодировки, размер контейнера и путь к итоговому артефакту. Таблица, питающая график, должна быть богаче минимальных полей x и y: когда это безопасно, сохраняются даты, ранги, группы, сравниваемые периоды, знаменатели, benchmark и соседние показатели. Это позволяет проверить смысл графика и не превращает визуализацию в непрозрачную картинку. Маршрут доставки зависит от поверхности. В web Work Mode для уже выбранной inline-подачи skill предпочитает нативное отображение, а не MCP chart/table widgets; если это не подходит, нужен воспроизводимый статический fallback. Для HTML-отчёта или dashboard используется упакованный Recharts-путь вместе с fallback на те же данные. Статический Python-рендер уместен, когда явно заказаны Python, файл изображения, notebook или экспорт, а не как универсальная замена нативной поверхности. Для локальных HTML/CSS/SVG/canvas/JavaScript-решений требуется реальная необходимость в локальном рендеринге, интерактивности, offline-переносимости или большом артефакте. Финальный QA проверяет не только наличие marks. Масштаб должен соответствовать сравнению, подписи, ticks, legends и annotations не должны пересекаться или обрезаться, а контейнер должен сохранять читаемость на ноутбуке и мобильном экране. Цвет не является единственным каналом различения: применяются порядок, подписи, тон, открытая заливка, line style или faceting. Рекомендуется заранее выбрать одну палитровую политику, не использовать случайные цвета библиотеки, градиенты, декоративные фоны и лишние guide-lines. Заголовок должен быть понятен поверхности, subtitle — при необходимости содержать единицы, период, когорту, denominator или объём, а финальная проверка должна выполняться в том же отчёте, dashboard, widget или HTML, который увидит читатель. Ограничение скилла в том, что он задаёт метод выбора и качества визуала, но не предоставляет данные автоматически и не подтверждает корректность бизнес-метрики: определения, фильтры, период и источник нужно проверять отдельно.