How To Use Microsoft's Fabric Skills To Build a Power BI Report

Seven CSV files and one paragraph of instructions went in. A four-page Power BI report came out: a star-schema semantic model with 20 measures, 43 visuals across pages named Executive Overview, Geographic Performance, Product Performance, and Customers & Commercial, and a published copy in a Power BI workspace. Claude Code built it with Microsoft’s Power BI skills in about an hour, then took about 15 minutes more to publish it. This article follows the run from the first prompt to the publish, including the bug the agent caught by looking at its own screenshots and the problems it left for a person to find.

What the skills are, and what you install

A skill is a Markdown file, SKILL.md, that teaches an AI coding tool one job: which commands and APIs to use, and which rules to follow. A skill doesn’t run anything. The tool reads it and does the work. The other half is an MCP server, a program that gives the tool actions it can call, in this case against a Power BI semantic model. Microsoft Learn puts the split this way: skills teach the AI assistant what to do, and MCP servers do it.

Microsoft publishes its skills in the open-source microsoft/skills-for-fabric repository, under the MIT license, and released them publicly at Build, on June 2–3, 2026. The repository’s marketplace offers two plug-ins. The Power BI one, powerbi-authoring, isn’t part of the main fabric-skills bundle. Today it holds two skills and a server:

• semantic-model-authoring builds and changes semantic models as TMDL.
• powerbi-report-cli plans, designs, writes and publishes reports. It has four modes (planning, design, authoring and management) and picks one from your request.
• The local Power BI Authoring MCP server, @microsoft/powerbi-modeling-mcp, runs through npx.

The run in this article is from June 2026, when those four modes were four separate skills: powerbi-report-planning, powerbi-report-design, powerbi-report-authoring and powerbi-report-management. On September 17, 2026, powerbi-report-cli replaced them, and the repository’s changelog says existing report prompts keep working. How to Install Microsoft’s Fabric Skills tours the whole repository; this article stays with the Power BI plug-in.

To install it in Claude Code, type these two commands at the prompt, then start a new session so the skills load:

/plugin marketplace add microsoft/skills-for-fabric
/plugin install powerbi-authoring@fabric-collection

The same commands work in GitHub Copilot CLI. You also need the Azure CLI, signed in with az login, because the publish step gets its token from it; Power BI Desktop, where the agent opens and checks the report; and a workspace you can publish to. Claude Code is an officially supported tool for these skills, and this run used Claude Opus 4.8 6:53. If Claude Code is new to you, How To Use Claude Code for Power BI Development installs it and adds the same Skills for Fabric plug-ins.

The whole run, from the prompt to the publish.

1:53One vague ask

The starting point was a Demo folder with seven CSV files in Data: a Sales fact table and six dimensions, Date, Product, Customer, Store, Employee and Promotion 1:27. The data was already clean, on purpose. The run tests the skills, and messy source data would bring problems of its own. This article’s download has the same CSV files, the project the agent built, and its design contract.

The run started with /powerbi-report-design, followed by this prompt:

Please consume the data in the data folder and build me a report on all of our sales metrics. Make it executive facing, and make it about three or four pages. And in particular, I want some geographic analysis in there as well.

With today’s plug-in, invoke powerbi-report-cli instead, or just ask, and it chooses the mode.

The planning step usually interviews you before anything else: who the report is for, what it should do, how many pages, and whether to publish it or only build the project. This prompt already named the audience, the subject, the size and one must-have, so the agent skipped the interview 2:28. Put the same things in your first prompt and the interview gets shorter.

Before it designed anything, the agent profiled the data. Its notes, saved at the top of the spec, record 2,000 sales rows from January 2024 to December 2025 and revenue down 9.2%, from $3.15M in 2024 to $2.86M in 2025.

2:44The design contract

Before any model or page existed, the agent wrote _brief/report-spec.md. The top half is for people: the audience (executive leadership), the purpose, the source files, the data profile, and the four pages. The bottom half is a “Canonical design contract” in YAML, which the later steps follow as the definition of what to build. YAML is a plain-text format in which indentation sets the structure, so the spacing matters 3:22. You don’t have to write it, but you can read it.

The contract gives each page a 12-by-12 grid with named regions. Page 1’s:

layout_contract:
  canvas: { width: 1920, height: 1080, margin: 32, gutter: 24, snap: 8 }
  grid:
    columns: 12
    rows: 12
    regions:
      header:  [1,  1,  10, 2]
      filters: [10, 1,  13, 2]
      kpis:    [1,  2,  13, 4]
      trend:   [1,  4,   9, 9]
      mix:     [9,  4,  13, 9]
      geo:     [1,  9,   7, 13]
      seg:     [7,  9,  13, 13]

Then it places every visual in a region, with the fields it shows and the question it answers. These are the Year slicer and the first of page 1’s five KPI cards, the one this article follows:

- { id: year_slicer, region: filters, kind: slicer, field_bindings: Date[Year], slicer_type: dropdown }
- { id: kpi_revenue,  region: kpis, kind: cardVisual, slot: 1, of: 5, purpose: "Total net revenue and YoY direction", field_bindings: Sales[Revenue], color_strategy: measure_match, insight_basis: "Revenue YoY % vs prior year (-9.2%)" }

