Agent Skills for Power BI: what a BI developer should do with them, and where to draw the line

Your coding assistant can now build Power BI reports. At Microsoft Build 2026, Arun Ulag's Fabric and Databases announcement post said that the open-source Agent Skills for Fabric now extend to Power BI, so developers and analysts can create reports from natural language or even a screenshot of the result they want.

That changes who, or what, edits your PBIP files. Tools like GitHub Copilot CLI, Claude Code and Cursor can now follow Microsoft's own instructions for semantic models and PBIR reports. It is a preview, and the documented boundaries are the interesting part.

What was announced

Skills for Fabric is an open-source catalog (MIT License) in the microsoft/skills-for-fabric repository on GitHub. Microsoft describes a skill as a reusable instruction set: a SKILL.md file that tells an AI coding tool which APIs to call, what query syntax to use, which authentication setup is needed and which practices to follow.

For Power BI, the entry point is the powerbi-authoring plugin. It bundles a semantic model skill and four report skills:

• semantic-model-authoring for creating, editing and deploying semantic models, including Import, DirectQuery and Direct Lake, DAX measures and relationships.
• powerbi-report-design, which produces a design brief (layout, chart choice, colors, theme) but does not write files.
• powerbi-report-planner, a guided workflow that gathers requirements, inspects the model and waits for your approval before building.
• powerbi-report-authoring, which creates, edits and validates PBIR report definitions.
• powerbi-report-management, which lists, uploads, downloads, updates and deletes report items in Fabric workspaces through the Fabric REST API.

The plugin also registers the Power BI Modeling MCP server, so the agent can connect to Power BI Desktop and Fabric workspaces.

Skills are knowledge, MCP servers are hands

This distinction matters for how you think about risk. Microsoft puts it plainly: skills teach the assistant what to do, and MCP servers do it. A skill is static markdown loaded into the agent's context. It does not run anything on its own.

The actions come from the tools. In the Power BI setup, the MCP server inspects schemas, runs DAX and edits models. The Power BI Desktop bridge lets the agent reload Desktop and capture screenshots. The management skill drives az rest calls against your workspaces.

So the question is not "do I trust the skill?" It is "what can the agent reach, and with whose permissions?"

The guardrails Microsoft already wrote down

The Learn pages for these skills read like a checklist. A few points stand out:

• PBIP only. The report authoring skill works only with PBIP files. Reports in PBIR-Legacy format are not supported.
• Commit a baseline first. Microsoft recommends committing to source control before you let the agent modify PBIR files, so you can revert.
• The file on disk wins. PBIR is the source of truth. If you have unsaved changes in Power BI Desktop, the agent works from the saved version and your changes are not included.
• Local until you say otherwise. The planner does not publish to Fabric unless you explicitly approve it, and the management skill treats edits as local-only until you request publishing.
• Check model bindings. When uploading a local PBIP to Fabric, entity names in PBIR must match the table names of the target semantic model.
• Avoid soon-to-be-deprecated visuals. The docs list Q&A, Bing maps and filled maps as visuals you should not ask the agent to create.

I like that the planner is approval-gated. It writes requirements.md, design-brief.md and plan.md first and builds nothing until you approve. That is the right default.

What this means for you

After two decades in data, my view is that the semantic model is still where the value sits. An agent that builds a page in minutes on a weak model only gets you to the wrong answer faster. Microsoft's own framing points the same way: semantic models are the governed foundation the agents build on.

A sensible way to start:

1. Move one non-critical report to PBIP with the PBIR format, and put it in Git.
2. Install the powerbi-authoring plugin in a dev setup, not on the machine you publish production from.
3. Start with the design skill on an existing report. Ask for critique only. It writes no files, so it is a low-risk way to judge the quality.
4. Try a small, specific edit with the authoring skill, such as adding a card for one measure. Review the Git diff line by line.
5. Only then try the planner on a new report, and read the brief before you approve it.
6. Keep publishing manual, or tie it to a dev workspace, until you have seen enough diffs to trust the pattern.

Two more points from my side. Sign the agent in with an account that has access to dev workspaces only, because the management skill can delete report items as well as create them. And treat model changes with more caution than report changes. A wrong visual is visible. A wrong measure can sit in a report for months.

Where it fits, and where it does not

This is a developer workflow in your terminal or editor, built on PBIP files. It is separate from Copilot in Power BI, which Microsoft says can now also modify semantic models with built-in recommendations.

If your team does not use PBIP and source control yet, that is the real first step, with or without agents.

Takeaway

Agent Skills for Power BI make PBIP and Git more valuable than ever. The agent is fast, but your review is the quality gate: baseline commit, small diffs, approval before publish and least-privilege access.

Have you moved your reports to PBIP yet, and which report would you let an agent touch first?

Sources

• Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases (Microsoft Azure Blog)
• Skills for Microsoft Fabric (Microsoft Learn)
• Power BI Agentic overview (Microsoft Learn)
• What is the Power BI Report Authoring skill? (Microsoft Learn)
• Power BI report planner and management skills overview (Microsoft Learn)