kai-data-dashboard - Data To Dashboard Handoff
Turn existing Kai artifacts into a dashboard spec, data contract, or lightweight static dashboard. This skill is a companion surface. It should not replace analytics setup, audit analysis, or outbound strategy.
Use /kai-analytics when the user needs a tracking plan or attribution model. Use /kai-html-presentation when the user needs a client-ready audit deck. Use this skill when the data already exists and needs to become a dashboard-ready operator surface.
Phase 0: Identify The Source
Accept these inputs:
workspace/sdr-operator/<package-slug>/- Any folder with
kai-data.json, audit-data.json, _data-sources.md, or _data-gaps.md
- CSV exports from CRM, ESP, sequencer, ads, analytics, or sales tools
- Markdown reports with source-backed findings
- User-provided metrics and targets
If there is no source folder or file, ask for it. Do not fabricate sample data unless the output is explicitly labeled internal_demo.
Phase 1: Load Provenance
Before designing the dashboard:
- Read
_data-sources.md, _data-gaps.md, and available JSON/CSV files.
- Declare data mode:
sales_external, onboarding_connected, user_provided, or internal_demo.
- List unsupported fields as gaps.
- Do not add numbers that are not present in the source.
For audit folders, run:
python scripts/quality_gates/audit_provenance_lint.py <source-folder> --audit-dir
Phase 2: Choose Dashboard Type
Pick the dashboard type from the source and request:
| Type |
Best Fit |
Primary View |
sdr_operator_room |
SDR package, lead ledger, reply data |
Pipeline state, source quality, next actions |
marketing_ops |
Campaign, content, SEO, ad, lifecycle data |
Channel performance and bottlenecks |
executive_scorecard |
Monthly/weekly report |
KPIs, decisions, risks, next steps |
audit_delivery |
Audit folder |
Findings, scorecards, fixes, data gaps |
connector_health |
API sync or integration data |
Source freshness, failures, missing credentials |
Default to sdr_operator_room when the source is from /kai-sdr-operator.
Phase 3: Produce Dashboard Artifacts
Write output to:
<source-folder>/dashboard/
Required files:
dashboard-spec.md
metrics-dictionary.md
data-contract.json
source-map.md
data-gaps.md
Optional file when the user asks for a usable static artifact:
index.html
Do not build a full frontend app unless the user asks for implementation. For app builds, hand the spec to the relevant frontend skill or repository code.
Dashboard Spec Requirements
Each dashboard spec must include:
- Audience: executive, operator, SDR, marketer, client, founder, or analyst.
- Jobs to be done.
- Metric definitions with exact formulas.
- Data source per metric.
- Refresh cadence and freshness warning.
- Widgets, filters, drilldowns, empty states, and error states.
- Alert thresholds with source or hypothesis label.
- Permissions and sensitive-data handling.
- Handoff notes for frontend, BI, or static HTML build.
For SDR dashboards, include:
- Status counts by
sourced, enriched, approved_for_copy, queued, sent, replied, meeting_booked, disqualified, suppressed, and blocked.
- Source quality table.
- Fit score distribution.
- Next-action queue.
- Reply triage categories.
- Suppression, bounce, opt-out, and complaint warnings.
- Data gaps that block live outreach.
Static HTML Rules
If writing index.html:
- Keep it single-file unless the user requests app integration.
- Use tables for dense operator data.
- Use restrained styling, readable status colors, and responsive layouts.
- Keep critical numbers visible as text, not only canvas or images.
- Include a source footer or source drawer.
- Include empty states for missing metrics.
- Do not hide gaps. Show them as a first-class panel.
Quality Gates
Before handoff:
- Confirm every number has a source, retrieval date, or
internal_demo label.
- Confirm every metric has a formula or definition.
- Confirm
_data-gaps.md or data-gaps.md is represented.
- Confirm no placeholder text remains.
- Confirm sensitive fields are either excluded, masked, or explicitly approved.
- If HTML is produced, check desktop and mobile readability.
Output Summary
Final response should include:
- Dashboard folder path.
- Dashboard type.
- Files produced.
- Data gaps.
- Whether a static HTML dashboard was built or only specified.
1---2name: kai-data-dashboard3description: Convert Kai workflow data, CSV exports, audit folders, SDR package outputs, and marketing reports into dashboard-ready specs or lightweight static dashboards. Use when "data dashboard", "operator dashboard", "operator room", "HTML operators room", "sales dashboard", "SDR dashboard", "turn this data into a dashboard", "dashboard handoff", "visualize Kai data", or any request to package sourced marketing, sales, audit, or SDR data for a dashboard or presentation surface.4---5
6# kai-data-dashboard - Data To Dashboard Handoff
7
8Turn existing Kai artifacts into a dashboard spec, data contract, or lightweight static dashboard. This skill is a companion surface. It should not replace analytics setup, audit analysis, or outbound strategy.
9
10Use `/kai-analytics` when the user needs a tracking plan or attribution model. Use `/kai-html-presentation` when the user needs a client-ready audit deck. Use this skill when the data already exists and needs to become a dashboard-ready operator surface.
11
12## Phase 0: Identify The Source
13
14Accept these inputs:
15
16- `workspace/sdr-operator/<package-slug>/`
17- Any folder with `kai-data.json`, `audit-data.json`, `_data-sources.md`, or `_data-gaps.md`
18- CSV exports from CRM, ESP, sequencer, ads, analytics, or sales tools
19- Markdown reports with source-backed findings
20- User-provided metrics and targets
21
22If there is no source folder or file, ask for it. Do not fabricate sample data unless the output is explicitly labeled `internal_demo`.
23
24## Phase 1: Load Provenance
25
26Before designing the dashboard:
27
281. Read `_data-sources.md`, `_data-gaps.md`, and available JSON/CSV files.
292. Declare data mode: `sales_external`, `onboarding_connected`, `user_provided`, or `internal_demo`.
303. List unsupported fields as gaps.
314. Do not add numbers that are not present in the source.
32
33For audit folders, run:
34
35```bash
36python scripts/quality_gates/audit_provenance_lint.py <source-folder> --audit-dir
37```
38
39## Phase 2: Choose Dashboard Type
40
41Pick the dashboard type from the source and request:
42
43| Type | Best Fit | Primary View |
44|---|---|---|
45| `sdr_operator_room` | SDR package, lead ledger, reply data | Pipeline state, source quality, next actions |
46| `marketing_ops` | Campaign, content, SEO, ad, lifecycle data | Channel performance and bottlenecks |
47| `executive_scorecard` | Monthly/weekly report | KPIs, decisions, risks, next steps |
48| `audit_delivery` | Audit folder | Findings, scorecards, fixes, data gaps |
49| `connector_health` | API sync or integration data | Source freshness, failures, missing credentials |
50
51Default to `sdr_operator_room` when the source is from `/kai-sdr-operator`.
52
53## Phase 3: Produce Dashboard Artifacts
54
55Write output to:
56
57```text
58<source-folder>/dashboard/
59```
60
61Required files:
62
63```text
64dashboard-spec.md
65metrics-dictionary.md
66data-contract.json
67source-map.md
68data-gaps.md
69```
70
71Optional file when the user asks for a usable static artifact:
72
73```text
74index.html
75```
76
77Do not build a full frontend app unless the user asks for implementation. For app builds, hand the spec to the relevant frontend skill or repository code.
78
79## Dashboard Spec Requirements
80
81Each dashboard spec must include:
82
83- Audience: executive, operator, SDR, marketer, client, founder, or analyst.
84- Jobs to be done.
85- Metric definitions with exact formulas.
86- Data source per metric.
87- Refresh cadence and freshness warning.
88- Widgets, filters, drilldowns, empty states, and error states.
89- Alert thresholds with source or hypothesis label.
90- Permissions and sensitive-data handling.
91- Handoff notes for frontend, BI, or static HTML build.
92
93For SDR dashboards, include:
94
95- Status counts by `sourced`, `enriched`, `approved_for_copy`, `queued`, `sent`, `replied`, `meeting_booked`, `disqualified`, `suppressed`, and `blocked`.
96- Source quality table.
97- Fit score distribution.
98- Next-action queue.
99- Reply triage categories.
100- Suppression, bounce, opt-out, and complaint warnings.
101- Data gaps that block live outreach.
102
103## Static HTML Rules
104
105If writing `index.html`:
106
107- Keep it single-file unless the user requests app integration.
108- Use tables for dense operator data.
109- Use restrained styling, readable status colors, and responsive layouts.
110- Keep critical numbers visible as text, not only canvas or images.
111- Include a source footer or source drawer.
112- Include empty states for missing metrics.
113- Do not hide gaps. Show them as a first-class panel.
114
115## Quality Gates
116
117Before handoff:
118
1191. Confirm every number has a source, retrieval date, or `internal_demo` label.
1202. Confirm every metric has a formula or definition.
1213. Confirm `_data-gaps.md` or `data-gaps.md` is represented.
1224. Confirm no placeholder text remains.
1235. Confirm sensitive fields are either excluded, masked, or explicitly approved.
1246. If HTML is produced, check desktop and mobile readability.
125
126## Output Summary
127
128Final response should include:
129
130- Dashboard folder path.
131- Dashboard type.
132- Files produced.
133- Data gaps.
134- Whether a static HTML dashboard was built or only specified.
majiayu000