Each page ends with a space_audit block that counts the grid cells in use; page 1 reports empty_cell_pct: 0. The full file, with all four pages, the color map and the accessibility notes, is in the download.

Read the contract before you approve it. Check the page list and the question each page answers, the measure named in every visual’s field_bindings, the color map, and the slicers on each page. Give the agent your guidance while it writes the spec and the contract, and iterate on it there 8:43. In this run the agent stopped for my approval before it built anything; the video doesn’t show that step. Today’s powerbi-report-cli requires it. Since release 0.3.19, on October 1, 2026, a request to build and publish a new report stops at the finished spec until you approve it in a later reply.

Come back to the contract once the report is built, because the two can drift. This contract asks for a filled map on page 2 and an Orders card on page 1. The finished report has an Azure Maps visual with a bubble layer on page 2, and a Revenue YoY card in place of Orders.

Commit the spec with the project. It can become part of the report’s design specifications 4:22.

4:39The semantic model it builds

Next, semantic-model-authoring turned the CSV files into a semantic model, written as TMDL inside the project in Sales.SemanticModel. From the files it left:

• Seven import tables, one per CSV file, with Date marked as the date table.
• Six relationships, from Sales to each dimension.
• 20 measures, each with a /// description: 16 on Sales, and a count measure on each of Customer, Product, Store and Employee.

If TMDL is new to you, Power BI as Code walks through the format. Once the files were written, the agent validated the model through the modeling MCP server 4:56, the one The Power BI Modeling MCP Server, Hands-On works with. Three of the measures, as the agent wrote them in Sales.tmdl:

	/// Cost of goods sold = unit cost x quantity, summed per line.
	measure COGS = SUMX(Sales, Sales[Unit Cost] * Sales[Quantity])
		formatString: $#,##0
		lineageTag: bb7c2512-b735-4f56-b723-bd80ddd187fc

	/// Gross profit = Revenue - COGS.
	measure 'Gross Profit' = [Revenue] - [COGS]
		formatString: $#,##0
		lineageTag: daaf3dbc-4a4b-4a4d-8baf-11fa01c79cbf

	/// Gross margin as a percent of revenue.
	measure 'Gross Margin %' = DIVIDE([Gross Profit], [Revenue])
		formatString: 0.0%
		lineageTag: 7361edb0-81fe-4e36-9b3c-2f9a6b5c65fb

And the three behind the card this article follows:

	/// Revenue for the same period in the prior year.
	measure 'Revenue PY' = CALCULATE([Revenue], SAMEPERIODLASTYEAR('Date'[Date]))
		formatString: $#,##0
		lineageTag: 46d8d1b9-9254-435b-b780-4c06a0d61995

	/// Year-over-year revenue change in dollars.
	measure 'Revenue YoY' = [Revenue] - [Revenue PY]
		formatString: $#,##0
		lineageTag: 84281bd8-928c-4a17-8efc-5dbd55cdf955

	/// Year-over-year revenue change as a percent.
	measure 'Revenue YoY %' = DIVIDE([Revenue] - [Revenue PY], [Revenue PY])
		formatString: 0.0%
		lineageTag: 08529063-8378-4faa-8231-7a5a2d2a278b

5:27Pages, validation and screenshots

powerbi-report-authoring (today, powerbi-report-cli in authoring mode) wrote the four pages as PBIR in Sales.Report/definition/pages/: a page.json for each page and a visual.json for each of the 43 visuals. In this run the agent wrote a generator script in a temporary folder and produced the files from it, so each fix was a change to the script and a rerun.

Next the agent checked its own work, in the loop of steps 4 and 5 in the diagram above 5:59. It fixed the errors it found in the first render 6:02, opened the project in Power BI Desktop 6:09, and captured a screenshot of every page 6:23. The model hadn’t fully refreshed, so it connected to the local model through the modeling MCP server, refreshed it, and captured the pages again 6:36. Microsoft Learn’s page on the report authoring skill describes the same loop, with the Power BI Desktop CLI opening, reloading and capturing the report; the Desktop bridge article covers that tool.

Reading the screenshots is how the agent finds problems. It reviews each page in turn:

The agent read its own screenshot of each page and listed what to fix.

That review caught two problems besides the year-over-year card 8:04. On page 2 the Azure Maps visual showed an empty world view. The agent turned off the visual’s filled-map layer and turned on a bubble layer sized by revenue (bubbleLayer with sizeByValue on, filledMap off), and the map came back zoomed to the United States, with Florida as the largest bubble. On page 1 the KPI cards rounded $2.86M to “$3M”, so it set the cards’ display units to millions with one decimal place, and the revenue card read $2.9M.

The agent kept its screenshots in folders inside the project, ending with _final_shots, and you can reuse them in wireframes and design documents 7:47. Since release 0.3.19, the skill saves validation screenshots to a temporary folder unless you name a location. It also saved memories, notes for later sessions, about the mechanical problems it had worked through 8:16.

