build

name	build
description	Implement and deploy a Rayfin (Microsoft Fabric Data App) from a Ready-to-Build spec — checks prerequisites, plans a dependency-aware build sequence, then executes it against the Rayfin CLI/SDK and the app's own scaffolded implementation skills. Invoke with /build.
disable-model-invocation	true

Build a Rayfin app from its spec

Check the spec's prerequisites, work out a real build order for its remaining user stories (not just file order), decide which tool each story needs, and then actually execute — real CLI commands, real deploys — rather than re-teaching DAX, Vega-Lite, or the entity decorator API this skill doesn't own.

🔴 User-invoked only (disable-model-invocation: true). This skill runs real, hard-to-reverse commands against live Fabric infrastructure (npx rayfin up and friends) — it must never fire on its own initiative from a description match. The user decides when building starts.

Boundaries

This is the most important section of this skill. build contains no DAX syntax, Vega-Lite authoring guidance, entity decorator API reference, or CLI flag documentation beyond the sequencing table below — all real technique detail is delegated, by name, to the skill already scaffolded into every create-rayfin-generated project's src/.agents/skills/:

Story kind	Delegate to (scaffolded, per-app)
Project scaffold, deploy sequencing, CLI flags	rayfin (Microsoft-authored, rayfin-managed: true — treat as the authority over this plugin's own ../common/rayfin-platform.md if they ever disagree)
Semantic-model connection setup	fabric-cli
Runtime semantic-model queries	fabric-sdk
Writing/testing DAX	dax-authoring, schema-discovery
Splitting DAX vs. TS vs. Vega-Lite responsibilities	query-design
Charts, data grids, theming	visuals, app-design
Pre-publish browser validation	app-validation, playwright-cli

Never duplicate what those skills already do. This skill's job is which story, which tool, in which order, checked off how — orchestration against the spec, not technique.

Workflow

1. Resolve the target app via ../common/spec-location.md.
2. Gate check: read requirements.md's Status. If it is not Ready to Build, stop and say so — list what's missing (an unfilled Screens/visuals or Data contract section) and suggest plan-frontend/plan-data-source. Only proceed past Draft/In Review if the user explicitly overrides after being told what's incomplete.
3. Load ../common/rayfin-platform.md for the command/config-file index, and confirm the app's own bundled .agents/skills/rayfin/SKILL.md exists and agrees with it — that skill is kept current by the CLI itself and wins on any conflict.
4. Prerequisite check — spec-level. Build a checklist from three sources and check each item, rather than discovering a missing prerequisite mid-story:
   • Programmatically checkable: run what can actually be run — node --version (Rayfin needs 22+), npx rayfin login status (signed in to the right tenant), npx rayfin up status if a prior deployment is expected to exist already.
   • Named in this plugin's own references: anything ../common/rayfin-platform.md's "Known preview gotchas" or ../plan-data-source/references/data-source-options.md's "Tenant prerequisites" section calls out for the paths this spec actually uses (e.g. only check the Execute DAX Queries REST API tenant setting if the spec has a read path at all).
   • Named by the project itself: look for a setup guide, platform-notes doc, or a team_communication-style prerequisites handoff in this project (check the subproject's own CLAUDE.md/README.md for a pointer, or search near the app folder) — if one exists, it is the authoritative list for this project's tenant/capacity/permission prerequisites; read it rather than re-deriving that list from scratch.
   • For anything not mechanically checkable (a tenant admin setting, a permission grant, region/ capacity availability), ask the user to confirm rather than assuming — unless a project document already states it was resolved, in which case cite that document instead of asking again.
   • 🔴 This is a soft gate, not a hard block (unlike the Status gate in step 2). If a prerequisite can't be verified or confirmed, stop, state plainly which one and why it matters (what breaks if it's actually missing), and offer the choice explicitly: fix/confirm it first, or proceed anyway accepting the risk. Never silently skip a prerequisite and never silently block on one either — the user decides.