activator-authoring-cli

更新检查 — 每个会话仅检查一次（强制） 首次在会话中使用此技能时，必须先运行 check-updates 技能，然后再继续。

• GitHub Copilot CLI / VS Code：调用 check-updates 技能（例如，/fabric-skills:check-updates）。
• Claude Code / Cowork / Cursor / Windsurf / Codex：读取本地 package.json 版本，然后通过 git fetch origin main --quiet && git show origin/main:package.json（或 GitHub API）与远程版本进行比较。如果远程版本较新，则显示更新日志和更新说明。
• 如果本会话中此前已执行过检查，则跳过。

重要提示

1. 要根据工作区名称查找工作区详细信息（包括其 ID）：先列出所有工作区，然后使用 JMESPath 进行筛选
2. 要根据工作区 ID、项目类型和项目名称查找项目详细信息（包括其 ID）：先列出该工作区中该类型的所有项目，然后使用 JMESPath 进行筛选

activator-authoring-cli — 通过 CLI 编写 Activator 项目和规则

目录

任务	参考	备注
在 Fabric 中查找工作区和项目	COMMON-CLI.md § 在 Fabric 中查找工作区和项目	强制 — 先阅读链接 [用于解析工作区/项目 ID]
身份验证和令牌获取	COMMON-CORE.md § 身份验证和令牌获取	受众错误 = 401
身份验证步骤	COMMON-CLI.md § 身份验证步骤	使用通用文档中的 az login / 令牌指南
核心控制平面 REST API	COMMON-CORE.md § 核心控制平面 REST API	列出工作区、列出项目、创建项目
长时间运行操作（LRO）	COMMON-CORE.md § 长时间运行操作（LRO）	Create、getDefinition、updateDefinition 可能返回 202
Fabric 项目定义	ITEM-DEFINITIONS-CORE.md § 定义封装	Base64 编码的部件结构
通过 az rest 调用 Fabric 控制平面 API	COMMON-CLI.md § 通过 az rest 调用 Fabric 控制平面 API	始终传入 --resource https://api.fabric.microsoft.com
LRO 模式	COMMON-CLI.md § 长时间运行操作（LRO）模式	轮询 202 响应
实体类型、源和视图	source-types.md	实体封装、源实体和 timeSeriesView-v1 变体
Eventstream 源	eventstream-source.md	推送源工作流：先创建 Eventstream 接收器，然后扩展发现的 Activator 实体
KQL 源	kql-source.md	KQL 源架构、时间轴支持、设计指南
Digital Twin Builder / 本体源	dtb-source.md	DTB / 本体源架构、JSON 字符串查询负载、快照与时间轴指南
实时中心源	real-time-hub-source.md	实时中心源架构、工作区事件类型
Power BI 源	powerbi-source.md	powerBiSource-v1、存储的查询负载、DatasetMetric、筛选器、持久化和 ALM 回读限制
规则条件	rule-conditions.md	规则模板结构、检测条件、聚合、时间窗口、发生选项、扩充
操作类型	action-types.md	TeamsMessage、EmailMessage、FabricItemInvocation 操作架构

---

工具栈

工具	用途
az CLI	Fabric 身份验证和 REST API 令牌获取
curl	通过共享的 fabric_lro 辅助工具执行支持标头的 Fabric REST 调用
jq	JSON 筛选和解码后的定义检查
python	必须用于构建 ReflexEntities.json——json.dumps() 能正确处理嵌套字符串化。PowerShell 的 ConvertTo-Json 会破坏嵌套 JSON 字符串。

⚠️ 关键：始终使用 Python（而非 PowerShell）构建 ReflexEntities.json 负载和 API 请求正文。

Python 模式

import json, base64, uuid

# Stringify template → JSON string for definition.instance
instance_string = json.dumps(template_dict, separators=(',', ':'))

# Encode entities and write updateDefinition request body
payload_b64 = base64.b64encode(json.dumps(entities).encode('utf-8')).decode('utf-8')
body = json.dumps({"definition": {"parts": [{"path": "ReflexEntities.json", "payload": payload_b64, "payloadType": "InlineBase64"}]}})
with open('update-body.json', 'w', encoding='utf-8') as f:
    f.write(body)
# Then: az rest --method POST --url "...updateDefinition" --resource "https://api.fabric.microsoft.com" --body @update-body.json

