data-vizard 0.0.1 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/plugins/marketplace.json +20 -0
- package/.claude-plugin/marketplace.json +30 -0
- package/CHANGELOG.md +18 -0
- package/LICENSE +21 -0
- package/README.md +132 -0
- package/bin/data-vizard.js +361 -1
- package/package.json +32 -10
- package/plugins/data-vizard/.claude-plugin/plugin.json +20 -0
- package/plugins/data-vizard/.codex-plugin/plugin.json +43 -0
- package/plugins/data-vizard/README.md +187 -0
- package/plugins/data-vizard/assets/icon.png +0 -0
- package/plugins/data-vizard/assets/logo-dark.png +0 -0
- package/plugins/data-vizard/assets/logo.png +0 -0
- package/plugins/data-vizard/assets/screenshot-output.png +0 -0
- package/plugins/data-vizard/assets/screenshot-workflow.png +0 -0
- package/plugins/data-vizard/assets/wizard-chart-logo-source.png +0 -0
- package/plugins/data-vizard/skills/data-analyst/SKILL.md +63 -0
- package/plugins/data-vizard/skills/data-analyst/agents/openai.yaml +4 -0
- package/plugins/data-vizard/skills/data-analyst/references/analysis-playbook.md +30 -0
- package/plugins/data-vizard/skills/data-curator/SKILL.md +67 -0
- package/plugins/data-vizard/skills/data-curator/agents/openai.yaml +4 -0
- package/plugins/data-vizard/skills/data-curator/references/dataset-intake-checklist.md +34 -0
- package/plugins/data-vizard/skills/data-vizard/SKILL.md +137 -0
- package/plugins/data-vizard/skills/data-vizard/agents/openai.yaml +4 -0
- package/plugins/data-vizard/skills/data-vizard/references/workflow-map.md +60 -0
- package/plugins/data-vizard/skills/designer/SKILL.md +107 -0
- package/plugins/data-vizard/skills/designer/agents/openai.yaml +4 -0
- package/plugins/data-vizard/skills/designer/assets/html-starter/index.html +95 -0
- package/plugins/data-vizard/skills/designer/references/style-directions.md +40 -0
- package/plugins/data-vizard/skills/narrator/SKILL.md +62 -0
- package/plugins/data-vizard/skills/narrator/agents/openai.yaml +4 -0
- package/plugins/data-vizard/skills/narrator/references/anti-ai-tropes.md +43 -0
- package/plugins/data-vizard/skills/narrator/references/story-structures.md +29 -0
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "data-vizard",
|
|
3
|
+
"version": "0.1.1",
|
|
4
|
+
"description": "A staged data visualization workshop for moving from dataset intake to analysis, narrative, design, and an HTML artifact.",
|
|
5
|
+
"author": {
|
|
6
|
+
"name": "Trine"
|
|
7
|
+
},
|
|
8
|
+
"license": "MIT",
|
|
9
|
+
"keywords": [
|
|
10
|
+
"data-visualization",
|
|
11
|
+
"storytelling",
|
|
12
|
+
"csv",
|
|
13
|
+
"analysis",
|
|
14
|
+
"html"
|
|
15
|
+
],
|
|
16
|
+
"skills": "./skills/",
|
|
17
|
+
"interface": {
|
|
18
|
+
"displayName": "Data Vizard",
|
|
19
|
+
"shortDescription": "Guide data visualization projects from dataset to HTML story.",
|
|
20
|
+
"longDescription": "Data Vizard bundles five Codex skills for a complete data visualization workflow: orchestration, data curation, exploratory analysis, narrative framing, and HTML visualization design.",
|
|
21
|
+
"developerName": "Trine",
|
|
22
|
+
"category": "Productivity",
|
|
23
|
+
"capabilities": [
|
|
24
|
+
"Interactive",
|
|
25
|
+
"Write",
|
|
26
|
+
"Data Analysis",
|
|
27
|
+
"Visualization"
|
|
28
|
+
],
|
|
29
|
+
"brandColor": "#5B35D5",
|
|
30
|
+
"composerIcon": "./assets/icon.png",
|
|
31
|
+
"logo": "./assets/logo.png",
|
|
32
|
+
"logoDark": "./assets/logo-dark.png",
|
|
33
|
+
"screenshots": [
|
|
34
|
+
"./assets/screenshot-workflow.png",
|
|
35
|
+
"./assets/screenshot-output.png"
|
|
36
|
+
],
|
|
37
|
+
"defaultPrompt": [
|
|
38
|
+
"Use Data Vizard to build a visualization from this CSV.",
|
|
39
|
+
"Guide me from dataset intake to an HTML data story.",
|
|
40
|
+
"Help me choose the best story direction for this dataset."
|
|
41
|
+
]
|
|
42
|
+
}
|
|
43
|
+
}
|
|
@@ -0,0 +1,187 @@
|
|
|
1
|
+
# Data Vizard Plugin
|
|
2
|
+
|
|
3
|
+
Data Vizard is an agent plugin for staged data visualization work. It bundles skills for dataset intake, curation, exploratory analysis, narrative framing, and HTML visualization design.
|
|
4
|
+
|
|
5
|
+

