build-workflow
Skill108 starsChanged 5 months agoMITView on GitHub
START HERE when building, modifying, or iterating on a data app or dashboard. Defines the fast, iterative "time to wow" workflow: ship one real hero visual first, preview every visual against live data, then expand breadth and polish. Deploy with `rayfin up` for review. Orchestrates the dax, fabric-data, visuals, headless-preview, and app-design skills so you don't front-load all of them.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 52
Don't enumerate the whole model.
- Distinctive: line 71
Stop after the hero slice and use user feedback before going further.
- Distinctive: line 75
Add the rest of what the user asked for — more KPIs, charts, table/matrix specs, filters.
- Very specific: line 96
Deploy sparingly —
rayfin upis a slow round-trip: Use it for milestone review: once after the hero slice, then after a *batch* of Phase … - Distinctive: line 109
Don't load every skill upfront.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Build Workflow — Ship fast, then iterate
Optimize time to wow: the time until the user sees a real, compelling result in the deployed app. Build a thin vertical slice, preview it, then iterate. Do not front-load exhaustive schema discovery, perfect DAX, or perfect theming before anything is visible — that is the slowest possible path.
Headless preview is the agent validation loop. Preview each visual against live data (
npm run preview→ PNG + report), wire it into the app, and deploy withrayfin upto ship the result for review.
The loop
Edit → preview each visual (headless) → wire it in → (milestone) deploy with
rayfin up → review → refine. Keep each edit/preview loop small and local:
the headless preview is your fast inner loop, so rayfin up is a milestone
step, not a per-visual one. One reviewed change beats a big-bang build every time.
- All visuals: render the spec headlessly against live data to a PNG +
report —
npm run preview— and critique it before it ships. Use it to choose a visual type, check the data fits, and catch clipping/overlap/contrast. (→headless-preview)
Phases
Phase 1 — Hero slice (time to wow)
Get ONE compelling, real visual wired to live data, previewed, and on screen — as fast as possible.
Scaffold first, then start here.
npm run pack:add -- analyticsalready gave you the dashboard kit + a runnable demo (src/demo). Don't re-read setup or re-copy files — go straight to the hero slice, then swap the demo for it.
- Pick an archetype — decide the dashboard's shape from the request: executive
summary, operational monitoring, or analytical deep-dive. This frames the hero
tile and the breadth that follows. Default to executive summary when unsure.
(→
app-design: Dashboard archetypes) - Minimum schema scan — discover just enough to find one compelling metric:
one scope probe + the one or two tables/measures behind your hero visual.
Don't enumerate the whole model. (→
dax: Fast path) - One hero query — write a single DAX query at the visual's grain,
quick-test it once, ship it. (→
dax: Fast path) - One hero visual — render it the simplest way: map the hero query with
toChartData, author one Graphein spec, and pass it to aChartCard(or render aKpiCard/DataTableCardwith atable/matrixspec) — pass the mapped spec +loading/error, don't hand-write chart code. (→visuals: Fast path) - Preview it against live data —
npm run preview -- --spec hero.json --query <alias> --dax-file q.dax, view the PNG + report, and tune the spec until it reads well. KPI/table/matrix/slicers/dashboard rasterize to PNG too, so preview them before shipping. (→headless-preview) - Sensible default theme — pick a characterful font pairing + a primary
color and move on. Do not perfect theming yet. (→
app-design: Fast path) - Drop the hero tile into
src/App.tsx— the scaffold renders a bundled all-Graphein demo (src/demo/) so a fresh app is never blank; deletesrc/demo/**and replace<DemoDashboard />with your hero visual (its providers + slicers + cross-filter wiring are the pattern to copy). Deploy withrayfin upfor review.
Stop after the hero slice and use user feedback before going further.
Phase 2 — Breadth
Add the rest of what the user asked for — more KPIs, charts, table/matrix specs, filters.
Preview each new visual against live data as you author it — not once
at the end. Pull in interactivity (cross-filtering / cross-highlighting) only
when the user actually needs it. (→ dax, visuals, headless-preview)
Phase 3 — Polish
Now refine, driven by what the running app actually shows:
- Theme/typography depth, layout rhythm, and the
app-designFinal Audit. - Loading / empty / error states for every async visual.
- Edge-case DAX correctness, number/date formatting, dark mode.
(→ app-design and dax reference files — read on demand.)
Rules
- Preview every visual before it ships. A
npm run previewagainst live data is the validation loop for getting one visual right. - Validate visuals headlessly before you deploy. A
npm run previewagainst live data catches problems far faster than a deploy round-trip. - Deploy sparingly —
rayfin upis a slow round-trip. Use it for milestone review: once after the hero slice, then after a batch of Phase 2 work — never per visual. Headless preview is the per-visual loop, so a "simple dashboard" should reach the user in one or two deploys, not one per tile. - One reviewed change at a time. Small loops surface problems immediately.
- Read references lazily. The sibling skills carry deep references (DAX patterns, visual recipes, style recipes). Open them only when a specific problem demands it — not as upfront reading.
- Don't gold-plate Phase 1. Exhaustive discovery and perfect theming are Phase 3 concerns; they must never block the first ship.
Skill read order
Don't load every skill upfront. Pull each one in as its phase needs it, and stop at its Fast path section until you genuinely need more.
| When | Skill | How much |
| Phase 1 — pick a shape | app-design | Dashboard archetypes |
| Phase 1 — find a metric | dax | Fast path only |
| Phase 1 — write the hero query | dax | Fast path only |
| Phase 1 — render it | visuals | Fast path only |
| Phase 1 — check it vs live data | headless-preview | for each visual |
| Phase 1 — quick default look | app-design | Fast path only |
| Phase 2 — breadth & interactivity | dax, visuals | deeper sections |
| Phase 2 — vet each new visual | headless-preview | per visual |
| Phase 3 — polish & correctness | app-design, dax | references, on demand |
| Connections / data plumbing | fabric-data | only if not already wired |
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- neurawork-git/n8n-autopilot★ 18same name
- simstudioai/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository33 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/angular-blankapp/AGENTS.mdAGENTS.md
- templates/angular-dashboard/AGENTS.mdAGENTS.md
- templates/campus-scheduler/AGENTS.mdAGENTS.md
- templates/fabric-atlas/AGENTS.mdAGENTS.md
- templates/field-technician/AGENTS.mdAGENTS.md
- templates/finance-analytics/AGENTS.mdAGENTS.md
- templates/ibcs-trainer/AGENTS.mdAGENTS.md
- templates/maritime-insights/AGENTS.mdAGENTS.md
- templates/paragliding-insights/AGENTS.mdAGENTS.md
- templates/slide-deck/AGENTS.mdAGENTS.md
- templates/static-blankapp/AGENTS.mdAGENTS.md
- templates/todo-local-experimental/AGENTS.mdAGENTS.md
- templates/universal-app/AGENTS.mdAGENTS.md
- template-gallerySkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- rayfinSkill
- analyticsSkill
- app-designSkill
- authenticationSkill
- capability-routerSkill
- data-modelingSkill
- daxSkill
- fabric-dataSkill
- graphein-visualsSkill
- headless-previewSkill
- visualsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

