build-dashboard

build-dashboard — скилл для создания дашбордов, которые помогают мониторить показатели, находить причины изменений и принимать операционные решения. Он отделяет дашборд от отчёта, notebook-only анализа и временного сообщения в чате: результат должен быть summary-first, chart-led, сканируемым и пригодным для регулярного использования. В центре workflow находятся краткий бриф, определения метрик, источники, фильтры, логика раскладки, QA и понятная передача результата владельцу. Перед построением нужно понять аудиторию, вопрос, который она решает, объект измерения, нужный диапазон данных, частоту обновления, ограничения доступа и поверхность доставки. Если недостающий ввод способен изменить рекомендацию или структуру дашборда, источник советует уточнить его; в остальных случаях можно зафиксировать разумное допущение. Доставка выбирается по контексту: подключённый BI-инструмент, портативный HTML, MCP artifact или явно запрошенный Streamlit. Это не требование использовать один стек, а способ не смешивать дизайн метрик с механикой конкретной платформы. Раздел source discovery требует изучить все потенциально относящиеся к задаче источники, а semantic layer использовать как карту, а не как единственную границу поиска. Для каждого структурированного источника нужно заново проверить схемы, таблицы, представления, модели и метрики. При пересечениях сравниваются владелец, свежесть, определение, grain и покрытие; конфликт нельзя скрывать молча. Если обязательный источник недоступен, скилл требует остановить этот путь и не выдавать fallback, sample или scratch-данные за реальные. Для устойчивого дашборда предпочтительны проверенные компактные агрегаты и явно записанный query/source path. Модель метрик строится от решения, а не от фиксированного набора карточек. Источник предлагает рассмотреть релевантные семейства reach, volume, value, quality, depth, mix, movement, risk и constraints. Из них выбираются hero metrics для основного экрана, diagnostic metrics для движения и разрезов, guardrails для интерпретации и detail metrics для поиска. Метрики должны использовать согласованные даты, фильтры, измерения и определения, чтобы карточки, графики и таблицы сходились. Нельзя добавлять независимые вторичные числа только ради заполнения привычного количества KPI-карточек. Визуальная композиция идёт от summary к detail: сначала статус или главный outcome, затем движение во времени, затем разрезы, объясняющие изменение, и только после этого lookup-таблица. Глобальные фильтры нужны лишь тогда, когда действительно меняют общий вид; лучше несколько сильных контролов, чем плотная панель настроек. Выбор графика должен отвечать конкретному вопросу и оставаться совместимым с типом сравнения. Перед handoff проверяются открытие артефакта, работа фильтров, рендеринг графиков, сверка чисел, управление доступом, производительность, свежесть и заметность ограничений. Скилл задаёт проверяемый процесс доверия к дашборду, но не придумывает бизнес-значения, цели или источники, которых нет в исходных данных.