fusion-redirect
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.
Install
With your agent
Install OMGSkills skill "crowdstrike/foundry-skills:skills/fusion-redirect" into this agent's normal skills directory: call the OMGSkills MCP get_install_plan tool for your agent and run the script it returns (it installs only the pinned commit and verifies SKILL.md), and stop if MCP or the pin is unavailable. Do not overwrite or change existing skills without asking me.
Manual command
git clone https://github.com/CrowdStrike/foundry-skills /tmp/foundry-skills && ln -s /tmp/foundry-skills/skills/fusion-redirect ~/.claude/skills/fusion-redirectFrom README
Falcon Fusion Redirect When 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. What to do Do NOT scaffold a Foundry app. Do NOT produce a manifest.yml. Do NOT hand-write workflow YAML with placeholder action IDs. Respond with all three: A clear statement that this request does not need a Foundry app The plugin name: crowdstrike-falcon-fusion How to it: /plugin crowdstrike-falcon-fusion or https://github.com/CrowdStrike/fusion-skills Why this exists The 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.
