Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

dashboard-specification

Estrelas3

Forks3

Atualizado14 de junho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

ryudkiss-hue

ryudkiss-hue/nyc_data

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Especialistas em gestão de projetosNegócios e Operações Financeiras·SOC 13-1082

Explorador de arquivos

8 arquivos

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

Mais deste repositório

mesmo repositório

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