agentleFS
MicrosoftKnown publishermicrosoft/awesome-rayfin/templates/universal-app/.agents/skills/build-workflow/SKILL.md

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
  1. Very specific:

    Don't enumerate the whole model.

    line 52
  2. Distinctive:

    Stop after the hero slice and use user feedback before going further.

    line 71
  3. Distinctive:

    Add the rest of what the user asked for — more KPIs, charts, table/matrix specs, filters.

    line 75
  4. Very specific:

    Deploy sparingly — rayfin up is a slow round-trip: Use it for milestone review: once after the hero slice, then after a *batch* of Phase …

    line 96
  5. Distinctive:

    Don't load every skill upfront.

    line 109

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 with rayfin up to 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 -- analytics already 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.

  1. 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)
  2. 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)
  3. One hero query — write a single DAX query at the visual's grain, quick-test it once, ship it. (→ dax: Fast path)
  4. One hero visual — render it the simplest way: map the hero query with toChartData, author one Graphein spec, and pass it to a ChartCard (or render a KpiCard / DataTableCard with a table / matrix spec) — pass the mapped spec + loading/error, don't hand-write chart code. (→ visuals: Fast path)
  5. 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)
  6. Sensible default theme — pick a characterful font pairing + a primary color and move on. Do not perfect theming yet. (→ app-design: Fast path)
  7. 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; delete src/demo/** and replace <DemoDashboard /> with your hero visual (its providers + slicers + cross-filter wiring are the pattern to copy). Deploy with rayfin up for 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-design Final 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 preview against live data is the validation loop for getting one visual right.
  • Validate visuals headlessly before you deploy. A npm run preview against live data catches problems far faster than a deploy round-trip.
  • Deploy sparingly — rayfin up is 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.

WhenSkillHow much
Phase 1 — pick a shapeapp-designDashboard archetypes
Phase 1 — find a metricdaxFast path only
Phase 1 — write the hero querydaxFast path only
Phase 1 — render itvisualsFast path only
Phase 1 — check it vs live dataheadless-previewfor each visual
Phase 1 — quick default lookapp-designFast path only
Phase 2 — breadth & interactivitydax, visualsdeeper sections
Phase 2 — vet each new visualheadless-previewper visual
Phase 3 — polish & correctnessapp-design, daxreferences, on demand
Connections / data plumbingfabric-dataonly if not already wired

Download now (ZIP)

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.