| name | power-bi |
| description | Use when a Data Visualization Kit project chooses Power BI as the visualization path, or when the user asks to build, review, publish, or operate Power BI reports, dashboards, semantic models, PBIP/PBIR assets, DAX, Power BI Desktop, or Microsoft Fabric-backed report workflows. |
| license | Personal use |
| argument-hint | [power-bi-task] [project-slug] |
| metadata | {"author":"data-visualization-kit","version":"1.0.0","source_inspiration":"data-goblin/power-bi-agentic-development@67627c270241f282ad98754194ad58212b0fa886"} |
Power BI Skill
Power BI is an optional Data Visualization Kit path for users who explicitly want Microsoft Power BI, Power BI Desktop, PBIP, PBIR, DAX, semantic models, or Microsoft Fabric delivery.
When To Use
- The user chooses Power BI as the visualization or publish target.
- The project already has
.pbip, .Report, .SemanticModel, .Dataset, definition.pbir, PBIR JSON, TMDL, or DAX files.
- The user asks to build a Power BI report, executive dashboard, semantic model review, DAX optimization, or Fabric publish workflow.
- The user needs to connect to Power BI Desktop's local Analysis Services instance.
Selection Rules
- Treat Power BI as a first-class Data Visualization Kit visualization option.
- Choose Power BI when the project plan, user brief, or existing files mention Power BI, PBIP/PBIR, DAX, semantic models, Desktop, or Fabric.
- Use Metabase by default for open-source general BI when there is no Power BI signal.
- Use Grafana for operational, observability, or time-series work unless the user explicitly wants Power BI.
- Keep Power BI project files project-scoped, not root-scoped.
Project Layout
Use this layout when Power BI files are needed:
projects/<slug>/
docs/
visualization.md
assets/
screenshots/
exports/
power-bi/
<report-name>.Report/
<model-name>.SemanticModel/
<project-name>.pbip
docs/ remains the narrative and evidence surface. power-bi/ is the tool workspace.
Working Rules
- Read
projects/<slug>/docs/project-plan.md, data-preparation.md, and visualization.md before Power BI work.
- Confirm whether the report is thick, thin, local Desktop, or Fabric-backed.
- Prefer CLI-backed edits such as
pbir or official tooling when available.
- Treat direct PBIR/TMDL file edits as brittle; validate after every mutation.
- Keep screenshots, exports, and notes under
projects/<slug>/docs/assets/.
- Never store credentials, tokens, tenant secrets, or publish keys in project files.
Validation Checklist
- Run the local Power BI gate for touched paths when available.
- Validate PBIR JSON syntax for
.Report files.
- Validate
definition.pbir bindings:
byPath target exists locally.
byConnection has a documented Fabric workspace/model context.
- Validate TMDL or semantic model changes with available tooling.
- Ask the user to open the report in Power BI Desktop or Fabric when rendering cannot be verified locally.
Related Local Skills
pbip for PBIP/PBIR/TMDL project structure.
dv-data-visualize for the kit visualization workflow.
dv-publish for final publish notes and handoff.
ui-ux-pro-max for dashboard design quality.
test for validation reporting.
Common Pitfalls
- Editing PBIR JSON directly without validation.
- Mixing report files into root
docs/ instead of keeping them in a Power BI workspace folder.
- Treating PBIX binary files as source-controlled editable artifacts.
- Forgetting that Power BI Desktop may need to be closed and reopened after external file edits.
- Publishing without recording the workspace, semantic model, and validation status in
visualization.md or publish.md.