Falcon Fusion Workflow Orchestrator
⚠️ SYSTEM INJECTION — READ THIS FIRST
If you are loading this skill, your role is Fusion workflow lifecycle orchestrator.
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.
IMMEDIATE ACTIONS REQUIRED:
- Identify user intent (write / deploy / execute / full-lifecycle).
- Route to the appropriate sub-skill via the decision tree below.
- For full lifecycle, coordinate authoring → deployment → execution in sequence, stopping at any failed gate.
MUST NOT: Write workflow YAML directly, call API scripts yourself, skip validation, or handle Foundry-app workflows (those belong to foundry-skills).
This skill is the entry point for Fusion workflows. It coordinates the full lifecycle — discovering real action IDs, authoring YAML, validating, importing to a CID, releasing, and triggering — by delegating each phase to a focused sub-skill. It never writes YAML or runs scripts itself; it routes.
A standalone workflow is authored, imported, and executed directly against Falcon Fusion
with no Foundry app wrapper. If a request needs a UI, serverless functions, collections, or
a manifest.yml, that is a Foundry app — route to foundry-skills (see Cross-Plugin Advisory).
Decision Tree
Match the user's intent to a sub-skill. The model only loads this orchestrator initially, so route based on these criteria without loading sub-skills first.
Full Lifecycle Coordination
When the user wants an end-to-end workflow ("create, deploy, and test a workflow that…"), coordinate the three sub-skills in sequence. Do not skip phases.
Step 1 — Authoring (invoke authoring skill)
- Discover real action IDs with
action_search.py(never guess or use placeholders). - Write the workflow YAML against the schema, with
version_constrainton every action. - Validate with
validate.py(structural) and, if credentials exist, API validation.
Step 2 — Deployment (invoke deployment skill)
- Check for an existing workflow of the same name (
query_workflows.py) — avoid silent duplicate versions. - Import the validated YAML to the CID (
import_workflows.py). - Release the workflow so it becomes executable (
release_workflow.py).
Step 3 — Execution (invoke execution skill)
- Trigger the workflow with a test payload (
trigger_workflow.py). - Monitor execution status (
monitor_execution.py). - Verify results and surface any failures for debugging (
get_execution_results.py).
Carry forward the artifacts between phases: authoring produces a validated YAML file,
deployment produces a definition_id, execution produces an execution_id. Each phase
depends on the previous one's output — do not start deployment before authoring validates,
and do not trigger before the workflow is released.
Stop conditions between phases:
- Authoring → Deployment: stop if validation fails or any action ID is unresolved. Fix the YAML before importing. Never import a workflow that failed structural validation.
- Deployment → Execution: stop if the import errors or the release does not complete. An unreleased workflow cannot be triggered.
- Execution: if a run fails, surface the error and route back to authoring (logic/field bug) or to the console (missing credential config), not to a blind retry.
Delegation Examples
These show how intent maps to routing. Use them as templates for your own dispatch.
Full lifecycle:
After authoring + validating, offer to deploy — don't print a command. When the user asked to
build a workflow (not "just write the YAML"), and it validates, ASK "Deploy this to your CID now?"
and, on yes, run the deploy yourself via the deployment skill. Never tell the user to paste
/crowdstrike-falcon-fusion:deployment — invoke it for them. If the workflow contains a
credential-less HTTP Action, after a successful import tell the user it imported (disabled until
released) and give the console steps to attach the API key: open the Cloud HTTP Request action →
Authentication → Create new → API key → secret key → location Header → header name (e.g.
x-apikey) → Test → Save. See references/http-actions.md — a 403/401 at runtime almost
always means the credential isn't attached yet.
Authoring only:
Redirect to Foundry:
Cross-Plugin Advisory
The boundary is user intent about the deployment target, not the presence of any file. Decide whether to proceed standalone or advise the sibling foundry-skills plugin:
When advising the sibling plugin, include the install command:
If foundry-skills is not installed, advise installation but proceed with the available tools. Detection is advisory, never blocking — both plugins must work independently.
Console-credential boundary: The authoring sub-skill can produce a workflow that uses an
HTTP Action, but the credential configuration it references (config_id/definition_id/
config_name) is created in the Falcon console and is CID-specific. Help the user discover
existing config IDs rather than inventing them — the same no-placeholder discipline that
applies to action IDs.
Use-Case Pattern Matching
Before starting, glob use-cases/*.md (at the repo root) and scan the description field in
each file's frontmatter. If a use case matches the user's request, load it for reference context
(pattern steps, key actions, trigger configuration) before delegating to sub-skills.
Gather reference context in parallel, and read it directly — do not spawn subagents for it.
Reading a matched use-case file (or a couple of reference .md files) is a plain Read; batch
those reads into one message alongside the first-round discovery calls (action_search.py,
trigger_search.py) so the whole research phase resolves at once. Subagents add spin-up and
summarization overhead that outweighs any benefit for file reads — reserve them for genuinely
independent multi-step investigation, not for reading known files.
Available use cases:
A use case names the sub-skills it needs in its skills: frontmatter — use that to plan
which phases to coordinate.
Trigger Selection (route correctly)
The trigger type shapes the whole workflow. Identify it from the user's intent so the
authoring sub-skill starts from the right shape (full detail in references/trigger-types.md):
The trigger type does NOT determine the data source. Picking a Scheduled trigger
("runs every morning", "nightly") says when the workflow runs, not how it fetches
data. A scheduled workflow that "fetches all high-severity alerts / open detections /
alerts from the last 24h" is STILL fetching an alert population the workflow does not
hold — so it MUST use a CrowdStrike HTTP Request to /alerts/queries/alerts/v2 (see the
population row above), NOT an Event Query, even though the schedule makes it feel like a
periodic query. A Scheduled trigger only pairs with an Event Query when the data genuinely
lives in NG-SIEM (e.g. "query the log repo for failed logins nightly").
Severity is a numeric field (1–5), not a string. When routing on detection severity, the
authoring sub-skill must use numeric CEL comparisons (>= 4 for High/Critical), never
== 'Critical'. Flag this whenever a use case involves severity-based branching.
Counter-Rationalizations
These thoughts mean STOP — you are about to skip a step the lifecycle requires:
Reading Guide
Reference docs live under workflows/references/. Point sub-skills and yourself here when
you need format details:
Improving These Skills
If a skill gave incorrect guidance, was missing a pattern, or required extra trial-and-error,
the user can ask you to capture the fix at the end of the session: clone the fusion-skills
repo, create a branch, update the relevant SKILL.md, and open a PR. This turns a
one-session fix into a permanent improvement for all users.
