plan-data-source

name

plan-data-source

description

Use when the user wants to decide or spec a Rayfin (Microsoft Fabric Data App)'s data source — connecting to a semantic model for reads, defining app-owned write-back entities, or both. Trigger phrases — "what data source should this app use", "connect this app to a semantic model", "plan the write-back for", "create a data source for [app]". Writes the Data contract (reads) and Data contract (write-back) sections of that app's requirements.md; does not run the fabric-app-data CLI or generate any client code.

Plan a Rayfin app's data source(s)

Turn "what data does this app need" into an explicit, buildable data contract — which semantic model tables/measures it reads, and what (if anything) it needs to remember as app-owned write-back — before any connection code exists.

Boundaries

• Produces the ## Data contract — reads and ## Data contract — write-back sections of requirements.md. Does not run fabric-app-data init/add/generate, does not write real lowercase-decorator entity TypeScript, and does not touch rayfin.yml's services block — all of that is build's job, informed by what this skill wrote.
• Does not invent table/column/measure names. If the user doesn't know the exact semantic-model schema yet, say so and either ask them to check the model in Power BI / Fabric first, or note it as an open item for build's scaffolded schema-discovery skill to resolve via DAX INFO functions once the model is connected — don't guess field names into a spec.

Workflow

1. Resolve the target app via ../common/spec-location.md.
2. Load references/data-source-options.md — the read/write/storage decision guide.
3. If plan-frontend has already run (Screens/visuals table exists and is non-empty), work from it: for each screen, ask which path(s) it needs per the "deciding between them" section of the reference. If frontend planning hasn't happened yet, ask directly what the app needs to show and what it needs to remember.
4. Read path: get the semantic model's share link (or workspace + model name) from the user. For each screen that reads it, capture the exact table(s)/column(s)/certified measure(s) — ask the user directly, or if they're unsure, note it as an open item rather than guessing. Ask explicitly whether there are any known data-shape gotchas (NULL semantics, grain, missing columns) the app must honor, and capture them verbatim — these are exactly the details that are invisible from the schema and expensive to discover mid-build.
5. Write path (only if this app has one): ask what decision/action the app needs to remember, sketch the entity's fields and any status enum, ask who's allowed to create/update it (feeds @role()), and identify the natural key(s) a downstream report would join on back to the read-path data. State explicitly in the write-up: additive only, never mutates the source model.
6. Storage path: only raise this if the user's request actually involves file attachments.
7. Write/update requirements.md's two Data contract sections in the existing style — see ../new-app/references/requirements-template.md for the shape, and match the illustrative @Entity/@PrimaryKey decorator-sketch convention for write-back at spec stage.
8. If both Screens/visuals and the Data contracts are now filled in, offer to promote Status from Draft/In Review toward Ready to Build — this is the point where the spec is plausibly buildable — but only with the user's explicit go-ahead, and only via new-app/ update-app's ownership of that promotion (hand back to whichever of those is driving the session, or ask directly if this skill was invoked standalone).
9. Summarize back: which reads and which write-back entity (if any) were captured, and any open items (unresolved schema names, unconfirmed tenant prerequisites) still outstanding.