brianbrady.dev

Microsoft Fabric UX / agentic development / design-to-code infrastructure

Microsoft Fabric UX Agentic AI Design-to-Code DevKit

The Microsoft Fabric UX Agentic AI Design-to-Code DevKit is the production agentic AI layer for moving from design specification to reliable component implementation. It treats Figma, Microsoft Fabric UX documentation, product code, accessibility requirements, and Azure DevOps automation as one connected system instead of a set of disconnected handoffs.

In its finished form, the DevKit gives feature teams a Node CLI, secure Figma OAuth, cross-platform design-spec readers, Microsoft Fabric UX parity rules, issue filing, migration planning, and agent-ready implementation contracts. The goal is simple: make the supported Microsoft Fabric UX path easier to use than local reinvention, while giving upstream component teams precise evidence when the library needs to evolve.

1 CLI for Figma intake, repo review, parity reports, issues, and migration plans
3 execution environments: local terminals, Codespaces, and agent runners
4 implementation outcomes: use Microsoft Fabric UX, keep local, file feature, or file bug
Loop feature delivery continuously feeds Microsoft Fabric UX component production

What the finished DevKit is

The DevKit is a design-to-code operating system for Microsoft Fabric UX adoption. It gives an agent the same evidence a senior component engineer would gather manually: the Figma node tree, visual captures, design tokens, component names, product requirements, repo conventions, existing local components, Microsoft Fabric UX React examples, Microsoft Fabric UX Angular examples, composition constraints, accessibility expectations, and issue history.

Instead of asking an agent to guess whether a Microsoft Fabric UX component is close enough, the DevKit turns the decision into a traceable report. The report says what the design requires, what the current repo already uses, what Microsoft Fabric UX supports, what Microsoft Fabric UX explicitly does not support, and which path should be taken for implementation.

Infrastructure surface

The DevKit exposes its capabilities as portable infrastructure rather than one-off prompts: environment diagnostics, remote Figma authentication, design-spec intake, parity analysis, migration planning, and issue preparation all produce structured outputs an agent can reason over and a human can review.

The implementation detail can be a local terminal, Codespaces session, or automated agent runner. The contract is the same: gather evidence first, make the decision explicit, then act only through a reviewable plan.

Evidence contract

The core product is a reviewable engineering artifact.

At the center of the DevKit is an evidence contract. Every design-to-code decision is backed by a structured packet: Figma requirements, repo environment facts, candidate Microsoft Fabric UX Web Components, rejected alternatives, composition constraints, accessibility obligations, and the final verdict. That contract lets agents move from best-guess implementation to reviewable engineering judgment.

It also changes what failure means. A failed migration is not wasted effort; it becomes precise upstream evidence for Microsoft Fabric UX. The same artifact that blocks an unsafe replacement can become a feature request, a bug report, a wrapper issue, a documentation fix, or a new documented adoption pattern.

Inputs

Figma nodes, screenshots, product requirements, repo packages, imports, wrappers, and current UI behavior.

Analysis

Candidate components, rejected alternatives, parity gates, composition rules, accessibility obligations, and risks.

Outputs

Migration plans, implementation instructions, ADO issue payloads, accepted paths, and blocked-adoption evidence.

Production guardrails

The DevKit is intentionally opinionated about when an agent is allowed to act. It does not let an agent invent unsupported Microsoft Fabric UX compositions, silently replace local controls, or file vague issues. The agent must pass evidence gates, name the exact component path, preserve the current product behavior when Microsoft Fabric UX does not meet parity, and ask before creating Azure DevOps work.

That constraint is what makes the system usable in production instead of only impressive in demos. The agent is free to gather evidence and explain tradeoffs, but implementation, issue filing, and migration happen through reviewable contracts rather than improvisation.

Reviewability

Every output is designed to be reviewed by humans. Parity reports explain why a component was accepted or rejected. Migration plans show the exact files, dependencies, and component substitutions involved. Filed issues include Figma evidence, acceptance criteria, rejected alternatives, and the reason the gap blocks adoption.

The result is agent work that can be inspected, challenged, approved, or converted into upstream platform work.

What I built

A production-grade agentic workflow, not a prompt library.