# Decode a getDefinition response
response = json.loads(api_output)
for part in response['definition']['parts']:
    if part['path'] == 'ReflexEntities.json':
        entities = json.loads(base64.b64decode(part['payload']).decode('utf-8'))

# Generate GUIDs for uniqueIdentifier and step id fields
entity_id = str(uuid.uuid4())

---

连接

请参阅 COMMON-CLI.md § Authentication Recipes 中的共享身份验证指南。按照 COMMON-CLI.md § Finding Workspaces and Items in Fabric 解析工作区和项 ID。以下示例假设 WS_ID 和 REFLEX_ID 已解析。

---

项目 CRUD

请使用 COMMON-CLI.md § Item CRUD Operations 中的共享机制。Activator 使用 reflexes 端点，而非通用的 items 端点：

操作	端点	方法	范围	备注
创建	/v1/workspaces/{workspaceId}/reflexes	POST	Reflex.ReadWrite.All 或 Item.ReadWrite.All	可能返回 202 LRO——使用 COMMON-CLI 中的 fabric_lro
更新元数据	/v1/workspaces/{workspaceId}/reflexes/{reflexId}	PATCH	Reflex.ReadWrite.All 或 Item.ReadWrite.All	按照 COMMON-CLI 元数据更新模式操作
删除	/v1/workspaces/{workspaceId}/reflexes/{reflexId}	DELETE	Reflex.ReadWrite.All 或 Item.ReadWrite.All	永久删除时添加 ?hardDelete=true
getDefinition	/v1/workspaces/{workspaceId}/reflexes/{reflexId}/getDefinition	POST	Reflex.ReadWrite.All 或 Item.ReadWrite.All	必须提供空正文；可能返回 202 LRO——使用 fabric_lro
updateDefinition	/v1/workspaces/{workspaceId}/reflexes/{reflexId}/updateDefinition	POST	Reflex.ReadWrite.All 或 Item.ReadWrite.All	使用 Python 构建 update-body.json，然后按照 COMMON-CLI 的 updateDefinition 模式操作

---

通过定义管理规则

通过 getDefinition 和 updateDefinition 管理规则。负载为 ReflexEntities.json，其中包含经过 Base64 编码的实体对象 JSON 数组。工作流：获取 → 解码 → 修改 → 重新编码 → 更新。

获取定义

getDefinition 使用 POST（而非 GET），需要 ReadWrite 范围，并且可能返回 202 LRO。请使用 COMMON-CLI.md § Long-Running Operations (LRO) Pattern 中的 fabric_lro 辅助工具，通过 Location 标头轮询 202 响应，然后再解码。

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 .

更新定义

必须使用 Python 构建 update-body.json（参见 Python Patterns），然后按照 COMMON-CLI 的 updateDefinition 模式，将其上传到 /v1/workspaces/{workspaceId}/reflexes/{reflexId}/updateDefinition。

ReflexEntities.json——组装流程

按顺序构建实体 JSON 数组。每个实体的 uniqueIdentifier 都需要一个新生成的 GUID。对于此技能中手动编写的拉取源流程，请使用 templateVersion 1.2.4。对于由 Eventstream 接收器创建的流程，请保留解码后的 Activator 定义中已有的模板版本；这些回读结果可能使用 1.1。

步骤 1——容器（恰好 1 个）：

