Name the deployment skill consistently with its siblings

The skill declared 'name: deploy' while living in skills/deployment/.
Both resolve, so nothing was broken, but 'deploy' was the only
imperative verb among six otherwise nominal skill names (authoring,
execution, lookup-files, setup, workflows). Renaming the frontmatter to
'deployment' matches the directory and the authoring/execution pattern,
and it also removes a cosmetic quirk where the command picker offered
:deploy and rewrote it to :deployment on submit.

Changing the frontmatter rather than the directory keeps the diff to 15
lines with no path or CI churn, and follows the nominal naming used
throughout foundry-skills as well.

Updates the 12 references that named the skill 'deploy' across the
README, the orchestrator's routing table, and the sibling skills.

Author: mraible

README.md

@@ -151,7 +151,7 @@ The skills include hooks that ensure the right skills get used:
 
 3. **`PreToolUse` hook (cross-plugin bridge)** — Advisory only. If a request needs a Foundry app (UI, functions, collections, `manifest.yml`), it suggests the sibling [`crowdstrike-falcon-foundry`](https://github.com/CrowdStrike/foundry-skills) plugin. It never blocks a skill.
 
-The `workflows` orchestrator is the entry point: you say what you want, and it routes to `authoring` (discover actions, write and validate YAML), `deploy` (import and release to a CID), and `execution` (trigger and monitor). Hooks observe prompts and tool I/O to keyword-match Fusion actions; no data leaves the session.
+The `workflows` orchestrator is the entry point: you say what you want, and it routes to `authoring` (discover actions, write and validate YAML), `deployment` (import and release to a CID), and `execution` (trigger and monitor). Hooks observe prompts and tool I/O to keyword-match Fusion actions; no data leaves the session.
 
 ## Skills
 
@@ -161,7 +161,7 @@ One plugin provides five skills: an orchestrator plus four focused sub-skills.
 |-------|---------|
 | `workflows` | Primary orchestrator — routes intent and coordinates the full workflow lifecycle |
 | `authoring` | Action discovery (`action_search.py`), YAML authoring, CEL expressions, schema validation (`validate.py`) |
-| `deploy` | Duplicate check, import to CID, release, version management |
+| `deployment` | Duplicate check, import to CID, release, version management |
 | `execution` | Trigger workflows with payloads, monitor status, tail logs, debug failures |
 | `lookup-files` | Manage Falcon Next-Gen SIEM lookup files (CSV/JSON/TXT) for CQL `match()` queries |
 
@@ -185,7 +185,7 @@ graph TD
     style LF fill:#f59e0b,stroke:#d97706,color:#fff
 ```
 
-A typical lifecycle: `authoring` produces a validated YAML file → `deploy` imports it and returns a `definition_id` → `execution` triggers it and returns an `execution_id`. Each phase depends on the previous one's output.
+A typical lifecycle: `authoring` produces a validated YAML file → `deployment` imports it and returns a `definition_id` → `execution` triggers it and returns an `execution_id`. Each phase depends on the previous one's output.
 
 ```
 skills/

skills/deployment/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: deploy
+name: deployment
 description: >
   Import, release, and manage Falcon Fusion workflow definitions in a CID.
   TRIGGER when user asks to import a workflow, release a workflow version,

skills/deployment/references/console-verification.md

@@ -34,7 +34,7 @@ that, and how to navigate the console reliably to do it.
    followed by a blank/partial canvas (0 nodes drawn, Test/Save/Publish locked).
    A clean render draws the full graph with **zero** console errors.
 4. Delete the test workflow afterward with `delete_workflow.py --id <hex>` (see
-   the deploy skill) so it doesn't linger in the CID.
+   the deployment skill) so it doesn't linger in the CID.
 
 The crash above is caused by referencing a node the canvas can't build — most
 often a synthetic gateway pass-through. See `workflows/references/yaml-schema.md`

skills/execution/SKILL.md

@@ -5,7 +5,7 @@ description: >
   TRIGGER when user asks to run a workflow, check execution status, tail logs,
   get execution results, or debug a workflow failure.
   DO NOT TRIGGER for writing YAML (use authoring) or importing/releasing
-  workflows (use deploy).
+  workflows (use deployment).
 version: 1.0.0
 updated: 2026-06-26
 tags: [fusion, soar, workflows, execution, monitoring, debugging]
@@ -49,7 +49,7 @@ An execution moves through states and ends in a **terminal** state. The terminal
 
   Run `/crowdstrike-falcon-fusion:setup` to configure credentials interactively (writes the TOML profile).
 - An API client with the **Workflow** API scope
