Copilot for Fabric: Part 2, skills and the killer prompt

Part 1 built the GitHub Copilot CLI foundation. This part adds the Fabric-specific tools and follows 2_Fab_Init.md. It ends with 4_killer_prompt.md, the prompt I use for an end-to-end Fabric Roadshow build.

The repository

If the setup is useful, star the repository. It is a small way to signal which parts should keep evolving.

What Part 2 adds

The guide installs:

1. Python 3.13 as the explicit runtime for the current Fabric packages;
2. Fabric CLI (fab) for administration from the terminal;
3. fabric-cicd for Git-based deployment; and
4. Skills for Fabric for workload-specific instructions and tool routing.

The distinction matters:

Skills do not replace authentication, permissions, APIs, or the CLI. They help the agent use those surfaces in the right order.

Before running the guide

Complete Part 1, then check:

copilot --version
az account show --output table
gh auth status
git --version
py -3.13 --version

Live operations also require access to the intended Fabric workspace and capacity.

1. Select Python 3.13

py -3.13 --version

If it is missing:

py install 3.13

This selects the compatible interpreter without changing every Python project on the machine:

py -3.13 -m pip install --upgrade fabric-cicd

Using py -3.13 -m pip avoids installing into a different Python environment.

2. Install Fabric CLI

pip install --upgrade ms-fabric-cli
fab --version
fab auth login

fab is one route through Fabric, not the route for every task. When a purpose-built skill or MCP tool owns an operation, the prompt should prefer it.

3. Install fabric-cicd

py -3.13 -m pip install --upgrade fabric-cicd
py -3.13 -m pip show fabric-cicd | Select-String "Version"

Keep selecting that interpreter in deployment scripts:

py -3.13 .\your_deploy_script.py

4. Install Skills for Fabric

Start Copilot CLI:

copilot

Inside it:

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

Focused bundles are also available:

/plugin install fabric-authoring@fabric-collection
/plugin install fabric-consumption@fabric-collection
/plugin install fabric-operations@fabric-collection

The collection covers Spark and Lakehouse, Warehouse and SQL endpoints, Power BI, Eventhouse, Eventstream, migrations, deployment pipelines, OneLake governance, and end-to-end architectures.

Restart Copilot CLI after installation or update. Skills load at session start.

Use the quick installer correctly

The bottom of 2_Fab_Init.md contains an idempotent PowerShell block. It checks or installs Python 3.13, updates Fabric CLI and fabric-cicd, updates an existing skills checkout, and prints the plugin commands when first-time installation is still needed.

Verify afterwards:

python --version
py -3.13 --version
fab --version
py -3.13 -m pip show fabric-cicd | Select-String "Version"

$pkg = "$env:USERPROFILE\.copilot\installed-plugins\fabric-collection\skills-for-fabric\package.json"
if (Test-Path $pkg) {
  "skills-for-fabric: v$((Get-Content $pkg | ConvertFrom-Json).version)"
} else {
  "skills-for-fabric: not installed"
}

The killer prompt is an execution contract

4_killer_prompt.md does not work because it is dramatic. It works because it specifies a concrete outcome, the tool routes, acceptance tests, and failure rules.

The mission is to build an analytics solution from the SalesLT Lakehouse to a published Power BI report:

• a uniquely named Fabric workspace and GitHub repository;
• Bronze, Silver, and Gold Lakehouses;
• three medallion notebooks;
• incremental MERGE logic with lineage columns;
• a Gold star schema;
• a Direct Lake model with a Product Category hierarchy;
• a PBIR report;
• a nightly Fabric Data Pipeline; and
• committed definitions.

It also states expected validation values, approximately $708,690.15 and 32 orders, plus an idempotency check where a second unchanged run produces zero inserts and updates.

What makes the prompt useful

It gives each run a safe identity

The preflight creates a slug and uses it in the workspace and repository:

Fabric Roadshow_<slug>
FabricRoadshow_<slug>

Previous demos are not deleted. The prompt also records the token audience for Fabric Items, Power BI Datasets, OneLake DFS, and SQL endpoints. Mixing those audiences creates authentication failures that look like implementation bugs.

It defines contracts

The prompt names the source tables, Gold entities, hierarchy, lineage columns, and incremental behavior. Bronze, Silver, and Gold merges must be idempotent. That gives the agent measurable work rather than an architecture picture.

It routes work to the right skill

Workspace and Lakehouse setup, medallion authoring, semantic-model work, and pipeline deployment have different owners. fab and handwritten REST are fallbacks, not reflexes.

It makes parallel work explicit

The prompt identifies two fan-out points: preflight and workspace work first, then semantic model, report shell, and pipeline work after Gold completes. That is how a live demo avoids waiting for independent work serially.

It records previous failures

Useful details include:

• Fabric Items API uses /v1/, while Power BI Datasets uses /v1.0/myorg/;
• pipeline schedules use W. Europe Standard Time;
• report projections need nativeQueryRef;
• TMDL uses tabs and the SQL endpoint GUID for Direct Lake framing;
• a fresh semantic model may need REST executeQueries; and
• Windows may require shell=True when az is launched from Python.

Those details are debugging history encoded for the next run.

Use it safely

Before pasting the prompt:

1. complete Parts 1 and 2;
2. confirm az, gh, fab, and copilot identities;
3. replace environment-specific assumptions;
4. confirm the source workspace and SalesLT Lakehouse;
5. confirm capacity and permissions;
6. review local paths, repository owner, plugin names, and expected totals; and
7. understand that it creates cloud resources, schedules, and a GitHub repo.

Copy only the block between --- BEGIN --- and --- END ---. Treat it as a worked template, not a portable deployment script.

Why it is “killer”

The useful combination is:

1. a concrete outcome;
2. platform-specific rules;
3. explicit tool routing;
4. measurable tests; and
5. orchestration rules for parallel work and failure.

The prompt should change after every run. A new failure belongs in the setup repository, so the next run starts with the lesson already captured.

Start at the beginning: Part 1: build the GitHub Copilot CLI foundation

Use the full demo prompt: 4_killer_prompt.md