• 类型：container-v1。使用与源图匹配的容器负载类型：KQL 源使用 kqlQueries，Real-Time Hub 工作区订阅使用 rthSubscriptions，Power BI 源使用大小写完全匹配的 pbiMetrics，Eventstream 流程则使用回读结果中已有的服务创建类型。
• 所有其他实体都通过 parentContainer.targetUniqueIdentifier 引用此容器 第 2 步 — 数据源（恰好 1 个，选择正确的类型）：
• 请参阅 eventstream-source.md、kql-source.md、dtb-source.md、real-time-hub-source.md 或 powerbi-source.md，了解受支持的数据源工作流
• 对于手动编写的拉取数据源，设置 parentContainer.targetUniqueIdentifier → 容器 GUID
• 对于 eventstreamSource-v1：请勿从手动编写数据源开始。先创建或更新带有 Activator 目标的 Eventstream，然后读取 Activator 定义，并从自动创建的 eventstreamSource-v1 和 SourceEvent 实体继续。在公开读取结果中，这些由接收器创建的实体可能不会显式包含 parentContainer。
• 对于 kqlSource-v1：KQL 查询应返回所有数据（请勿预先筛选条件——让规则处理）。必须包含 eventhouseItem、metadata 和 queryParameters。对于 Fabric Eventhouse/KQL DB 数据源，请使用 eventhouseItem: { itemId, workspaceId, itemType: "KustoDatabase" }。对于外部 ADX/Kusto 数据源，请使用 eventhouseItem: { clusterHostName, databaseName }。创建 Activator 前，请直接对目标数据源运行 KQL，并确认返回的列、时间戳字段和行结构正确。 只要查询结果有合适的时间戳列，就应使用 eventTimeSettings 以及 DURATION_START/DURATION_END 查询参数，并在 KQL 中用 declare query_parameters(startTime:datetime, endTime:datetime); 声明这些参数。 仅当底层数据没有合适的时间戳列且每一行都代表当前状态时，才使用快照模式（queryParameters: []，不设置 eventTimeSettings，不进行时间筛选）。请参阅 kql-source.md。
• 对于 digitalTwinBuilderSource-v1：使用 DTB / Ontology connection 项引用 { itemId, workspaceId, itemType }，其中 itemType 为 DigitalTwinBuilder 或 Ontology。query.queryString 必须是 JSON 字符串载荷，而不是 KQL。创建 Activator 前，请先直接运行 DTB / Ontology 查询，并确认返回的列、键字段和时间戳字段正确。 如果返回的行包含合适的时间戳字段，优先使用 eventTimeSettings 和 DURATION_START/DURATION_END 查询参数；与 KQL 不同，这些持续时间参数会作为 DTB 终结点 URL 查询参数应用，而不是在查询正文中引用。请参阅 dtb-source.md。
• 对于 powerBiSource-v1：根据限定范围的报表/页面/视觉对象和语义模型元数据，以确定性方式构建数据源。其父容器必须使用精确的 payload.type: "pbiMetrics"。将源查询载荷以 JSON 文本形式存储在 query.queryString 中，并在 metricDefinition 中存储匹配的 DatasetMetric。使用 updateDefinition 持久化，要求明确收到 HTTP 200（或终结的 LRO 成功状态），并在出现任何导入错误时停止。请参阅 powerbi-source.md。

第 3 步 — SourceEvent 视图（恰好 1 个）：

• 类型：timeSeriesView-v1，definition.type: "Event"，实例：引用 Source 的 entityId 的 SourceEvent 模板
• 对于手动编写的拉取数据源流程，设置 parentContainer → 容器 GUID
• 对于 Eventstream 接收器创建的流程，重用读取结果中自动创建的 SourceEvent，而不是再创建一个

第 4 步 — 根据触发器类型选择实体图

• 对于 AttributeTrigger 规则（阈值、范围、文本匹配、布尔值检查、聚合）：
  • 创建一个 Object 视图
  • 如果事件必须映射到对象实例，可选择创建 SplitEvent
  • 创建 IdentityPartAttribute 和所有必需的 BasicEventAttribute 实体
  • 规则随后会在 ScalarSelectStep 中引用这些值属性
• 对于 EventTrigger 规则（在每个事件、心跳、事件字段状态／变更时触发）：
  • 使用最精简的图：Container → Source → SourceEvent → Rule（+ 可选的 fabricItemAction-v1）
  • 除非场景确实需要基于属性的建模，否则不要创建 Object、SplitEvent、IdentityPartAttribute 或 BasicEventAttribute 实体
  • FieldsDefaultsStep 必须包含一个 EventSelector 行，其嵌套的 EventReference.entityId 指向 SourceEvent 实体。顶层 EventReference 行无效。
  • EventTrigger 会直接在 FieldsDefaultsStep / EventDetectStep 中读取原始事件字段

步骤 5 — Rule（每个警报 1 个）：

• 类型：timeSeriesView-v1，definition.type："Rule"
• 始终添加 "description": "Created by: skills-for-fabric"，以便用户清楚了解
• 实例：规则模板（参见 rule-conditions.md）
  • AttributeTrigger（v1.2.4）：ScalarSelectStep → ScalarDetectStep → （DimensionalFilterStep）* → ActStep
  • EventTrigger（v1.2.4）：FieldsDefaultsStep → （EventDetectStep）+ → （DimensionalFilterStep）* → ActStep