I built the DevKit as infrastructure at the boundary between component engineering, developer experience, design systems, and AI agent reliability. That meant designing the CLI surface, reducing the context footprint of Microsoft Fabric UX skills, defining parity-analysis gates, packaging agent-ready instructions, validating package contents, adding OAuth and Figma intake flows, and wiring the system into Azure DevOps issue creation.

CLI

Commands for diagnostics, Figma intake, parity analysis, migration planning, auth status, and issue previews.

Auth

Remote OAuth broker flow with Azure Key Vault client-secret storage and managed-identity access.

Skills

Agent-ready instructions that compress component docs into reliable evidence without flooding context.

ADO

Structured issue creation with duplicate detection, acceptance criteria, and parity evidence.

Agentic design-to-code flow

The agent moves through evidence gates before touching code.

01

Read the design spec

Pulls Figma nodes, images, component metadata, variables, styles, annotations, and product spec links through the CLI.

02

Gather requirements

Extracts roles, states, slots, density, keyboard behavior, validation rules, accessibility needs, and product constraints.

03

Review the environment

Inspects package manifests, framework versions, imports, existing tri-*, pbi-*, and local component usage.

04

Read Microsoft Fabric UX evidence

Loads streamlined Microsoft Fabric UX docs, examples, composition rules, wrapper APIs, tokens, and known issues.

05

Produce a plan

Chooses Microsoft Fabric UX, keeps an existing component, files a feature request, files a bug, or blocks migration with evidence.

Migration diagram

A circular system for replacing existing UI with Microsoft Fabric UX Web Components.

Component production and feature implementation move at the same time. Consumers use every Microsoft Fabric UX Web Component that meets parity, file precise issues when Microsoft Fabric UX does not, and migration agents later replace legacy product UI as those issues land back in production.

Build

Microsoft Fabric UX teams create components

Agents in Microsoft Fabric UX generate or update components from Figma specs, docs, examples, tests, wrappers, and release notes.

Consume

Feature teams implement product work

Agents read specs and use Microsoft Fabric UX Web Components where the documentation and environment evidence meet requirements.

Gap

DevKit files precise issues

When parity fails, the agent files Microsoft Fabric UX feature requests, Microsoft Fabric UX bugs, existing-component requests, or repo-local follow-ups.

Resolve

ADO agents open PRs

Automated Azure DevOps agents pick up approved issues, resolve the upstream gap, and open reviewed pull requests.

Migrate

Migration agents replace legacy UI

After Microsoft Fabric UX ships, migration agents revisit product repos and replace eligible existing components with Microsoft Fabric UX Web Components.

Microsoft Fabric UX adoption loop delivery continues while the component platform catches up

Automatic Figma OAuth

The CLI handles Figma authentication through a remote Microsoft Fabric UX OAuth broker. Users do not paste personal access tokens into repos, and no OAuth client secret ships in the npm package, VS Code extension, or agent prompt. The remote broker owns the sensitive Figma client-secret exchange, with the client secret stored in Azure Key Vault and accessed by the broker through managed identity. The CLI receives only user-scoped credentials and stores them in the native credential store or an agent-safe fallback.

  • Browser login on local Windows, macOS, and Linux machines.
  • Device-style login for GitHub Codespaces, SSH terminals, and headless agent runners.
  • Token status, refresh, logout, and diagnostics available as JSON for automation.
  • Remote Azure App Service broker backed by Azure Key Vault, managed identity, HTTPS-only endpoints, and health checks.

Auth capabilities

Authentication is built for both humans and agents. Local machines use browser-based sign-in, while hosted and headless environments use a device-style flow. Token status, refresh, logout, and diagnostics are exposed as machine-readable state so agent sessions can fail safely instead of guessing about credentials.

Design-spec readers

The CLI exposes Figma API requests in agent-friendly formats so the same workflow works across local terminals, Linux build agents, Codespaces, Windows developer machines, and CI validation. Commands can return compact requirement summaries for humans or stable JSON for agents.

A design read can include file structure, selected node trees, component instances, variants, text content, layout properties, variables, published component references, image captures, comments, and linked specs. The DevKit normalizes that evidence into a requirement packet before the agent compares it against Microsoft Fabric UX.