7:30The year-over-year bug it caught

The first screenshot of the Executive Overview showed the Revenue YoY % card at +90.8%, for a business whose revenue fell 9.2%.

Before it raised the card, the agent queried the live model to check the numbers behind the page: revenue of $6.0M, gross profit of $2.32M, a 38.6% margin, 2,000 orders, and an average order value of $3,003, all matching its profile of the CSV files. Then it flagged the card and proposed a fix:

The agent checked the numbers against the live model, then explained the +90.8% and proposed a fix in the report.

The cause was the filter context. With the Year slicer on all years, Revenue adds up 2024 and 2025. SAMEPERIODLASTYEAR shifts those dates back one year, to 2023 and 2024 (Microsoft Learn: it returns the same dates as DATEADD(dates, -1, year)), and 2023 has no rows. So the card compared two years of revenue with one. As the agent put it, the number is “only meaningful for a single year”.

The same measure under two filters.

The agent’s fix was in the report, in two parts. Each page’s Year slicer now saves 2025 as its selection (the slicer’s filter holds the value 2025L), and the four slicers share a sync group, so a change on one page carries to the others:

"syncGroup": {
  "groupName": "YearSync",
  "fieldChanges": true,
  "filterChanges": true
}

And page 1’s page.json stops the Year slicer from filtering the monthly trend chart, so the line keeps all 24 months. The source is the slicer and the target is the line chart:

"visualInteractions": [
  {
    "source": "a4f0a509ad8152e6f4e7",
    "target": "cebbc5bab389e1f80db2",
    "type": "NoFilter"
  }
]

After the change, the card reads -9.2% and the trend shows the decline across both years:

The finished Executive Overview, in the agent’s own final screenshot.

The agent caught the bug because it looked at a rendered page, the way a person would, so it can only catch what it renders, and you still have to look too.

A reviewer would also notice that a default slicer value is a choice the reader can undo: clear the slicer, and the card shows +90.8% again. One option is a measure that returns blank unless exactly one year is in the filter context:

Revenue YoY % =
IF (
    HASONEVALUE ( 'Date'[Year] ),
    DIVIDE ( [Revenue] - [Revenue PY], [Revenue PY] )
)

With one year selected, the card works as before. With every year selected, it’s blank instead of wrong.

9:00Published, but empty

There are two ways to get the report into the service. Power BI Desktop’s Publish button uploads the semantic model, the report, and the data cached in the model 9:02. Or you ask the agent, as this run did: “please publish this to the sales performance demo workspace” 9:12, which handed the job to the management skill.

The agent got a token for the Fabric API from the Azure CLI:

az account get-access-token --resource "https://api.fabric.microsoft.com" --query accessToken -o tsv

It passed the token to a Python script it wrote, which called the Fabric REST API twice: first to publish the Sales semantic model to the workspace, then to publish the Sales Performance report bound to it.

Two details came up that you’d also hit doing this by hand. The local definition.pbir points at the model by path:

"datasetReference": {
  "byPath": {
    "path": "../Sales.SemanticModel"
  }
}

A published report has to point at the published model instead, so the agent published it with a byConnection reference. And in this run, the service rejected the PBIR schema versions in the files, so the agent changed the $schema versions from 2.0.0 to 1.2.0 and added a layoutOptimization property to report.json before the report would publish 10:17:

The report published after two changes for the service, and the agent went on to check whether the model had data.

The report opened in the service with errors where its visuals should be 10:32. A publish sends the semantic model’s definition, which for the Fabric REST API is its TMDL files and definition.pbism (Microsoft Learn). The imported data lives in cache.abf in the project’s .pbi folder, which isn’t part of the definition. So the service got the model’s metadata and schema, and no rows 10:38.

To fill the model you need a refresh, and a refresh needs a source the service can reach. This model reads files in C:\Demo\Data, so the service needs an on-premises data gateway, in standard or personal mode, with those files set up as its data sources (Microsoft Learn). A source the service can reach directly makes this smoother; the video’s example is an Azure SQL database 10:04. Or publish from Power BI Desktop, which takes the cached data along 10:49. Publishing took the agent about 15 more minutes 10:21.

11:03Verdict: a fast junior developer

My verdict is to treat these skills like a really fast junior developer. The agent isn’t entirely independent, but it did a good job of troubleshooting the problems it found, and in about an hour it did what would probably take a junior developer the better part of a week, or at least a few days 11:04.

Its work needs the review you’d give any new developer’s. A checklist from this run:

• Approve the design contract before the agent builds, and compare it with the finished report.
• Read every measure, and check two or three numbers against a source you trust.
• Look at every page with the slicers set, and again with them cleared.
• Plan the refresh, through a gateway or a source the service can reach, before you publish.

Point it at a new report you’ve been meaning to build, or at an existing one. Keep the project in source control, as Get Your Power BI Reports AI-Ready with GitHub sets up, so every change the agent makes is a diff you can read. Then review that diff before anyone else sees the report.