• instance 必须是 JSON 字符串（使用 json.dumps()）
• instance.steps[] 中的每个模板步骤都需要一个 GUID 格式的 id。缺少步骤 ID 可能会导致表达式图无效，因为后端转换器会使用步骤 ID 作为输出节点 ID。
• 对于 AttributeTrigger，将 parentObject 设为 Object，将 parentContainer 设为 Container
• 对于 EventTrigger，将 parentContainer 设为 Container；除非设计明确要求，否则省略 parentObject
• 默认设置为 settings: { "shouldRun": true, "shouldApplyRuleOnUpdate": false }，使新创建的规则处于已启动／运行中状态
• 仅当用户明确要求停止规则，或特定的安全验证／评估工作流需要禁用规则以避免副作用时，才将 shouldRun 设为 false
• 对于包含动态内容的 TeamsMessage 操作，保留工作读取结果中的特定字段引用结构：headline / optionalMessage 中的内联混合内容片段使用 AttributeReference，其 type 为 "complex"；结构化的 additionalInformation 条目使用 NameReferencePair + AttributeReference / EventFieldReference，其 type 为 "complexReference"，且 name 为 "reference"

规则实体示例：

{
    "uniqueIdentifier": "<rule-guid>",
    "payload": {
        "name": "My Rule Name",
        "description": "Created by: skills-for-fabric",  # Required for user clarity
        "parentObject": {"targetUniqueIdentifier": "<object-guid>"},
        "parentContainer": {"targetUniqueIdentifier": "<container-guid>"},
        "definition": {
            "type": "Rule",
            "instance": stringify_instance(rule_template),
            "settings": {"shouldRun": True, "shouldApplyRuleOnUpdate": False}
        }
    },
    "type": "timeSeriesView-v1"
}

步骤 6 — Fabric Item Action（仅适用于 FabricItemInvocation）：

• 类型：fabricItemAction-v1 — 当规则调用 Fabric 项目（例如 Pipeline、Notebook、Spark 作业定义、Dataflow 或 UDF / Function Set）时，使用此独立操作实体
• 在规则的 FabricItemBinding 中，将 fabricJobConnectionDocumentId 设为独立的 fabricItemAction-v1.uniqueIdentifier
• 各目标的架构以及 UDF 特有的注意事项（itemType 与读取结果中的 FunctionSet、subitemId、规范 parameterType 映射、动态参数结构），请参见 action-types.md

引用完整性预检

每次调用 updateDefinition 前，都要验证即将发送的确切实体数组：

1. 构建 ReflexEntities.json 中所有顶层 uniqueIdentifier 的集合。
2. 确认每个 parentContainer.targetUniqueIdentifier、parentObject.targetUniqueIdentifier、SourceReference.entityId、EventReference.entityId、AttributeReference.entityId 和 fabricJobConnectionDocumentId 都能解析到该数组中的实体（或解析到最新解码回读中未更改、且已包含在重新编码数组中的实体）。
3. 确认每个引用都指向预期的实体类型：容器引用指向 container-v1；当模板要求视图时，源、事件、属性、规则和对象引用指向 timeSeriesView-v1；源引用指向源实体；Fabric 项操作绑定指向 fabricItemAction-v1。
4. 如果有任何引用缺失，请根据最新的 getDefinition 输出重建图，并且不要调用 updateDefinition。

FailedToResolveEntity 且提示 DocumentType timeSeriesView not found，表示某条规则、属性、拆分事件或事件引用指向的 timeSeriesView-v1 GUID 不在已提交的定义中。应将其视为需要在重试前修复的实体连线错误，而非暂时性后端故障。

实体连线摘要

Container ← everything references this via parentContainer
    │
    ├── Source ← parentContainer → Container
    │
    ├── SourceEvent ← parentContainer → Container
    │        │         instance references Source by entityId
    │        │
    │        ├── EventTrigger Rule ← parentContainer → Container
    │        │       minimal event-only path; reads raw event fields directly
    │        │
    │        └── Object ← parentContainer → Container
    │              │
    │              ├── (SplitEvent) ← OPTIONAL, parentObject → Object, parentContainer → Container
    │              │       instance references SourceEvent by entityId
    │              │       maps events to objects via FieldIdMapping
    │              │
    │              ├── Identity Attr ← parentObject → Object, parentContainer → Container
    │              │
    │              ├── Value Attr(s) ← parentObject → Object, parentContainer → Container
    │              │       instance references SourceEvent (or SplitEvent if used) by entityId
    │              │
    │              └── AttributeTrigger Rule ← parentObject → Object, parentContainer → Container
    │                      instance references Value Attr by entityId in ScalarSelectStep
    │
    └── (FabricItemAction) ← parentContainer → Container (for any FabricItemInvocation action: Pipeline, Notebook, Spark job, Dataflow, or UDF / Function Set)

