Azure Fabric Capacity Manager
Manage Microsoft Fabric capacities and their lifecycle with the Azure Python SDK.
The evidence shows use of DefaultAzureCredential, avoidance of connection strings, and production credential-chain constraints, providing some least-privilege and audit awareness. However, create, update, suspend, and delete operations have external and billing effects without user confirmation, rollback/recovery guidance, or sufficiently explicit data-flow and permission boundaries, so points are deducted.
The documentation covers basic CRUD, LROs, and context management, but has reproducible correctness risks: FabricCapacityAdministration is used without an import, the main document uses CapacitySku while the reference uses RpSku, list_skus signatures conflict, and exception handling and diagnosable failure feedback are thin. Static calibration caps this at 10, so the score is conservative.
Triggers, audience, and core Fabric-capacity scenarios are reasonably clear. Non-fit boundaries, permission prerequisites, async usage, mainland-China network fit, and SDK/API version variance are not sufficiently defined, so points are deducted.
The skill has YAML metadata, MIT licensing, installation and environment-variable notes, layered references, and a version field. It lacks a changelog, explicit maintenance responsibility and update path, and contains inconsistent reference content, so it does not merit full marks.
The skill can help generate common capacity-management code and explains LROs, SKUs, and states. However, key examples may not run as written, destructive operations lack safety workflow, and error handling, paging, monitoring, and production validation are incomplete. Static evidence cannot establish correctness, so this remains at or below 7.
Auditable source documentation, an MIT license, and repository-level CI/test material are present, but the supplied tests do not cover this skill's key Python SDK paths and there is no skill-specific acceptance suite or third-party execution evidence. Conclusions therefore rely mainly on documentation claims and are capped at 5.
- Verify model names, method names, and the list_skus signature against the target azure-mgmt-fabric version; in particular resolve the missing FabricCapacityAdministration import and the CapacitySku/RpSku mismatch.
- Add explicit confirmation, least-privilege permissions, audit logging, and feasible recovery/rollback procedures for create, scale, suspend, and delete operations; deletion should not be presented as an unguarded default.
- Add diagnosable handling for exceptions, polling timeouts, retry boundaries, pagination, authorization failures, and missing resources, plus executable skill-specific tests.
- Reconcile DefaultAzureCredential(require_envvar=True) with the AZURE_TOKEN_CREDENTIALS requirement and validate mainland-China connectivity and enterprise proxy conditions.
What does this skill do, and when should you use it?
This skill supports development with the Azure Fabric Management SDK for Python. It explains package installation, Azure credential configuration, and use of FabricMgmtClient to create, inspect, list, update, suspend, resume, and delete Microsoft Fabric capacities. It also covers name availability, SKU discovery, capacity states, and long-running operations. It is a good fit for Azure developers automating Fabric capacity management from Python.
It guides users through installing azure-mgmt-fabric and azure-identity, reading AZURE_SUBSCRIPTION_ID and AZURE_RESOURCE_GROUP, configuring DefaultAzureCredential or a specific Azure credential, and creating FabricMgmtClient with deterministic cleanup. Examples call fabric_capacities and operations to create capacities, retrieve details, list by resource group or subscription, update SKUs and tags, suspend, resume, delete, check names, and list available SKUs. Mutating operations are handled as long-running operations using .result() or manual polling.
- A Python Azure developer needs to provision a Microsoft Fabric capacity with a region, SKU, and administrators.
- A platform engineer needs to inventory Fabric capacities across a resource group or subscription.
- An operations team wants to suspend unused capacities to stop billing and resume them later.
- An application team needs to scale a capacity SKU, add cost-tracking tags, or validate a name before creation.
- A developer needs a consistent pattern for handling Fabric management long-running operations.
What are this skill's strengths and limitations?
- Covers the main Fabric capacity lifecycle, including creation, updates, suspension, resumption, and deletion.
- Clearly recommends DefaultAzureCredential and explains local-development and production configuration.
- Emphasizes deterministic cleanup for clients, async credentials, transports, and token caches.
- Includes practical patterns for SKUs, states, name checks, and long-running operations.
- The scope is centered on capacity management and does not demonstrate broader Fabric workloads or analytics operations.
- The create-capacity example uses FabricCapacityAdministration without showing its import.
- The supplied material does not provide evidence of dedicated test coverage for this individual skill.
- The referenced capabilities.md and non-hero-scenarios.md files are not included in the supplied source.
How do you install this skill?
Place the skill directory in the skills directory used by the coding agent. The full repository can be installed with npx skills add microsoft/skills, followed by selecting skills in the wizard. Install the Python dependencies with pip install azure-mgmt-fabric and pip install azure-identity. The source does not specify the exact copy path for this individual skill across agents.
How do you use this skill?
A suitable trigger prompt is: Use azure-mgmt-fabric in Python to create and manage a Microsoft Fabric capacity with DefaultAzureCredential and context managers. Set AZURE_SUBSCRIPTION_ID and AZURE_RESOURCE_GROUP before running the generated code. For production use of DefaultAzureCredential, set AZURE_TOKEN_CREDENTIALS=prod or a specific credential. Choose either synchronous or asynchronous APIs consistently and wait for every mutating LRO to complete.