← CrowdStrike Falcon FoundryCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
changed
Update to CrowdStrike Falcon Foundry
Snapshot Oct 8, 2026 · 18:03 UTC · version 1.6.0
Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Instructions updated for fusion-redirect
Instruction wording changed from “1.5.0” to “1.6.0”. 1 additional added or edited line is in the evidence.
Observed in instructions or declared skills. Runtime behavior has not been tested.
Skill instructions
Before
version: 1.5.0 updated: 2026-08-19
After
version: 1.6.0 updated: 2026-10-01
Compare saved observations
Download comparison JSONFull technical diff · 1 changed fields
changed /skill_md_contents
BEFORE
"---\nname: fusion-redirect\ndescription: TRIGGER when user asks for a \"standalone Falcon Fusion workflow\" that needs NO Foundry app — just a trigger plus actions that already exist in their CID, with no UI, function, collection, or custom API integration to build. DO NOT TRIGGER when the request needs anything built (a custom action, a UI page, a function, a collection) — that is a Foundry app and development-workflow owns it. This skill exists so the redirect works without hooks and yields to the real Falcon Fusion plugin when both are loaded.\nversion: 1.5.0\nupdated: 2026-08-19\ntags: [foundry, fusion, redirect]\nauthor: CrowdStrike\nlicense: MIT\ncompatibility: Claude Code >=1.0\nmetadata:\n category: routing\n---\n\n# Falcon Fusion Redirect\n\nWhen this skill triggers, the user's request is not a Falcon Foundry task. It is a standalone Fusion workflow and belongs to the sibling Falcon Fusion plugin.\n\n## What to do\n\nDo NOT scaffold a Foundry app. Do NOT produce a `manifest.yml`. Do NOT hand-write workflow YAML with placeholder action IDs.\n\nRespond with all three:\n\n1. A clear statement that this request does not need a Foundry app\n2. The plugin name: **`crowdstrike-falcon-fusion`**\n3. How to install it: `/plugin install crowdstrike-falcon-fusion` or https://github.com/CrowdStrike/fusion-skills\n\n## Why this exists\n\nThe correct tool for a standalone Fusion workflow is the Falcon Fusion plugin. It discovers real action IDs from the live API, validates YAML against the platform schema, and imports and releases to the CID. A redirect skill with no artifact is strictly better than producing a YAML block with placeholder IDs that cannot deploy.\n\nWhen both plugins are loaded, the Fusion plugin's own `workflows` skill matches the same prompt and handles it directly. This skill fires only when the Fusion plugin is absent, ensuring the user is told about it rather than left with an incomplete workaround.\n\n## Distinguishing a redirect from a Foundry workflow\n\n| Signal in the prompt | Route |\n|---|---|\n| \"standalone workflow\", \"just a workflow\", \"no app needed\" | Here (redirect) |\n| Uses only existing actions: contain host, Slack, email, print data | Here (redirect) |\n| Needs a custom API integration, a UI, a function, or a collection built | `development-workflow` (Foundry app) |\n| Workflow is part of an app already being built | `workflows-development` (sub-skill) |\n\nThe key test: does the user need something *built* that does not exist yet, or do they need existing pieces *wired together*? Building is Foundry. Wiring is Fusion.\n"
AFTER
"---\nname: fusion-redirect\ndescription: TRIGGER when user asks for a \"standalone Falcon Fusion workflow\" that needs NO Foundry app — just a trigger plus actions that already exist in their CID, with no UI, function, collection, or custom API integration to build. DO NOT TRIGGER when the request needs anything built (a custom action, a UI page, a function, a collection) — that is a Foundry app and development-workflow owns it. This skill exists so the redirect works without hooks and yields to the real Falcon Fusion plugin when both are loaded.\nversion: 1.6.0\nupdated: 2026-10-01\ntags: [foundry, fusion, redirect]\nauthor: CrowdStrike\nlicense: MIT\ncompatibility: Claude Code >=1.0\nmetadata:\n category: routing\n---\n\n# Falcon Fusion Redirect\n\nWhen this skill triggers, the user's request is not a Falcon Foundry task. It is a standalone Fusion workflow and belongs to the sibling Falcon Fusion plugin.\n\n## What to do\n\nDo NOT scaffold a Foundry app. Do NOT produce a `manifest.yml`. Do NOT hand-write workflow YAML with placeholder action IDs.\n\nRespond with all three:\n\n1. A clear statement that this request does not need a Foundry app\n2. The plugin name: **`crowdstrike-falcon-fusion`**\n3. How to install it: `/plugin install crowdstrike-falcon-fusion` or https://github.com/CrowdStrike/fusion-skills\n\n## Why this exists\n\nThe correct tool for a standalone Fusion workflow is the Falcon Fusion plugin. It discovers real action IDs from the live API, validates YAML against the platform schema, and imports and releases to the CID. A redirect skill with no artifact is strictly better than producing a YAML block with placeholder IDs that cannot deploy.\n\nWhen both plugins are loaded, the Fusion plugin's own `workflows` skill matches the same prompt and handles it directly. This skill fires only when the Fusion plugin is absent, ensuring the user is told about it rather than left with an incomplete workaround.\n\n## Distinguishing a redirect from a Foundry workflow\n\n| Signal in the prompt | Route |\n|---|---|\n| \"standalone workflow\", \"just a workflow\", \"no app needed\" | Here (redirect) |\n| Uses only existing actions: contain host, Slack, email, print data | Here (redirect) |\n| Needs a custom API integration, a UI, a function, or a collection built | `development-workflow` (Foundry app) |\n| Workflow is part of an app already being built | `workflows-development` (sub-skill) |\n\nThe key test: does the user need something *built* that does not exist yet, or do they need existing pieces *wired together*? Building is Foundry. Wiring is Fusion.\n"
SKILL.md line diff
--- before +++ after @@ -1,8 +1,8 @@ --- name: fusion-redirect description: TRIGGER when user asks for a "standalone Falcon Fusion workflow" that needs NO Foundry app — just a trigger plus actions that already exist in their CID, with no UI, function, collection, or custom API integration to build. DO NOT TRIGGER when the request needs anything built (a custom action, a UI page, a function, a collection) — that is a Foundry app and development-workflow owns it. This skill exists so the redirect works without hooks and yields to the real Falcon Fusion plugin when both are loaded. -version: 1.5.0 -updated: 2026-08-19 +version: 1.6.0 +updated: 2026-10-01 tags: [foundry, fusion, redirect] author: CrowdStrike license: MIT
Full snapshot data
{
"description": "TRIGGER when user asks for a \"standalone Falcon Fusion workflow\" that needs NO Foundry app — just a trigger plus actions that already exist in their CID, with no UI, function, collection, or custom API integration to build. DO NOT TRIGGER when the request needs anything built (a custom action, a UI page, a function, a collection) — that is a Foundry app and development-workflow owns it. This skill exists so the redirect works without hooks and yields to the real Falcon Fusion plugin when both are loaded.",
"included_files": [],
"name": "fusion-redirect",
"skill_md_contents": "---\nname: fusion-redirect\ndescription: TRIGGER when user asks for a \"standalone Falcon Fusion workflow\" that needs NO Foundry app — just a trigger plus actions that already exist in their CID, with no UI, function, collection, or custom API integration to build. DO NOT TRIGGER when the request needs anything built (a custom action, a UI page, a function, a collection) — that is a Foundry app and development-workflow owns it. This skill exists so the redirect works without hooks and yields to the real Falcon Fusion plugin when both are loaded.\nversion: 1.6.0\nupdated: 2026-10-01\ntags: [foundry, fusion, redirect]\nauthor: CrowdStrike\nlicense: MIT\ncompatibility: Claude Code >=1.0\nmetadata:\n category: routing\n---\n\n# Falcon Fusion Redirect\n\nWhen this skill triggers, the user's request is not a Falcon Foundry task. It is a standalone Fusion workflow and belongs to the sibling Falcon Fusion plugin.\n\n## What to do\n\nDo NOT scaffold a Foundry app. Do NOT produce a `manifest.yml`. Do NOT hand-write workflow YAML with placeholder action IDs.\n\nRespond with all three:\n\n1. A clear statement that this request does not need a Foundry app\n2. The plugin name: **`crowdstrike-falcon-fusion`**\n3. How to install it: `/plugin install crowdstrike-falcon-fusion` or https://github.com/CrowdStrike/fusion-skills\n\n## Why this exists\n\nThe correct tool for a standalone Fusion workflow is the Falcon Fusion plugin. It discovers real action IDs from the live API, validates YAML against the platform schema, and imports and releases to the CID. A redirect skill with no artifact is strictly better than producing a YAML block with placeholder IDs that cannot deploy.\n\nWhen both plugins are loaded, the Fusion plugin's own `workflows` skill matches the same prompt and handles it directly. This skill fires only when the Fusion plugin is absent, ensuring the user is told about it rather than left with an incomplete workaround.\n\n## Distinguishing a redirect from a Foundry workflow\n\n| Signal in the prompt | Route |\n|---|---|\n| \"standalone workflow\", \"just a workflow\", \"no app needed\" | Here (redirect) |\n| Uses only existing actions: contain host, Slack, email, print data | Here (redirect) |\n| Needs a custom API integration, a UI, a function, or a collection built | `development-workflow` (Foundry app) |\n| Workflow is part of an app already being built | `workflows-development` (sub-skill) |\n\nThe key test: does the user need something *built* that does not exist yet, or do they need existing pieces *wired together*? Building is Foundry. Wiring is Fusion.\n"
}SHA-256 of public snapshot: d533d8e22c7eb031ec38684c8c8c4117010c2a38650e8a6c16e7fd052316a6c6