Figma intake capabilities

The intake layer can read file structure, selected node trees, component instances, variants, text content, layout properties, variables, published component references, image captures, comments, and linked specs. It normalizes that material into a compact requirement packet for parity review.

Decision model

The plan is only as good as the evidence behind it.

Every recommendation is anchored to a small set of verdicts. If Microsoft Fabric UX meets the spec and the repo can consume it safely, the plan uses Microsoft Fabric UX. If an existing repo component is the right answer for now, the plan names it. If Microsoft Fabric UX is missing a capability, the DevKit files a feature request. If Microsoft Fabric UX claims support but fails the documented behavior, the DevKit files a bug report. If the component exists upstream but the consuming repo cannot adopt it yet, the DevKit files a migration or wrapper issue for that existing component.

Issue automation

Issues are not vague handoffs. The DevKit attaches the parity report, Figma evidence, current environment findings, affected component names, rejected alternatives, and acceptance criteria. Duplicate detection runs before filing, and the agent asks for approval before creating upstream work.

Approved Azure DevOps issues become work items that automated ADO agents can pick up. Those agents resolve the bug or feature gap, update Microsoft Fabric UX Web Components from the design evidence, regenerate documentation and examples, run validation, and open pull requests for review.

ADO automation capabilities

The issue layer previews work before filing, detects duplicates, separates feature requests from bugs, includes acceptance criteria, and preserves the parity evidence that explains why adoption is blocked. Automated Azure DevOps agents can then pick up the issue and turn it into reviewed platform work.

Cross-platform execution

The DevKit is portable Node infrastructure, not a set of machine-specific scripts. It uses normalized paths, browser-safe login, stdout-first JSON, explicit exit codes, and dependency checks so the same commands run in PowerShell on Windows, Bash on Linux, GitHub Codespaces, CI jobs, and agent sessions.

  • Windows developer machines with PowerShell and VS Code.
  • Linux containers, CI workers, and Codespaces terminals.
  • Headless agent runs that need non-interactive auth and machine-readable output.
  • Local repo migrations where the agent needs filesystem and package evidence.

Quality bar

The finished system is validated like product infrastructure: CLI unit tests, broker login tests, token refresh tests, Codespaces tests, package contents tests, JSON schema stability checks, example catalog validation, Microsoft Fabric UX documentation consistency checks, remote broker tests, Azure Key Vault configuration checks, and cross-platform command runs.

Checklist Auditor

The same philosophy powers Checklist Auditor. Instead of relying on manual review to find missing exports, stale README sections, inconsistent Storybook controls, wrapper/API drift, missing options metadata, undocumented component surfaces, stale generated contracts, and package export gaps, the auditor converts the component health checklist into executable rules.

In one auditing pass, it resolved more than 5,000 bugs, inconsistencies, missing exports, and documentation or metadata gaps across the Microsoft Fabric UX component catalog. The DevKit can then consume those deterministic findings as structured platform evidence instead of vague review comments.

That link matters for agentic AI: the DevKit helps agents decide and route work, while Checklist Auditor keeps component-health truth grounded in repeatable checks and deterministic repairs.

Not screenshot-to-code

The DevKit is not a screenshot-to-React generator. It is a decision system for production UI adoption. Its job is not to make code that looks close once; its job is to determine whether a supported Microsoft Fabric UX Web Component can carry the product requirement over time.

When it cannot, the DevKit preserves delivery momentum while generating the upstream work needed to close the gap.

Why it matters

Local implementation friction becomes platform intelligence.

The DevKit makes migration continuous instead of episodic. Feature teams keep shipping with the best available components. Microsoft Fabric UX teams receive precise evidence for missing capabilities. Automated ADO agents turn those issues into PRs. Migration agents return later and replace eligible product UI with Microsoft Fabric UX Web Components as soon as the upstream platform catches up. Implementation keeps moving, and the component system gets smarter every lap.

The important shift is leverage. One feature team's failed migration becomes a reusable Microsoft Fabric UX issue. One checklist violation becomes a rule. One accepted parity path becomes a documented adoption pattern. Over time, the DevKit turns local implementation friction into platform intelligence.