Back to selected projects

I built the AI skills that shipped with Fabric CLI

People were already using AI assistants to run the Fabric CLI, but the assistants didn't understand Fabric, and everyone was writing their own instructions. Before GA, I proposed a shared set of AI assets, shaped it with the PM, and wrote it: agent context, a custom mode, a prompt, skills, references, and scripts. It's all public.

March 2026Shipped with Fabric CLI at GA
36 filesIn my main AI assets pull request
PublicPRs, release notes, and a launch article I co-wrote

The problem

The Fabric CLI lets developers run Microsoft Fabric from a terminal. More and more people were hooking it up to GitHub Copilot, Claude, Cursor, and other assistants. Each agent needed enough product context to use the CLI correctly, and users kept writing the same instructions over and over.

There was no single source of truth. Agents needed to know Fabric's hierarchy, command patterns, authentication, safety rules, and how to check their work. They also needed real workflows, not just a long reference doc.

I thought the CLI needed one structured set of agent assets, not another pile of one-off prompts.

My role

I was the Senior Content Designer on the Fabric CLI team. None of this was in the original release plan. I brought it up because agents were becoming real CLI users, and the line between product guidance, design, and code was moving fast.

The PM and I set the direction based on what others in the industry were doing, our own experience with the CLI, and feedback from community power users. Then I wrote the files, opened the PRs, and revised them through product and engineering review.

It took my job from improving specific product experiences to designing how agents use the product.

One file wasn't going to cut it

We looked at a different folder structure, fewer and broader skills, skipping a core skill, one universal context file, and just using AGENTS.md.

One file looked simpler. But it would have mixed product context, agent behavior, workflows, and task instructions all together. It also wouldn't handle the different file formats, install paths, and loading rules that Copilot, Claude, and Cursor each use.

So we split it into four layers. A core skill covers the basics once, and the other skills build on it without repeating the same auth, hierarchy, safety, and command guidance.

Four layers instead of one big file. Shared context, agent behavior, prompts, and task skills each live in their own place.

What I implemented

My main AI assets pull request added or reorganized 36 files. I wrote the files in it, including:

  • Tool-specific context for GitHub Copilot, Claude, and Cursor
  • A custom Fabric CLI agent mode
  • A reusable workspace-creation prompt
  • Core and Power BI skills
  • Detailed command and scenario references
  • Automation scripts for health checks, semantic model refresh, refresh history, and report rebinding
  • Repo guidance that points contributors and agents to the right source material

The repo has changed since GA. The pull request shows exactly what I contributed at launch.

Built around how people actually use it

We didn't just guess what agents needed. People in the community were already telling us how they used agents with the CLI, what got them better results, and which skills helped.

That shaped which skills we did first, how people would get to them, and how it would work across assistants. We kept the release to a core skill, Power BI scenarios, and workspace creation instead of trying to cover every Fabric task.

  1. 1User goalCreate or manage a Fabric resource
  2. 2Tool contextLoad the right product and CLI model
  3. 3Prompt or skillApply task-specific guidance
  4. 4CLI actionRun concise Fabric commands
  5. 5VerificationCheck authentication, paths, and results
From goal to checked result. The agent loads only the guidance it needs for the task, not a generic prompt or the whole API spec.

Review and release

The PM reviewed the direction. Engineering reviewed and tested the code. The PR passed the repo's automated checks before it was approved and merged.

It shipped with the Fabric CLI GA release. The release notes credit the AI assets, and I co-wrote the GA article with the PM about why the CLI was becoming something agents run.

Primary contributionInspect AI assets PR #17636 files, review history, checks, and merged commits ↗Release evidenceRead the v1.5 release notesPublic contribution credit and release date ↗Product framingRead the co-authored GA articleAgent execution model, scenarios, and contributors ↗

The public response

People outside Microsoft didn't talk about it as extra docs. They talked about it as a change in what the CLI could do.

“The agent execution layer is the piece I’m most excited about. We’ve been building agent-driven Fabric workflows at DataMartIn, and a CLI purpose-built for assistants to operate it fluently changes everything.”
Martin RojzePublic response to the Fabric CLI GA announcement

Leon Gordon said something similar: that it turned a developer tool into something agents use. That's not an adoption number, but it shows people got it and saw how it fit their work.

What happened next

After GA, product and engineering started asking a new question: which repeated workflows should become skills next?

After the release, I also built internal skills for the engineering teams I supported. Same idea, different problems. That's a separate story, so I've kept it out of this one.

What I learned

Teaching an agent a list of commands is the easy part. The real work was setting up something we could maintain, that tied together product knowledge, task guidance, per-tool setup, and checking results.

I think it also shows how design jobs are changing. This took product judgment, information architecture, interaction design, technical writing, writing code in the repo, and working closely with engineering. My title mattered a lot less than seeing what was missing and getting it into the product.