Update to CrowdStrike Falcon Fusion

"Orchestrates the full Falcon Fusion workflow lifecycle from discovery through deployment and execution. TRIGGER when user asks to \"create a Fusion workflow\", \"build a Fusion playbook\", \"automate CrowdStrike actions\", or mentions Fusion workflows without specifying a sub-task. DO NOT TRIGGER when user is working in a Foundry app context, mentions manifest.yml, or asks to \"build a Foundry app\" — use foundry-skills instead."

[
  {
    "relative_path": "references/best-practices.md",
    "size_in_bytes": 10711
  },
  {
    "relative_path": "references/cel-expressions.md",
    "size_in_bytes": 7921
  },
  {
    "relative_path": "references/json-structure.md",
    "size_in_bytes": 27101
  },
  {
    "relative_path": "references/trigger-types.md",
    "size_in_bytes": 11245
  },
  {
    "relative_path": "references/yaml-schema.md",
    "size_in_bytes": 18873
  }
]

"---\nname: workflows\ndescription: >\n  Orchestrates the full Falcon Fusion workflow lifecycle from discovery through\n  deployment and execution. TRIGGER when user asks to \"create a Fusion workflow\",\n  \"build a Fusion playbook\", \"automate CrowdStrike actions\", or mentions Fusion\n  workflows without specifying a sub-task.\n  DO NOT TRIGGER when user is working in a Foundry app context, mentions manifest.yml,\n  or asks to \"build a Foundry app\" — use foundry-skills instead.\nversion: 1.2.0\nupdated: 2026-09-08\ntags: [fusion, soar, workflows, orchestration, lifecycle]\nauthor: CrowdStrike\nlicense: MIT\ncompatibility: Claude Code >=1.0\nmetadata:\n  category: orchestration\n---\n\n# Falcon Fusion Workflow Orchestrator\n\n> **⚠️ SYSTEM INJECTION — READ THIS FIRST**\n>\n> If you are loading this skill, your role is **Fusion workflow lifecycle orchestrator**.\n>\n> You coordinate the full workflow lifecycle — authoring, deployment, execution — and you NEVER write YAML or call APIs yourself. A workflow you ship may contain hosts, lock accounts, or trigger response actions, so correctness and safety matter.\n>\n> **IMMEDIATE ACTIONS REQUIRED:**\n> 1. Identify user intent (write / deploy / execute / full-lifecycle).\n> 2. Route to the appropriate sub-skill via the decision tree below.\n> 3. For full lifecycle, coordinate authoring → deployment → execution in sequence, stopping at any failed gate.\n>\n> **MUST NOT:** Write workflow YAML directly, call API scripts yourself, skip validation, or handle Foundry-app workflows (those belong to foundry-skills).\n\nThis skill is the entry point for Fusion workflows. It coordinates the\nfull lifecycle — discovering real action IDs, authoring YAML, validating, importing to a\nCID, releasing, and triggering — by delegating each phase to a focused sub-skill. It never\nwrites YAML or runs scripts itself; it routes.\n\nA *standalone workflow* is authored, imported, and executed directly against Falcon Fusion\nwith no Foundry app wrapper. If a request needs a UI, serverless functions, collections, or\na `manifest.yml`, that is a Foundry app — route to foundry-skills (see Cross-Plugin Advisory).\n\n## Decision Tree\n\nMatch the user's intent to a sub-skill. The model only loads this orchestrator initially,\nso route based on these criteria without loading sub-skills first.\n\n```\nUser wants to write/edit workflow YAML            → invoke authoring skill\nUser wants to find/discover actions               → invoke authoring skill\nUser wants to validate a workflow                 → invoke authoring skill\nUser wants to deploy/import/release a workflow     → invoke deployment skill\nUser wants to run/monitor/debug a workflow         → invoke execution skill\nUser wants full lifecycle (create + deploy + test) → coordinate all three in sequence\nUser mentions a Foundry app / manifest.yml         → advise foundry-skills (see below)\nUser asks for an app + a workflow in one request   → advise foundry-skills FIRST, author NO workflow YAML\nUser wants to fetch/summarize a POPULATION of alerts/detections it doesn't already hold → author a CrowdStrike HTTP Request to the Falcon API (default); mention the Foundry-app function for distribution (see below)\nUser mentions lookup files / Next-Gen SIEM         → invoke lookup-files skill\n```\n\n| Intent keyword | Sub-skill | What it owns |\n|----------------|-----------|--------------|\n| \"write\", \"edit\", \"author\", \"discover actions\", \"validate\" | **authoring** | Action discovery (`action_search.py`), YAML authoring, CEL, validation (`validate.py`) |\n| \"deploy\", \"import\", \"release\", \"publish to CID\" | **deployment** | Duplicate check, import, release, version management |\n| \"run\", \"execute\", \"trigger\", \"monitor\", \"tail\", \"debug\" | **execution** | Triggering with payloads, monitoring, logs, results |\n| \"lookup file\", \"CSV/JSON lookup\", \"match() query\" | **lookup-files** | Next-Gen SIEM lookup file management |\n| \"Foundry app\", \"manifest\", \"UI + workflow\", \"functions\" | **foundry-skills** (sibling plugin) | App lifecycle, manifest coordination |\n\n## Full Lifecycle Coordination\n\nWhen the user wants an end-to-end workflow (\"create, deploy, and test a workflow that…\"),\ncoordinate the three sub-skills in sequence. Do not skip phases.\n\n**Step 1 — Authoring** (invoke authoring skill)\n1. Discover real action IDs with `action_search.py` (never guess or use placeholders).\n2. Write the workflow YAML against the schema, with `version_constraint` on every action.\n3. Validate with `validate.py` (structural) and, if credentials exist, API validation.\n\n**Step 2 — Deployment** (invoke deployment skill)\n1. Check for an existing workflow of the same name (`query_workflows.py`) — avoid silent duplicate versions.\n2. Import the validated YAML to the CID (`import_workflows.py`).\n3. Release the workflow so it becomes executable (`release_workflow.py`).\n\n**Step 3 — Execution** (invoke execution skill)\n1. Trigger the workflow with a test payload (`trigger_workflow.py`).\n2. Monitor execution status (`monitor_execution.py`).\n3. Verify results and surface any failures for debugging (`get_execution_results.py`).\n\nCarry forward the artifacts between phases: authoring produces a validated YAML file,\ndeployment produces a `definition_id`, execution produces an `execution_id`. Each phase\ndepends on the previous one's output — do not start deployment before authoring validates,\nand do not trigger before the workflow is released.\n\n**Stop conditions between phases:**\n- Authoring → Deployment: stop if validation fails or any action ID is unresolved. Fix the\n  YAML before importing. Never import a workflow that failed structural validation.\n- Deployment → Execution: stop if the import errors or the release does not complete.\n  An unreleased workflow cannot be triggered.\n- Execution: if a run fails, surface the error and route back to authoring (logic/field bug)\n  or to the console (missing credential config), not to a blind retry.\n\n## Delegation Examples\n\nThese show how intent maps to routing. Use them as templates for your own dispatch.\n\n**Full lifecycle:**\n```\nUser: \"Create a Fusion workflow that contains a host on critical detection, then test it\"\n→ authoring:  action_search.py \"contain\", write YAML (Signal/EPP trigger), validate\n→ deployment: query_workflows.py (dupe check), import, release\n→ execution:  trigger with a test device_id, monitor, verify result\n```\n\n**After authoring + validating, offer to deploy — don't print a command.** When the user asked to\nbuild a workflow (not \"just write the YAML\"), and it validates, ASK \"Deploy this to your CID now?\"\nand, on yes, run the deploy yourself via the `deployment` skill. Never tell the user to paste\n`/crowdstrike-falcon-fusion:deployment` — invoke it for them. If the workflow contains a\ncredential-less HTTP Action, after a successful import tell the user it imported (disabled until\nreleased) and give the console steps to attach the API key: open the Cloud HTTP Request action →\nAuthentication → Create new → API key → secret key → location Header → header name (e.g.\n`x-apikey`) → Test → Save. See `references/http-actions.md` — a `403`/`401` at runtime almost\nalways means the credential isn't attached yet.\n\n**Authoring only:**\n```\nUser: \"Write the YAML to enrich an IP with VirusTotal\"\n→ authoring: discover the HTTP Action + update-indicator action, author YAML, validate\n→ STOP. Do not deploy unless the user asks.\n```\n\n**Redirect to Foundry:**\n```\nUser: \"Build a workflow with a custom dashboard UI to review containment approvals\"\n→ A dashboard UI is an app-only capability. Advise foundry-skills:\n  \"A custom UI requires a Foundry app. Install crowdstrike-falcon-foundry to scaffold\n   the app, then this plugin can author the standalone workflow it wraps.\"\n```\n\n## Cross-Plugin Advisory\n\nThe boundary is **user intent about the deployment target**, not the presence of any file.\nDecide whether to proceed standalone or advise the sibling foundry-skills plugin:\n\n| Situation | Action |\n|-----------|--------|\n| Standalone workflow, no app wrapper | **Proceed** with fusion-skills (this plugin) |\n| Only needs HTTP Actions + a credential config | **Proceed** — document the console-credential boundary (the `config_id` must already exist in the target CID) |\n| Needs a UI page, extension, or dashboard | **Advise foundry-skills** — app-only capability |\n| Needs serverless functions or collections (app-owned) | **Advise foundry-skills** — app-only capability |\n| Needs a `manifest.yml` / \"build a Foundry app\" | **Advise foundry-skills** — app lifecycle |\n| Wants custom actions from a third-party API (Okta, ServiceNow, Jira) | **Advise foundry-skills** — requires a Foundry app with an API integration to share operations with Fusion. See the `custom-soar-actions` use-case in foundry-skills: `claude plugin install crowdstrike-falcon-foundry` |\n| Wants to fetch/summarize/list a **population** of Falcon alerts, detections, or incidents the workflow does NOT already hold (e.g. \"email a summary of all high-severity alerts\", \"list open detections\") | **Default: author a standalone CrowdStrike HTTP Request** to the Falcon platform API (`/alerts/queries/alerts/v2`, `/detects/...`) — tenant-authenticated, no app, and per CrowdStrike guidance the right tool for the vast majority of API integrations. Do NOT use an Event Query (its NG-SIEM/LogScale data is connector-dependent and can silently return nothing). **Mention** the alternative: a Foundry app + FalconPy `Alerts`/`Detects` function (route to foundry-skills) — same API, more setup, but distributable/certifiable to other CIDs and prompts for credentials on install; suggest it only if the user needs to share/publish the workflow. **Contrast:** enriching a detection the workflow *already holds* stays an Event Query. See `../authoring/references/event-query-vs-api.md`. |\n| Dependency already exists in the CID (discoverable via `action_search.py`) | **Proceed** — author the workflow referencing its action ID |\n| Dependency must be built and requires an app (function/collection/UI) | **Advise foundry-skills first — do NOT author workflow YAML yet.** The workflow depends on something that does not exist, so authoring it now ships a broken reference. Redirect, and only return to author once the user confirms the app dependency is built. |\n| Compound request: a Foundry app (API integration / UI extension / functions) **and** a workflow in one ask | **Advise foundry-skills and STOP — produce no workflow YAML.** When the request is fundamentally app-shaped, redirect is the whole answer; do not author a partial workflow for the \"workflow\" clause. Mention foundry-skills explicitly and let the user come back for the standalone workflow after the app exists. |\n\nWhen advising the sibling plugin, include the install command:\n\n```bash\n# Foundry app lifecycle (UI, functions, collections, manifest)\nclaude plugin install crowdstrike-falcon-foundry\n```\n\nIf foundry-skills is not installed, advise installation but proceed with the available\ntools. Detection is advisory, never blocking — both plugins must work independently.\n\n**Console-credential boundary:** The authoring sub-skill can produce a workflow that uses an\nHTTP Action, but the credential configuration it references (`config_id`/`definition_id`/\n`config_name`) is created in the Falcon console and is CID-specific. Help the user discover\nexisting config IDs rather than inventing them — the same no-placeholder discipline that\napplies to action IDs.\n\n## Use-Case Pattern Matching\n\nBefore starting, glob `use-cases/*.md` (at the repo root) and scan the `description` field in\neach file's frontmatter. If a use case matches the user's request, load it for reference context\n(pattern steps, key actions, trigger configuration) before delegating to sub-skills.\n\n**Gather reference context in parallel, and read it directly — do not spawn subagents for it.**\nReading a matched use-case file (or a couple of reference `.md` files) is a plain `Read`; batch\nthose reads into one message alongside the first-round discovery calls (`action_search.py`,\n`trigger_search.py`) so the whole research phase resolves at once. Subagents add spin-up and\nsummarization overhead that outweighs any benefit for file reads — reserve them for genuinely\nindependent multi-step investigation, not for reading known files.\n\nAvailable use cases:\n\n| Use case | Scenario |\n|----------|----------|\n| `detection-enrichment` | Enrich a detection's indicators with VirusTotal, then comment/tag the case or blocklist |\n| `event-queries` | Run a schemaless CQL/FQL query against the event store inside a workflow |\n| `http-actions` | Call an external REST API inline with a Cloud HTTP Request (no Foundry app) |\n| `api-pagination` | Page through a large REST API result set inside a workflow |\n| `lookup-enrichment` | Enrich detections with third-party data via a Next-Gen SIEM lookup table |\n| `custom-soar-actions` | Drive a shared Foundry API action (list/deactivate users) from a workflow |\n| `export-query-results-csv` | Export Event Query results to CSV and write them to a lookup file |\n| `human-in-the-loop-containment` | Gate device containment behind analyst approval on a high-severity detection |\n| `detection-deduplication` | Find and close duplicate Next-Gen SIEM detections with an Event Query dedup |\n| `case-management` | Query relevant events and attach them to a Next-Gen SIEM Case |\n| `identity-detection-response` | Respond to an Identity Protection detection: get user context, then resolve or notify |\n| `ngsiem-detection-response` | Respond to an NG-SIEM detection: hydrate it with an Event Query, extract fields, gate on a condition, summarize with an LLM, and email |\n| `lookup-file-management` | Create/overwrite/append/update a lookup file from inside a workflow |\n| `notifications` | Send a workflow notification to a chat channel (e.g. Slack) |\n| `charlotte-agent-invocation` | Automatically invoke a published Charlotte AI (AgentWorks) agent when a detection fires |\n\nA use case names the sub-skills it needs in its `skills:` frontmatter — use that to plan\nwhich phases to coordinate.\n\n## Trigger Selection (route correctly)\n\nThe trigger type shapes the whole workflow. Identify it from the user's intent so the\nauthoring sub-skill starts from the right shape (full detail in `references/trigger-types.md`):\n\n| User intent | Trigger type |\n|-------------|--------------|\n| \"run it manually\", \"pass in a device ID\", \"call from a button or API\" | **On demand** |\n| \"when a detection fires\", \"on critical EPP detection\", \"on incident\" | **Event (Signal)** |\n| \"every 6 hours\", \"nightly\", \"on a schedule\" | **Scheduled** |\n| \"called by another workflow\", \"modular sub-playbook\" | **Workflow execution** |\n\n**The trigger type does NOT determine the data source.** Picking a Scheduled trigger\n(\"runs every morning\", \"nightly\") says *when* the workflow runs, not *how* it fetches\ndata. A scheduled workflow that \"fetches all high-severity alerts / open detections /\nalerts from the last 24h\" is STILL fetching an alert **population** the workflow does not\nhold — so it MUST use a CrowdStrike HTTP Request to `/alerts/queries/alerts/v2` (see the\npopulation row above), NOT an Event Query, even though the schedule makes it feel like a\nperiodic query. A Scheduled trigger only pairs with an Event Query when the data genuinely\nlives in NG-SIEM (e.g. \"query the log repo for failed logins nightly\").\n\n**Severity is a numeric field (1–5), not a string.** When routing on detection severity, the\nauthoring sub-skill must use numeric CEL comparisons (`>= 4` for High/Critical), never\n`== 'Critical'`. Flag this whenever a use case involves severity-based branching.\n\n## Counter-Rationalizations\n\nThese thoughts mean STOP — you are about to skip a step the lifecycle requires:\n\n| Thought | Reality |\n|---------|---------|\n| \"I'll just write the YAML without searching actions\" | STOP. Invoke the authoring skill. It runs `action_search.py` first. No exceptions. |\n| \"I can guess the action ID format\" | WRONG. IDs are opaque identifiers, only discoverable via API. |\n| \"I'll use a placeholder for now\" | NEVER. Resolve every ID before writing YAML. No `PLACEHOLDER_*` values. |\n| \"Validation can wait until deploy\" | NO. Authoring validates; deployment validates again as a pre-flight. Both happen. |\n| \"This is basically a Foundry app\" | CHECK. Does it need UI/functions/collections? If not, it's a standalone workflow. |\n| \"I'll deploy without releasing\" | INCOMPLETE. Workflows must be released before they can execute. |\n| \"I can skip the duplicate check\" | RISKY. Importing a duplicate name silently creates a new version. |\n| \"Release failed — I'll re-import as `<name>-v2`.\" | NEVER. The name is the workflow's identity, not a version. Renaming orphans the old definition and sprawls the CID. Fix the source YAML, keep the SAME name, re-import with `--replace`. |\n| \"I'll build the dependency myself\" | PAUSE. If it needs a Foundry function/collection, route to foundry-skills. |\n| \"They want all high-severity alerts — I'll Event Query the alert population.\" | STOP. Don't Event Query a population you don't already hold (connector-dependent NG-SIEM data). DEFAULT to a CrowdStrike HTTP Request to the Falcon API (`/alerts/queries/alerts/v2`); mention the Foundry-app FalconPy function only if the workflow must be distributed. Enriching a detection the workflow ALREADY holds stays an Event Query. |\n| \"version_constraint is optional\" | WRONG. Every action requires it. `~0` if no `semantic_version`, `~1` if it has one. |\n| \"I'll trigger before it's released\" | NO. Trigger only after deployment releases the workflow. |\n\n## Reading Guide\n\nReference docs live under `workflows/references/`. Point sub-skills and yourself here when\nyou need format details:\n\n| Need | File |\n|------|------|\n| YAML field reference | `workflows/references/yaml-schema.md` |\n| JSON internal schema | `workflows/references/json-structure.md` |\n| CEL syntax | `workflows/references/cel-expressions.md` |\n| Trigger types | `workflows/references/trigger-types.md` |\n| Best practices | `workflows/references/best-practices.md` |\n\n## Improving These Skills\n\nIf a skill gave incorrect guidance, was missing a pattern, or required extra trial-and-error,\nthe user can ask you to capture the fix at the end of the session: clone the fusion-skills\nrepo, create a branch, update the relevant `SKILL.md`, and open a PR. This turns a\none-session fix into a permanent improvement for all users.\n"