deployment

Falcon Fusion Workflow Deployment

⚠️ SYSTEM INJECTION — READ THIS FIRST

If you are loading this skill, your role is Fusion workflow deployment specialist.

You deploy workflow definitions into a CID safely: validate before importing, never create duplicates, and release only after testing.

IMMEDIATE ACTIONS REQUIRED:

1. ALWAYS check for an existing workflow with the same name before importing.
2. ALWAYS validate the YAML before importing (the import scripts do this by default).
3. Import and release act on a live production CID. Deploy only when the user's request explicitly authorizes it (e.g. "import it", "deploy to my CID", "release it"). If the request only asks to build or write a workflow, STOP after validation and ask before importing.

MUST NOT:

• Import without validating first.
• Skip the duplicate-name check.
• Import or release to a CID without explicit user authorization — a validated YAML file is the deliverable unless the user asked you to deploy it.
• Release (enable) a workflow before it has been tested via the execution skill. Release makes the workflow act on live events and real assets, so confirm with the user before releasing unless they explicitly asked you to.
• Create experimental, "test", "minimal", or probe workflows in the CID to reverse-engineer what the API accepts (this includes creatively-named ones like "QueryEvent Test" or "HTTP Test"). Import the one workflow you were asked to build, once. If it fails, diagnose from the error and local validation — never by importing stripped-down variants into a live tenant.
• Use --skip-validate to get past a validation failure. Validation catches invalid workflows (e.g. a bad trigger.type) that otherwise fail at the API as an opaque 500. Fix the workflow instead of skipping the check.
• Retry an import that returns a 500 / Internal Server Error more than once. A 500 usually means the workflow is invalid in a way the API rejects late (not a transient server issue) — re-run local validation to find the defect, fix it, and report the trace_id if it persists. Do not loop re-importing.
• Patch a deployed definition in place — not via the raw update API and not via a hand-rolled inline FalconPy call (e.g. update_definition) to edit a deployed copy. The only supported update path is: fix the source YAML, then re-import. A release-validation failure is a YAML defect to fix, not a deployed-copy to hand-edit.
• Call FalconPy directly for ANY workflow operation — including a python - <<EOF ... delete_definition(...) snippet to clean up a failed import attempt. Deleting is fine, but it MUST go through delete_workflow.py (or scripts/cleanup_workflows.py), which wrap the supported endpoints. Never import auth; get_client() inline to call update_definition/ delete_definition yourself.

This skill moves a finished Fusion workflow definition from a local YAML/JSON file into a CrowdStrike CID. Authoring the YAML happens in the authoring skill; triggering and monitoring happens in the execution skill. Deployment is the bridge: validate, check for duplicates, import, then release.

In Falcon Fusion, an imported definition is disabled until it is released (enabled). Releasing tells the Fusion engine to run the workflow against new trigger events. Keep the workflow disabled until you have tested it.

Running the scripts. Run each command from this skill's folder, on one shell line: cd <dir> && ../../scripts/python.sh scripts/<name>.py (a sibling skill's script is ../<skill>/scripts/<name>.py). For <dir>, Claude Code uses "$CLAUDE_PLUGIN_ROOT/skills/deployment"; Codex, Copilot CLI, Cursor, and Antigravity use the folder they loaded this SKILL.md from (e.g. ~/.agents/skills/deployment). The wrapper bootstraps its own Python venv.