# power-bi-agentic-development: Power BI skills and subagents for Claude Code and GitHub Copilot > A plugin marketplace that teaches coding agents Power BI and Microsoft Fabric, covering semantic models, DAX, TMDL, reports and paginated reports. The install path is short; the versioning policy is the part that needs reading first. **data-goblin/power-bi-agentic-development** — 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. - Repository: https://github.com/data-goblin/power-bi-agentic-development - Website: https://data-goblins.com - Stars: 953 · Forks: 141 - Language: C# - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/data-goblin-power-bi-agentic-development ## What power-bi-agentic-development actually installs Coding agents are good at general software work and weak at domain conventions they were never handed. Power BI is a domain with a lot of them: TMDL syntax, PBIR report layout files, DAX evaluation context, the difference between a semantic model and the report sitting on top of it. This repository packages those conventions as agent-readable resources so Claude Code or GitHub Copilot stops inventing table names and measure definitions. The unit of distribution is a plugin marketplace in Anthropic format. The repository root holds a single `.claude-plugin/marketplace.json` catalog, and the actual content lives under `plugins/`. A plugin bundles skills, subagents, hooks and MCP servers around one topic. The README lists eleven child plugins, among them `goblin-mode`, `tabular-editor`, `pbi-desktop`, `pbip`, `semantic-models`, `reports`, `paginated-reports`, `custom-visuals`, `fabric-cli`, `fabric-admin` and `etl`. Who this is for: a BI developer or analytics engineer who already uses an agentic coding tool daily and wants Power BI artifacts in the same loop. It is not a Power BI add-in, not a desktop extension, and not something that runs inside Power BI Desktop. It changes what your agent knows. ## How skills, subagents and hooks reach the agent The mechanism is file-based instruction loading, not a runtime library. Copilot CLI reads `skills//SKILL.md` for each skill, and the README states that skills load identically between Claude Code and Copilot CLI. Because Copilot CLI also reads the same `.claude-plugin/marketplace.json` manifest, the marketplace and child-plugin layout transfers without modification. That is the design decision worth noticing: the repository targets one manifest format and gets a second host for free. Subagents are the second layer. Where a skill is passive context, a subagent is a named worker the host agent can hand a task to, and the README notes that agents differ in how they are wired between the two hosts. Hooks are the third layer, scripts that fire on agent events rather than on request. The practical consequence is that the same repository produces different behaviour depending on which host you run. A plugin that works cleanly in Claude Code may need different agent wiring under Copilot CLI. The README separates the compatibility notes for exactly this reason, and that section is where the divergence is documented. ## Installing the marketplace and running a first task Installation happens in the terminal, before you open a Power BI project. In Claude Code, the README gives a single command to register the marketplace: ```bash claude plugin marketplace add data-goblin/power-bi-agentic-development ``` After that, plugins are installed either through the `/plugin` interface, where you navigate to the installed marketplace, or from the command line. The README shows the command-line form for each child plugin, for example: ```bash claude plugin install tabular-editor@power-bi-agentic-development claude plugin install pbip@power-bi-agentic-development ``` The README also documents enabling marketplace auto-update through the same interface. Given the weekly release cadence and the deliberate breaking transition described below, auto-update is a decision rather than a default you should accept without thinking about it. For Copilot CLI there are two documented paths. The first registers the marketplace and then installs a named child plugin: ```bash copilot plugin marketplace add data-goblin/power-bi-agentic-development copilot plugin install tabular-editor@power-bi-agentic-development ``` The second skips marketplace registration and installs one plugin straight from its subdirectory: ```bash copilot plugin install data-goblin/power-bi-agentic-development:plugins/pbip ``` The README is explicit that the bare form without a qualifier installs nothing useful, because the root is a catalog rather than a plugin. That is a real trap: the command looks correct and produces no working skills. Verification is done inside an interactive Copilot session, where the README lists slash commands including `/env` for loaded instructions and MCP servers, `/plugin list` for installed plugins, `/skills list` for available skills, `/skills info pbip` for one skill's details, and `/agent` to browse installed agents. If `/skills list` is empty after an install, the install did not take, and the qualifier is the first thing to check. ## The 26.26 to 26.38 transition window The README carries a warning that deserves more weight than a warning usually gets. Skills are under active development on a weekly release cadence, and versions 26.26 through 26.38 are described as a deliberate breaking transition. Within that range, skills may be consolidated, renamed, removed, or made less automatic from one weekly release to the next. The README tells readers to pin 26.25 or earlier if they need the pre-transition structure, and warns against assuming compatibility from one transition release to the next. That is an unusually honest statement, and it also means the project is not a dependency you can float. The three most recent releases are v26.31.0 on 2026-07-29, v26.30.1 on 2026-07-27 and v26.30.0 on 2026-07-22, all inside the transition window. The last push to the repository was on 2026-08-08. If your team writes runbooks that name a plugin, or if you share prompt snippets internally that reference a skill by name, a rename breaks them silently. The failure mode is not an error message. It is an agent that quietly stops loading the skill you thought was there, and answers from general knowledge instead. Verification after every upgrade is the only defence the project offers. ## Windows long paths break the clone before the install The most concrete limitation documented is a Windows one. TMDL files produce repository-relative paths over 260 characters, and the legacy MAX_PATH limit blocks `git clone` from writing them unless long path support is enabled at both the operating system and git level. Without it, the README states that `copilot plugin install` aborts with `Filename too long`. The repository ships an example script at `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. It also gives the git-side setting: ```powershell git config --system core.longpaths true ``` Note the scope. `--system` writes a machine-wide git setting, which on a shared or managed build agent is a change someone else has to approve. On a locked-down corporate image you may not be able to make it at all, in which case this project is simply not installable on that machine regardless of how well the skills fit your work. That is a genuine wrong-tool case, and it has nothing to do with the quality of the skills. The second limitation is scope. Everything here assumes an agentic coding host. If your team works in Power BI Desktop and the Service only, with no Claude Code or Copilot CLI in the loop, none of this applies to you. ## How this differs from plain Power BI documentation The obvious alternative is not another plugin marketplace. It is the Microsoft documentation set plus the agent's own general knowledge, which is what most people start with. The difference in approach is where the domain knowledge lives. Microsoft Learn is written for a human reading a page, and the agent has to retrieve and interpret it on every task. This repository puts the same domain material into files the host loads automatically, so the agent starts a Power BI task already holding the conventions rather than searching for them. That trade is not free. Documentation is versioned by Microsoft and stays current. Skills in this repository are versioned by a weekly cadence and, during the transition window, are explicitly unstable. You are exchanging stability for immediacy. A second difference is that the marketplace covers the surrounding process, not just the artifact. The plugin list includes `fabric-admin` and `etl` alongside `semantic-models` and `reports`, so workspaces, deployment pipelines and transformation work sit in the same agent context as the model itself. Documentation rarely bundles those together, and an agent that can reason across a model and its deployment path is doing something a documentation lookup cannot. ## Licence and the cost of keeping up The repository is GPL-3.0. For a plugin marketplace of instruction files and scripts, the practical question is what your organisation does with derivative plugins. If you fork a skill, adapt it internally, and distribute the result, GPL-3.0 carries obligations that a permissive licence would not. If you install and use it internally without redistribution, the everyday impact is smaller. This is a description of the licence, not legal advice; the compliance question belongs with whoever handles open source in your organisation. Upgrade cost is the more immediate budget item. The README states a weekly release cadence, and the transition window means a weekly release can rename or remove a skill. Three releases landed between 2026-07-22 and 2026-07-29, which is a dense stretch. Every upgrade is a verification pass: confirm the plugins you depend on still exist under the same names, and confirm the skills still load. Pin deliberately. The README's own guidance is to pin 26.25 or earlier if you need the pre-transition structure, which implies the maintainers expect pinned users to exist. Treat the version number as part of your configuration, not as background noise. ## Conclusion Adopt it if you already drive Power BI work through Claude Code or Copilot CLI and you want the agent to read TMDL, PBIP and DAX conventions instead of guessing at them, and pin a version before you build habits around a plugin name. Do not adopt it if you need a stable API surface across months, or if you work outside the Microsoft BI stack entirely. Verify two things first: which transition release you are installing, and whether your checkout path survives the Windows MAX_PATH limit, because a truncated clone fails before any skill loads. ## FAQ ### How can agentic AI be used in Power BI with power-bi-agentic-development? The repository packages Power BI and Microsoft Fabric knowledge as plugins for coding agents such as Claude Code and GitHub Copilot, so the agent can work on semantic models, DAX, TMDL, reports and paginated reports with domain conventions loaded. The README describes agentic development as using agents to build, manage and optimise artifacts including workspaces and deployment pipelines. ### How do I install power-bi-agentic-development in Claude Code? Run the marketplace add command in the terminal, then install named child plugins either through the /plugin interface or from the command line. The README shows the marketplace command and one install command per plugin, for example tabular-editor and pbip. ### Does power-bi-agentic-development work with GitHub Copilot CLI? Yes. Copilot CLI reads the same .claude-plugin/marketplace.json manifest the repository uses, so the marketplace and child-plugin layout works without modification. You can either register the marketplace and install a named child plugin, or install a single plugin directly from its subdirectory. ### Which version of power-bi-agentic-development should I pin? The README states that versions 26.26 through 26.38 are a deliberate breaking transition in which skills may be consolidated, renamed, removed or made less automatic between weekly releases. It advises pinning 26.25 or earlier if you need the pre-transition skill structure and behaviour. ### Why does installing power-bi-agentic-development fail with Filename too long on Windows? TMDL files produce repository-relative paths over 260 characters, and the legacy MAX_PATH limit blocks git clone from writing them unless long path support is enabled at both the OS and git level. The README points to useful-stuff/agent-scripts/enable-windows-longpaths.ps1 as an example script and recommends a reboot after the registry change. ## Sources - [data-goblin/power-bi-agentic-development on GitHub](https://github.com/data-goblin/power-bi-agentic-development) - [License: GPL-3.0](https://github.com/data-goblin/power-bi-agentic-development/blob/main/LICENSE) - [Project website](https://data-goblins.com) - [README](https://github.com/data-goblin/power-bi-agentic-development/blob/main/README.md) - [Releases](https://github.com/data-goblin/power-bi-agentic-development/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/data-goblin-power-bi-agentic-development