-- The **definition ID** of the workflow to run (from the deploy skill's import output, or `query_workflows.py --search`)
+- The **definition ID** of the workflow to run (from the deployment skill's import output, or `query_workflows.py --search`)
 - Verify auth before running:
   ```bash
   ${CLAUDE_PLUGIN_ROOT}/scripts/python.sh common/scripts/auth.py
@@ -65,7 +65,7 @@ A workflow must be enabled before it will execute. Confirm it exists and is enab
 ${CLAUDE_PLUGIN_ROOT}/scripts/python.sh deployment/scripts/query_workflows.py --search "my workflow"
 ```
 
-Look for `Status: enabled` in the output. If it shows `disabled`, release it first with the deploy skill (`release_workflow.py --id <id>`).
+Look for `Status: enabled` in the output. If it shows `disabled`, release it first with the deployment skill (`release_workflow.py --id <id>`).
 
 ### 2. Trigger the workflow with a payload
 
@@ -155,7 +155,7 @@ Single fetch. Reads `resources[0]` from the API envelope for the execution's `st
 
 ## Common Pitfalls
 
-1. **Triggering an unreleased workflow.** A disabled definition will not execute. Confirm `Status: enabled` (step 1) before triggering, and release it via the deploy skill if needed.
+1. **Triggering an unreleased workflow.** A disabled definition will not execute. Confirm `Status: enabled` (step 1) before triggering, and release it via the deployment skill if needed.
 
 2. **Missing required parameters.** When triggered via API (not the console UI), parameters are not prompted by the platform. Pass every required field in `--params`. Empty params are the most common failure cause.
 

skills/lookup-files/SKILL.md

@@ -5,7 +5,7 @@ description: >
   TRIGGER when user asks to create, list, update, or delete lookup files,
   or needs help with CQL match() function.
   DO NOT TRIGGER for Fusion workflows, action discovery, or workflow deployment —
-  use the workflows/authoring/deploy skills.
+  use the workflows/authoring/deployment skills.
 version: 1.0.0
 updated: 2026-06-26
 tags: [falcon, ngsiem, siem, lookup-files, cql, threat-hunting]

skills/workflows/SKILL.md

@@ -50,7 +50,7 @@ so route based on these criteria without loading sub-skills first.
 User wants to write/edit workflow YAML            → invoke authoring skill
 User wants to find/discover actions               → invoke authoring skill
 User wants to validate a workflow                 → invoke authoring skill
-User wants to deploy/import/release a workflow     → invoke deploy skill
+User wants to deploy/import/release a workflow     → invoke deployment skill
 User wants to run/monitor/debug a workflow         → invoke execution skill
 User wants full lifecycle (create + deploy + test) → coordinate all three in sequence
 User mentions a Foundry app / manifest.yml         → advise foundry-skills (see below)
@@ -62,7 +62,7 @@ User mentions lookup files / Next-Gen SIEM         → invoke lookup-files skill
 | Intent keyword | Sub-skill | What it owns |
 |----------------|-----------|--------------|
 | "write", "edit", "author", "discover actions", "validate" | **authoring** | Action discovery (`action_search.py`), YAML authoring, CEL, validation (`validate.py`) |
-| "deploy", "import", "release", "publish to CID" | **deploy** | Duplicate check, import, release, version management |
+| "deploy", "import", "release", "publish to CID" | **deployment** | Duplicate check, import, release, version management |
 | "run", "execute", "trigger", "monitor", "tail", "debug" | **execution** | Triggering with payloads, monitoring, logs, results |
 | "lookup file", "CSV/JSON lookup", "match() query" | **lookup-files** | Next-Gen SIEM lookup file management |
 | "Foundry app", "manifest", "UI + workflow", "functions" | **foundry-skills** (sibling plugin) | App lifecycle, manifest coordination |
@@ -77,7 +77,7 @@ coordinate the three sub-skills in sequence. Do not skip phases.
 2. Write the workflow YAML against the schema, with `version_constraint` on every action.
 3. Validate with `validate.py` (structural) and, if credentials exist, API validation.
 
-**Step 2 — Deployment** (invoke deploy skill)
+**Step 2 — Deployment** (invoke deployment skill)
 1. Check for an existing workflow of the same name (`query_workflows.py`) — avoid silent duplicate versions.
 2. Import the validated YAML to the CID (`import_workflows.py`).
 3. Release the workflow so it becomes executable (`release_workflow.py`).
@@ -114,8 +114,8 @@ User: "Create a Fusion workflow that contains a host on critical detection, then
 
 **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 `deploy` skill. Never tell the user to paste
-`/crowdstrike-falcon-fusion:deploy` — invoke it for them. If the workflow contains a
+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.