Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

dashboard-specification

Estrellas3

Forks3

Actualizado14 de junio de 2026 a las 05:06

Define complete requirements for a data dashboard before development begins. Use when a new dashboard is requested, when an existing dashboard needs redesign, or when stakeholder alignment is needed before building.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

ryudkiss-hue

ryudkiss-hue/nyc_data

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Especialistas en gestión de proyectosOperaciones empresariales y financieras·SOC 13-1082

Explorador de archivos

8 archivos

SKILL.md

readonly

name	dashboard-specification
description	Define complete requirements for a data dashboard before development begins. Use when a new dashboard is requested, when an existing dashboard needs redesign, or when stakeholder alignment is needed before building.

When to use

A stakeholder requests a new dashboard and you need to capture requirements clearly
An existing dashboard is misaligned with user needs and needs redesign
Multiple stakeholders have conflicting ideas about what the dashboard should show
A developer needs a clear spec before building

Process

Define dashboard purpose — articulate the single sentence: "This dashboard answers [question] for [audience] who need to [decision or action]." If this can't be expressed in one sentence, the scope needs narrowing.
Profile the users — for each user type, document: visit frequency, primary questions, key decisions, and technical comfort. Different audiences typically warrant separate dashboards rather than extra filters.
Define the metric hierarchy — organise into: primary KPIs (top of page, max 3–5), secondary metrics (supporting context), and detail breakdowns. Flag scope creep if total metrics exceed 10–12.
Design information architecture — follow hero → trends → breakdowns → details pattern; place most important content top-left; define sections and their purpose
Specify interactivity — list every filter, drill-down, and toggle; justify each one (adds decision value vs. adds complexity)
Document data requirements — for each metric: source table, calculation, refresh frequency, and any known data quality issues

Inputs the skill needs

Required: stakeholder's business question or use case
Required: intended users and their roles
Optional: existing dashboard or report to build on
Optional: refresh frequency requirements and data source constraints

Output

references/dashboard_design_principles.md — layout, hierarchy, and interactivity guidelines
references/dashboard_requirements_guide.md — stakeholder question frameworks
assets/dashboard_spec_template.md (filled) — complete spec: purpose, users, metrics, layout, interactivity, data sources, and success criteria

Más de este repositorio

mismo repositorio

data-catalog-entry

ryudkiss-hue/nyc_data

Create standardized metadata for data assets. Use when documenting new datasets, building data catalogs, improving data discoverability, or creating data dictionaries for teams.

2026-06-173

analysis-planning

ryudkiss-hue/nyc_data

Structure analysis approach before starting work. Use when receiving new analysis requests, breaking down complex questions into steps, or planning iterative analysis workflows.

2026-06-173

data-quality-audit

ryudkiss-hue/nyc_data

Comprehensive data quality assessment against business rules, schema constraints, and freshness expectations. Activate when validating production pipelines, onboarding new data sources, or when stakeholders report data quality concerns.

2026-06-143

segmentation-analysis

ryudkiss-hue/nyc_data

Identify distinct customer or user segments based on behavior, attributes, or value. Activate when you need to answer "who are our best customers?" or "what distinct groups exist in our user base?" and need data-driven profiles to inform strategy.

2026-06-143

visualization-builder

ryudkiss-hue/nyc_data

Create effective, publication-ready data visualizations. Use when choosing chart types, designing presentation visuals, building dashboard charts, or applying visual design best practices to data output.

2026-06-143

methodology-explainer

ryudkiss-hue/nyc_data

Create a clear, transparent explanation of analytical methodology for any audience level. Activate when you deliver findings that require the audience to trust the method — A/B tests, attribution models, forecasts, statistical analyses, or anything where "how did you get that?" is a likely question.

2026-06-143

name	dashboard-specification
description	Define complete requirements for a data dashboard before development begins. Use when a new dashboard is requested, when an existing dashboard needs redesign, or when stakeholder alignment is needed before building.

When to use

A stakeholder requests a new dashboard and you need to capture requirements clearly
An existing dashboard is misaligned with user needs and needs redesign
Multiple stakeholders have conflicting ideas about what the dashboard should show
A developer needs a clear spec before building

Process

Define dashboard purpose — articulate the single sentence: "This dashboard answers [question] for [audience] who need to [decision or action]." If this can't be expressed in one sentence, the scope needs narrowing.
Profile the users — for each user type, document: visit frequency, primary questions, key decisions, and technical comfort. Different audiences typically warrant separate dashboards rather than extra filters.
Define the metric hierarchy — organise into: primary KPIs (top of page, max 3–5), secondary metrics (supporting context), and detail breakdowns. Flag scope creep if total metrics exceed 10–12.
Design information architecture — follow hero → trends → breakdowns → details pattern; place most important content top-left; define sections and their purpose
Specify interactivity — list every filter, drill-down, and toggle; justify each one (adds decision value vs. adds complexity)
Document data requirements — for each metric: source table, calculation, refresh frequency, and any known data quality issues

Inputs the skill needs

Required: stakeholder's business question or use case
Required: intended users and their roles
Optional: existing dashboard or report to build on
Optional: refresh frequency requirements and data source constraints

Output

references/dashboard_design_principles.md — layout, hierarchy, and interactivity guidelines
references/dashboard_requirements_guide.md — stakeholder question frameworks
assets/dashboard_spec_template.md (filled) — complete spec: purpose, users, metrics, layout, interactivity, data sources, and success criteria