|
|
6
|
+
|
|
7
|
+
## What This Plugin Provides
|
|
8
|
+
|
|
9
|
+
- `data-vizard:data-vizard` - Orchestrates the full workflow and keeps user decision gates explicit.
|
|
10
|
+
- `data-vizard:data-curator` - Profiles, cleans, reshapes, joins, enriches, and documents datasets.
|
|
11
|
+
- `data-vizard:data-analyst` - Finds patterns, caveats, comparisons, anomalies, and evidence-backed story directions.
|
|
12
|
+
- `data-vizard:narrator` - Turns analysis into audience-facing structure, copy, titles, annotations, and caveats.
|
|
13
|
+
- `data-vizard:designer` - Designs and builds HTML visualization artifacts with chart, layout, accessibility, interaction, and motion guidance.
|
|
14
|
+
|
|
15
|
+
## Install From npm
|
|
16
|
+
|
|
17
|
+
Use the published installer:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
npx data-vizard install
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Equivalent commands:
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
pnpm dlx data-vizard install
|
|
27
|
+
bunx data-vizard install
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
The installer copies this plugin into `~/.data-vizard/marketplace`, writes Codex and Claude Code marketplace files, and attempts to install `data-vizard@data-vizard` with both CLIs when available.
|
|
31
|
+
|
|
32
|
+
## Compatibility
|
|
33
|
+
|
|
34
|
+
| Host | Status | Manifest | Notes |
|
|
35
|
+
| --- | --- | --- | --- |
|
|
36
|
+
| Codex app and CLI | Supported | `.codex-plugin/plugin.json` | Visual plugin metadata, skills, and local marketplace install are supported. Local/workspace plugins can appear through marketplaces or workspace sharing. |
|
|
37
|
+
| Claude Code | Supported | `.claude-plugin/plugin.json` | Uses a separate Claude manifest and marketplace file. Validate with `claude plugin validate`. |
|
|
38
|
+
| npm | Supported | `bin/data-vizard.js` | Ships the plugin, assets, marketplace files, root README, and changelog. |
|
|
39
|
+
|
|
40
|
+
## Development Install From A Fresh Clone
|
|
41
|
+
|
|
42
|
+
Normal installs should use npm. This clone-based path is only for development before a version is published.
|
|
43
|
+
|
|
44
|
+
Prerequisites:
|
|
45
|
+
|
|
46
|
+
- Codex app or Codex CLI with plugin support.
|
|
47
|
+
- Claude Code CLI with plugin support, if installing for Claude Code.
|
|
48
|
+
- This repository cloned locally.
|
|
49
|
+
|
|
50
|
+
From the repository root for Codex:
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
cd /path/to/data-vizard
|
|
54
|
+
codex plugin marketplace add "$(pwd)"
|
|
55
|
+
codex plugin add data-vizard@data-vizard
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
From the repository root for Claude Code:
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
cd /path/to/data-vizard
|
|
62
|
+
claude plugin marketplace add "$(pwd)"
|
|
63
|
+
claude plugin install data-vizard@data-vizard
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
Why this works:
|
|
67
|
+
|
|
68
|
+
- The Codex marketplace definition lives at `.agents/plugins/marketplace.json`.
|
|
69
|
+
- The Claude Code marketplace definition lives at `.claude-plugin/marketplace.json`.
|
|
70
|
+
- Both marketplaces are named `data-vizard`.
|
|
71
|
+
- Both point to the plugin source at `./plugins/data-vizard`.
|
|
72
|
+
|
|
73
|
+
Verify the install:
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
codex plugin marketplace list
|
|
77
|
+
codex plugin list --available --json
|
|
78
|
+
claude plugin list
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
After installing or reinstalling a plugin, start a new Codex thread or Claude Code session so the updated skills are loaded.
|
|
82
|
+
|
|
83
|
+
## Basic Usage
|
|
84
|
+
|
|
85
|
+
In a new Codex thread, invoke the orchestrator:
|
|
86
|
+
|
|
87
|
+
```text
|
|
88
|
+
Use $data-vizard:data-vizard to build a visualization from this CSV.
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
In Claude Code, invoke the orchestrator:
|
|
92
|
+
|
|
93
|
+
```text
|
|
94
|
+
/data-vizard:data-vizard Build a visualization from this CSV.
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
Or call a role skill directly when you already know the stage:
|
|
98
|
+
|
|
99
|
+
```text
|
|
100
|
+
Use $data-vizard:data-curator to profile and clean this dataset.
|
|
101
|
+
Use $data-vizard:data-analyst to find story directions in this curated CSV.
|
|
102
|
+
Use $data-vizard:narrator to turn this analysis into a story brief.
|
|
103
|
+
Use $data-vizard:designer to build the HTML visualization.
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
The orchestrator confirms where project artifacts should live in the active workspace before creating or changing files.
|
|
107
|
+
|
|
108
|
+

|
|
109
|
+
|
|
110
|
+
## Privacy And Data
|
|
111
|
+
|
|
112
|
+
Data Vizard works on files and datasets you provide in the active workspace. The plugin does not add a server, background sync, analytics, or external app connector. Codex and Claude Code host settings still control model access, file permissions, network access, and command approvals.
|
|
113
|
+
|
|
114
|
+
For sensitive datasets, review source rights before importing data, keep private raw files out of commits, and document caveats close to any public-facing claims.
|
|
115
|
+
|
|
116
|
+
## Updating After Pulling Changes
|
|
117
|
+
|
|
118
|
+
After pulling plugin updates:
|
|
119
|
+
|
|
120
|
+
```bash
|
|
121
|
+
cd /path/to/data-vizard
|
|
122
|
+
codex plugin add data-vizard@data-vizard
|
|
123
|
+
claude plugin install data-vizard@data-vizard
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
Then start a new Codex thread or Claude Code session. If Codex or Claude Code still shows an older version, confirm that the plugin manifests under `plugins/data-vizard/` have a new version, then reinstall again.
|
|
127
|
+
|
|
128
|
+
## Release Checks
|
|
129
|
+
|
|
130
|
+
Local package checks:
|
|
131
|
+
|
|
132
|
+
```bash
|
|
133
|
+
NPM_CONFIG_CACHE=/tmp/data-vizard-npm-cache npm pack --dry-run --json
|
|
134
|
+
node bin/data-vizard.js install --dry-run --root /tmp/data-vizard-local-smoke
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
Published-package smoke test:
|
|
138
|
+
|
|
139
|
+
```bash
|
|
140
|
+
cd /tmp
|
|
141
|
+
NPM_CONFIG_CACHE=/tmp/data-vizard-npm-cache npx --yes data-vizard@0.1.1 --version
|
|
142
|
+
NPM_CONFIG_CACHE=/tmp/data-vizard-npm-cache npx --yes data-vizard@0.1.1 install --dry-run --root /tmp/data-vizard-published-smoke
|
|
143
|
+
NPM_CONFIG_CACHE=/tmp/data-vizard-npm-cache npx --yes data-vizard@0.1.1 install --root /tmp/data-vizard-published-stage --no-codex --no-claude
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
Claude Code compatibility check:
|
|
147
|
+
|
|
148
|
+
```bash
|
|
149
|
+
claude plugin validate plugins/data-vizard
|
|
150
|
+
claude plugin marketplace add /tmp/data-vizard-published-stage
|
|
151
|
+
claude plugin install data-vizard@data-vizard --scope local
|
|
152
|
+
claude plugin list
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
## Troubleshooting
|
|
156
|
+
|
|
157
|
+
If Codex says:
|
|
158
|
+
|
|
159
|
+
```text
|
|
160
|
+
plugin `data-vizard` was not found in marketplace `data-vizard`
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
Register the repo marketplace first:
|
|
164
|
+
|
|
165
|
+
```bash
|
|
166
|
+
cd /path/to/data-vizard
|
|
167
|
+
codex plugin marketplace add "$(pwd)"
|
|
168
|
+
codex plugin add data-vizard@data-vizard
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
If `codex` itself fails because it cannot find a native vendor binary, repair the Codex CLI install:
|
|
172
|
+
|
|
173
|
+
```bash
|
|
174
|
+
npm uninstall -g @openai/codex
|
|
175
|
+
npm install -g @openai/codex@latest
|
|
176
|
+
codex --version
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
If optional plugin validation fails with `ModuleNotFoundError: No module named 'yaml'`, use a local validation environment rather than changing system Python:
|
|
180
|
+
|
|
181
|
+
```bash
|
|
182
|
+
python3 -m venv .venv-validator
|
|
183
|
+
.venv-validator/bin/python -m pip install --upgrade pip PyYAML
|
|
184
|
+
.venv-validator/bin/python /path/to/plugin-creator/scripts/validate_plugin.py plugins/data-vizard
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
That validation step is only for development checks; normal plugin installation does not require `PyYAML`.
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: data-analyst
|
|
3
|
+
description: Explore curated datasets to identify patterns, anomalies, comparisons, relationships, uncertainty, and possible visualization story directions. Use when the user needs exploratory data analysis, evidence-backed story candidates, analytical caveats, or requests for additional data from Data Curator before choosing a narrative.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Data Analyst
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Analyze data to discover possible story directions. Do not write the final narrative or choose the final direction; present evidence-backed options for the user to select.
|
|
11
|
+
|
|
12
|
+
## Core Rule
|
|
13
|
+
|
|
14
|
+
Do not decide the final story, exclude plausible analytical directions, or request data enrichment silently. Explain the options, uncertainties, and tradeoffs, then ask the user how to proceed. Ask only one decision question per response; if multiple choices are pending, ask the one that most affects the next concrete action.
|
|
15
|
+
|
|
16
|
+
## Button-Ready Choices
|
|
17
|
+
|
|
18
|
+
Present one analysis direction decision at a time in this strict format:
|
|
19
|
+
|
|
20
|
+
```text
|
|
21
|
+
Choose one:
|
|
22
|
+
A. Short option label - one sentence explaining the tradeoff.
|
|
23
|
+
B. Short option label - one sentence explaining the tradeoff.
|
|
24
|
+
C. Short option label - one sentence explaining the tradeoff.
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Use no more than four options unless the user asks for a broader menu. When useful, make the final option either `D. Combine options - say which candidates to merge.` or `D. Something else - describe the direction to explore.` Stop after presenting story candidates and wait for the user. Do not include a second `Choose one:` block in the same response.
|
|
28
|
+
|
|
29
|
+
## Workflow
|
|
30
|
+
|
|
31
|
+
1. Confirm the analysis brief.
|
|
32
|
+
Ask the single most important missing analysis detail first. Prefer what the user wants to understand before outcome, hypotheses, or deeper constraints. Ask follow-up questions one at a time.
|
|
33
|
+
|
|
34
|
+
2. Inspect the curated data.
|
|
35
|
+
Review schema, units, time period, geography, categories, transformations, and Curator caveats.
|
|
36
|
+
|
|
37
|
+
Prefer curated project data from `data/<project-name>/curated/`. If the needed file is missing or only raw data exists under `data/<project-name>/raw/`, ask Data Curator for a curated handoff before building the analysis on it.
|
|
38
|
+
|
|
39
|
+
3. Explore analytical angles.
|
|
40
|
+
Check distributions, trends, rankings, comparisons, segmentation, correlation, change over time, outliers, missingness, and normalization needs.
|
|
41
|
+
|
|
42
|
+
4. Identify data gaps.
|
|
43
|
+
If the dataset cannot support strong analysis, ask Data Curator for specific improvements such as denominators, benchmarks, longer history, or cleaner categories.
|
|
44
|
+
|
|
45
|
+
5. Generate story candidates.
|
|
46
|
+
Offer multiple possible story variations. Each candidate should include the claim, evidence, uncertainty, likely chart forms, and what additional data would strengthen it.
|
|
47
|
+
|
|
48
|
+
6. Ask the user to choose.
|
|
49
|
+
Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis.
|
|
50
|
+
|
|
51
|
+
7. Handoff to Narrator.
|
|
52
|
+
Provide the chosen insight, supporting evidence, counterpoints, caveats, and suggested sequence of facts.
|
|
53
|
+
|
|
54
|
+
## Boundaries
|
|
55
|
+
|
|
56
|
+
- Do not overclaim causality from correlation.
|
|
57
|
+
- Do not bury uncertainty or data quality problems.
|
|
58
|
+
- Do not choose style, copy tone, or visual identity; hand those choices to Narrator and Designer.
|
|
59
|
+
- Do not fabricate data. If data is missing, ask Curator or the user.
|
|
60
|
+
|
|
61
|
+
## Reference
|
|
62
|
+
|
|
63
|
+
Read `references/analysis-playbook.md` when exploring a dataset or preparing story candidates.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Analysis Playbook
|
|
2
|
+
|
|
3
|
+
## Explore
|
|
4
|
+
|
|
5
|
+
- Distribution: range, skew, concentration, missingness
|
|
6
|
+
- Comparison: groups, categories, geographies, cohorts
|
|
7
|
+
- Time: trend, seasonality, breaks, before-after changes
|
|
8
|
+
- Ranking: leaders, laggards, volatility, movement
|
|
9
|
+
- Relationship: correlation, clustering, segmentation
|
|
10
|
+
- Normalization: per-capita, rates, shares, index values
|
|
11
|
+
- Outliers: extreme values, data errors, meaningful exceptions
|
|
12
|
+
|
|
13
|
+
## Story Candidate Format
|
|
14
|
+
|
|
15
|
+
Use this structure for each candidate:
|
|
16
|
+
|
|
17
|
+
- Working title
|
|
18
|
+
- Claim or question
|
|
19
|
+
- Evidence from the data
|
|
20
|
+
- Why it matters
|
|
21
|
+
- Caveats and uncertainty
|
|
22
|
+
- Suggested chart forms
|
|
23
|
+
- Additional data that would strengthen it
|
|
24
|
+
|
|
25
|
+
## Cautions
|
|
26
|
+
|
|
27
|
+
- Separate correlation from causation.
|
|
28
|
+
- Prefer rates or denominators when comparing differently sized groups.
|
|
29
|
+
- Treat missing data as an analytical fact, not just a cleanup problem.
|
|
30
|
+
- Surface boring-but-important findings if they prevent a misleading story.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: data-curator
|
|
3
|
+
description: Find, evaluate, clean, profile, reshape, join, and supplement datasets for data visualization projects. Use when the user needs help locating data, assessing dataset fitness, preparing messy CSV/XLSX/JSON data, enriching a dataset with external sources, documenting data limitations, or responding to Analyst requests for better data before visualization.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Data Curator
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Prepare trustworthy data for visualization. Work interactively: surface dataset choices, data quality issues, enrichment options, and transformation assumptions before committing to them.
|
|
11
|
+
|
|
12
|
+
## Core Rule
|
|
13
|
+
|
|
14
|
+
Do not choose a dataset, external source, join key, cleaning rule, imputation strategy, or enrichment direction without consulting the user. Present options with tradeoffs, then ask the user to choose. Ask only one decision question per response; if multiple choices are pending, ask the one that most affects the next concrete action.
|
|
15
|
+
|
|
16
|
+
## Button-Ready Choices
|
|
17
|
+
|
|
18
|
+
Present one dataset, cleaning, or enrichment decision at a time in this strict format:
|
|
19
|
+
|
|
20
|
+
```text
|
|
21
|
+
Choose one:
|
|
22
|
+
A. Short option label - one sentence explaining the tradeoff.
|
|
23
|
+
B. Short option label - one sentence explaining the tradeoff.
|
|
24
|
+
C. Short option label - one sentence explaining the tradeoff.
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Use no more than four options unless the user asks for a broader menu. Include `D. Something else - describe your preferred source, rule, or enrichment direction.` when the user may want a custom path. Stop after presenting the choices and wait for the user. Do not include a second `Choose one:` block in the same response.
|
|
28
|
+
|
|
29
|
+
## Workflow
|
|
30
|
+
|
|
31
|
+
1. Clarify the brief.
|
|
32
|
+
Ask the single most important missing brief detail first. Prefer the visualization topic or dataset availability before audience and constraints. Ask follow-up questions one at a time.
|
|
33
|
+
|
|
34
|
+
2. If no dataset is provided, propose dataset search directions.
|
|
35
|
+
Offer likely sources and search terms as button-ready choices. Ask the user to approve before downloading, scraping, or relying on a source.
|
|
36
|
+
|
|
37
|
+
3. Inspect the data.
|
|
38
|
+
Profile rows, columns, types, missingness, outliers, duplicates, units, granularity, time coverage, geography, and likely join keys.
|
|
39
|
+
|
|
40
|
+
4. Report data fitness.
|
|
41
|
+
Summarize what the data can support, what it cannot support, and what claims would be risky.
|
|
42
|
+
|
|
43
|
+
5. Propose cleaning and shaping actions.
|
|
44
|
+
Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning.
|
|
45
|
+
|
|
46
|
+
6. Supplement if useful.
|
|
47
|
+
If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join.
|
|
48
|
+
|
|
49
|
+
7. Produce handoff notes.
|
|
50
|
+
Give Data Analyst a concise data dictionary, transformation log, caveats, and recommended analytical questions.
|
|
51
|
+
|
|
52
|
+
## Data Storage
|
|
53
|
+
|
|
54
|
+
Store project datasets under `data/<project-name>/`, not under `outcome/` and not under a root-level `outputs/` folder.
|
|
55
|
+
|
|
56
|
+
- Put source snapshots, downloads, and reacquirable raw files in `data/<project-name>/raw/`.
|
|
57
|
+
- Put cleaned, joined, aggregated, or analysis-ready files in `data/<project-name>/curated/`.
|
|
58
|
+
- Put data dictionaries, transformation logs, and curator handoff notes beside the relevant curated files.
|
|
59
|
+
- Keep public-facing HTML, story briefs, product context, and design artifacts in `outcome/<project-name>/`.
|
|
60
|
+
|
|
61
|
+
## Analyst Callback
|
|
62
|
+
|
|
63
|
+
When Data Analyst asks for better data, investigate the gap and return options. Examples: finer geography, longer time range, population denominators, category mappings, inflation adjustment, or benchmark datasets.
|
|
64
|
+
|
|
65
|
+
## Reference
|
|
66
|
+
|
|
67
|
+
Read `references/dataset-intake-checklist.md` when profiling a real dataset, evaluating whether a dataset is suitable, or preparing a handoff to Data Analyst.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Dataset Intake Checklist
|
|
2
|
+
|
|
3
|
+
## Profile
|
|
4
|
+
|
|
5
|
+
- Source and license
|
|
6
|
+
- Rows, columns, file format, encoding
|
|
7
|
+
- Column names, inferred types, units
|
|
8
|
+
- Time coverage and frequency
|
|
9
|
+
- Geographic coverage and granularity
|
|
10
|
+
- Category definitions
|
|
11
|
+
- Missing values and placeholder codes
|
|
12
|
+
- Duplicates and unique keys
|
|
13
|
+
- Outliers and impossible values
|
|
14
|
+
- Join keys and likely enrichment fields
|
|
15
|
+
|
|
16
|
+
## Fitness Questions
|
|
17
|
+
|
|
18
|
+
- What questions can this data answer?
|
|
19
|
+
- What questions can it not answer?
|
|
20
|
+
- What normalization is needed for fair comparison?
|
|
21
|
+
- What external context would make patterns more meaningful?
|
|
22
|
+
- What claims would be misleading?
|
|
23
|
+
- What caveats must travel with the data?
|
|
24
|
+
|
|
25
|
+
## Handoff Format
|
|
26
|
+
|
|
27
|
+
Give Analyst:
|
|
28
|
+
|
|
29
|
+
- A compact data dictionary
|
|
30
|
+
- Cleaned or recommended schema
|
|
31
|
+
- Transformation log
|
|
32
|
+
- Enrichment options
|
|
33
|
+
- Risks and caveats
|
|
34
|
+
- Questions worth exploring first
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: data-vizard
|
|
3
|
+
description: Orchestrate an interactive data visualization workflow for workshop participants from dataset discovery or intake through curation, analysis, narrative structure, design direction, and final HTML artifact planning. Use when the user wants end-to-end guidance, invokes Data Vizard, wants help deciding which Data Vizard role skill to use next, or asks to coordinate Data Curator, Data Analyst, Narrator, and Designer while keeping the user involved in all major decisions.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Data Vizard
|
|
7
|
+
|
|
8
|
+
## Overview
|
|
9
|
+
|
|
10
|
+
Guide the participant through the full data visualization process as an interactive facilitator. Use the role skills directly when a task is narrow, and coordinate them when the user wants an end-to-end workshop flow.
|
|
11
|
+
|
|
12
|
+
## Core Rule
|
|
13
|
+
|
|
14
|
+
Do not make major project decisions silently. Ask the user before choosing dataset sources, enrichment strategy, analytical direction, narrative framing, chart form, visual style, interaction model, or motion behavior.
|
|
15
|
+
|
|
16
|
+
When the user has not supplied enough context, ask exactly one focused decision question and wait. If more than one decision is needed, ask the highest-leverage or most blocking question first and postpone the rest until after the user answers. If a decision can be postponed, continue with a clearly labeled assumption instead of stacking multiple questions.
|
|
17
|
+
|
|
18
|
+
## Button-Ready Choices
|
|
19
|
+
|
|
20
|
+
Present one decision gate at a time in a strict, compact choice format so Codex surfaces can turn choices into buttons when supported.
|
|
21
|
+
|
|
22
|
+
Use this pattern:
|
|
23
|
+
|
|
24
|
+
```text
|
|
25
|
+
Choose one:
|
|
26
|
+
A. Short option label - one sentence explaining the tradeoff.
|
|
27
|
+
B. Short option label - one sentence explaining the tradeoff.
|
|
28
|
+
C. Short option label - one sentence explaining the tradeoff.
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Keep labels short, start at `A`, and include no more than four options unless the user asks for a broader menu. Add `D. Something else - describe your preferred direction.` when the user may reasonably want a custom path.
|
|
32
|
+
|
|
33
|
+
After presenting button-ready choices, stop and wait for the user. Do not continue as if an option was selected. Do not include a second `Choose one:` block in the same response.
|
|
34
|
+
|
|
35
|
+
## Workflow
|
|
36
|
+
|
|
37
|
+
The role sequence is mandatory for every visualization artifact. Do not skip Data Curator, Data Analyst, Narrator, or Designer. Even when the user delegates a choice or asks for speed, run each stage and leave a compact handoff artifact or ledger entry before moving to the next one. A stage may be brief, but it must be explicit.
|
|
38
|
+
|
|
39
|
+
1. Establish the project brief.
|
|
40
|
+
Ask for the single missing detail that most affects the next step, using button-ready choices where possible. Prefer topic or dataset source first; defer audience, constraints, and artifact format until they become necessary. If the user does not have a dataset, route to Data Curator.
|
|
41
|
+
|
|
42
|
+
Store project-specific product context in `outcome/<project-name>/PRODUCT.md`, not in the repository root. This file should capture the audience, purpose, personality, anti-references, design principles, and accessibility goals for that one visualization project.
|
|
43
|
+
|
|
44
|
+
2. Curate the data.
|
|
45
|
+
Use Data Curator to find, inspect, clean, reshape, or supplement data. Ask the user to approve external dataset choices and enrichment assumptions unless the user has explicitly delegated the source choice; delegated choices still require a Curator handoff note.
|
|
46
|
+
|
|
47
|
+
3. Analyze for possible story directions.
|
|
48
|
+
Use Data Analyst to profile the data and propose evidence-backed story variations. Do not let the Analyst pick the final story unless the user has explicitly delegated story direction; delegated choices still require an Analyst handoff note explaining the selected direction and alternatives considered.
|
|
49
|
+
|
|
50
|
+
4. Structure the narrative.
|
|
51
|
+
Use Narrator after the user selects or delegates a story direction. Shape the visualization story, titles, sequence, annotations, claims, caveats, and audience language. Always leave a story brief before Designer implements.
|
|
52
|
+
|
|
53
|
+
5. Choose the design direction.
|
|
54
|
+
Use Designer to propose visual directions and style families as button-ready choices. Ask the user to choose before implementing unless the user has explicitly delegated design direction; delegated choices still require a Designer plan before implementation. If the user asks for variants, produce a small set of clearly differentiated options.
|
|
55
|
+
|
|
56
|
+
6. Build or plan the HTML artifact.
|
|
57
|
+
The final Designer output should be an HTML-based artifact or a precise implementation plan for one. Prefer a single self-contained HTML file unless the user requests a framework. Store completed visualization artifacts under `outcome/<project-name>/`.
|
|
58
|
+
|
|
59
|
+
## Role Routing
|
|
60
|
+
|
|
61
|
+
- Use `$data-curator` when the user needs data discovery, cleaning, profiling, reshaping, joining, or supplementing.
|
|
62
|
+
- Use `$data-analyst` when the user needs patterns, comparisons, anomalies, uncertainty, or possible story directions.
|
|
63
|
+
- Use `$narrator` when the user has selected an analytical direction and needs the visualization story shaped in language.
|
|
64
|
+
- Use `$designer` when the user needs chart design, visual style, motion design, interaction, accessibility, or an HTML visualization artifact.
|
|
65
|
+
|
|
66
|
+
## Subagents
|
|
67
|
+
|
|
68
|
+
Skills are the primary packaging model. Subagents are optional execution helpers.
|
|
69
|
+
|
|
70
|
+
Use subagents only when parallel exploration would help, such as asking Analyst to explore story candidates while Designer explores possible visual styles from the same brief. When using subagents, keep the user-facing workflow intact: summarize options, explain tradeoffs, and ask the user to choose.
|
|
71
|
+
|
|
72
|
+
## Project Ledger
|
|
73
|
+
|
|
74
|
+
For every visualization project, maintain a repo-accessible progress ledger at:
|
|
75
|
+
|
|
76
|
+
```text
|
|
77
|
+
project-ledgers/<project-name>.md
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Normalize `<project-name>` to lowercase hyphen-case, such as `nyc-taxi-weather-jan-2026.md`. Create the file when the workflow starts if it does not already exist.
|
|
81
|
+
|
|
82
|
+
Update the ledger whenever a stage is completed:
|
|
83
|
+
|
|
84
|
+
- Data Vizard completes orchestration or a decision gate
|
|
85
|
+
- Data Curator produces a dataset or handoff notes
|
|
86
|
+
- Data Analyst presents story candidates or the user selects one
|
|
87
|
+
- Narrator produces or revises the approved story brief
|
|
88
|
+
- Designer produces, revises, or verifies the HTML artifact
|
|
89
|
+
|
|
90
|
+
Record each skill boundary, files or references loaded, user decision gates, evidence notes, and outputs produced. Keep the ledger focused on progress, handoffs, decisions, caveats, and artifacts rather than token accounting.
|
|
91
|
+
|
|
92
|
+
Use this compact table shape:
|
|
93
|
+
|
|
94
|
+
```markdown
|
|
95
|
+
| Stage | Skill | Status | Decisions / Evidence | Outputs |
|
|
96
|
+
| --- | --- | --- | --- | --- |
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## Project Storage
|
|
100
|
+
|
|
101
|
+
Use these repo paths consistently for each project:
|
|
102
|
+
|
|
103
|
+
```text
|
|
104
|
+
data/<project-name>/raw/
|
|
105
|
+
data/<project-name>/curated/
|
|
106
|
+
outcome/<project-name>/PRODUCT.md
|
|
107
|
+
outcome/<project-name>/<artifact-name>.html
|
|
108
|
+
project-ledgers/<project-name>.md
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
Store source snapshots, raw files, cleaned tables, joins, and data handoff notes under `data/<project-name>/`. Store public-facing HTML artifacts, story briefs, product context, design briefs, favicons, and presentation-specific assets under `outcome/<project-name>/`.
|
|
112
|
+
|
|
113
|
+
Store the final visualization outcome in a predictable repo path:
|
|
114
|
+
|
|
115
|
+
```text
|
|
116
|
+
outcome/<project-name>/<artifact-name>.html
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
Normalize `<project-name>` to lowercase hyphen-case, matching the project ledger name when possible. For example:
|
|
120
|
+
|
|
121
|
+
```text
|
|
122
|
+
outcome/nyc-taxi-weather-jan-2026/index.html
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
When Designer creates presentation-specific supporting files, keep them inside the same project outcome folder:
|
|
126
|
+
|
|
127
|
+
```text
|
|
128
|
+
outcome/<project-name>/assets/
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
Do not store source snapshots, raw datasets, or reusable curated tables in `outcome/`; those belong under `data/<project-name>/`.
|
|
132
|
+
|
|
133
|
+
For the default workshop path, prefer a single self-contained HTML file named `index.html`. After Designer verifies the artifact, update `project-ledgers/<project-name>.md` with the final outcome path and verification notes.
|
|
134
|
+
|
|
135
|
+
## Reference
|
|
136
|
+
|
|
137
|
+
Read `references/workflow-map.md` when planning a multi-step workshop session, testing the workflow against a sample dataset, or deciding how the role skills should hand off to each other.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Data Vizard Workflow Map
|
|
2
|
+
|
|
3
|
+
## Decision Gates
|
|
4
|
+
|
|
5
|
+
Pause for user input at these moments:
|
|
6
|
+
|
|
7
|
+
- Dataset source or enrichment source selection
|
|
8
|
+
- Cleaning rules that change meaning
|
|
9
|
+
- Analytical story direction selection
|
|
10
|
+
- Narrative frame and audience tone selection
|
|
11
|
+
- Visual style family, chart form, and motion behavior selection
|
|
12
|
+
- Final implementation approach for the HTML artifact
|
|
13
|
+
|
|
14
|
+
Ask only one decision gate per assistant turn. If several gates are pending, choose the one that most affects the next concrete action, then wait for the user's answer before presenting the next gate.
|
|
15
|
+
|
|
16
|
+
## Recommended Handoffs
|
|
17
|
+
|
|
18
|
+
All four role handoffs are required for a completed visualization artifact. The process may be lightweight, but it must not jump directly from dataset choice to final HTML.
|
|
19
|
+
|
|
20
|
+
Curator to Analyst:
|
|
21
|
+
|
|
22
|
+
- Dataset location and format, using `data/<project-name>/raw/` or `data/<project-name>/curated/`
|
|
23
|
+
- Data dictionary
|
|
24
|
+
- Transformation log
|
|
25
|
+
- Known caveats
|
|
26
|
+
- Suggested analytical questions
|
|
27
|
+
|
|
28
|
+
Analyst to Narrator:
|
|
29
|
+
|
|
30
|
+
- Selected or candidate story directions
|
|
31
|
+
- Main evidence
|
|
32
|
+
- Counter-evidence or uncertainty
|
|
33
|
+
- Caveats that must remain visible
|
|
34
|
+
- Possible chart forms
|
|
35
|
+
|
|
36
|
+
Narrator to Designer:
|
|
37
|
+
|
|
38
|
+
- Audience and tone
|
|
39
|
+
- Main claim or question
|
|
40
|
+
- Section sequence
|
|
41
|
+
- Annotation priorities
|
|
42
|
+
- Required caveat language
|
|
43
|
+
|
|
44
|
+
Designer to user:
|
|
45
|
+
|
|
46
|
+
- Visual direction options
|
|
47
|
+
- Selected implementation plan
|
|
48
|
+
- HTML artifact path
|
|
49
|
+
- Verification notes
|
|
50
|
+
|
|
51
|
+
## Project Files
|
|
52
|
+
|
|
53
|
+
- Store project-specific product context at `outcome/<project-name>/PRODUCT.md`.
|
|
54
|
+
- Store raw and curated datasets under `data/<project-name>/`.
|
|
55
|
+
- Store final HTML and public-facing supporting assets under `outcome/<project-name>/`.
|
|
56
|
+
- Store progress and handoff ledgers under `project-ledgers/<project-name>.md`.
|
|
57
|
+
|
|
58
|
+
## Workshop Facilitation Tone
|
|
59
|
+
|
|
60
|
+
Be collaborative and explicit. Explain why the current decision matters, offer a small set of options for that one decision, and help the participant make the choice. Avoid turning the workflow into a hidden autopilot or a long intake form.
|