关键：definition.instance 是 JSON 字符串

timeSeriesView-v1 实体中 definition 内的 instance 是经过 JSON 编码的字符串，而不是嵌套对象。规则模板必须始终包装在完整的实体信封中。

❌ 错误——原始模板对象（会失败）：

{
  "templateId": "AttributeTrigger",
  "templateVersion": "1.2.4",
  "steps": [...]
}

✅ 正确——包含字符串化 instance 的实体信封：

{
  "uniqueIdentifier": "<new-guid>",
  "payload": {
    "name": "My Rule Name",
    "parentObject": { "targetUniqueIdentifier": "<object-guid>" },
      "parentContainer": { "targetUniqueIdentifier": "<container-guid>" },
      "definition": {
        "type": "Rule",
        "instance": "{\"templateId\":\"AttributeTrigger\",\"templateVersion\":\"1.2.4\",\"steps\":[...]}",
        "settings": { "shouldRun": true, "shouldApplyRuleOnUpdate": false }
      }
    },
    "type": "timeSeriesView-v1"
}

使用 json.dumps() 进行字符串化。不要使用 PowerShell 的 ConvertTo-Json。

两种规则模板类型

模板	使用场景	步骤
AttributeTrigger	监视属性值（数字、文本、布尔值）	ScalarSelectStep → ScalarDetectStep → (DimensionalFilterStep)* → ActStep
EventTrigger	在事件发生时触发（状态、变化、心跳）	FieldsDefaultsStep → (EventDetectStep)+ → (DimensionalFilterStep)* → ActStep

EventTrigger 不包含 ScalarSelectStep/ScalarDetectStep。直接对事件执行操作时使用。通过 EventDetectStep 支持状态、变化和心跳检测。

---

源验证关卡

编写任何引用信号（测量值、字段或事件属性）的规则之前，都要确认源真实存在。只有通过以下全部三项检查，请求的源才算真实存在：

1. 仅在请求的工作区中解析源——不要搜索或替换为其他工作区中的源。
2. 验证该源上存在请求的信号列/字段（KQL 表/列、Eventstream 字段、Real-Time Hub 事件属性或 DTB / Ontology 属性）。
3. 观察至少一条包含该信号的代表性行/事件/样本——运行 KQL / DTB 查询或检查流，并确认确实返回了数据。

应将只有架构信息、零行、未发出数据或过时的证据视为缺少源数据，而非真实存在的源。缺少源时，停止并询问哪个源和字段提供该信号（以及任何缺失的阈值、接收方或操作详情）。不要创建 Reflex，也不要调用 updateDefinition 来强行适配现有 Activator / Eventstream 请求，并明确说明未创建或更新任何 Activator / Reflex / Eventstream。唯一例外是用户明确要求针对未来或尚未发出数据的源进行编写。

---

必须 / 优先 / 避免

必须执行

