Using Power BI Semantic Modeling safely

This guide explains how to use the official powerbi-modeling skill with a compatible agent. It structures the work but does not replace professional Power BI review.

Provide the repository instructions

Place the reviewed skill file in the repository context supported by your GitHub Copilot or agent workflow. Check the commit, provenance, and local policy before enabling it. Practical model inspection requires a configured Power BI Modeling MCP server or another explicitly approved tool path that provides equivalent access.

Inspect the connection and model first

Start by listing available connections and local instances. Connect only to the intended Desktop or Fabric model. Then read the model overview, tables, relationships, and measures. Share only the model information required for the specific task.

Assess quality step by step

Review dimensions, facts, keys, and filter paths first. Then assess cardinality, activity, and cross-filter behavior. Check measures for business definition, DAX expression, format, and documentation. Technical keys may be hidden from report authors while remaining traceable for model maintenance.

Protect changes

Read-only analysis is the safest starting point. Before changing model objects or security roles, make the purpose, target, authorization, and rollback plan explicit. Test RLS with representative identities and compare measures with trusted reference values. Never store credentials, tokens, or confidential example data in instructions.

Frequently asked questions

### Is this skill a Power BI program?

No. According to the provider, it is guidance for a compatible agent. Modeling takes place in Power BI and through the approved tools available to that environment.

### Must the agent always connect first?

Yes. The primary source requires inspecting the active model state first so that recommendations reflect real tables, relationships, and measures.

### Is a star schema always mandatory?

No. It is a proven pattern for many analytical models. Business requirements can justify exceptions, but those exceptions should be documented and tested.