power-bi-agentic-development: A Claude Code and Copilot Plugin Marketplace for Power BI and Fabric Work
Power BI AI skills and Power BI agents for Claude Code and GitHub Copilot: a plugin marketplace of Power BI skills, subagents, and hooks for semantic models, DAX, TMDL, reports, and AI dashboards. Includes Microsoft Fabric skills and Fabric agents. Weekly updates.
At a glance
- What is it?
- A GPL-3.0 marketplace of Power BI and Microsoft Fabric skills, subagents and hooks distributed as installable plugins. The interesting part is the packaging, not the prompts, and the release notes admit versions 26.26 through 26.38 are a deliberate breaking transition.
- Who is it for?
- Adopt this if your team already drives Claude Code or Copilot CLI against PBIP projects and wants Power BI domain instructions loaded without hand-writing them. Do not adopt it if you need a frozen, auditable toolchain: the maintainers state that 26.26 through 26.38 will rename, consolidate and remove skills between weekly releases, so pin 26.25 or earlier if you depend on the pre-transition layout.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 38 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: agents that do not know TMDL from a TMDL file name
A general coding agent asked to edit a semantic model has no reliable prior about the file formats involved. It may not know that a Power BI project can be stored as PBIP with TMDL parts, that measures and calculated columns live in different TMDL object types, or that a paginated report and a Power BI report are different artifacts with different tooling. The repository's own framing is that a plugin is a collection of resources that help coding agents perform better, typically special instruction files and scripts, and that this marketplace is focused on everything that helps an agent work with Power BI and Fabric. That is the problem statement: agent context, not agent capability.
The audience is narrow and identifiable. You need to be using Claude Code or the standalone Copilot CLI as your working environment, and you need to be doing Power BI or Fabric work inside it. Someone who writes DAX in the Power BI Desktop formula bar and never opens a terminal gets nothing from this. Someone who has already built their own CLAUDE.md and instruction files for their semantic model conventions may find the plugin set redundant or actively conflicting with their own rules.
Marketplace, plugins, skills, subagents, hooks: what is actually in the box
The repository is an Anthropic-format plugin marketplace, which the README distinguishes carefully from a single distributable plugin. The root .claude-plugin/ directory contains only marketplace.json, a catalog. The actual payload lives in child plugins under plugins/, and the install commands name them: goblin-mode, tabular-editor, pbi-desktop, pbip, semantic-models, reports, paginated-reports, custom-visuals, fabric-cli, fabric-admin, etl. Each of those is a bundle of instruction files and scripts.
The README's taxonomy is worth taking literally. Plugins can contain skills, subagents, hooks, and MCP servers. Skills are the instruction layer, and Copilot CLI reads them from skills/<name>/SKILL.md. Subagents are separate agent definitions you can browse with /agent. Hooks are the part with real teeth: they run at defined points in the agent loop, which is where a marketplace like this stops being a prompt library and starts being executable policy. The README does not enumerate which hooks ship in which plugin, so treat hook behaviour as something to inspect in the repository before you enable it.
The topics list confirms the surface area: DAX, TMDL, semantic-model, PBIP, reporting, plus Microsoft Fabric. Note that the repository's primary language is C#, which is consistent with Power BI tooling (Tabular Editor is a C# tool, and the badge row includes it) rather than with the instruction files themselves.
Installation: two paths, and one that silently does nothing
For Claude Code, the README gives this as the entry point:
claude plugin marketplace add data-goblin/power-bi-agentic-development
After that, plugins are installed either through the /plugin interface or from the command line, for example:
claude plugin install pbip@power-bi-agentic-development
Copilot CLI reads the same .claude-plugin/marketplace.json manifest, so the layout works without modification. Two install forms are documented. The first registers the marketplace and then installs a named child:
copilot plugin marketplace add data-goblin/power-bi-agentic-development copilot plugin install tabular-editor@power-bi-agentic-development
The second skips registration and installs straight from a subdirectory:
copilot plugin install data-goblin/power-bi-agentic-development:plugins/pbip
The README calls out a trap explicitly. Running copilot plugin install data-goblin/power-bi-agentic-development with no qualifier installs nothing useful, because the root is a marketplace catalog rather than a plugin. That is a good piece of documentation: it anticipates the exact mistake the directory structure invites.
Verification inside Copilot CLI uses /env for loaded instructions, MCP servers, skills, agents and plugins; /plugin list for installed plugins; /skills list and /skills info pbip for skill-level detail; and /agent to browse installed agents. Those commands are your audit surface. Run them after install and read what actually loaded, because a marketplace install that reports success tells you nothing about whether a given skill was picked up.
The Windows path limit is a real install blocker, not a footnote
TMDL files, the README states, have a problem with repository-relative paths over 260 characters. Windows' legacy MAX_PATH blocks git clone from writing them unless long path support is enabled at both the OS and git level. Without that, copilot plugin install aborts with Filename too long.
The repository ships a script, useful-stuff/agent-scripts/enable-windows-longpaths.ps1, intended to be run from an elevated PowerShell environment, and the README recommends a reboot after the registry change. The git side is a separate switch:
git config --system core.longpaths true
This is the kind of constraint that decides adoption for a Windows-based BI team. It is not a bug in the marketplace; it is an interaction between deep plugin directory nesting and a documented Windows OS limitation. But it means a locked-down corporate machine where you cannot edit the registry or run an elevated script is a machine where the clone step fails before any skill is useful. If your Power BI developers work on managed Windows laptops without local admin, test the clone before you plan anything around this repository.
The breaking transition is the single most important line in the README
The maintainers put a warning at the top: the skills are under active development with a weekly release cadence, so expect regular renaming and restructuring. Then they go further and name the window. Versions 26.26 through 26.38 are described as a deliberate breaking transition, in which skills may be consolidated, renamed, removed, or made less automatic between weekly releases. The README instructs readers to pin 26.25 or earlier if they need the pre-transition structure and behaviour, and says not to assume compatibility from one transition release to the next.
That is unusually candid, and it should drive your decision. The recent release list shows how fast the cadence runs: v26.30.0, v26.30.1 and v26.31.0 all landed within about a week in July 2026. A weekly cadence plus an announced restructuring window means any internal documentation you write against specific skill names has a short shelf life. The phrase made less automatic is the one to watch: if your workflow depends on a skill firing without being asked, a release inside the transition window can take that away, and the failure will look like the agent ignoring you rather than like a version change.
There is no deprecation table in the supplied material mapping old skill names to new ones. If you need one, you will be reading release notes yourself.
Where this is the wrong tool, and what to use instead
This marketplace assumes an agentic terminal workflow. If your team's Power BI development happens entirely in Power BI Desktop with Tabular Editor or DAX Studio attached, none of these plugins do anything for you, because there is no agent reading the instruction files. The natural alternative in that world is Tabular Editor itself, which the repository's own badge row references. The difference in approach is fundamental: Tabular Editor applies deterministic, scriptable transformations to a model through its own API and CLI, so a rename or a measure rewrite is a command with a predictable result. A skill is an instruction to a language model, and the result is a model's best interpretation of that instruction. Determinism versus adaptability. If your changes must be reproducible in a deployment pipeline, prefer the deterministic tool and treat agent skills as authoring assistance, not as the pipeline step.
There is a second mismatch. This repository is a catalog of Power BI-specific knowledge, not a Power BI connector. It does not appear to give the agent live access to a Fabric workspace on its own; that would come from MCP servers or the fabric-cli and fabric-admin plugins, and the README lists MCP servers as a possible plugin component without stating which ones ship where. If your goal is an agent that can query a semantic model directly, verify the MCP side of the relevant plugin before assuming the marketplace covers it. The README does not confirm it for you.
Licence and maintenance: GPL-3.0 on instruction files
The repository is GPL-3.0. For a collection of skill definitions, subagents and hooks, that choice is worth pausing on. GPL-3.0 is a copyleft licence, and the practical question is what counts as a derivative work when the material is prompt text and scripts rather than linked code. If you copy a SKILL.md into your own internal plugin and distribute it, or ship a product that bundles these plugins, the licence terms apply to that distribution. Internal use inside your own organisation is a different situation from redistribution. This is not legal advice, and the boundary between configuration text and program is exactly the kind of question your own counsel should answer if you plan to redistribute anything derived from these files.
On maintenance cost, the material supports one concrete figure: a weekly release cadence, with three releases in roughly a two-week span visible in the release list. If you install the marketplace and enable auto-update, you inherit that cadence whether or not you want it, and during the 26.26 to 26.38 window an auto-update can change skill names under you. The lower-cost configuration is to pin a version outside the transition window and update deliberately, reading the release notes before each bump. The higher-cost configuration is auto-update plus a team that has built habits around specific skill names. Pick based on how much of your workflow depends on the agent behaving the same way tomorrow as it did today.
Who should install it, and the three things to check first
Install it if you are already running Claude Code or Copilot CLI against PBIP or TMDL-based Power BI projects and you are tired of re-explaining semantic model structure in every session. The multi-plugin split is sensible: you can take pbip and semantic-models without pulling in fabric-admin, which keeps unrelated instructions out of your agent's context. Start with the marketplace add command, install one plugin, and run /skills list to see what landed before adding more.
Do not install it if you need a stable, versioned tool interface for a deployment pipeline, or if you cannot enable Windows long paths on the machines that will clone it. Both of those are hard stops visible in the README rather than edge cases.
Three things to verify yourself, because the supplied material does not settle them. First, read the SKILL.md files inside plugins/pbip and plugins/semantic-models to see what instructions will be injected into your agent's context and whether they conflict with your existing project rules. Second, check which plugins actually ship MCP servers, since the README lists MCP as a possible plugin component without saying where. Third, confirm your intended use against GPL-3.0 before you redistribute anything. The version you pin matters more than the feature list here: 26.25 or earlier for stability, and treat anything in the 26.26 to 26.38 range as a moving target by the maintainers' own description.
Editorial conclusion
Adopt this if your team already drives Claude Code or Copilot CLI against PBIP projects and wants Power BI domain instructions loaded without hand-writing them. Do not adopt it if you need a frozen, auditable toolchain: the maintainers state that 26.26 through 26.38 will rename, consolidate and remove skills between weekly releases, so pin 26.25 or earlier if you depend on the pre-transition layout. Before installing anything, open plugins/pbip and plugins/semantic-models in the repository, read the SKILL.md files that will be loaded into your agent's context, and confirm the GPL-3.0 terms suit how you intend to redistribute anything you build on top.
Community notes