• 创作前确认真实数据源——遵循 Source Validation Gate：在请求的工作区中解析数据源，验证请求的信号列/字段，并在创作前查看至少一条有代表性的行/事件/样本。仅有架构、零行、未发出数据或过时的证据都属于缺少源数据——停止并询问哪些数据源和字段可以提供这些数据（以及任何缺失的阈值、接收方或操作详情），并说明尚未创建或更新任何 Activator/Reflex/Eventstream，而不是创作规则。如果用户明确要求针对未来/尚未发出数据的数据源进行创作，请说明这一假设，并在不声称已观察到数据源的前提下继续。
• 使用 az rest 时始终指定 --resource https://api.fabric.microsoft.com——否则令牌受众会有误
• 调用 getDefinition 时始终发送 --body '{}'——这是一个 POST 请求，省略请求体可能导致 411 错误
• 调用 updateDefinition 时，始终对 ReflexEntities.json 负载进行 Base64 编码
• 对 timeSeriesView-v1 实体中的 definition.instance 字段，始终使用 JSON.stringify——该字段必须是字符串，而不能是嵌套对象。始终将规则模板包装在完整的实体信封中（参见上文的 ❌/✅ 示例）——绝不要输出没有实体包装器的原始模板对象
• 始终使用正确的模板类型——值条件使用 AttributeTrigger（包含 ScalarSelectStep 和 ScalarDetectStep），基于事件的触发使用 EventTrigger（包含 FieldsDefaultsStep 和 EventDetectStep，不包含 ScalarDetectStep）
• 始终使用规范的 EventTrigger 选择器——FieldsDefaultsStep.rows 包含 EventSelector（kind: Event），其中嵌套了一个复杂的 EventReference；绝不要直接将 EventReference 放入 rows
• 添加实体时，uniqueIdentifier 始终使用新的 GUID——重复的 GUID 会导致数据损坏
• 更改 uniqueIdentifier 时，始终更新所有交叉引用——其他实体通过 targetUniqueIdentifier 引用该标识符
• 在执行 updateDefinition 之前，始终运行引用完整性预检——负载中的每个 targetUniqueIdentifier、entityId 和 fabricJobConnectionDocumentId 都必须能解析到所提交的 ReflexEntities.json 中包含的实体
• 处理 LRO 响应——create、getDefinition 和 updateDefinition 可能返回 202；请轮询 Location 标头

建议

• 优先采用读取-修改-写入，而不是整体替换——获取当前定义，修改实体数组，然后更新
• 除非要永久删除，否则优先软删除，而不是硬删除
• 通过工作区列表 + JMESPath 动态发现 ID，而不是硬编码 GUID
• 对大多数警报，优先使用基于状态转换的条件，而不是稳态条件——即使用户使用了“is greater than”“is below”或“is outside the range”等随意的状态描述，也应优先使用 NumberBecomes、NumberEntersOrLeavesRange、LogicalBecomes 等检测器，或显式的变化条件。将普通的警报表述理解为“当它进入该状态时通知我”，以避免条件持续为真时重复通知
• 只有当用户明确要求在数值保持触发状态时重复触发（例如“每当它大于 30 时通知我”“每次评估时，只要它高于 30 就触发”），或下游的事件次数/窗口模式确实依赖此语义时，才使用 IsGreaterThan、IsLessThan 或 IsOutsideRange 等稳态条件

避免

• 硬编码工作区或项 ID——始终动态解析
• 忘记 .platform 部分——仅在使用 ?updateMetadata=true 时，将其包含在 updateDefinition 中
• 在列表终结点上使用未筛选的 SELECT *——大型工作区请使用分页
• 修改带有加密敏感度标签的项定义——getDefinition 会被阻止
• 在 KQL 查询中预筛选条件——从 KQL 返回所有数据，并让 Activator 规则步骤处理阈值、文本条件和维度筛选。KQL 是数据源，而不是规则引擎
• 在 PowerShell az rest --body 中内联 JSON——PowerShell 会破坏引号和特殊字符。始终使用 [System.IO.File]::WriteAllText($path, $json, [System.Text.UTF8Encoding]::new($false)) 将 JSON 写入临时文件，并传入 --body @$path
• 删除后重复使用显示名称——软删除的项会在几分钟内保留其名称。请使用唯一名称或先彻底删除
• 强行将请求套用到无关的现有项上——如果没有任何来源通过来源验证门槛（缺失、仅有架构、零行、不产生事件或已过时），请勿创建 Reflex，也不要对无关的现有 Activator / Eventstream 调用 updateDefinition 来满足请求；请先询问缺少的来源
• 只读列出或检查——对于“显示所有 Activator”“列出 Activator”“显示规则”“检查此警报”或“解码定义”之类的提示词，请使用 activator-consumption-cli。只有在用户要求创建、更新、删除、配置或更改内容时，才应运行此创作技能。

---

示例

按照组装流程构建定义。完整的实体架构请参阅参考文档：source-types.md、rule-conditions.md、action-types.md。

---

Agent 集成说明

• 此技能使用 Fabric Items API（/reflexes）执行 CRUD，并使用 Definition API 管理规则
• 无需额外的数据平面协议——所有操作都使用带有 Fabric API 受众的 az rest
• 若要读取 Activator 项和规则而不进行修改，请改用 activator-consumption-cli 技能