From a blank laptop to Copilot for Fabric: Part 1

The difficult part of a new Fabric session is often not Fabric. It is the missing foundation: the wrong Python version, an expired Azure login, a different GitHub account, or an MCP server that was never configured.

That is why I built GitHubCopilot4Fabric. It started as my checklist and became a repeatable route from a plain Windows machine to a Copilot CLI environment ready for Fabric work.

Find the setup on GitHub

The setup guides, scripts, and prompts are here:

If it helps, star the repository. That makes it easier for other Fabric users to find and gives me a useful signal about which parts deserve more work.

This is Part 1. It follows 1_GHCP_Init.md. Part 2 adds the Fabric-specific tools and skills.

What the repository is

It is not an installer that silently changes a machine. The guide explains:

• installation commands;
• authentication checkpoints;
• optional productivity tools;
• MCP configuration;
• a custom Copilot CLI status line; and
• a final diagnostic script.

That separation is intentional. If a command fails, you can identify the layer that failed instead of debugging one opaque installer.

Start with the repository

Open PowerShell 7 and clone it:

git clone https://github.com/Remc0000/GithubCopilot4Fabric.git
Set-Location .\GithubCopilot4Fabric
code .\1_GHCP_Init.md

Read the guide from top to bottom. Do not paste every block at once because some installations change PATH and some authentication steps are interactive.

Layer 1: command-line tools

The guide establishes:

Verify versions after installation:

pwsh --version
copilot --version
az --version
gh --version
git --version
node --version
py -3.13 --version
uv --version

These checks are a preflight, not decoration. A missing command becomes harder to diagnose once Copilot is in the middle of a multi-step task.

Layer 2: sign in deliberately

Installation and identity are separate milestones:

copilot login
az login
gh auth login

Confirm the active accounts:

az account show --output table
gh auth status

An agent can run the right command against the wrong subscription or GitHub account. Check first.

Layer 3: add tools when they help

The guide includes optional tools:

• AI Engineering Fluency CLI for Copilot token visibility;
• OpenSpec for requirements and scenarios;
• Spec Kit for specification-driven work; and
• Handy for local speech-to-text.

Start with the core CLI. Add the rest when the task justifies them. OpenSpec and Spec Kit are especially useful when a Fabric outcome spans several items, tables, quality rules, and deployment targets.

Layer 4: add current context with MCP

The setup checks two MCP surfaces:

1. GitHub MCP for repositories, issues, pull requests, and code context.
2. Microsoft Learn MCP for current Microsoft and Fabric documentation.

Add Microsoft Learn:

copilot mcp add --transport http microsoft-learn https://learn.microsoft.com/api/mcp

Then verify:

copilot mcp list

In a running Copilot CLI session, /mcp show provides the same sort of check. The practical gain is current documentation when an API or product behavior has moved since the model’s training data.

Layer 5: make the terminal observable

The guide can configure a third-party status line showing:

• context-window usage;
• active Azure and GitHub identities;
• token usage;
• subagent activity; and
• OpenSpec or Spec Kit work.

Read the status-line files before enabling them. They download and execute third-party scripts when they render. Pin a reviewed commit rather than following main forever.

Run the health check

The quick-check script reports available commands, Node.js compatibility, Python 3.13, Handy, and status-line files. A healthy setup should let you run:

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

Then start Copilot:

copilot

The foundation is now ready. The Fabric CLI, fabric-cicd, and Skills for Fabric come in Part 2.

What I learned

The value is not one install command. It is a setup that is:

• repeatable on a new machine;
• inspectable when something fails;
• diagnosable before a demo;
• updateable in one repository; and
• safe to hand to another person.

That is a better use of a checklist than keeping it in my terminal history.

Continue with Part 2

In Part 2: add Fabric skills and put the killer prompt to work, I follow 2_Fab_Init.md, install Fabric CLI and fabric-cicd, and examine the prompt that orchestrates a Fabric Roadshow build.

Next: Copilot for Fabric, Part 2 →