plugins/fabric-consumption/skills/activator-consumption-cli/SKILL.md
Inspect existing alerts, notifications, and automated actions in Fabric via read-only REST API calls using `az rest` CLI. **Invoke this skill** whenever the user wants to: (1) list existing alerts in a workspace, (2) inspect how an alert or notification is configured, (3) read and decode an Activator/Reflex definition (ReflexEntities.json), (4) list rules, sources, and actions behind an alert, (5) understand why an alert fires or what action it takes. **Invoke this skill before answering questions** about an Activator/Reflex item in a Fabric workspace — the listing, lookup, and decoding workflows are part of this skill, not preamble to it. Triggers: "show my alerts", "what alerts do I have", "inspect this alert", "show me the rule", "show me the action", "show me the source", "get reflex definition", "list activators", "list alerts", "list reflex items", "show activator items", "activator details", "find activator named"
npx skillsauth add microsoft/skills-for-fabric activator-consumption-cliInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Update Check — ONCE PER SESSION (mandatory) The first time this skill is used in a session, run the check-updates skill before proceeding.
- GitHub Copilot CLI / VS Code: invoke the
check-updatesskill (e.g.,/fabric-skills:check-updates).- Claude Code / Cowork / Cursor / Windsurf / Codex: read the local
package.jsonversion, then compare it against the remote version viagit fetch origin main --quiet && git show origin/main:package.json(or the GitHub API). If the remote version is newer, show the changelog and update instructions.- Skip if the check was already performed earlier in this session.
CRITICAL NOTES
- To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering
- To find the item details (including its ID) from workspace ID, item type, and item name: list all items of that type in that workspace and, then, use JMESPath filtering
| Task | Reference | Notes |
|---|---|---|
| Finding Workspaces and Items in Fabric | COMMON-CLI.md § Finding Workspaces and Items in Fabric | Mandatory — READ link first [needed for workspace/item ID resolution] |
| Fabric Topology & Key Concepts | COMMON-CORE.md § Fabric Topology & Key Concepts | |
| Authentication & Token Acquisition | COMMON-CORE.md § Authentication & Token Acquisition | Wrong audience = 401 |
| Core Control-Plane REST APIs | COMMON-CORE.md § Core Control-Plane REST APIs | |
| Long-Running Operations (LRO) | COMMON-CORE.md § Long-Running Operations (LRO) | getDefinition may return 202 |
| Rate Limiting & Throttling | COMMON-CORE.md § Rate Limiting & Throttling | |
| Fabric Item Definitions | ITEM-DEFINITIONS-CORE.md § Definition Envelope | Base64 payload structure |
| Authentication Recipes | COMMON-CLI.md § Authentication Recipes | az login flows |
| Fabric Control-Plane API via az rest | COMMON-CLI.md § Fabric Control-Plane API via az rest | Always pass --resource https://api.fabric.microsoft.com |
| LRO Pattern | COMMON-CLI.md § Long-Running Operations (LRO) Pattern | |
| Pagination Pattern | COMMON-CLI.md § Pagination Pattern | |
| Tool Stack | SKILL.md § Tool Stack | |
| Connection | SKILL.md § Connection | |
| Listing Activator Items | SKILL.md § Listing Activator Items | |
| Inspecting a Single Activator | SKILL.md § Inspecting a Single Activator | |
| Reading the Definition | SKILL.md § Reading the Definition | |
| Exploring Rules, Sources, and Actions | SKILL.md § Exploring Rules, Sources, and Actions | |
| Must / Prefer / Avoid | SKILL.md § Must / Prefer / Avoid | |
| Examples | SKILL.md § Examples | |
| Tool | Purpose | Install |
|---|---|---|
| az cli | Fabric REST API calls for reading Activator items and definitions | winget install Microsoft.AzureCLI |
| jq | JSON processing, Base64 decoding, definition inspection | winget install jqlang.jq |
Use the shared authentication guidance in COMMON-CLI.md § Authentication Recipes. Resolve workspace and item IDs per COMMON-CLI.md § Finding Workspaces and Items in Fabric. Examples below assume WS_ID and REFLEX_ID are already resolved.
az rest --method GET \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes" \
--resource "https://api.fabric.microsoft.com" \
| jq '.value[] | {id, displayName, description}'
Required scopes: Workspace.Read.All or Workspace.ReadWrite.All
For workspaces with many items, follow the continuationUri returned in each response:
NEXT_URL="https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes"
while [ -n "$NEXT_URL" ]; do
RESPONSE=$(az rest --method GET \
--url "$NEXT_URL" \
--resource "https://api.fabric.microsoft.com")
echo "$RESPONSE" | jq '.value[] | {id, displayName, description}'
NEXT_URL=$(echo "$RESPONSE" | jq -r '.continuationUri // empty')
done
az rest --method GET \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes?recursive=true&rootFolderId=${FOLDER_ID}" \
--resource "https://api.fabric.microsoft.com" \
| jq '.value[] | {id, displayName}'
az rest --method GET \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}" \
--resource "https://api.fabric.microsoft.com" \
| jq '{id, displayName, description, type, workspaceId}'
getDefinitionis a POST (not GET), requires ReadWrite scopes (Reflex.ReadWrite.AllorItem.ReadWrite.All) even for read-only inspection, and may return 202 LRO. Use thefabric_lrohelper from COMMON-CLI.md § Long-Running Operations (LRO) Pattern so 202 responses can be polled via theLocationheader before decoding.
DEFINITION=$(fabric_lro POST \
"https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
'{}')
echo "$DEFINITION" \
| jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
| base64 -d | jq .
DEFINITION=$(fabric_lro POST \
"https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
'{}')
echo "$DEFINITION" \
| jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
| base64 -d | jq . > reflex-entities.json
Once you have the decoded ReflexEntities.json, use jq to extract specific components.
cat reflex-entities.json | jq '[.[] | .type] | sort | group_by(.) | map({type: .[0], count: length})'
cat reflex-entities.json | jq '.[] | select(.type | endswith("Source-v1")) | {name: .payload.name, type: .type, id: .uniqueIdentifier}'
cat reflex-entities.json | jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, id: .uniqueIdentifier, shouldRun: .payload.definition.settings.shouldRun}'
# Objects
cat reflex-entities.json | jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Object") | {name: .payload.name, id: .uniqueIdentifier}'
# Attributes for a specific object
OBJECT_ID="<object-guid>"
cat reflex-entities.json | jq --arg oid "$OBJECT_ID" '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Attribute" and .payload.parentObject.targetUniqueIdentifier == $oid) | {name: .payload.name, id: .uniqueIdentifier}'
RULE_ID="<rule-guid>"
cat reflex-entities.json \
| jq --arg rid "$RULE_ID" '.[] | select(.uniqueIdentifier == $rid) | .payload.definition.instance' -r \
| jq '.steps[] | {step: .name, rows: [.rows[] | .kind]}'
cat reflex-entities.json | jq '.[] | select(.type == "fabricItemAction-v1") | {name: .payload.name, itemType: .payload.fabricItem.itemType, itemId: .payload.fabricItem.itemId}'
Get a high-level overview of an Activator's configuration:
cat reflex-entities.json | jq '{
containers: [.[] | select(.type == "container-v1") | .payload.name],
sources: [.[] | select(.type | endswith("Source-v1")) | {name: .payload.name, type: .type}],
objects: [.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Object") | .payload.name],
rules: [.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, active: .payload.definition.settings.shouldRun}],
actions: [.[] | select(.type == "fabricItemAction-v1") | {name: .payload.name, type: .payload.fabricItem.itemType}]
}'
--resource https://api.fabric.microsoft.com with az rest--body '{}' for getDefinition — it is a POST and omitting the body can cause 411 errorsgetDefinition may return 202; poll the Location headerReflexEntities.json payload before inspection — it is Base64-encoded in the API responsedefinition.instance field in rule entities — it is a JSON-encoded string, not a nested objectjq locallygetDefinition — it is a POST endpoint; GET will return 405# Step 1: List activators
az rest --method GET \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes" \
--resource "https://api.fabric.microsoft.com" \
| jq '.value[] | {id, displayName}'
# Step 2: For a specific activator, get and decode its definition
az rest --method POST \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
--resource "https://api.fabric.microsoft.com" \
--headers "Content-Type=application/json" \
--body '{}' \
| jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
| base64 -d \
| jq '.[] | select(.type == "timeSeriesView-v1" and .payload.definition.type == "Rule") | {name: .payload.name, active: .payload.definition.settings.shouldRun}'
# Decode definition and extract rule details
az rest --method POST \
--url "https://api.fabric.microsoft.com/v1/workspaces/${WS_ID}/reflexes/${REFLEX_ID}/getDefinition" \
--resource "https://api.fabric.microsoft.com" \
--headers "Content-Type=application/json" \
--body '{}' \
| jq '.definition.parts[] | select(.path=="ReflexEntities.json") | .payload' -r \
| base64 -d \
| jq '.[] | select(.payload.name == "Too hot for medicine") | .payload.definition.instance' -r \
| jq '.steps[] | {step: .name, details: .rows}'
Activation history (when rules fired) is not available via the public REST API. It is accessible via the Activator MCP server using the get_activations_for_rule tool.
Use the shared authentication guidance in COMMON-CLI.md § Authentication Recipes before connecting to the Activator MCP endpoint.
pip install mcp httpx azure-identity aiohttp
uniqueIdentifierget_activations_for_rule with the rule IDThe Activator MCP endpoint is at:
https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspaceId}/reflexes/{activatorId}
Use the shared Fabric API authentication guidance from COMMON-CORE.md § Authentication & Token Acquisition. MCP clients should rely on standard Azure identity flows and must not hardcode tokens.
get_activations_for_ruleConnect using the MCP streamable_http_client, then call the tool:
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client
# After connecting and initializing the session:
result = await session.call_tool(
"get_activations_for_rule",
{
"getActivationsParams": {
"workspaceId": "<workspace-id>",
"artifactId": "<activator-id>",
"ruleId": "<rule-uniqueIdentifier>",
}
},
)
The response contains totalCount and an activations array with details of each time the rule fired.
| Tool | Purpose |
|------|---------|
| list_rules | List rules in an Activator (alternative to public API decode) |
| get_activations_for_rule | Get activation history for a specific rule |
/reflexes) for listing and getDefinition for inspectionaz rest with the Fabric API audiencegetDefinition requires ReadWrite scopes even for read-only access — this is a known API requirementdevelopment
Build a guided requirements-to-implementation workflow for new Power BI reports and dashboards from semantic models, datasets, or PBIP projects. Use when the user wants to: (1) plan then implement a report, (2) define audience, scope, page plan, design direction, dependencies, and delivery target, (3) create a locked report spec with approval before PBIR authoring. For direct edits to existing report files, use `powerbi-report-authoring`. For design-only critique or redesign, use `powerbi-report-design`. Triggers: "build me a dashboard", "create a new report", "plan then implement", "define and build Power BI report", "walk me through creating a report".
tools
Manage Power BI report workspace items in Microsoft Fabric via `az rest` CLI against the Fabric REST API. Use when the user wants to: (1) create reports from PBIR definitions, (2) get or download report definitions, (3) update report definitions or properties, (4) list workspace reports, (5) delete reports. For report layout authoring (pages, visuals, filters, formatting), use `powerbi-report-authoring`. Triggers: upload Power BI report, download PBIR definition, publish Power BI report to Fabric, manage Power BI reports.
development
Generate Power BI report visual design guidance before PBIR files are written. Use when the user wants to: (1) choose tone, signature, page archetypes, chart types, layout, color, typography, theme direction, or accessibility approach, (2) redesign/restyle an existing report, apply a brand, or critique chart/layout choices, (3) produce a design contract for `powerbi-report-authoring`. For end-to-end requirements, approval, and build sequencing, use `powerbi-report-planning`. Triggers: "design Power BI report", "make dashboard look professional", "choose chart type", "apply brand to report", "redesign report", "create design brief".
tools
Create and modify Power BI report files in PBIR/PBIP format using the `powerbi-report-author` and `powerbi-desktop` CLIs. Use when the user wants to: (1) implement an approved report spec or design brief, (2) add or edit pages, visuals, filters, slicers, bookmarks, themes, or formatting, (3) validate PBIR and verify rendering in Power BI Desktop. For open-ended visual design, use `powerbi-report-design` first. For end-to-end requirements and approval workflow, use `powerbi-report-planning` first. Triggers: "edit PBIR", "create Power BI report page", "add visual to PBIP", "format report visual", "validate Power BI report", "reload Desktop screenshot", "implement an approved PBIP report spec", "edit PBIR pages/visuals".