Release v1.1.0 (#39)

Run the skills across every major AI coding assistant. Codex, Copilot CLI, Cursor, and Antigravity CLI join Claude Code, each with documented install steps and Agent Plugins manifests (a root plugin.json and a Codex .codex-plugin/plugin.json) plus an Agent Plugins marketplace catalog so the non-Claude assistants can discover the plugin. A foundry-redirect skill declines Falcon Foundry app requests and points to the sibling crowdstrike-falcon-foundry plugin.

validate.py now catches four failures that used to pass local validation and only failed at release: a pinned action referenced by its long output path, MITRE ATT&CK trigger fields on the NG-SIEM trigger, a default:true gateway with no expression or else, and a missing or fake-domain email recipient. Also documents the version_constraint output-path shape, corrects the authoring docs on event/system variables and action names, and fixes three shipped examples so they release cleanly.

Adds US-3 cloud region support, a throttling reference in the execution skill, and a Deduplicate and Rate Limit action reference with a worked example. Hardens the multi-assistant test harness: a shared unwrap_log helper so JSON-wrapped and plain-text reports parse the same way, a tenant fallback when an assistant authors outside its working directory, and per-run cleanup of the e2e work dir.

Author: mraible

.agents/plugins/marketplace.json

@@ -0,0 +1,21 @@
+{
+  "name": "fusion-marketplace",
+  "interface": {
+    "displayName": "CrowdStrike Falcon Fusion"
+  },
+  "plugins": [
+    {
+      "name": "crowdstrike-falcon-fusion",
+      "source": {
+        "source": "url",
+        "url": "https://github.com/CrowdStrike/fusion-skills.git",
+        "ref": "v1.1.0"
+      },
+      "policy": {
+        "installation": "INSTALLED_BY_DEFAULT",
+        "authentication": "ON_USE"
+      },
+      "category": "Developer Tools"
+    }
+  ]
+}

.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "name": "crowdstrike-falcon-fusion",
       "source": "./",
       "description": "CrowdStrike Falcon Fusion skills for authoring, deploying, and executing Fusion workflows. Includes live action discovery, YAML authoring with schema validation, workflow import and release, execution monitoring, and Falcon Next-Gen SIEM lookup files.",
-      "version": "1.0.1",
+      "version": "1.1.0",
       "author": {
         "name": "CrowdStrike"
       },

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "crowdstrike-falcon-fusion",
   "description": "CrowdStrike Falcon Fusion skills for authoring, deploying, and executing Fusion workflows. Includes live action discovery, YAML authoring with schema validation, workflow import and release, execution monitoring, and Falcon Next-Gen SIEM lookup files.",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "author": {
     "name": "CrowdStrike"
   },

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "crowdstrike-falcon-fusion",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "description": "CrowdStrike Falcon Fusion skills for authoring, deploying, and executing Fusion workflows. Includes live action discovery, YAML authoring with schema validation, workflow import and release, execution monitoring, and Falcon Next-Gen SIEM lookup files.",
   "author": {
     "name": "CrowdStrike",

.github/workflows/main.yml

@@ -220,6 +220,16 @@ jobs:
             fail=1
           fi
 
+          # Agent Plugins marketplace catalog pins the plugin to the release tag;
+          # its source.ref must match v<version> so it can't drift on a manual edit
+          if [ -f .agents/plugins/marketplace.json ]; then
+            agents_ref=$(jq -r '.plugins[0].source.ref' .agents/plugins/marketplace.json)
+            if [ "${agents_ref#v}" != "$plugin_version" ]; then
+              echo "FAIL: .agents/plugins/marketplace.json ref '$agents_ref' != v$plugin_version"
+              fail=1
+            fi
+          fi
+
           # All SKILL.md versions must match plugin.json
           for skill in skills/*/SKILL.md; do
             skill_version=$(sed -n 's/^version: *//p' "$skill")

CHANGELOG.md

@@ -4,27 +4,28 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/), and this project adheres to [Semantic Versioning](https://semver.org/).
 
-## [1.1.0] - TBD
+## [1.1.0] - 2026-08-19
 
 ### Added
 
-- **`foundry-redirect` skill** — declines Falcon Foundry app requests (a UI page, serverless function, collection, `manifest.yml`, or custom third-party API integration) and points to the sibling `crowdstrike-falcon-foundry` plugin. The `workflows` orchestrator already declines these, but its description matches Fusion-workflow language, so a "build a Foundry app" prompt never loads it; a Claude Code hook covered that gap, but hooks do not fire in Codex, Copilot CLI, Cursor, or the Agent SDK. This skill's description matches Foundry-app language directly, so the redirect is reachable on every assistant. It yields to the Foundry plugin's own skill when that plugin is installed.
-- **Skill scripts run on assistants other than Claude Code.** The scripts now resolve their own location with `os.path.realpath` instead of `os.path.abspath`, so an assistant that launches a script through a `~/.agents/skills/<skill>` symlink (Codex, Copilot CLI, Cursor, Antigravity) correctly finds the shared `common/scripts` modules and the managed-venv wrapper — the cold-start dependency bootstrap fires as it does for Claude Code, instead of failing with a missing-`falconpy` error. Each `SKILL.md` now shows a portable invocation — `cd` into the skill's folder, then run `../../scripts/python.sh <script>` on one line — that works whether or not `${CLAUDE_PLUGIN_ROOT}` is set, since that variable is defined only by Claude Code and no equivalent exists on the other assistants.
+- **`foundry-redirect` skill** — declines Falcon Foundry app requests (a UI page, serverless function, collection, `manifest.yml`, or custom third-party API integration) and points to the sibling `crowdstrike-falcon-foundry` plugin. Its description matches Foundry-app language, so the redirect is reachable on every assistant, and it yields to the Foundry plugin's own skill when that plugin is installed.
+- **Skills run on assistants other than Claude Code** (Codex, Copilot CLI, Cursor, Antigravity). Scripts resolve their own location, so the managed-venv bootstrap works when a skill is launched through a `~/.agents/skills/` symlink instead of failing with a missing-`falconpy` error. Each `SKILL.md` shows a portable invocation that works whether or not the Claude-only `${CLAUDE_PLUGIN_ROOT}` is set.
 - **Agent Plugins manifests for non-Claude assistants** — A root `plugin.json` conforming to the [Agent Plugins](https://agent-plugins.org) 1.0.0 spec and a Codex-flavored `.codex-plugin/plugin.json`, so Codex, Copilot CLI, Cursor, and Antigravity CLI can discover the plugin alongside the existing Claude manifest. CI validates both and keeps their versions in lockstep with `.claude-plugin/plugin.json`.
-- **Install instructions for five AI coding assistants** — Claude Code, Codex, Copilot CLI, Cursor, and Antigravity CLI each get documented install commands (`--plugin-dir` for Claude Code, Copilot CLI, and Cursor; a `~/.agents/skills/` symlink for Codex and Antigravity CLI). Claude Code is verified end to end; the others load the skills and are documented, with broader end-to-end verification tracked separately.
-- US-3 cloud region to credential setup: a `[us-3]` profile example (`https://api.us-3.crowdstrike.com`) in the setup skill's multi-cloud block and in the README region notes, alongside a `[us-gov-1]` example that was also missing. The auth module already accepts any `base_url`, so this documents the host rather than changing behavior.
+- **Install instructions for five AI coding assistants** — Claude Code, Codex, Copilot CLI, Cursor, and Antigravity CLI each get documented install commands (`--plugin-dir` for Claude Code, Copilot CLI, and Cursor; a `~/.agents/skills/` symlink for Codex and Antigravity CLI). In a live-tenant run, Claude Code, Codex, Copilot CLI, and Cursor each authored a valid workflow from the canonical prompt and imported it to the tenant (left disabled until released). Antigravity CLI loads the skills, but its weekly quota was exhausted before a full author-and-import run, so its end-to-end path is not yet verified.
+- US-3 cloud region in credential setup: a `[us-3]` profile example (`https://api.us-3.crowdstrike.com`) in the setup skill's multi-cloud block and the README region notes, alongside a `[us-gov-1]` example that was also missing.
 - Throttling reference in the execution skill: explains that a workflow stuck "in progress" may be throttled (Fusion paces an action past a volume limit, auto-retrying up to 6 hours) rather than failed, how to recognize it on the execution detail view, and when sustained throttling signals a workflow-design issue.
-- Deduplicate and Rate Limit action reference plus a worked tutorial example. Covers all six Deduplicate activities and all four Rate Limit activities: the `definition`/`cid` scope values (which the console labels "Workflow" and "CID"), the atomic claim, metadata handoff, and the save-time validation the builder runs. The example deduplicates third-party NG-SIEM detections into a single case. Action IDs were confirmed against a live tenant; the example passes validation at all tiers.
+- Deduplicate and Rate Limit action reference plus a worked tutorial example, covering all six Deduplicate and four Rate Limit activities — the `definition`/`cid` scope values (labeled "Workflow" and "CID" in the console), the atomic claim, metadata handoff, and the builder's save-time validation. The example deduplicates third-party NG-SIEM detections into a single case.
 
 ### Fixed
 
-- Three authoring-doc corrections from a Fusion engineer's tech review. `version_constraint` is no longer framed as class-specific — nearly every action carries one whether or not it declares a `class`, so include it on every action node. The event-trigger and system-level variables (`Trigger.CID`, `Workflow.Execution.ID`, `Workflow.Definition.Name`, etc.) are now shown in the `${data['...']}` form and are documented as living in the `data` namespace like any other field rather than as an exception. And the action `name:` field is described as a relabelable display label — renaming it does not break references, which resolve by node key and action `id`.
-- **`version_constraint` decides the shape of an action's output paths, and that was undocumented.** Unpinned, a reference carries the action's namespace (`${data['DeviceQuery.Device.query.devices']}`); pinned at `~1` the same field is `${data['DeviceQuery.devices']}`. The two forms are mutually exclusive, so adding a `version_constraint` to an existing workflow without shortening its `${data['...']}` references produces YAML that imports cleanly and then fails at release with `property "..." contains unknown variable`. The schema and best-practices references now document this as a single two-part edit. Verified against a live tenant for Device Query, Get device details, and Event Query. The `workflows` copies of both references were also brought in line with the `authoring` copies, which had drifted: they still said to "always use `~1`" and claimed all CrowdStrike actions sit at major version 1, which is wrong for the 0.x actions such as Charlotte AI.
-- Clarified that only class-based actions strictly *require* a `version_constraint` at import. A non-class action such as Device Query imports and releases without one; it just keeps the older, longer output paths.
-- **`validate.py` now catches the pinned/long-path mismatch before release.** The structural tier flags a `${data['...']}` reference that keeps an action's output namespace (`device.query`, `device.get_details`, `logscale.query_event`) while that action is pinned with a `version_constraint` — the exact shape that imports cleanly and passes server-side `validate_only`, then fails at release as an unknown variable. The error names the collapsed replacement (`${data['<node>.<field>']}`). An unpinned action legitimately keeps the long path, so the check fires only when the referenced node is pinned. This turns the documentation above into an enforced check; a release-gated eval had produced a workflow that imported clean and failed release on precisely this.
-- **MITRE ATT&CK trigger fields that release rejects on the NG-SIEM trigger are now flagged.** `Trigger.Detection.MitreAttack.Tactic` and `.Technique` are advertised by trigger discovery — including `trigger_search.py --fields` — on the `Investigatable/NGSIEM` trigger, but the release validator rejects them as unknown variables; they are not on the NG-SIEM trigger payload at release time. The structural validator now flags a workflow that references them on that trigger, and `trigger_search.py --fields` marks them "NOT release-valid" so the tool stops steering authors toward a field that fails at release. Source MITRE tactics/techniques from the hydrated detection instead. Surfaced by a release-gated eval; confirmed live.
-- **A `default: true` condition node is now flagged, because it fails release.** A condition that routes only via a node-level `default: true` (no `cel_expression`/`expression`, no `else:`) imports cleanly and passes server-side `validate_only`, then fails at release with `exclusive gateway ... has no condition set and is not marked as default`. Verified live against a tenant — the release API does not honor a node-level `default: true`, including the console-exported `default_gateway_decision_*` shape. A gateway's default flow is the `else:` branch of the expression-bearing condition, so the structural validator now requires every condition to carry an expression or an `else:` (a bare `default: true` no longer counts). Two shipped tutorial examples, `intro-receive-email-trigger` and `intro-lookup-file-actions`, used the `default: true` shape and would have failed release; both were converted to the `else:` form and re-verified to release cleanly. A third, `network-contain-endpoint-on-detection`, used it across three gateways (including a five-way product gateway that became an `else_if` chain); it was converted and now **releases cleanly (verified live)**, together with the recipient fix below.
-- **A missing or fake `to` recipient on the Request human input "send email" action is now flagged.** Like the plain Send email action, it requires a `to` recipient at release (`A value is required for the property "to"`), but server-side `validate_only` does not enforce it — so a workflow passed every local check and failed at release (surfaced live on `network-contain-endpoint-on-detection`, whose four approval-email actions had no `to`). The recipient check now covers both email actions: it flags a missing/empty `to`, the wrong `recipients:` key, and a hardcoded fake-domain address (e.g. `@example.com`) that dead-ends at runtime because no CID approves it. The right recipient is a variable the user supplies — a trigger parameter, a `WorkflowCustomVariable`, or a value from a prior step — which is what the fixed `network-contain` example now uses (`${WorkflowCustomVariable.approver_email}`).
+- Authoring-doc corrections from a Fusion engineer's review: event and system variables (`Trigger.CID`, `Workflow.Execution.ID`, `Workflow.Definition.Name`, etc.) are documented in the `${data['...']}` form like any other field, and the action `name:` is described as a relabelable display label — renaming it doesn't break references, which resolve by node key and action `id`.
+- **Documented that `version_constraint` decides an action's output-path shape.** Unpinned, a reference carries the action's namespace (`${data['DeviceQuery.Device.query.devices']}`); pinned at `~1` the same field collapses (`${data['DeviceQuery.devices']}`). The two forms are mutually exclusive, so pinning an action without shortening its `${data['...']}` references imports cleanly and then fails at release with `property "..." contains unknown variable`. Only class-based actions require a `version_constraint` at import; others release fine without one and keep the longer paths.
+- **`validate.py` now catches four release-only failures** — workflows that import cleanly and pass server-side validation, then fail when you release them:
+  - a pinned action referenced by its long, unpinned output path (the mismatch documented above);
+  - MITRE ATT&CK trigger fields (`Trigger.Detection.MitreAttack.Tactic`/`.Technique`) on the NG-SIEM trigger — advertised by trigger discovery but rejected at release; source them from the hydrated detection instead (`trigger_search.py --fields` now marks them "NOT release-valid");
+  - a `default: true` gateway node with no expression or `else:` (`exclusive gateway ... has no condition set`); put the fallthrough in an `else:` on the expression-bearing condition;
+  - a missing/empty or fake-domain `to` recipient on the Send email and Request human input actions; use a variable the user supplies (trigger parameter, `WorkflowCustomVariable`, or a prior step's output), not a hardcoded `@example.com`-style address that no CID delivers to.
+- Fixed three shipped examples so they release cleanly: `intro-receive-email-trigger`, `intro-lookup-file-actions`, and `network-contain-endpoint-on-detection` (converted off `default: true` gateways, with its approval emails taking a configurable `${WorkflowCustomVariable.approver_email}` recipient).
 
 ## [1.0.1] - 2026-08-07