plan-frontend

name

plan-frontend

description

Use when the user wants to plan the screens, visuals, or front-end/UI updates for a Rayfin (Microsoft Fabric Data App) — either a new app or an existing one. Trigger phrases — "plan the screens for", "design the front end of", "what visuals should this app have", "plan the UI updates for [app]". Writes the Screens/visuals table in that app's requirements.md, checked against what Rayfin's built-in design system actually supports; does not write Vega-Lite, TSX, or CSS.

Plan a Rayfin app's front end

Turn a rough idea of "what this app should show" into a Screens/visuals table that's checked against what Rayfin's template can actually build without extra engineering — so the spec is buildable, not aspirational.

Boundaries

• Produces the ## Screens / visuals table in requirements.md. Does not write Vega-Lite JSON, .tsx components, or touch global.css/theme tokens — that implementation work is owned by the scaffolded per-app app-design/visuals/query-design skills at build time.
• Does not decide what data backs a screen beyond naming its rough source — the exact table/column/measure list is plan-data-source's section. If both are being planned together, hand off to plan-data-source for that half rather than guessing at column names here.

Workflow

1. Resolve the target app via ../common/spec-location.md. If invoked standalone (not chained from new-app/update-app), still confirm the app before touching its spec.
2. Load references/design-standards.md — the preconfigured visual/grid/theming capability list and its explicit "outside the preconfigured set" call-outs.
3. For each screen the user describes, ask: who looks at it and what decision or action does it support (not just "what data does it show" — a screen exists to drive a decision). Then:
   • Recommend a visual type from the preconfigured list where one genuinely fits the data shape and the decision it supports (a KPI card for one number, a bar/line chart for a trend or comparison, a data grid for a sortable list a user will scan and act on a row of, etc.).
   • Explicitly flag anything falling outside the preconfigured set (e.g. an interactive pin map) — state that it needs custom engineering, will cost more build iterations, and should be called out in the spec's Open risks section.
   • Note the binding pattern: .dax + Vega-Lite (semantic-model read, chart), .dax + custom table .tsx (semantic-model read, list/grid), or Rayfin GraphQL / no DAX (app-owned write-back screen, e.g. a flag/assignment dialog).
4. Write/update the ## Screens / visuals table in requirements.md — Screen | Purpose | Source | Binding pattern, matching the existing table shape (see the spec's own Data contract sections for what "Source" should name once plan-data-source has run; if it hasn't yet, use a provisional description and note it needs the data-source pass).
5. Note the "can't open outside the Fabric portal" limitation in Open risks if this app's usage pattern makes that relevant (e.g. anyone expecting a standalone browser tab).
6. If this section is now complete (every screen has a recommended visual and a noted binding pattern), offer to promote requirements.md Status from Draft to In Review — state why, and only do it with the user's go-ahead (see ../common/spec-location.md's status-lifecycle rule).
7. Summarize back: which screens were added/changed, and which (if any) need custom engineering flagged as a risk.