Pre-release — used regularly by the maintainer in real Fabric work, evolving fast. Contributions and feedback welcome.
Bootstrap a Fabric-ready Copilot agent workspace for VS Code.
The 30-second version
- What — a one-click installer that scaffolds an opinionated Microsoft Fabric development workspace in VS Code.
- Who it's for — anyone working in Fabric (semantic models, data engineering, reports, pipelines, admin, app dev, DevOps) who wants Copilot agents that already know the right tools and house conventions.
- How to run — double-click
Setup-FabricAgenticWorkspace.bat, answer a few prompts, and let it scaffold.- What you get — a numbered 47-agent organisation (10 clear dropdown entries + 37 delegated workers), three embedded Fabric skills, two curated open-source skill sources, optional CLI/MCP tooling, optional GitHub/Azure DevOps repository onboarding, and governed DEV→PROD guidance.
Windows installer (PowerShell +
.bat); the workspace itself is OS-agnostic once created.
The demo video demonstrates the guided installation flow: launch the installer, answer the setup prompts, let the workspace scaffold, and open the configured VS Code environment with agents, skills, and optional live tooling ready to use.
In this recording, the main requirements are already installed. Setup always verifies Git, VS Code 1.117.0+, the Fabric extension, and the recommended TMDL extension first. Missing/outdated Git or VS Code stops setup; supported optional runtimes and tools follow the install rules documented below.
az) is the dependency most likely to take longer
when it needs to be installed from scratch.
- Why this exists
- What is this?
- What you get
- Agent → tools → skills matrix
- Agentic design principles
- Prerequisites
- Quick start
- What the agents can do
- Workspace structure
- How it works under the hood
- FAQ
- Current status (v0.7.0)
- Contributing
- Files in this repository
- License
- Third-party notices
This is a personal project — and like most personal projects, it started from a real need.
I was doing a lot of work across Microsoft Fabric: building semantic models, doing ETL with Spark notebooks, designing data pipelines, and managing workspaces — all while adapting my workflow to the dynamic and always evolving agentic development.
The Microsoft Fabric and Fabric Data Engineering - Remote VS Code extensions are great for syncing items locally and running notebooks against remote Spark. But the AI-assisted development experience felt like it could be improved: GitHub Copilot didn't know about my TMDL and DAX best practices — particularly my own conventions around table naming, measure structures, and folder organization. Furthermore data pipeline JSON authoring wasn't really covered anywhere I looked.
So I built a multi-agent workspace that brings everything together. A master agent coordinates session startup and routes into specialist teams — each focused on a specific Fabric workload (semantic models, data engineering, admin, reports, pipelines, app dev, and DevOps/ALM). They all read from what I consider the best skill repositories from the community — Microsoft's skills-for-fabric and data-goblin's power-bi-agentic-development — plus custom embedded skills for TMDL and data pipeline authoring that I wrote from scratch and keep updating, based on my job and the problems I face there.
As I went deeper I realised the agent → tools → skills chain matters as much as the agents themselves. So each agent now owns a minimum, deterministic set of tools — the right CLI for its workload (fab, az, sqlcmd, pbir, Tabular Editor CLI, pbi-tools, gh, az devops) and the MCP servers where they help — instead of a vague "all tools to everyone" pile. Tool availability is discovered once and recorded in a machine-specific tool-status.json inventory. An agent then checks what's actually installed, uses it if present, and falls back cleanly when it isn't — which is what keeps the whole thing working on locked-down corporate PCs. A custom fabric-cli-policy skill encodes the decision rule: prefer fab, with az as a documented fallback. And each agent loads only the skills its current subtask needs rather than eagerly reading everything.
This is a starting point, not a finished system. V0.6 evolved the previous nine-agent set into a Master-led organisation: two cross-domain reviewers, seven Team Leads, and 37 focused workers, plus a Capability Maintenance team for skill, agent and tool upkeep. V0.7 fine-tunes how that organisation works together: nested delegation is configured by the installer, every agent carries specialist knowledge drawn from the custom, Microsoft and Kurt skills, the teams share one WORK ORDER / WORK RESULT contract, destructive work is gated behind explicit approval tokens, and the vendor skill refresh is more robust. The architecture remains additive: users still download the same two installer files and receive the same clean workspace shape.
Then I thought: this should be replicable. Not just for me — for anyone who works with Fabric and wants an AI-powered development workflow. So I packaged everything into a one-click installer and a shareable agent configuration.
⚠️ Disclaimer — Please read before usingThis is a personal and community project, built in my spare time for fun and to share something useful. It is not an official Microsoft product, is not affiliated with Microsoft in any way, and comes with no guarantees of any kind.
AI involvement: This project was built with significant help from GitHub Copilot in VS Code. Copilot assisted in writing the installer scripts, agent configuration files, custom skills, documentation, and a large portion of the "heavy lifting" — from structuring the codebase and handling edge cases, to generating boilerplate and refining prompts. The core ideas, design decisions, and testing are mine; the speed at which it came together is Copilot's.
Early stage — use with care: This is very much a pre-release version. It has been tested and works, but it is at the beginning of its life. Given the level of AI involvement in its creation, there may be bugs, edge cases, or behaviours that do not work as expected in your specific environment. Do not use this in production environments without fully understanding what the scripts do. Always review the code before running it.
Third-party skill dependencies: This workspace clones and depends on two external repositories — microsoft/skills-for-fabric and data-goblin/power-bi-agentic-development. These are independent open-source projects maintained by their respective owners. This project has no control over their content, availability, or future changes. The agents are resilient to these repos restructuring or renaming their internal folders — every skill folder is registered natively at install time, each agent's pinned skill paths are re-resolved on every run (a renamed folder is matched by prefix and annotated, a missing one falls back to keyword discovery), and new upstream skills auto-attach to the right specialist by topic keywords. However, if a whole repository is renamed, moved, or removed at the GitHub level, the clone/update step will break until the references are updated.
Licensing & provenance:
skills-for-fabricis MIT-licensed;power-bi-agentic-developmentis GPL-3.0 and is used only as a locally cloned, gitignored reference that agents read at runtime — it is never copied, AI-rewritten, or redistributed inside this project. The custom embedded skills (fabric-tmdl,fabric-pipelines, andfabric-cli-policy) are original maintainer-authored works in this repository — written from scratch (fabric-tmdlandfabric-cli-policyfrom my own best practices;fabric-pipelinesderived from Microsoft sources combined with my working experience). Always check those repos directly for their own licensing terms and usage conditions.This project is used regularly by the maintainer in real Microsoft Fabric work, including local, live, and hybrid workflows on a locked-down corporate Windows machine. It is still pre-release: the structure is covered by an automated test suite and the organisation has been exercised end-to-end (including a live Fabric publish), but agent behaviour is prompt-driven and keeps being tuned from real use.
That said — it is a practical starting point, and I hope it saves you time and sparks ideas. Feedback, bug reports, and contributions are very welcome.
This is a guided workspace bootstrapper and multi-agent Copilot configuration for Microsoft Fabric development in VS Code. Instead of manually setting up folders, config files, agent definitions, skill references, and cloning repositories, you run a single script and everything is ready.
Once set up, a 47-agent Copilot organisation lives inside your workspace: the Fabric Workspace Master, two executive reviewers, seven specialist Team Leads, and 37 delegated workers. The Capability Maintenance team owns skills, agent coverage, tools, and installer health. All roles use selective Microsoft, community, and custom embedded knowledge.
This project is:
- A VS Code workspace bootstrapper for Microsoft Fabric developers
- A GitHub Copilot Chat / Agent Mode workspace configuration bundle
- A local-first Fabric development accelerator with optional live tooling
- A repeatable way to package the maintainer's real-world Fabric workflow
This project is not:
- An official Microsoft product
- A hosted service or SaaS application
- A GitHub Copilot CLI or Claude Code plugin distribution
- A replacement for Fabric Git integration, deployment review, or workspace governance
- A guarantee that AI-generated edits are correct without human review and testing
This workspace is designed first for VS Code GitHub Copilot Chat / Agent Mode. In that mode, the installer creates local custom agents and embedded skills, then clones Microsoft and data-goblin repositories as local reference sources that those agents can search and read at runtime.
The upstream repositories also provide plugin-oriented workflows for GitHub
Copilot CLI, Claude Code, or compatible agent runtimes. This project does not
redistribute, copy, or install those upstream plugin bundles into its own
.github structure. If you want those CLI/plugin workflows, install and use the
upstream projects directly:
Tool vs runtime — don't conflate them. The Fabric CLI (
fab) is a tool the agents actively call (including from Copilot Chat) to work live against a Fabric workspace — it is central to the live and hybrid modes, not an add-on. GitHub Copilot CLI and Claude Code are something else: alternative runtimes to VS Code Copilot Chat. This project targets Copilot Chat / Agent Mode and is intentionally a lean, curated workspace — its.githubholds only the maintainer's agents and skills, with no plugin hooks, manifests, or bundled plugin items. That curated shape is exactly why it fits Chat / Agent Mode rather than a hook-based Copilot CLI plugin distribution.
Practical advice: if you work in Copilot CLI or Claude Code plugin mode, avoid installing every available plugin into one crowded workspace. Plugins can bring their own agents, skills, hooks, and instructions; too many unrelated plugins can compete for context and make the agent less focused. Create or open a task-specific project folder and install only the plugins that match that work. For example, this is how I would scope a CLI environment, while still deferring to the upstream documentation for exact install commands and current behavior:
| Project scope | Consider installing |
|---|---|
| PBIP / source-controlled Power BI project | pbip |
| Semantic model / DAX / TMDL-heavy work | semantic-models, optionally tabular-editor |
| Power BI Desktop live-model work | pbi-desktop |
| Report / PBIR / visual work | reports, optionally pbip |
| Fabric CLI / service operations | fabric-cli |
| Fabric admin / governance work | fabric-admin |
In short: use this installer for the VS Code Copilot Chat / Agent Mode workspace. For CLI/plugin workflows, use a focused project folder and install only the upstream plugins that fit the project.
| Component | Description |
|---|---|
| 000 — Fabric Workspace Master | Primary contact: startup, intent classification, working-mode choice, minimum-team routing, one-writer ownership, and one consolidated result |
| 001 — Fabric Solution Architect | Cross-domain architecture, dependencies, sequencing, ownership, validation, and rollback planning; normally read-only |
| 002 — Integration QA & Change Controller | Independent cross-artifact, security, source-control, and release-readiness validation |
| 010 — Semantic Model Team Lead | Model architecture, relationships/storage, TMDL, DAX, semantic security/AI metadata, validation, and performance |
| 020 — Reporting Team Lead | Report planning, PBIR authoring, themes, custom visuals, paginated reports, and report QA |
| 030 — Data Engineering Team Lead | Spark/notebooks, Lakehouse/Delta/MLV, Warehouse, SQL Database, Dataflows, pipelines, RTI, and ontology |
| 040 — Fabric Administration & Governance Team Lead | Workspace/capacity administration, access/governance, monitoring, catalog, and operations |
| 050 — ALM & DevOps Team Lead | GitHub, Azure DevOps, Fabric Git Integration, deployments/releases, and Power BI ALM |
| 060 — Applications & Integration Team Lead | Python/Fabric SDK, REST/authentication/XMLA, SQL/ODBC, and data-access integrations |
| 070 — Capability Maintenance Team Lead | Microsoft/Kurt repo refresh, skill and agent coverage, tool lifecycle, failed-install recovery, and installer regression |
| Custom TMDL Skill (original to this repo) | Comprehensive embedded skill covering TMDL syntax, indentation rules, property ordering, Direct Lake patterns, lineageTag rules, and post-edit validation. Written from scratch for this project. |
| Custom Pipelines Skill (original to this repo) | Full pipeline activity type reference with typeProperties, expression syntax, Variable Library integration, and validation checklist. Authored for this project. |
| Custom CLI Policy Skill (original to this repo) | Embedded decision policy that tells the agents to prefer the Fabric CLI (fab) and fall back to az/sqlcmd only where needed — with az rest → fab api translation, a fallback matrix for SQL/TDS and non-Fabric tokens, and guardrails. Written from scratch for this project. |
| Microsoft skills-for-fabric | Git-cloned from microsoft/skills-for-fabric — Spark, SQL, Eventhouse, medallion, and more |
| Data-goblin skills | Git-cloned from data-goblin/power-bi-agentic-development by Kurt Buhler — PBIP, DAX, reports, Fabric CLI, Fabric admin |
| Git Version Control | A new target is initialised and receives its expected first commit; existing repositories commit only changed installer-owned paths |
| Business repository onboarding | Optionally clone GitHub or Azure DevOps repositories as independent Git repositories from just a clone URL, mirror their live branches locally, and open them with the workspace in one multi-root VS Code window |
| VS Code Configuration | Settings and tasks pre-configured for the agentic workflow |
The workspace is not skill soup. Each agent has a bounded purpose, owns a
minimum set of deterministic tools, and reads only the skills its current subtask
needs. The CLIs (fab, az, sqlcmd, pbir, Tabular Editor CLI, pbi-tools,
gh, az devops) are binaries invoked through execute, gated on
.github/agent-docs/tool-status.json (a machine-specific, gitignored inventory written by
the installer). The MCP servers are different: they are Copilot frontmatter tools, so
each authorised agent lists the relevant server wildcard (powerbi-modeling-mcp/* or
Fabric MCP/*) in its tools: allowlist — VS Code only exposes an MCP server's tools to an
agent when that wildcard is present, and silently ignores it where the extension is not
installed. If a tool is missing, the agent degrades gracefully; routing is by topic,
never by tool availability.
| Agent | Capabilities | Tools used (via execute, gated on tool-status.json) |
Skills / docs used (selective) |
|---|---|---|---|
| 000 — Fabric Workspace Master | Startup, intent classification, minimum-team routing, one writer per artifact, consolidated outcome | Reads tool status for routing; delegates specialist execution | Copilot/AGENTS startup docs, working-flow reference, only task-relevant skills |
| 001 — Fabric Solution Architect | Cross-domain architecture, dependency maps, sequencing, ownership, validation and rollback | Read/search; delegates approved plans to relevant Team Leads | Orchestration, working modes and source-control safety guidance |
| 002 — Integration QA & Change Controller | Independent cross-artifact, environment, security and release validation | Read/search/execute validation only | Orchestration, working modes and source-control safety guidance |
| 010 — Semantic Model Team Lead | Architecture, relationships, TMDL, DAX, security/AI metadata, model validation | Tabular Editor 2, Modeling MCP/TOM, TMDL, fab, sqlcmd |
fabric-tmdl plus selective Microsoft/Kurt semantic skills |
| 020 — Reporting Team Lead | UX planning, PBIR implementation, themes, advanced visuals, paginated reports, report QA | pbir, report JSON, Desktop verification where available |
Selective Kurt PBIR/report/theme/visual skills |
| 030 — Data Engineering Team Lead | Spark, Lakehouse/Delta, Warehouse, SQL Database, Dataflows, pipelines, RTI, ontology | fab, sqlcmd, Fabric MCP and workload-native tools |
fabric-pipelines plus selective Microsoft engineering skills |
| 040 — Fabric Administration & Governance Team Lead | Workspace/capacity, access/governance, monitoring/catalog/operations | fab, az, Fabric MCP/REST where appropriate |
Selective Microsoft administration/governance skills |
| 050 — ALM & DevOps Team Lead | Git/GitHub/Azure DevOps, Fabric Git, deployments, releases and Power BI ALM | git, gh, az devops, fab, pbi-tools |
Source-control safety, CLI policy and selective definition reads for reviews |
| 060 — Applications & Integration Team Lead | Python/Fabric SDK, REST/auth/XMLA, SQL/ODBC/data-access integration | fab, az, REST, Modeling MCP/TOM, sqlcmd |
CLI policy plus selective Microsoft SDK/integration skills |
| 070 — Capability Maintenance Team Lead | Repo refresh, skill inventory/mapping, agent coverage, tool installs/updates/PATH recovery, installer regression | git plus approved user-scope/portable tool installers and live detection |
Maintenance, tool-policy and source-control safety guidance |
The 37 worker agents sit behind these rows. They inherit the same tool gates and skill-loading rules, but each owns a narrower artifact or validation responsibility.
Every installed/checked tool has a clear agent-level owner — no orphans:
| Tool | Covered by | Status |
|---|---|---|
fab |
Semantic, Data Engineering, Administration, ALM/DevOps, Applications | Covered |
az |
Data Engineering, Administration, ALM/DevOps, Applications | Covered |
pbir |
Reporting | Covered |
Tabular Editor CLI (TabularEditor*.exe) |
Semantic Model | Covered |
pbi-tools |
ALM & DevOps | Covered |
sqlcmd |
Semantic Model, Data Engineering, Applications | Covered |
gh |
ALM & DevOps | Covered |
Azure DevOps CLI extension (az devops) |
ALM & DevOps | Covered |
| Power BI semantic-model MCP server | Semantic Model, Reporting, Applications | Covered |
| Fabric MCP server | Data Engineering, Administration, ALM & DevOps | Covered |
git |
ALM & DevOps, Capability Maintenance | Covered |
| Tool installation/update/recovery | Capability Maintenance | Covered; explicit user approval required |
Note on
tool-status.json: the installer detects each tool (honoring real command names / aliases, e.g. Tabular Editor isTabularEditor.exe/TabularEditor2.exe/TabularEditor3.exe, notte) and recordsfound,version,command,path,category,installMode, and areasonwhen missing. Core tools (Python,fab,az, the two MCP servers) are auto-installed best-effort; the specialist tools (pbir, Tabular Editor,pbi-tools,sqlcmd,gh,az devops) are detect → explain provider/purpose → ask Y/N → best-effort install only on Yes, so nothing heavy is installed silently.
You don't hand-edit tool-status.json — it stays current automatically through three
complementary paths, so a tool you install after setup is picked up without fuss:
- Re-run the installer (update mode). Detection runs on every run before the
"previously declined" check, so a tool you installed yourself is found and flipped to
found: trueon the very next run — even if you'd earlier answered "No" to installing it. Re-running is safe (it never touches your Fabric items) and the recommended way to refresh the whole inventory. - Ask the Capability Maintenance Team Lead. It can refresh the inventory, check
publisher versions, repair PATH, and diagnose a failed installer. Environment & Tooling
may install or update a supported tool only after explicit approval, using the same
user-scope or portable principles as the installer, then rewrites
tool-status.json. - Runtime self-correction. If the JSON is momentarily stale, a specialist agent may
do a single live re-check (
Get-Command/--version) for the one tool it needs before falling back — so a freshly installed tool can be used the same session.
The agents aren't just prompts with a job title — they're built on a small set of agent-design best practices, and all 47 definitions are held to them. This is what keeps the workspace effective on real (often locked-down) machines instead of falling over the first time a tool is missing or a skill folder gets renamed upstream.
| Principle | What it means | How the organisation applies it |
|---|---|---|
| Bounded scope, single responsibility | One agent owns one workload; no two agents fight over the same work | Master assigns one writer per artifact; Team Leads delegate narrowly scoped implementation or validation work |
| Deterministic tool gating | Never assume a CLI/MCP exists — check first, then use it or fall back | Every agent reads .github/agent-docs/tool-status.json and uses a tool only when <key>.found is true |
| Graceful degradation | A missing tool slows you down, it never blocks you | Every owned tool has a documented fallback (e.g. Tabular Editor → fabric-tmdl checklist; fab admin → portal + az rest; pbir → direct PBIR JSON edit) |
| Minimum-necessary context (anti-soup) | Load only what the current subtask needs, never "read all skills" | Each agent's Knowledge section pins the few skills for its role; workers receive a lean operating contract and a self-contained WORK ORDER instead of re-reading the flow documents |
| Topic-based routing | The right specialist is chosen by task type, never by what happens to be installed | Master routes by topic; a missing tool never changes the owner — the specialist falls back instead |
| Lean, deterministic startup | One status call, then work — never a menu | The Master runs Get-SessionStatus.ps1 once per session and acts on the request in the same turn |
| Safety guardrails | Irreversible actions get an explicit token; secrets never get hardcoded | Deletes/drops/PROD/release/security changes require APPROVED:<ACTION>:<artifact> from the user; dispatched agents without the token return NEEDS APPROVAL; IDs and secrets stay external; review agents remain read-only |
| Skill precedence on conflict | When two sources disagree, the tie-break is explicit | House style (fabric-tmdl) wins on "how we do it here"; upstream skills win on "is this valid?" |
| Resilient discovery | Don't fail just because an upstream folder moved | Skill paths are re-resolved on every installer run (renames matched by prefix, new skills auto-attached by keyword); a still-missing path falls back to keyword discovery under the clones |
The standout: the team works as a team. Nested delegation is enabled by the installer, every hop speaks the same WORK ORDER / WORK RESULT contract, only the agent you selected can talk to you, and destructive work stops until you hand over a literal approval token. This flow was verified end-to-end — including a live Fabric publish — for v0.7.0.
These principles are deliberately enforced inside the agent bodies (the Agent → tools → skills matrix above shows the per-agent result), so they hold no matter which agent you land on.
Before running the installer, make sure you have:
| Tool | Required? | How to get it |
|---|---|---|
| VS Code 1.117.0+ | Required | You install it — code.visualstudio.com. The installer checks the version and stops if it's missing; older versions have known bugs that break Copilot agent tools. |
| GitHub Copilot + Agent Mode | Required | You install it — from the VS Code Extensions marketplace. Agent mode must be enabled (chat.agent.enabled). The installer does not install or check this; org tenants may need admin to enable it. |
| Git | Required | You install it — git-scm.com. The installer checks for Git and stops if it's missing; it does not install Git. |
| Microsoft Fabric Extension | Required | You install it — VS Code marketplace or code --install-extension fabric.vscode-fabric. Required for the pull/push workflow with Fabric. The installer checks and warns if it's missing, but does not install it. |
| TMDL Extension | Recommended | You install it — code --install-extension analysis-services.tmdl. Syntax highlighting and validation for .tmdl files. The installer checks and reminds you, but does not install it. |
| Fabric Data Engineer Remote | Nice to have | You install it — run notebook cells against remote Spark from VS Code. The installer mentions it as a tip but does not install it. |
| Python 3.10–3.13 | Installer auto-installs (if needed) | Installer installs it where possible — only if no real Python 3 is found. It attempts Python 3.12 via winget Python.Python.3.12 --scope user, then the python.org 3.12.10 per-user installer. Skipped entirely if you already have Python (e.g. Anaconda). Needed only for the fab/az CLIs. python.org |
Fabric CLI (fab) |
Installer auto-installs (recommended) | Installer installs it where possible — primary CLI the agents use for Fabric API, jobs, export/import, OneLake & table ops. Once a real Python is available it runs pip install ms-fabric-cli with a --user retry. Continues if corporate policy, network, or Python/pip blocks it. Repo |
| az CLI | Installer auto-installs (fallback) | Installer installs it where possible — only needed for SQL/TDS (sqlcmd -G) and non-Fabric token audiences; fab covers the rest. Tries winget Microsoft.AzureCLI first, then an isolated user environment at %USERPROFILE%\.fabric-az if needed. The winget path may be blocked or require elevation depending on company policy; failure is non-blocking. Install |
| Fabric MCP server | Installer auto-installs (full-live / hybrid) | Installer installs it where possible — VS Code extension fabric.vscode-fabric-mcp-server, giving agents structured Fabric operations (create/list items, OneLake files & tables, read item definitions). Attempts code --install-extension ... --force. Not needed for full-local mode. |
| Power BI semantic-model MCP server | Installer auto-installs (full-live / hybrid) | Installer installs it where possible — VS Code extension analysis-services.powerbi-modeling-mcp, a live XMLA connection to running models (run DAX EVALUATE for live comparison, make transactional model edits). Attempts code --install-extension ... --force. Not needed for full-local mode. |
sqlcmd |
Optional — installer detects, asks Y/N | Query Fabric Warehouse / SQL endpoints over TDS (Data Engineering and Applications). On Yes, setup installs modern go-sqlcmd per-user through verified winget extraction or the official portable release. go-sqlcmd |
| Tabular Editor CLI | Optional — installer detects, asks Y/N | Semantic-model validation, Best Practice Analyzer, and automation. Setup installs free TE2 per-user and never confuses it with the newer te preview CLI. It tries an automated install first; if blocked it gives you the exact portable link. Corporate security can return that ZIP empty or block it, and an IT/download approval may be needed — the 016 agent still validates via the fabric-tmdl + bpa-rules skills meanwhile. tabulareditor.com |
pbir CLI |
Optional — installer detects, asks Y/N | Explore, edit, format, validate and publish PBIR reports (Reporting team). Installed into an isolated user environment. Repo |
pbi-tools |
Optional — installer detects, asks Y/N | PBIP/PBIX extract-compile DevOps workflows (ALM & DevOps team). It tries an automated install first; if blocked it gives you the exact portable link. Corporate security can return that ZIP empty or block it, and an IT/download approval may be needed — the 055 agent still handles native PBIP/PBIR ALM via fab/pbir meanwhile. pbi.tools |
GitHub CLI (gh) |
Optional — installer detects, asks Y/N | GitHub PRs, Actions, releases and tags (ALM & DevOps team). Setup prefers GitHub's current verified portable release. cli.github.com |
| Azure DevOps CLI extension | Optional — installer detects, asks Y/N | Azure DevOps PRs, pipelines and boards (ALM & DevOps team). An az extension (needs az); on Yes, best-effort az extension add --name azure-devops. |
Optional specialist tools are opt-in, never silent. The six tools above power the new specialist agents (Reports, Semantic Model validation, DevOps). The installer detects each one, and if it's missing it explains the tool's provider and purpose and asks Y/N before any best-effort install — decline and it records that choice and stays quiet on later runs; accept and it installs per-user where it can or shows a manual link. Every result (present or not) is written to the tool inventory below, so the agents know what they can use and how to fall back.
CLIs and MCP servers — optional for full-local, required for live & hybrid. The core full-local workflow — the Fabric extension plus agents editing local files — needs no CLI or MCP server at all. But the full-live and hybrid ways of working genuinely run on them: the agents call
fab/azand the two MCP servers to read and edit the running workspace (see Three ways of working). The installer attempts to install Python,fab(recommended),az(fallback), and the two MCP server extensions where possible. If your environment blocks an optional install (corporate policy, no winget, no network, no Python/pip, or VS Code extension restrictions), it shows a warning for that item and continues. For a deep dive into what you can do once a CLI is installed — now a two-part catalogue coveringfab/azand a chapter for each specialist CLI (pbir, Tabular Editor CLI,pbi-tools,sqlcmd,gh,az devops) — see CLI-FUNCTIONALITIES.md.
Warning
What the installer puts on your machine — read before running. The installer is convenient but it is not just a folder creator: it also writes workspace files, clones public repositories, and attempts a small set of tool installs. Everything it touches is listed below so there are no surprises. Optional tool installs are best-effort and non-blocking — if your environment blocks one (corporate policy, no winget, no network, no Python/pip, or VS Code extension restrictions), the installer continues and prints what to install later. Git and VS Code 1.117.0+ are required prerequisites; if they are missing, setup stops.
In your chosen workspace folder, it will:
- Create the workspace folder and one sub-folder per Fabric workspace you choose to scaffold
- Write or refresh installer-managed files: 47 agent definitions (10 visible + 37 delegated), custom skills (TMDL, Pipelines, CLI policy), Copilot instructions,
AGENTS.md, and VS Code settings/tasks. A new.gitignoreis written only when none exists; an existing one is preserved and receives only the required safety exclusions for machine-local state and independent clones. - Initialise Git if needed. A new repository receives its expected initial workspace commit, including other non-ignored content already in that folder; an existing repository stages and commits only declared installer-owned paths, excluding unrelated staged and unstaged user work
- If you opt in, validate and clone your GitHub or Azure DevOps business repositories under
source-control-repositories/, mirror each repository's live branches locally, record them in a machine-local map, and add them to the multi-root VS Code workspace. These clones remain independent of the outer setup repository. - Clone two public GitHub repositories into the folder if missing, or run
git pull --ff-onlyif they already exist:microsoft/skills-for-fabricanddata-goblin/power-bi-agentic-development. If cloning or pulling is blocked, the installer warns and continues.
On your system, software is handled in three clearly separate groups — so you know what the script attempts to install and what it only checks:
① Attempted automatically for you (best-effort; failures are warnings, not setup blockers):
- Python — only if no real Python 3 executable is found. The installer attempts Python 3.12 via winget
Python.Python.3.12 --scope user, then the official python.org Python 3.12.10 installer with per-user settings (InstallAllUsers=0,PrependPath=1,Include_pip=1). - Fabric CLI
fab— only iffabis missing. After a real Python is available, the installer runspython -m pip install --upgrade ms-fabric-cli, then retries with--userif needed, and adds discovered Python Scripts folders to the user PATH. - Azure CLI
az— only ifazis missing. The installer tries wingetMicrosoft.AzureCLIfirst; that package may be blocked or may request elevation depending on company policy. If winget does not produce a usable command, it tries an isolated user environment at%USERPROFILE%\.fabric-az. Failure is non-blocking. - Two VS Code MCP-server extensions — only if missing and the VS Code CLI is available:
fabric.vscode-fabric-mcp-serverandanalysis-services.powerbi-modeling-mcp, viacode --install-extension <id> --force. These power full-live/hybrid mode; full-local mode does not need them.
② Checked or recommended only — you install these yourself (the script does not install them):
- Fabric extension
fabric.vscode-fabric— required for the core pull/push file workflow. If missing, the installer shows a prominent warning and continues. - TMDL extension
analysis-services.tmdl— recommended for.tmdlsyntax highlighting and validation. If missing, the installer reminds you and continues. - Fabric Data Engineer Remote
synapsevscode.vscode-synapse-remote— optional for running notebook cells against remote Spark. The installer mentions it as a tip; it does not install it.
③ Optional specialist CLIs — detected, then installed only if you say yes (per-tool Y/N prompt; never silent): for each of pbir, Tabular Editor CLI, pbi-tools, sqlcmd, gh, and the Azure DevOps CLI extension (az devops), the installer detects whether it is already present and, if not, explains the tool's provider and purpose and asks Y/N before any best-effort install. Decline and it records that choice (and stays quiet on re-runs); accept and it installs per-user where it can, or prints a manual link if the install is blocked. Every result is written to .github/agent-docs/tool-status.json, which the agents read to decide which tool to use or how to fall back.
In short: the installer attempts to bring the niche pieces that power CLI/live-agent scenarios (Python if needed, fab, az, and the two MCP server extensions), asks per-tool before installing the optional specialist CLIs, and never forces anything your company environment blocks. The mainstream authoring extensions remain your choice: the script checks and warns, but does not install them.
Update mode: if you point it at an existing folder, it refreshes installer-managed files (agents, embedded skills, configs), updates clean cloned skill repositories when possible, and limits its Git commit to installer-owned paths. Your Fabric item folders, personal files, unrelated Git work, business-repository changes, and user-added multi-root entries are left untouched.
On managed laptops, TLS inspection, endpoint security, winget policy, PATH delays, or missing elevation can interrupt an otherwise valid install. Optional failures do not block the full-local workspace.
- Re-run setup once after any pending installer finishes; every run refreshes PATH and re-detects real executables.
- If a tool remains missing, open VS Code and select 070 - Capability Maintenance Team Lead.
- Name the failed tool and the console message. Maintenance re-checks the exact installation, publisher version, PATH, and policy constraint.
- Environment & Tooling may install or update a supported tool only after your explicit approval. It prefers a verified user-scope or portable route and refreshes
tool-status.jsonafterward. - Git, VS Code, the Fabric extension, and the recommended TMDL extension remain user/IT-managed prerequisites.
Known limitation — Tabular Editor 2 and
pbi-toolson TLS-inspection proxies. These two ship only as GitHub-release ZIPs, and some corporate proxies return an empty (0-byte) file for that CDN. Rather than silently produce a broken download, the installer detects the block and prints the exact portable link so you can download it yourself — drop the ZIP in your Downloads folder and re-run setup to auto-pick it up, or raise it with the Capability Maintenance team. (azhad the same class of problem and is now handled automatically; TE2 andpbi-toolsare the two that may still need this manual step on locked-down machines.)
The Capability Maintenance team owns both failed-installer recovery and the ongoing latest-version lifecycle for supported tools. You no longer need a long copy/paste recovery prompt: select the team directly and name the tool.
After the Fabric workspace-folder questions, setup separately asks whether to clone repositories used for Fabric Git integration or source control. It keeps the prompts minimal: you choose how many repositories to clone and, for each, paste only its clone URL (no PAT or password). The provider (GitHub or Azure DevOps) is detected from the URL and a safe local folder name is derived from it. Nothing is connected to or changed on a live Fabric workspace.
The installer never asks for or stores a PAT. Git uses your already configured credential manager, browser sign-in, or SSH authentication. Each repository is cloned once into source-control-repositories/<Repo>/ and its live branches are mirrored locally (a bare clone plus one working tree per branch, excluding main/master), so you can open and review any branch without switching. On re-runs, if a matching clone already exists setup asks "You already have this repository locally. Pull existing branches so they match online? (y/N)" (default No). If you decline, it only fetches remote branch references and never pulls, resets, merges, pushes, or overwrites repository work. If you accept, it fast-forwards only the branch worktrees that are clean and strictly behind upstream — branches with local changes or local commits (diverged) are always left as-is for you to pull manually, so no work is ever lost. A dirty existing clone is preserved. The machine-local repository map and the multi-root .code-workspace file are gitignored by the outer workspace repository, while user-added workspace roots are preserved.
You need two files — keep them in the same folder (ideally as they are in the fabric-agentic-installer folder):
Setup-FabricAgenticWorkspace.bat ← double-click this
Setup-FabricAgenticWorkspace.ps1 ← the engine (called by the .bat)
Double-click Setup-FabricAgenticWorkspace.bat.
You'll see a terminal window:
===============================================
Fabric Agentic Workspace — One-click Setup
===============================================
Do you already have a local folder where you work with Fabric?
(e.g. where you sync your Semantic Models, Notebooks, Pipelines)
[1] Yes — I have an existing folder (I will provide the path)
[2] No — Create a new folder for me
Enter 1 or 2: _
Follow the prompts. The script will:
- Ask for your workspace folder (existing or new)
- Explain the Fabric development lifecycle and the three ways of working
- Ask how many Fabric workspaces to scaffold
- Separately ask whether to onboard GitHub/Azure DevOps business repositories and, if yes, ask only for each repository's clone URL (the provider and local folder name are derived automatically, and live branches are mirrored locally)
- Check all prerequisites (git, VS Code, Fabric extension, TMDL extension), automatically install Python, the
fab/azCLIs, and the two MCP extensions where possible, then detect the optional specialist CLIs (pbir, Tabular Editor,pbi-tools,sqlcmd,gh,az devops) and ask Y/N before installing any of them. It then offers an optionaly/Ncheck for newer versions of the tools you already have installed (per-tool Y/N; blocked/offline lookups are skipped) - Create the folder structure; clone and validate the chosen business repositories without changing live Fabric
- Clone Microsoft's skills-for-fabric and data-goblin's power-bi-agentic-development
- Write custom skills (TMDL, Pipelines, CLI policy)
- Generate all agent definitions (47 agents: 10 visible + 37 delegated workers)
- Write or merge configuration files (Copilot instructions, AGENTS.md,
.gitignore, VS Code settings, the local repository map, multi-root workspace, and tool inventory) - Initialise Git when needed, then create an initial commit or an installer-owned update commit when there are relevant changes
- Open the multi-root workspace in VS Code
Once VS Code opens:
- Open Copilot Chat (sidebar or
Ctrl+Shift+I) - Select 000 - Fabric Workspace Master from the agent dropdown
- Describe what you need (or just say hi) — the Master takes over from here
Open the workspace from the installer-generated
.code-workspacefile (VS Code offers to save it). It carrieschat.subagents.allowInvocationsFromSubagents: true, the VS Code setting that lets Team Leads dispatch their workers; without it only the first level of delegation (Master → Team Lead) is available.
On the first message the Master runs one status script and shows one compact block:
- Skill freshness (real upstream commit dates for the two clones, install date for the custom skills)
- Registered skill locations and whether nested dispatch is enabled
- Identity (
fab auth status, falling back toaz account show) — informational, never blocking - Live tool check (refreshes
tool-status.jsonif something was installed or removed since setup) - MCP servers: installed vs connected — installed is never presented as callable
Then it acts on your request by dispatching the owning Team Lead(s). When the work needs a live semantic model, the Master first opens the Power BI modeling MCP connection itself in the main chat (that is where a sign-in prompt can be answered) and hands the connection name down to the team; if it cannot connect, the team is told to use the REST fallback up front. You never switch agent for normal work; the only optional switch is the Run capability maintenance handoff button when you want skills and tools refreshed.
When a new version is released, updating is the same one step as installing:
- Download the latest installer files
- Double-click
Setup-FabricAgenticWorkspace.batand point to the same folder you used originally - The installer detects the existing folder and switches to update mode — it refreshes agent definitions, custom skills, Copilot instructions, and VS Code configs, then force-refreshes the skill repositories to their upstream state
- It also offers an optional version review — answer Y at
Check installed tools for updates now?to see Current / Update / Unverified for every supported installed CLI, then approve each proposed update separately - Your Fabric items, workspace folders, and any personal files are not touched
That's it. Reopen the workspace in VS Code and you're on the latest version.
This is very important for maintainability. The installer is the single source of truth for everything it ships. To keep every machine identical and upgradeable, an update follows five strict rules:
| # | Behaviour | What it means for you |
|---|---|---|
| 1 | Vendor skill repos are force-refreshed to upstream | skills-for-fabric/ and power-bi-agentic-development/ are reset to live upstream on every run. Any local change you made inside those folders is discarded (it is auto-stashed first, so it is recoverable via git -C <repo> stash list, but it will not survive as-is). Do not edit vendor clones — treat them as read-only references. |
| 2 | Installer-managed files are overwritten every run | Every agent under .github/agents/, the custom skills under .github/skills/, .github/copilot-instructions.md, AGENTS.md, and the .vscode/ configs are rewritten from the installer. Do not hand-edit these — your edits will be replaced on the next update. To change them, change the installer (Setup-FabricAgenticWorkspace.ps1) and re-run. |
| 3 | Obsolete installer files are purged | The installer records everything it ships in .github/agent-docs/installed-manifest.json (a write-log). On update it deletes any file it shipped before but no longer ships (a renamed or removed agent, a superseded config, a dropped skill). This is a strict old − new set difference over the write-log, never a folder sweep. |
| 4 | Your own files are never touched | Anything you create that the installer never shipped is not in any manifest, so it is never overwritten and never purged. Put your own notes, scripts, and experiments anywhere outside the managed files above and they are safe. |
| 5 | Fabric content and business clones are left alone | Your synced Fabric workspace folders and any business repositories under source-control-repositories/ live outside the managed .github write-log, so the update never edits, resets, or deletes them. On re-run, an existing business clone is only updated if you accept the opt-in (y/N) pull prompt, and even then only clean, strictly-behind branches are fast-forwarded — dirty or diverged branches are never touched. |
Rule of thumb: if you want a change to survive updates, it must live outside the installer-managed files — or be made in the installer itself. Editing a managed file directly is always temporary.
You don't configure anything manually. On your first message each session, the Master runs .github/agent-docs/Get-SessionStatus.ps1 once and reports skill freshness, registered skills, nested-dispatch status, identity and live tool availability in one block — then goes straight to your request. Maintenance is offered only when upstream skills are more than 30 days old, and only as a one-line hint.
Every request is delivered through the organisation; the Master never edits an artifact itself.
| Loop | When | Path |
|---|---|---|
| Simple | one team, one artifact | Master → Team Lead → worker → Lead validates → Master → you |
| Designed | cross-domain or a design change | Master → 001 Architect (PLAN) → Team Lead(s) in plan order → 002 QA (VERDICT) → Master → you |
| Blocked | approval / input / design question mid-work | worker → Lead relays → Master asks you → re-dispatch with the answer |
Every hop uses the same WORK ORDER (goal, artifact, mode, constraints, expected validation, approvals granted, context) and WORK RESULT (DONE | DONE WITH RISKS | NEEDS APPROVAL | NEEDS INPUT | NEEDS ARCHITECT | OUT OF SCOPE | FAILED, changed, validation, risks, request) contract, defined in .github/agent-docs/working-flow-reference.md. The WORK RESULT block is the mandatory last message of every dispatched agent; a turn that ends without it is re-dispatched once, never patched over by the parent. Only the agent you selected can talk to you; everyone else bubbles questions up.
Destructive work needs a token. Deleting or dropping anything — a measure, a table, a file, a role, a branch, a live item — is destructive even if you asked for it in plain words. The Master states exactly what will be destroyed (including collateral) and asks you to reply with APPROVED:<ACTION>:<artifact>; workers without that token in their WORK ORDER stop and return NEEDS APPROVAL, and they only execute what the token names.
Each of the 47 agents is generated from a knowledge catalog in the installer, so a worker is a real specialist rather than a job title:
- Knowledge and skills — the artifacts it owns, its write permission, and the exact custom / Microsoft / Kurt skill paths to read (resolved at install time), plus upstream skills auto-discovered by topic keywords from the live skill catalogue.
- Playbook — the numbered steps for its kind of work.
- Validation you must run before reporting — concrete checks; an agent may never claim a check it did not run.
- Tool ladder — preferred → fallback → last resort, gated by
tool-status.json(e.g. DAX: Modeling MCP → RESTexecuteQueries→ local TMDL). - Avoid — the anti-patterns for that role.
Team Leads additionally get a roster of their workers and dispatch rules; the Architect returns a structured PLAN, QA a VERDICT. For the per-team overview see the Agent → tools → skills matrix above.
Every specialist agent reads the relevant skill files before generating any code or edits. Skills provide:
- Exact syntax rules — TMDL indentation (tabs only), property ordering, lineageTag handling
- Activity type references — every pipeline activity with its typeProperties
- Best practices — DAX conventions, naming patterns, validation checklists
- File structure knowledge — where things go in a Fabric PBIP project
The skills come from three sources:
| Source | What it covers | Updated |
|---|---|---|
Custom embedded (.github/skills/) |
TMDL syntax, pipeline JSON, CLI policy — original to this repo | Re-run installer or edit directly |
Microsoft (skills-for-fabric/) |
Spark, SQL Warehouse/Database, Eventhouse/Eventstream/Activator, Dataflows, pipelines, deployment pipelines, Git integration, OneLake governance, medallion, Power BI reports, semantic models, FabricIQ | Mirrored to upstream on every installer run / via Capability Maintenance |
Data-goblin — Kurt Buhler (power-bi-agentic-development/) |
PBIP/TMDL/PBIR, DAX, semantic models, reports, themes, Deneb/custom visuals, paginated, Tabular Editor, Fabric CLI/admin | Mirrored to upstream on every installer run / via Capability Maintenance |
All skill folders from both clones are registered in VS Code's chat.agentSkillsLocations, so every agent sees the full catalogue natively and VS Code loads a skill's text on demand. A skill updated upstream is used immediately after the next installer run; a new skill in a registered folder needs nothing at all; a new folder is registered on the next installer run or at the next session start (the status script self-heals the registration).
Why git clone instead of npm install? Corporate environments typically block npm global installs and require admin approval. This workspace clones the skills repos via git — which you already have — so there's zero extra tooling or permissions needed.
After setup, your folder looks like this:
Fabric Workspaces/
├── .git/
├── .github/
│ ├── agents/
│ │ ├── 000-fabric-workspace-master.agent.md ← primary orchestrator
│ │ ├── 001-fabric-solution-architect.agent.md ← cross-domain planning
│ │ ├── 002-integration-qa-change-controller.agent.md
│ │ ├── 010-semantic-model-team-lead.agent.md
│ │ ├── 020-reporting-team-lead.agent.md
│ │ ├── 030-data-engineering-team-lead.agent.md
│ │ ├── 040-fabric-administration-governance-team-lead.agent.md
│ │ ├── 050-alm-devops-team-lead.agent.md
│ │ ├── 060-applications-integration-team-lead.agent.md
│ │ ├── 070-capability-maintenance-team-lead.agent.md
│ │ └── <37 delegated worker .agent.md files>
│ ├── agent-docs/
│ │ ├── starting-flow.md ← lean session startup (one status call)
│ │ ├── working-flow-reference.md ← team protocol, routing map, WORK ORDER/RESULT
│ │ ├── Get-SessionStatus.ps1 ← status script (skills, identity, live tool re-check)
│ │ ├── local/
│ │ │ └── repository-map.local.json ← local business-repo map (gitignored)
│ │ └── tool-status.json ← tool inventory (gitignored)
│ ├── copilot-instructions.md ← workspace-level context
│ └── skills/
│ ├── fabric-tmdl/
│ │ └── SKILL.md ← TMDL syntax & rules
│ ├── fabric-pipelines/
│ │ └── SKILL.md ← pipeline activity reference
│ └── fabric-cli-policy/
│ └── SKILL.md ← fab-first / az-fallback policy
├── .gitignore
├── .vscode/
│ ├── settings.json
│ └── tasks.json
├── AGENTS.md ← quick-reference guide
├── Fabric-Agentic-Workspace.code-workspace ← local multi-root file (gitignored)
├── source-control-repositories/ ← independent business clones (gitignored)
├── skills-for-fabric/ ← Microsoft skills (gitignored)
│ ├── skills/
│ └── common/
├── power-bi-agentic-development/ ← data-goblin skills (gitignored)
│ └── plugins/
└── <Your Workspace Folders>/ ← Fabric items synced here
Fabric items are synced into workspace sub-folders via the Fabric VS Code extension. In the default file-first mode the agents edit those local files — TMDL, DAX, pipeline JSON, notebooks — and you push changes back via the extension; in full-live or hybrid mode they can also act on the running workspace directly (REST/XMLA + MCP). See Three ways of working.
The setup script (Setup-FabricAgenticWorkspace.ps1) is fully self-contained.
Every agent definition, custom skill, and config file is embedded directly in
the script — no external templates, no internet dependencies for its own content.
External content is limited to the two public skill repositories, any business
repositories you explicitly choose to clone, and the tools it installs on your
machine — all listed in the install warning above.
The .bat wrapper calls the .ps1 with a process-scoped
-ExecutionPolicy Bypass, avoiding the common local script-policy block.
Stronger organisation controls such as application allowlisting can still stop it.
The script supports update mode — if you run it against an existing folder, it refreshes installation-managed agent definitions, custom skills, and configuration while leaving Fabric items, workspace folders, and personal files untouched. Its Git step stages and commits only declared installer-owned paths; unrelated user work is excluded.
Everything in this workspace sits on top of one lifecycle. It's the shared backbone for all three ways of working — only the editing step differs between them; everything from the DEV workspace onward is identical. The lifecycle uses Fabric's native Git integration plus Azure DevOps to take a change safely from idea to production.
Diagram note:
DEV/PRODbranch labels are illustrative. References below to workspace state, revert, or persistent production settings apply only to Fabric Git-supported definitions and verified environment configuration—not item data, unsupported state, or every workspace setting.
The lifecycle, end to end:
- Fabric DEV workspace — your live testing ground. However you make a change (see the three ways below), it lands here first and you validate it in the portal.
- Commit to Azure DevOps — development branch — in the Fabric portal, go to Workspace Settings → Git Integration and commit. This versions supported item definitions. A deliberate Git revert/update can restore those definitions, but not item data, unsupported artifacts, or every workspace setting.
- Pull Request: development → production branch — when development is stable and tested, open a PR using your verified branch mapping; the agents do not assume literal
DEVorPRODbranch names. - Production-specific configuration — review parameters, schedules, connections, and environment rules during promotion. Overrides do not automatically persist safely across every merge.
- Sync to the Fabric production workspace — after the PR is approved and merged, sync the verified production branch through Git Integration.
Shared safety anchor: Fabric Git commits capture supported, committed definitions. You can review that history and deliberately update production through PR + sync; data and unsupported state need separate backup and rollback controls.
Before the Fabric VS Code extension and AI agents, there were really two places to build — and neither was friendly to source control:
- In the workspace/portal itself. The Fabric workspace (and before it, the Power BI Service) was the main working place. You created and edited items online, and versioning was largely manual — saving copies, exporting, hoping you could find the last good state.
- In Power BI Desktop, then publish. Semantic models and reports were authored locally in Power BI Desktop (
.pbix) and published up to the workspace. The.pbixwas a binary blob: hard to diff, hard to review, awkward to keep in Git.
Two changes opened things up:
- Fabric Git integration started exposing item definitions as readable files — TMDL for semantic models, JSON for pipelines, source for notebooks — so a workspace could be backed by Azure DevOps / GitHub with real history.
- The Fabric VS Code extension let you pull those definitions into a local folder and push them back — proper file-based editing and source control.
This workspace uses the final layer: AI agents that natively understand TMDL, DAX, pipeline JSON, notebooks, and more — and that can edit either the local files or the running workspace directly. That's what makes the three ways of working below possible.
You now have three ways to make changes to your Fabric DEV environment. They all share the same promotion path: validate in DEV, commit the workspace state through Fabric Git integration, review via PR, and sync PROD deliberately. That shared lifecycle is the safety anchor. Live and hybrid work still require normal engineering discipline: review the generated changes, test in the portal, and keep local files aligned with the live workspace.
Edit Fabric items as files on disk, then push them back. Best for bulk/structured edits, diff-style review, and offline work. Needs only the Fabric extension + Git.
- Pull items from your DEV workspace into the local folder using the Fabric extension — semantic models (TMDL), notebooks, pipelines (JSON), reports.
- Edit locally with the AI agents or by hand. The agents understand TMDL, DAX, pipeline JSON, and notebook formats natively, so you can refactor measures, fix pipeline logic, restructure models, etc.
- Push the changes back to the DEV workspace via the Fabric extension — they go live in DEV immediately.
- Test in the Fabric portal, making any manual portal amendments if needed, then commit to Azure DevOps (lifecycle step 2 above).
Agents act directly on the running DEV workspace, with no files pulled down. Best for live data comparison, reading real deployed values, and quick in-place fixes. Needs the Fabric MCP server + Power BI semantic-model MCP server, plus fab/az.
- The agents connect to the live workspace via Fabric REST (
updateDefinition) and the two MCP servers. - Run DAX (
EVALUATE) on running models to compare data live — for example, check a measure's result after a logic change, or run the exact queries behind a report's visuals in both DEV and PROD to confirm a model change didn't break them. You can also run SQL against a Lakehouse or SQL database endpoint, and read real deployed GUIDs / SQL endpoints instead of guessing. - Edit definitions in place and create items directly in the workspace.
- Test in the portal, then commit to Azure DevOps as usual (lifecycle step 2).
Mix both in one session — some items edited as local files, others touched live. Best for real tasks that naturally span both edit paths. Needs the local toolset (Fabric extension + Git) and the live toolset (MCP + fab/az).
- Pull only what you need locally — just the items you'll edit as files.
- Do your mixed work: file edits for some items, live REST/XMLA/MCP for others. Both edit paths converge on the same DEV workspace and the same commit.
- Before starting a new job, re-pull from the live workspace (or clean up local) so your local folder matches live again.
Golden rule — keep local = live workspace. Each session, pull locally only the items you need, do your work, then re-pull (or clean up local) before a new job so your local folder exactly matches live and you avoid drift.
Q: Can I move the workspace folder after creation? A: Yes. The workspace is fully portable. Just open the new location in VS Code.
Q: What if I don't have the Fabric extension installed? A: The installer will warn you prominently but still create everything. Install the extension before using the pull/push workflow with Fabric.
Q: Does this work on macOS or Linux? A: The setup script is Windows-only (PowerShell + .bat). However, the workspace itself — including all agents and skills — works on any OS once the files exist. You'd just need to create the folder structure manually or adapt the script.
Q: Why does this clone skills via git instead of installing them? A: Cloning via git — which you already have as a prerequisite — sidesteps the npm global installs that typically need admin rights or IT approval on corporate machines.
Q: Can I add my own specialist agents?
A: Absolutely. Create a new .agent.md file in .github/agents/ and it will
appear in the Copilot Chat dropdown. Follow the existing agent structure.
Q: How do I update the skills and the tools the agents use? A: The Master offers maintenance at session start. You can also select 070 - Capability Maintenance Team Lead directly for a light repository/tool-inventory refresh or deeper skill, agent, installer and tool-lifecycle maintenance.
Q: Does setup connect my GitHub or Azure DevOps repository to Fabric? A: No. Repository onboarding is optional and local only. Setup validates the URL, uses your existing Git/SSH authentication to clone it, mirrors its live branches locally, and opens it as an independent VS Code repository. It does not request a PAT, push changes, configure Fabric Git integration, or modify a live Fabric workspace.
Q: Can multiple people share the same workspace via git?
A: Yes. Push the workspace to a shared repo. Each team member clones it,
selects the Master Agent, and connects to their own Fabric environment.
The installer-created .gitignore keeps cloned skill repos, independent business
clones, the local repository map, the multi-root workspace file, and machine-specific
VS Code settings out of source control; an existing .gitignore is preserved and
only the required safety exclusions are appended.
Q: Do I have to edit local files, or can the agents work live in the workspace? A: Both. There are three ways of working — full local (file-first), full live (agents act on the running DEV workspace via REST/XMLA + MCP), and hybrid. They share the same DEV-to-PROD promotion lifecycle, but live and hybrid work still need review, portal testing, and drift discipline. For hybrid, follow the golden rule: re-pull (or clean up local) before a new job so local = live workspace.
Q: What do I need for full-live / hybrid mode?
A: The two MCP servers (Fabric MCP + Power BI semantic-model MCP), plus fab/az.
They are VS Code extensions (fabric.vscode-fabric-mcp-server and
analysis-services.powerbi-modeling-mcp) that the installer auto-installs for you,
alongside fab/az. Full-local mode needs none of these.
Q: What are the optional specialist CLIs, and what happens if I don't install one?
A: They are the workload-specific tools individual agents can use — pbir (reports),
Tabular Editor CLI (semantic-model BPA/deploy), pbi-tools (PBIX/PBIP source control),
sqlcmd (T-SQL over the Fabric SQL endpoint), gh (GitHub) and az devops (Azure
DevOps). The installer asks Y/N per tool — none is installed silently. If a tool is
missing (you declined, or the install was blocked), nothing breaks: the owning agent
sees found: false in tool-status.json and uses a documented fallback. You can add any
of them later through 070 - Capability Maintenance Team Lead, which checks first,
asks before any installation or update, and refreshes the tool inventory afterward.
See CLI-FUNCTIONALITIES.md for a per-CLI deep dive.
Q: How does the workspace know which tools I have installed?
A: The installer writes .github/agent-docs/tool-status.json — a gitignored, machine-specific inventory. Agents read <tool>.found before invoking any CLI/MCP and fall back when absent. Re-run setup or use Capability Maintenance to refresh it, recover a failed installation, or perform an explicitly approved update.
| Area | Status |
|---|---|
| One-click setup (.bat + .ps1) | Validated manually — the setup flow is maintainer-used on Windows 10/11, including a locked-down corporate laptop |
| Master Agent session startup flow | Lean since v0.7.0 — one Get-SessionStatus.ps1 call (skill freshness, registered skills, nested-dispatch check, identity, live tool re-check), one compact status block, then straight to work; no blocking menus |
| Hierarchical routing | Fine-tuned in v0.7.0 — the installer now configures nested delegation, so the full Master → Team Lead → Worker → Lead → Master path is available out of the box; verified with single-team, multi-team (Architect PLAN + QA VERDICT) and approval-bubble scenarios |
| Agent → tools → skills model | Implemented — every agent carries a Knowledge section (resolved custom/Microsoft/Kurt skill paths + auto-discovered upstream skills), a Playbook, mandatory validation, a tool ladder and an Avoid list |
| Team protocol | Implemented in v0.7.0 — WORK ORDER / WORK RESULT contracts, three loops (Simple / Designed / Blocked), strict APPROVED:<ACTION>:<artifact> tokens for destructive work, session ledger |
Tool inventory (tool-status.json) |
Implemented — installer detects real executable paths/versions; refreshed live at every session start; Capability Maintenance owns approved installation/update and PATH recovery |
| GitHub / Azure DevOps repository onboarding | Implemented in v0.6.0 — optional independent clones from a clone URL, live-branch mirroring, safe re-runs, and a preserved multi-root VS Code workspace |
| Opt-in specialist CLIs | Implemented — pbir, Tabular Editor CLI, pbi-tools, sqlcmd, gh, az devops are detect → explain → Y/N → best-effort install; never silent; declined choices remembered |
| ALM & DevOps Team | Implemented — GitHub, Azure DevOps, Fabric Git, deployments/releases and Power BI ALM with five focused workers |
| Capability Maintenance Team | Implemented — repo sync, skill inventory/mapping, agent coverage, tools, installer regression and managed-file review |
| Manifest schema + CI tests | Implemented in v0.6.1, widened in v0.7.0 — JSON Schema plus a Pester suite (manifest, hierarchy, least-privilege, version, generated-file content, settings) run in GitHub Actions on every push/PR; the installer also self-tests generated agents and stamps an integrity manifest |
| Custom TMDL skill | Used in real work — comprehensive syntax and validation rules, maintained from practical modelling experience |
| Custom Pipelines skill | Used in real work — activity reference plus operational practices from production pipeline work |
| Custom CLI-policy skill | Used in real work — fab-first / az-fallback decision rule that every agent reads before a CLI/REST task |
CLI deep-dive (CLI-FUNCTIONALITIES.md) |
Expanded — two-part mini-book: fab/az workload guide plus a chapter per specialist CLI |
| Three ways of working (local / live / hybrid) | Documented and verified — live mode exercised in v0.7.0 testing (semantic model published to Fabric via REST, refreshed, regression DAX run) |
| Microsoft skills-for-fabric integration | Implemented; refresh hardened in v0.7.0 — the clone is mirrored to upstream on every run with explicit success/failure reporting, and every skill folder is registered natively for the agents |
| Data-goblin skills integration | Implemented; refresh hardened in v0.7.0 — as above |
| Idempotent re-run (update mode) | Implemented — managed files refreshed; existing-repository Git commits are limited to installer-owned paths; user files and unrelated Git work are untouched |
| Authoritative install + self-pruning | Implemented in v0.6.2 — vendor skill repos force-refreshed to upstream (local edits auto-stashed); managed files overwritten every run; obsolete installer files purged via a strict installed-manifest.json diff; user files, Fabric workspaces and business clones never touched |
| Portable download/rollback safety | Implemented in v0.6.0 — staged extraction, executable validation, official checksums/signatures where available, and prior-version restoration on activation failure |
| Automated regression tests | Widened in v0.7.0 — the Pester suite now also asserts the generated agents' content (Knowledge/Playbook/Return-contract sections, approval-token rule, no unresolved skill references), the emitted settings (nested dispatch, skill locations), the status script and the handoff; end-to-end live validation remains manual |
This is a pre-release. It is genuinely useful today, but expect rough edges. If something breaks, open an issue.
The agent organisation is governed by a machine-checkable manifest embedded in the installer, and several independent layers keep it honest:
- JSON Schema (
schema/agent-manifest.schema.json, draft-07) — defines the shape every agent entry must satisfy (required fields, the closed capability-token set, allowed properties). The manifest is validated against it in CI. - Pester test suite (
tests/) — covers manifest integrity (exactly 47 agents, 3 / 7 / 37 tiers, unique ids and prefixes), the delegation hierarchy (single root, no cycles, resolvable children), least-privilege tools (explicit per-agent tools, read-only default, only executives and team-leads may delegate), version/doc consistency (installer, manifest, README and CHANGELOG all agree), and — since v0.7.0 — the content of the generated files: every agent has its Knowledge / Playbook / Return-contract sections, workers carry the approval-token rule, the Master carries the maintenance handoff and only its nine children inagents:, the emitted settings enable nested dispatch, andGet-SessionStatus.ps1is shipped. - Real generator smoke test (
tests/Generated.Tests.ps1) — runs the installer in a safe dry-run mode (-EmitAgentsTo <dir>, no prerequisites, cloning, tool installs or launch) and asserts on the actual generated agent files, so the code that writes agents — not just the manifest data — is exercised. - Continuous integration (
.github/workflows/validate.yml) — the whole suite runs on GitHub Actions (PowerShell 7) on every push/PR touching the installer, schema or tests; the badge above reflects the latest run. - Install-time self-test + integrity manifest — after generating agents the
installer self-tests them against the manifest (
guardrail-status.json) and stamps a SHA-256installed-manifest.json. RunSetup-FabricAgenticWorkspace.ps1 -VerifyRoot <installed-workspace>at any time to re-hash the managed files and detect drift or tampering.
Run the tests locally by double-clicking tests/Run-Tests.bat, or:
powershell -NoProfile -ExecutionPolicy Bypass -Command "Import-Module Pester; Invoke-Pester -Path '.\tests' -Output Detailed"What this does not cover: a full end-to-end install against a live Fabric / VS Code environment, and the behavioural quality of an agent's prompt (only its structure, content sections and safety rules). Behaviour is validated by real-world use; the v0.7.0 release was checked with three end-to-end scenarios in a real workspace (single-team TMDL edit, multi-team Architect → Leads → QA with a live semantic-model publish and regression DAX, and a two-way destructive-action approval bubble).
This project is open source and actively looking for feedback, ideas, and improvements from the community. All contributions are welcome — from typo fixes to new agent workflows to cross-platform support.
See CONTRIBUTING.md for the full guide — how to set up, branch naming, commit style, and PR expectations.
Quick links:
| File | Purpose |
|---|---|
fabric-agentic-installer/Setup-FabricAgenticWorkspace.bat |
Double-click entry point — share this with your team |
fabric-agentic-installer/Setup-FabricAgenticWorkspace.ps1 |
The full installer — must be in the same folder as the .bat |
CHANGELOG.md |
Version history and release notes |
CONTRIBUTING.md |
Guide for contributors |
CODE_OF_CONDUCT.md |
Community standards |
SECURITY.md |
How to report security vulnerabilities |
LICENSE |
MIT License |
README.md |
This file |
This project is licensed under the MIT License — see the LICENSE file for details.
This project integrates and references third-party open-source skill repositories that remain the property of their respective authors and are licensed separately.
See THIRD_PARTY_NOTICES.md for attribution, repository links, and license information.