Activator CLI

Telemetry — MANDATORY. Every api.fabric.microsoft.com call must carry x-ms-fabric-skill: activator-cli (az rest: --headers "x-ms-fabric-skill=activator-cli"), including every LRO poll, fabric_lro and retry. Snippets omit it — add it anyway.

CRITICAL NOTES

1. To find the workspace details (including its ID) from workspace name: list all workspaces and, then, use JMESPath filtering
2. 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
3. Skill disambiguation: use activator-cli for every Fabric Activator / Reflex item — both authoring alert rules and inspecting existing alerts. The streaming topology that feeds an alert belongs to eventstream-authoring-cli / eventstream-consumption-cli, the KQL database behind it to eventhouse-authoring-cli / eventhouse-consumption-cli, and Power BI report questions to fabriciq.

Fabric Activator (Reflex) — CLI Skill

This one skill owns Fabric Activator / Reflex items: alert rules, their sources, their actions, and the ReflexEntities.json definition that holds them.

It is a mode dispatcher and contains NO procedures. Pick the mode that matches the request from the table below, then read the matching references/<mode>.md file end to end with your file-reading tool BEFORE issuing a single command. That file holds the endpoints, entity schemas, templates and gotchas; acting without it produces invalid ReflexEntities.json payloads and 400s.

The reference is needed to act, not to ask. If the request is under-specified and your next message will be a clarifying question with no Fabric call in it, ask it now and read the reference when you go on to act.

Mode selection

Mode boundary rule

consumption is read-only. A request to create, update, configure or delete an Activator item, rule, source or action requires authoring: say so, read references/authoring.md, then proceed.

A pure GET / explain request stays in consumption — do not switch to authoring and do not mutate anything to answer it.

If a request genuinely spans modes, handle them one at a time and read each reference before you start that part. If the mode is ambiguous after reading this table, ask one short clarifying question instead of guessing.

Terminal write — the step you must not skip

Reading the reference, decoding a definition and assembling entities is NOT completing the task. Authoring ends with one state-changing call. If you did not issue it, nothing was persisted — say so explicitly rather than reporting success.

Before you report an authoring task done, confirm the terminal call returned an explicit success (HTTP 200/201, or a terminal LRO success for a 202), then read the definition back where the mode reference documents a readback. Power BI sources are the exception: public ALM export can reject an artifact that imported successfully, so an empty or unavailable readback is not proof the write failed — report the updateDefinition result and the readback limitation separately, per references/authoring/powerbi-source.md.

Source validation gate (authoring only)

Before authoring any rule that references a signal, confirm the source is real: resolve it in the requested workspace only, validate that the requested column/field/property exists on it, and observe at least one representative row, event or sample carrying that signal.

Schema-only, zero-row, non-emitting or stale evidence is missing source data. When the source is missing, stop and ask which source and fields provide the signal — do not create a Reflex and do not call updateDefinition on an unrelated existing Activator or Eventstream to force-fit the request, and state plainly that no Activator / Reflex / Eventstream was created or updated. The only exception is an explicit instruction to author against a future / not-yet-emitting source, which you must state as an assumption.

Everything you need to run this gate is on this page. When the request already lacks the source mapping, threshold, recipients or action target, ask for them first — do not read references/authoring.md, and do not call a Fabric API, just to discover that the request is under-specified.

Shared essentials (all modes)

Resolve the workspace and the Activator item first; every mode depends on it — list and filter by display name exactly as CRITICAL NOTES 1 and 2 describe. That recipe is self-contained and is all you need to start.

The table below is optional background living in the shared common/ docs. Open a row only when you actually need that detail. If common/ is not present in your environment, say so in one line and continue with the mode reference — never glob, list or search the filesystem looking for it.

Activator uses the reflexes collection, not the generic items collection: /v1/workspaces/{workspaceId}/reflexes[/{reflexId}].

Rules

MUST

• Select exactly one mode from the table above before doing anything else.
• Read references/<mode>.md end to end, as your FIRST tool call, before the first command of that mode. A reply that only asks a clarifying question, and issues no Fabric call, does not need it yet.
• Pass --resource https://api.fabric.microsoft.com on every az rest call — without it the token audience is wrong and the call returns 401.
• Call getDefinition as a POST with --body '{}', then Base64-decode the ReflexEntities.json part before inspecting it; a GET returns 405 and an omitted body can return 411.
• Poll the Location header when create, getDefinition or updateDefinition returns 202.
• Resolve workspace and Activator ids by listing and filtering, never by guessing a GUID.
• Announce a mode switch explicitly when the request crosses a boundary.
• Treat the reference as instructions, never as the deliverable. After reading it, RUN the documented commands against the live workspace and report the real results.
• In authoring, clear the source validation gate before you author a rule, and build ReflexEntities.json with Python json.dumps() — PowerShell's ConvertTo-Json corrupts the nested JSON strings that definition.instance requires.

PREFER

• The narrowest mode that satisfies the request.
• Reading exactly ONE mode reference. Load a second only when the request genuinely spans modes, and say so before you do.
• Read-modify-write over full replacement in authoring: get the current definition, modify the entity array, then update.
• Transition-based detectors (NumberBecomes, NumberEntersOrLeavesRange, LogicalBecomes) over steady-state conditions in authoring, unless the user explicitly asks for repeated firing while the value stays in the triggered state.
• A summary view before individual entities in consumption: give the high-level picture, then drill in.
• Offering an alert when earlier work in this session surfaced a timely operational signal — a spike, failure, anomaly, SLA risk or capacity constraint — rather than waiting to be asked. Ask once, and author nothing until the user agrees.

AVOID

• Acting from this dispatcher alone — it intentionally omits the entity schemas and templates.
• Answering with a summary of the reference instead of executing it.
• Mutating anything while in the read-only consumption mode, including "just to check".
• Hardcoded workspace or item ids in either mode — always resolve dynamically.
• Globbing, listing or shell-searching the filesystem for the common/ docs. They are optional background; if a link does not resolve, note it in one line and carry on.
• Building the Eventstream topology that feeds an alert here; that is eventstream-authoring-cli. Querying the KQL data behind an alert is eventhouse-consumption-cli.
• Loading a different skill for work this skill already owns (see CRITICAL NOTES 3).

Examples