/powerbi-report-cli

name: powerbi-report-cli
description: "Plan, design, author, preview, publish, and manage Power BI reports across requirements, page design, local PBIR/PBIP edits, validation, screenshots, Fabric upload/download, and rebinding. Use for report lifecycle work; use semantic-model-authoring for model or DAX changes and fabriciq for data questions. Triggers: plan Power BI report, design report page, edit PBIR, preview PBIP, publish report, rebind report"
metadata:
  version: 1.0.5

> **Telemetry — MANDATORY.** Every `api.fabric.microsoft.com` call must carry > `x-ms-fabric-skill: powerbi-report-cli` (`az rest`: `--headers "x-ms-fabric-skill=powerbi-report-cli"`), > including every LRO poll, `fabric_lro` and retry. Snippets omit it — add it anyway.

> **CRITICAL NOTES** > 1. To find workspace details, including its ID, from a workspace name: list > all workspaces, then use JMESPath filtering. > 2. To find item details, including its ID, from a workspace ID, item type, > and item name: list all items of that type in that workspace, then use > JMESPath filtering. > 3. Use `powerbi-report-cli` for the report artifact: requirements, design, > PBIR/PBIP page and visual edits, preview, and publishing. Semantic model, > measure, and DAX work belongs to a semantic-model skill. Natural-language > questions about report data belong to `fabriciq`.

Power BI Reports - CLI Skill

This skill owns the Power BI report lifecycle end to end: requirements and scope, visual design, local PBIR/PBIP authoring and preview, and report-item transport to and from Microsoft Fabric.

It is a **mode dispatcher** and intentionally contains no detailed procedures. Select the mode that matches the request, then read the matching mode reference end to end before acting. The mode file holds the required workflow, commands, payloads, templates, and failure rules.

Mode Selection

| Mode | Use when the request... | Existing route examples | Read first | |---|---|---|---| | `planning` | creates a new report/dashboard and needs requirements, model/dependency inspection, scope, a page plan, and approval before implementation | create a report, build a dashboard, create from a semantic model, plan then implement, walk me through creating a report | [references/planning.md](references/planning.md), then [references/planning-part-02.md](references/planning-part-02.md) | | `design` | decides what a report should look like: tone, signature, page archetype, chart type, layout, color, typography, theme direction, accessibility, brand application, redesign, or critique | design a Power BI report, make the dashboard professional, choose a chart, apply a brand, redesign the report, create a design brief | [references/design.md](references/design.md) | | `authoring` | reads or edits local PBIR/PBIP files, validates them, previews the report, or captures screenshots | edit PBIR, create/add a report page or visual, format a visual, add filters/slicers/bookmarks/themes, validate PBIR, preview/reload/screenshot in Desktop or service | [references/authoring.md](references/authoring.md) | | `management` | moves a report definition to or from Fabric or manages the workspace report item | publish/upload/download PBIR or PBIP, list reports, get/update/delete a report, rebind a report | [references/management.md](references/management.md) |

Mode Boundary Rules

• Classify by **intent**, not by which file or tool is already open.
• `design` decides what the report should look like; `authoring` writes the

PBIR that realizes it. Choosing a chart type is `design`; encoding it into `visual.json` is `authoring`.

• Restyling or reformatting an existing local report is `authoring`, even when

the request uses design language. Use `design` when the user wants advice or a design contract rather than a file change.

• `authoring` changes local files and performs preview/validation. It does not

publish to Fabric.

• `management` transports definitions and manages Fabric report items. It does

not invent or directly author PBIR content.

• `planning` owns the guided requirements-to-approval flow for a new report. A

focused edit to an existing report goes directly to `authoring`.

A greenfield request can span modes in this order:

planning -> design -> authoring -> management

Handle one mode at a time. Announce each switch and read the new mode reference before starting that part. The `planning` approval gate is a turn boundary: never build or publish until the user explicitly approves the locked spec in a later reply.

> **GREENFIELD APPROVAL BARRIER — MANDATORY.** When a new-report request asks > to plan, build, and/or publish but the user has not approved a locked spec in > a prior reply, set the current phase to `approval_pending` and keep > `planning` as the only active mode. In this phase, do not load `authoring` or > `management`, edit/scaffold PBIR or semantic-model files, generate synthetic > data, call Fabric write APIs, or publish. Persist `_brief/report-spec.md`, ask > for explicit approval, and end the turn. The build/publish wording in the > original request is desired future scope, not approval to cross this barrier.

Required Deliverable by Mode

| Mode | Completion requirement | |---|---| | `planning` | Persist `_brief/report-spec.md` or the user-named equivalent, ask for explicit approval, and stop before implementation. | | `design` | Produce the complete `Design Brief:` contract, including `design_identity` and a page archetype/layout contract for every page. Do not edit PBIR or call Fabric APIs. | | `authoring` | Persist the requested PBIR/PBIP changes, validate each logical batch, then complete the selected preview and screenshot-review workflow required by the authoring reference. Do not publish. | | `management` | Complete the requested Fabric report operation, including LRO polling and documented readback verification. |

Rules

MUST

• Select the narrowest mode that fully c