diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
index 812d656..f67ba98 100644
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -14,7 +14,7 @@
       "name": "s1-secops-skills",
       "source": "./plugins/s1-secops-skills",
       "description": "SentinelOne SecOps skills for Claude: PowerQuery threat hunting and STAR/Custom Detection rules; Management Console API; Singularity Data Lake API; SDL dashboards; log parsing (OCSF); Hyperautomation SOAR; z-score anomaly baselining; autonomous DFIR alert investigation (soc-investigator); and one-prompt SDL solutions: source onboarding, asset enrichment, UEBA, ingest health, detection exclusions, Risk-Based Alerting, alert noise reduction, and Detection as Code.",
-      "version": "1.2.12",
+      "version": "1.2.14",
       "author": {
         "name": "Prithvi Moses",
         "email": "prithvi.moses@sentinelone.com"
diff --git a/plugins/s1-secops-skills/.claude-plugin/plugin.json b/plugins/s1-secops-skills/.claude-plugin/plugin.json
index 4298827..d398fbe 100644
--- a/plugins/s1-secops-skills/.claude-plugin/plugin.json
+++ b/plugins/s1-secops-skills/.claude-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "s1-secops-skills",
-  "version": "1.2.13",
+  "version": "1.2.14",
   "description": "SentinelOne SecOps skills for Claude: PowerQuery threat hunting and STAR/Custom Detection rules; Management Console API; Singularity Data Lake API; SDL dashboards; log parsing (OCSF); Hyperautomation SOAR; z-score anomaly baselining; autonomous DFIR alert investigation (soc-investigator); and one-prompt SDL solutions: source onboarding, asset enrichment, UEBA, ingest health, detection exclusions, Risk-Based Alerting, alert noise reduction, and Detection as Code.",
   "author": {
     "name": "Prithvi Moses",
diff --git a/plugins/s1-secops-skills/dist/hyperautomation.skill b/plugins/s1-secops-skills/dist/hyperautomation.skill
index 27b52d4..74b1133 100644
Binary files a/plugins/s1-secops-skills/dist/hyperautomation.skill and b/plugins/s1-secops-skills/dist/hyperautomation.skill differ
diff --git a/plugins/s1-secops-skills/dist/mgmt-console-api.skill b/plugins/s1-secops-skills/dist/mgmt-console-api.skill
index d61c5f1..ec076c4 100644
Binary files a/plugins/s1-secops-skills/dist/mgmt-console-api.skill and b/plugins/s1-secops-skills/dist/mgmt-console-api.skill differ
diff --git a/plugins/s1-secops-skills/dist/powerquery.skill b/plugins/s1-secops-skills/dist/powerquery.skill
index c97ac77..e533d60 100644
Binary files a/plugins/s1-secops-skills/dist/powerquery.skill and b/plugins/s1-secops-skills/dist/powerquery.skill differ
diff --git a/plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.13.plugin b/plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.14.plugin
similarity index 91%
rename from plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.13.plugin
rename to plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.14.plugin
index 0bb4761..2c5b79c 100644
Binary files a/plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.13.plugin and b/plugins/s1-secops-skills/dist/s1-secops-skills-v1.2.14.plugin differ
diff --git a/plugins/s1-secops-skills/dist/sdl-api.skill b/plugins/s1-secops-skills/dist/sdl-api.skill
index f38567e..709c5a4 100644
Binary files a/plugins/s1-secops-skills/dist/sdl-api.skill and b/plugins/s1-secops-skills/dist/sdl-api.skill differ
diff --git a/plugins/s1-secops-skills/dist/sdl-dashboard.skill b/plugins/s1-secops-skills/dist/sdl-dashboard.skill
index dcd74a0..adc56db 100644
Binary files a/plugins/s1-secops-skills/dist/sdl-dashboard.skill and b/plugins/s1-secops-skills/dist/sdl-dashboard.skill differ
diff --git a/plugins/s1-secops-skills/dist/sdl-log-parser.skill b/plugins/s1-secops-skills/dist/sdl-log-parser.skill
index 8f0cf9e..e66a149 100644
Binary files a/plugins/s1-secops-skills/dist/sdl-log-parser.skill and b/plugins/s1-secops-skills/dist/sdl-log-parser.skill differ
diff --git a/plugins/s1-secops-skills/dist/sdl-solutions.skill b/plugins/s1-secops-skills/dist/sdl-solutions.skill
index 417cfb3..37e550d 100644
Binary files a/plugins/s1-secops-skills/dist/sdl-solutions.skill and b/plugins/s1-secops-skills/dist/sdl-solutions.skill differ
diff --git a/plugins/s1-secops-skills/dist/soc-investigator.skill b/plugins/s1-secops-skills/dist/soc-investigator.skill
index 19aae78..ddf6fc0 100644
Binary files a/plugins/s1-secops-skills/dist/soc-investigator.skill and b/plugins/s1-secops-skills/dist/soc-investigator.skill differ
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/README.md b/plugins/s1-secops-skills/skills/hyperautomation/README.md
index 94da3a0..e4d00ff 100644
--- a/plugins/s1-secops-skills/skills/hyperautomation/README.md
+++ b/plugins/s1-secops-skills/skills/hyperautomation/README.md
@@ -47,6 +47,17 @@ Just describe the workflow in plain language:
 
 Claude will ask clarifying questions if needed, warn about any integrations that require pre-configuration, generate the workflow JSON, and optionally push it directly to your console.
 
+### Autonomous SOC (auto-investigate and respond)
+
+Describe an end-to-end auto-response flow and Claude builds the canonical alert to investigate to triage to decide to respond shape, with reusable response snippets and dynamic dispatch:
+
+- "Build an autonomous SOC workflow that investigates and responds to alerts on its own"
+- "Auto-triage every high/critical alert, add a verdict note, open a ticket, and remediate"
+- "On a ransomware alert, isolate the device and notify the SOC; auto-close false positives"
+- "Let an LLM pick isolate vs quarantine vs close-as-false-positive per alert"
+
+Full pattern and the reusable-snippet library: [`references/autonomous-soc-template.md`](references/autonomous-soc-template.md).
+
 ## Layout
 
 - `SKILL.md`: instructions Claude reads when the skill triggers
@@ -55,6 +66,9 @@ Claude will ask clarifying questions if needed, warn about any integrations that
 - `references/functions-reference.md`: `{{Function.X()}}` syntax and PowerQuery patterns
 - `references/validation-rules.md`: pre-output checklist
 - `references/api-integration.md`: Hyperautomation API reference (import, activate, trigger, list)
+- `references/snippets.md`: authoring and calling reusable snippets (`snippet_20` dispatch, lifecycle API)
+- `references/autonomous-soc-template.md`: the autonomous SOC pattern (investigate to decide to respond), response-snippet library, and a branded SOC-email snippet
+- `references/connections.md`: creating an integration connection via API and cloning it across sites
 
 ## Credit
 
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/SKILL.md b/plugins/s1-secops-skills/skills/hyperautomation/SKILL.md
index d7ae3c0..532eeb2 100644
--- a/plugins/s1-secops-skills/skills/hyperautomation/SKILL.md
+++ b/plugins/s1-secops-skills/skills/hyperautomation/SKILL.md
@@ -8,7 +8,12 @@ description: >
   security task. Also triggers when the user asks to import, export, test, validate, or submit
   a workflow to a SentinelOne console via API. Always use this skill for any task involving
   SentinelOne workflow JSON — even if phrased casually (e.g., "build me a thing that disables
-  a user when an alert fires"). When in doubt about whether this skill applies, use it.
+  a user when an alert fires"). Also triggers for autonomous / auto-response SOC requests:
+  "autonomous SOC", "SOC in a box", "auto-triage", "investigate and respond automatically",
+  "auto-isolate on a critical alert", "auto-close false positives and escalate real threats",
+  or letting an LLM decide isolate vs quarantine vs close per alert (the canonical
+  investigate-decide-respond shape lives in references/autonomous-soc-template.md).
+  When in doubt about whether this skill applies, use it.
 ---
 
 # SentinelOne Hyperautomation Skill
@@ -165,6 +170,9 @@ A workflow imported or created via the API is a **Private Draft owned by the tok
 | `references/functions-reference.md` | Using `{{Function.X()}}` syntax or PowerQuery patterns |
 | `references/validation-rules.md` | Before outputting any workflow — run the checklist |
 | `references/api-integration.md` | User wants to import/export/submit to a live console |
+| `references/snippets.md` | Building or calling a **snippet** (reusable sub-workflow): authoring rules, static vs dynamic `snippet_20` calls, and the snippet lifecycle API |
+| `references/autonomous-soc-template.md` | Building an **autonomous SOC** / auto-response workflow: canonical alert→investigate→triage→decide→respond shape, the reusable response-snippet library, dynamic-snippet dispatch, and a branded SOC-email snippet example |
+| `references/connections.md` | Creating an integration **connection** via API (endpoint + body), cloning a connection across sites, and the integration-vs-connection binding rule |
 
 ## Decision guide: pick the right pattern by use case
 
@@ -183,6 +191,10 @@ table to jump straight to the right starting point:
 | "Summarize this evidence with an LLM" | B12 (OpenAI) | B6 add-note |
 | "Create a Threat Intelligence indicator" | B9 (TI IOC create) | B4 accumulator inside loop |
 | "Add a note on the alert" | B6 (UAM GraphQL addAlertNote) | always wrap text in `Function.HTML_ENCODE` |
+| "Auto-investigate and respond to alerts end to end" | `references/autonomous-soc-template.md` | reusable response snippets + dynamic `snippet_20` dispatch, poll-until-complete loop |
+| "Reuse this step across several flows" / "stop copy-pasting this logic" | `references/snippets.md` (author a snippet, call it with `snippet_20`) | `use_latest_snippet_version` to auto-track edits |
+
+**Reuse via snippets is the default for shared logic.** Whenever the same action graph would appear in more than one workflow (a response action, a notification, a poll loop), build it once as a snippet and call it with a `snippet_20` node instead of duplicating it. See `references/snippets.md`.
 
 When in doubt, the load-bearing 17 atoms are:
 `http_request`, `variable`, `condition`, `loop`, `singularity_response_trigger`,
@@ -190,6 +202,8 @@ When in doubt, the load-bearing 17 atoms are:
 `delay`, `http_trigger`, `scheduled_trigger`, `create_interaction`, `wait_for_interaction`,
 `email_trigger`. Anything outside this set is exotic; confirm it exists before generating.
 
+> **Snippet node types.** *Calling* a snippet from a workflow uses a `snippet_20` node (not `snippet`). *Authoring* a snippet uses a `snippet_trigger` (inputs) + `snippet_output` (returns) in place of a normal trigger. See `references/snippets.md`.
+
 ## Example workflows (in references/examples/)
 
 Annotated real examples to use as structural references:
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/references/autonomous-soc-template.md b/plugins/s1-secops-skills/skills/hyperautomation/references/autonomous-soc-template.md
new file mode 100644
index 0000000..cd81ae5
--- /dev/null
+++ b/plugins/s1-secops-skills/skills/hyperautomation/references/autonomous-soc-template.md
@@ -0,0 +1,139 @@
+# Autonomous SOC workflow template
+
+An autonomous SOC workflow takes an alert from detection to a decided, executed response with no
+analyst in the loop.
+
+## Example prompts that should trigger this template
+
+Use this template when a user asks for end-to-end alert handling, auto-response, or a "SOC in a
+box" — even when phrased casually. Representative prompts:
+
+- "Build an autonomous SOC workflow that investigates and responds to alerts on its own."
+- "When a critical alert fires, run Purple AI, decide the response, and act, no analyst needed."
+- "Auto-triage every high/critical alert, add a verdict note, open a ticket, and remediate."
+- "Set up automatic containment: on a ransomware alert, isolate the device and notify the SOC."
+- "Create a flow that lets an LLM pick isolate vs quarantine vs close-as-false-positive per alert."
+- "Wait for the agentic investigation to finish, summarise it, then take the right action."
+- "Auto-close false positives and only escalate real threats to a human."
+- "When an identity alert comes in, revoke the user's SaaS sessions and lock their machine."
+- "Notify the SOC by email with the verdict and recommended actions whenever we auto-respond."
+- "Stop copy-pasting the isolate/quarantine logic into every flow, make them reusable."
+
+The last two map to the reusable-snippet best practice below (a notify-SOC snippet, and factoring
+each response into its own snippet). Anything of the form "investigate → decide → respond
+automatically" is this template.
+
+## Best practice: factor reusable logic into snippets
+
+**Any part of a flow that other flows also need should be a snippet, not inline actions.** Build the
+logic once as a snippet (`references/snippets.md`), publish it, and have every workflow call it.
+This removes duplicated logic across flows: when the logic changes you edit one snippet instead of
+editing every workflow that copied it, and callers on `use_latest_snippet_version: true` pick the
+change up automatically. Reusable pieces in a SOC context are almost always: the response actions
+(isolate, quarantine, rollback, revoke, close-as-FP), the collaboration steps (open a channel,
+create a ticket, escalate), and shared utilities (poll until an investigation completes). Reach for
+a snippet whenever you notice the same action graph appearing in more than one workflow.
+
+## Canonical shape (alert-triggered)
+
+1. **Singularity Response Trigger** — fire on the target alert (filter by name / severity).
+2. **Trigger Agentic Investigation** — `http_request` to Unified Alerts GraphQL, mutation
+   `alertTriggerActions` with action `S1/aiInvestigation/run`
+   (`payload.aiInvestigation{tenantId, consoleVersion:"HyperAutomation", userAgent:"SentinelOne-HyperAutomation"}`).
+3. **Pause for Investigation Completion** — a **static** snippet call that polls until the
+   investigation finishes (poll-until-complete loop below). Shared by every alert workflow.
+4. **Get Investigation Summary** — `http_request` GraphQL `aiInvestigations { status verdict result … }`
+   once complete.
+5. *(optional)* **IOC enrichment** — extract hashes into a variable, branch SHA1 / SHA256 / MD5
+   checks, enrich with an LLM or a threat-intel action.
+6. **Triage & Summary** — an `llm` action turns the investigation + alert into a verdict/summary.
+7. **Summary markdown** — an `llm` action formats a human-readable summary.
+8. **Add Note / Set Status** — `http_request` GraphQL `addAlertNote` + `analystVerdictUpdate` /
+   `statusUpdate` (wrap note text in `Function.HTML_ENCODE`).
+9. *(optional)* **Ticket + collaboration** — create a ticket, open a Slack channel (snippet), invite,
+   notify.
+10. **Response Decision** — an `llm` action returns ONE response action, expressed as the **name of a
+    response snippet**.
+11. **Response** — a **dynamic** `snippet_20` (`is_dynamic: true`,
+    `dynamic_snippet_name: "{{response-decision.data}}"`) that dispatches to the chosen response
+    snippet, passing the shared input contract.
+12. **Wrap-up** — `llm` action summary → update alert notes → update the collaboration channel.
+
+## The reusable snippet library
+
+Each response and each shared step is its own snippet, so any workflow can call it:
+
+- **Utility:** Pause for Investigation Completion (poll loop), Create Slack Channel, Create incident.
+- **Containment:** Isolate Device / Isolate from Network, Quarantine Alert, Lock User's Machine.
+- **Identity:** Revoke SaaS Session.
+- **Recovery:** Rollback.
+- **Triage:** Close as False Positive.
+- **Escalation:** Escalate to Human.
+
+### Shared input contract (this is what enables dynamic dispatch)
+
+Give every response snippet the SAME `snippet_trigger` inputs so ONE dynamic `snippet_20` can route
+to any of them with one `inputs` map. A workable contract:
+
+`Singularity-ID`, `Response-Input`, `Device-UUID`, `Group-ID`, `Channel-ID`, `Alert-Input`.
+
+The Response Decision LLM returns the name of one snippet in the library; the dynamic node runs it
+with these inputs. Adding a new response is then just: author a new snippet against the same
+contract and teach the LLM its name — no change to the parent workflow.
+
+## Poll-until-complete loop (used by the Pause snippet)
+
+A while-loop that polls a status and breaks when done:
+
+- **loop node:** `data { action_type:"loop", loop_type:"while", number_of_iterations:"1",
+  object_to_iterate:null, is_parallel:false }`. For a while-loop `number_of_iterations` is ignored;
+  it loops until a `break_loop` fires.
+- The loop node's `connected_to` carries BOTH `{target:<first inner node>, custom_handle:"inner"}`
+  AND `{target:<node after the loop>, custom_handle:null}` (the post-loop continuation). Omit the
+  default edge and nothing runs after the loop.
+- **Inner chain** (each node `parent_action` = the loop's `export_id`):
+  `[delay] → Get Status (http) → condition(status == "COMPLETED") ─true→ break_loop`. The
+  condition's false path has no edge, so the loop iterates again.
+- Read the full result AFTER the loop (a fresh Get) — a node placed after the loop can read the
+  loop's own outputs but not a loop-internal node's output.
+
+## Build order
+
+1. Create + publish + activate each reusable snippet (import each with `snippet_trigger` +
+   the shared-contract inputs + `snippet_output`).
+2. Build the parent workflow: **static**-call the utility snippets (Pause, Create Channel) and
+   **dynamic**-call the response library through one `snippet_20` driven by the Response Decision LLM.
+3. Publish/activate the parent and confirm bindings resolve
+   (`GET /workflow-actions/snippets-versions/{id}/{versionId}?query={}`).
+
+## Example: SOC notification snippet (branded HTML email)
+
+A reusable "notify the SOC" snippet: `snippet_trigger` (inputs `Verdict`, `Severity`,
+`Recommendation`, `Alert-ID`) → `send_email` → `snippet_output`. The email body is a self-contained,
+inline-styled HTML table (email clients need inline styles; no `<style>` blocks, no external CSS)
+that reads its values from the snippet inputs. `send_email` is a `core_action` (no connection
+needed). Keep the output non-empty (a literal such as `"notified"`).
+
+```html
+<div style="margin:0;padding:20px 12px;background:#eef0f4;font-family:Segoe UI,Roboto,Arial,sans-serif;">
+<table role="presentation" width="640" align="center" cellpadding="0" cellspacing="0" style="margin:0 auto;max-width:640px;background:#ffffff;border-radius:12px;overflow:hidden;">
+<tr><td style="background:#2c1a5e;padding:20px 28px;color:#ffffff;font-size:17px;font-weight:700;">SentinelOne <span style="color:#b79cff;">Purple AI</span>
+  <span style="float:right;color:#c9bdf0;font-size:11px;font-weight:600;text-transform:uppercase;letter-spacing:1px;">Automated SOC Response</span></td></tr>
+<tr><td style="padding:26px 28px 6px;">
+  <span style="display:inline-block;background:#fde8e6;color:#b31d13;font-size:11px;font-weight:700;padding:6px 13px;border-radius:20px;text-transform:uppercase;">Verdict: {{Function.HTML_ENCODE(snippet-input.Verdict)}}</span>
+  <h1 style="margin:14px 0 4px;font-size:21px;color:#181430;">Alert triaged</h1></td></tr>
+<tr><td style="padding:14px 28px 26px;">
+  <table role="presentation" width="100%" style="border-collapse:collapse;font-size:13px;">
+    <tr><td style="padding:10px 0;color:#8a8a96;width:150px;border-bottom:1px solid #eeeef3;">Severity</td><td style="padding:10px 0;color:#1c1830;font-weight:600;border-bottom:1px solid #eeeef3;">{{Function.HTML_ENCODE(snippet-input.Severity)}}</td></tr>
+    <tr><td style="padding:10px 0;color:#8a8a96;">Alert ID</td><td style="padding:10px 0;color:#4a4a58;font-family:monospace;font-size:11px;">{{snippet-input.Alert-ID}}</td></tr>
+  </table>
+  <div style="margin-top:14px;background:#f5f2fd;border-left:4px solid #6b3fd4;padding:16px 18px;">
+    <div style="font-size:11px;font-weight:700;color:#4a1fb8;text-transform:uppercase;letter-spacing:0.7px;margin-bottom:8px;">Recommended actions</div>
+    <div style="font-size:13px;color:#2a2636;line-height:1.65;">{{snippet-input.Recommendation}}</div>
+  </div></td></tr>
+</table></div>
+```
+
+Notes: wrap free-text inputs shown as text (verdict, severity) in `Function.HTML_ENCODE`; leave a
+pre-formatted recommendation raw so its line breaks render. Per the global style, avoid em-dashes in
+copy. This snippet is then called from any workflow with a `snippet_20` node (static or dynamic).
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/references/building-blocks-catalog.md b/plugins/s1-secops-skills/skills/hyperautomation/references/building-blocks-catalog.md
index c1386c1..c39379f 100644
--- a/plugins/s1-secops-skills/skills/hyperautomation/references/building-blocks-catalog.md
+++ b/plugins/s1-secops-skills/skills/hyperautomation/references/building-blocks-catalog.md
@@ -607,26 +607,36 @@ live import API on 2026-06-11:
 
 ---
 
-## A15. Snippet
+## A15. Snippet (call a reusable sub-workflow)
 
-**Purpose**: invoke a saved sub-workflow as a single action. Drives composability, e.g. one
-"Variables From Column GSheet" snippet is reused across 75+ workflows.
+**Purpose**: invoke a reusable sub-workflow as a single action, so shared logic lives in one place
+instead of being duplicated across flows. Full authoring + calling + lifecycle: `references/snippets.md`.
 
-**Real shape**:
+**Calling node is `snippet_20`** (not `snippet`). Static call, pinned to a version:
 ```json
 {
-  "type": "snippet",
-  "tag": "core_action",
-  "data": { "name": "Variables From Column GSheet", "action_type": "snippet" },
-  "snippet_workflow_id": null,
-  "snippet_version_id": null
+  "type": "snippet_20", "tag": "core_action",
+  "snippet_workflow_id": "<snippet id>", "snippet_version_id": "<version>",
+  "data": {
+    "name": "Isolate Device", "action_type": "snippet_20",
+    "inputs": "{\"Singularity-ID\":\"{{singularity-response-trigger.data.id}}\"}",
+    "use_latest_snippet_version": false, "is_dynamic": false,
+    "dynamic_snippet_name": "Isolate Device"
+  }
 }
 ```
 
-**Important caveat from the corpus**: when a workflow is exported, **`snippet_workflow_id` and
-`snippet_version_id` come back null** (0 of 194 snippets in the corpus carried IDs). On import,
-the user re-binds the snippet by name in the console UI. So when you generate a workflow that
-uses a snippet, make the `name` exactly match the snippet's name on the target tenant.
+- `data.inputs` is a JSON **string** mapping the snippet's input params to parent references.
+- `use_latest_snippet_version: true` auto-tracks the snippet's newest published version.
+- **Dynamic dispatch:** set `is_dynamic: true` and `dynamic_snippet_name` to a mustache expression
+  (e.g. `"{{response-decision.data}}"`) to route to whichever snippet that name resolves to at
+  runtime. All candidate snippets must share one input contract. See `references/snippets.md` and
+  the autonomous-SOC pattern in `references/autonomous-soc-template.md`.
+- Bindings survive export as `snippet_workflow_id` / `snippet_version_id`; resolve them with
+  `GET /workflow-actions/snippets-versions/{workflowId}/{versionId}?query={}`.
+
+**Authoring a snippet** uses `snippet_trigger` (inputs) + `snippet_output` (returns) — see
+`references/snippets.md` for the node shapes and the import rules.
 
 ---
 
@@ -1094,11 +1104,15 @@ single-tenant flows, broken on transfer. Prefer:
 array**, not a raw array. Verified: all 1 in-operator usage in the corpus uses
 `"[\"HIGH\",\"CRITICAL\"]"` style. Don't write `["HIGH","CRITICAL"]` directly.
 
-## E5. Snippet IDs missing on import
+## E5. Snippet authoring/calling traps (import 422 with no field named)
 
-When you import a workflow that uses snippets, the `snippet_workflow_id` and
-`snippet_version_id` are null. The user must re-bind in the console. **Match the snippet's
-`name` to the snippet's name on the target tenant** so re-binding is one click.
+- Call a snippet with a **`snippet_20`** node bound via `snippet_workflow_id` + `snippet_version_id`
+  (these persist through export). Do NOT use type `"snippet"` and do NOT embed the snippet's inner
+  actions into the parent — embedding orphans a node.
+- Authoring a snippet: `export_id 0` must be a real body action, not the `snippet_trigger`;
+  `snippet_output` values must be non-empty (a bare `{{slug.}}` imports but is invalid at runtime,
+  use a literal or a real `{{slug.field}}`); the workflow name must not contain parentheses `()`.
+  Full detail: `references/snippets.md`.
 
 ## E6. Forgetting `parent_action` on inner loop steps
 
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/references/connections.md b/plugins/s1-secops-skills/skills/hyperautomation/references/connections.md
new file mode 100644
index 0000000..b4f6fed
--- /dev/null
+++ b/plugins/s1-secops-skills/skills/hyperautomation/references/connections.md
@@ -0,0 +1,71 @@
+# Connections — creating integration connections via API
+
+Integration-backed actions (`tag: "integration"`) need a connection under their `integration_id`.
+An existing connection can be bound programmatically (bind the integration id, set
+`use_authentication_data: true`). A connection can also be **created** via the API — but creating
+one requires supplying the integration's secret (an API token) in the request body. That secret is
+supplied by the human operator; do not hard-code, echo, or store it.
+
+## Endpoint
+
+```
+POST /web/api/v2.1/hyper-automate/api/v1/connections?siteIds=<id>     (or ?accountIds=<acct>)
+```
+
+Returns `200` with a connection id. Scope with `siteIds` / `accountIds` to place the connection
+where the flow lives — connections are per-scope, so a site flow needs a connection in that site
+(or an account-level one that covers it).
+
+## Body (SentinelOne first-party connections)
+
+All three SentinelOne connections share one body shape; they differ only in `name`,
+`integration_id`, and the auth **prefix**:
+
+```json
+{
+  "data": {
+    "name": "<connection name>",
+    "url": "<console-host>",
+    "port": 443,
+    "protocol": "https://",
+    "integration_id": "<action-pack id for this integration>",
+    "is_default": true,
+    "authentication_data": {
+      "way_to_pass": "header",
+      "way_to_pass_input": "Authorization",
+      "way_to_pass_prefix": "Bearer",
+      "authentication_type": "api_key",
+      "api_key": "<console API token — operator supplies>"
+    }
+  }
+}
+```
+
+| Connection | `name` | Auth prefix | Used for |
+|---|---|---|---|
+| **SentinelOne SDL** | `SentinelOne SDL connection` | `Bearer` | SDL LRQ / PowerQuery / HEC ingest (`/sdl/…`, `/services/collector`) |
+| **SentinelOne GraphQL** | `SentinelOne GraphQL connection` | `Bearer` | Unified Alerts GraphQL, agentic-investigation, alert write-backs (`/web/api/v2.1/unifiedalerts/graphql`) |
+| **SentinelOne** (mgmt) | `SentinelOne connection` | `ApiToken` | Mgmt REST (`/web/api/v2.1/…`) — sign as `ApiToken`, NOT `Bearer` |
+
+- SDL and GraphQL sign `Bearer`; the mgmt "SentinelOne" connection signs `ApiToken` — set
+  `way_to_pass_prefix` accordingly. Binding the wrong one is the classic `HTTP 500
+  "Header must start with Bearer"` (mgmt token on an SDL endpoint) failure.
+- `api_key` is the console API token for all three.
+- **Find the `integration_id`** without hard-coding it: `GET /connections/scope?<scope>` on a scope
+  that already has the connection and read each connection's `integration_id`, or list the tenant's
+  integrations. Reuse that id when creating the same connection type in another scope.
+
+## Cloning a connection to another site
+
+To replicate a connection from one site to another (e.g. copy Site A's setup to Sites B and C):
+`GET` the source connection, reuse its `name`, `url`, `port`, `protocol`, `integration_id`, and the
+`authentication_data` shape, and `POST` to the target site scope with the `api_key` filled in.
+Everything except the secret comes straight from the source connection.
+
+## Binding + activation
+
+Bind the **integration** id on `http_request` actions (`integration_id`), set
+`use_authentication_data: true`, and rely on a connection existing under that integration in the
+action's scope. Do NOT bind a specific connection id — that imports/activates but fails at runtime
+(`"Must provide connection…"`). If no connection exists for a bound integration in the target scope,
+activation fails `400 "requires configuration"` — create the connection there first, then activate.
diff --git a/plugins/s1-secops-skills/skills/hyperautomation/references/snippets.md b/plugins/s1-secops-skills/skills/hyperautomation/references/snippets.md
new file mode 100644
index 0000000..61e3480
--- /dev/null
+++ b/plugins/s1-secops-skills/skills/hyperautomation/references/snippets.md
@@ -0,0 +1,121 @@
+# Snippets — reusable sub-workflows
+
+A snippet is a workflow you call from other workflows. Use snippets to factor any reusable
+slice of logic (isolate a device, quarantine a threat, open a ticket, poll until an investigation
+completes, notify the SOC) into one versioned block that many workflows share.
+
+## What makes a workflow a snippet
+
+A snippet is a workflow flagged `is_snippet=true`, but **what makes it a snippet is its NODES,
+not a flag in the create body.** It contains a `snippet_trigger` (its input contract) and a
+`snippet_output` (its return contract) in place of an ordinary trigger. The import endpoint ignores
+an explicit `is_snippet` field — include the `snippet_trigger` + `snippet_output` nodes and the
+platform treats the workflow as a snippet automatically.
+
+## Authoring a snippet
+
+Three kinds of node:
+
+1. **`snippet_trigger`** — the input contract. `data.action_type: "snippet_trigger"`,
+   `data.name: "Snippet Input"`, and `data.dynamic_properties` declares each input:
+
+   ```json
+   "dynamic_properties": {
+     "Singularity-ID": {"title": "", "description": "Alert id.", "index": 0},
+     "Alert-Input":    {"title": "", "description": "Alert summary.", "index": 1}
+   }
+   ```
+
+   Body actions read an input as `{{snippet-input.<Param>}}` (the slug of "Snippet Input").
+   Hyphenated params are fine: `{{snippet-input.Singularity-ID}}`.
+
+2. **Body actions** — any normal actions (`http_request`, `llm`, `condition`, `loop`,
+   `send_email`, …). Same shapes as in a regular workflow.
+
+3. **`snippet_output`** — the return contract. `data.action_type: "snippet_output"`, and
+   `data.output` maps output names to values:
+
+   ```json
+   "output": {"Isolated": "{{disconnect-endpoint.status}}"}
+   ```
+
+### Authoring rules (import returns `422 "Invalid workflow data"` and names no field — check these)
+
+- **`export_id 0` must belong to a real body action, not the `snippet_trigger`.** Assigning the
+  trigger `export_id 0` fails import. Convention: body action = `0`, `snippet_trigger` = `1`,
+  `snippet_output` = `2`; wire `trigger → body → output` via `connected_to.target`.
+- **`snippet_output` values must be non-empty.** A bare `{{slug.}}` (trailing dot, empty field)
+  imports but the snippet is invalid at runtime. Use a real `{{slug.field}}` the node actually
+  emits, or a literal string (e.g. `"done"`). `send_email` does not emit a `.status` field.
+- **The workflow name must not contain parentheses `()`** — import fails. Names must be unique
+  among live workflows (a collision also returns `422`).
+- Every node inside a loop sets `parent_action` = the loop's `export_id` (see the loop pattern
+  in `autonomous-soc-template.md`).
+
+## Calling a snippet — static
+
+A parent workflow calls a snippet with a **`snippet_20`** node. Do NOT use type `"snippet"`, and do
+NOT embed the snippet's inner actions into the parent (embedding produces an orphaned node on the
+canvas):
+
+```json
+{
+  "type": "snippet_20", "tag": "core_action",
+  "snippet_workflow_id": "<snippet id>", "snippet_version_id": "<pinned version>",
+  "data": {
+    "name": "Isolate Device", "action_type": "snippet_20",
+    "inputs": "{\"Singularity-ID\":\"{{singularity-response-trigger.data.id}}\"}",
+    "use_latest_snippet_version": false, "is_dynamic": false,
+    "dynamic_snippet_name": "Isolate Device"
+  }
+}
+```
+
+- `data.inputs` is a **JSON string** mapping the snippet's input-param names to mustache
+  references from the parent.
+- `use_latest_snippet_version: true` tracks the snippet's newest published version automatically;
+  `false` pins `snippet_version_id`.
+- Resolve a workflow's snippet bindings with
+  `GET /workflow-actions/snippets-versions/{workflowId}/{versionId}?query={}`.
+
+## Calling a snippet — dynamic (runtime dispatch)
+
+Set `is_dynamic: true` and make `dynamic_snippet_name` a **mustache expression that resolves to a
+snippet name at runtime**. The node dispatches to whichever snippet matches that name:
+
+```json
+"data": {
+  "name": "Response", "action_type": "snippet_20",
+  "inputs": "{\"Singularity-ID\":\"{{...}}\",\"Alert-Input\":\"{{...}}\"}",
+  "use_latest_snippet_version": false, "is_dynamic": true,
+  "dynamic_snippet_name": "{{response-decision.data}}"
+}
+```
+
+An upstream LLM (or condition) emits one of several snippet names; the dynamic `snippet_20` routes
+to it. For this to work, **every candidate snippet must share one input contract** (identical
+`snippet_trigger` `dynamic_properties`) so the same `inputs` map satisfies any of them. This is how
+an autonomous responder picks Isolate vs Quarantine vs Close-as-FP at runtime — see
+`autonomous-soc-template.md`.
+
+## Lifecycle (API)
+
+Snippets ride the `/workflows` API. Scope every call with `siteIds=<id>` **or** `accountIds=<acct>`
+to match where the snippet lives (a site snippet also appears in that account's list).
+
+- **Create** — import a workflow that contains `snippet_trigger` + `snippet_output`:
+  `POST /workflow-import-export/import?<scope>` with `{"data": <workflow>}`. (The console UI's
+  own create is `POST /workflows` with an `actions_create[]` seeding those two nodes; import is
+  equivalent and is what to use programmatically.)
+- **Publish** — `POST /v1/workflows/{id}/publish?<scope>` (bodyless, `204`).
+- **Activate** — `POST /workflows/{id}/{versionId}/activation?<scope>` with body
+  `{"data": {"version_description": "", "dimensions": {"x":0,"y":0,"width":256,"height":100}}}` (`204`).
+- **List** — `GET /v1/workflows?is_snippet=true&<scope>`.
+- **Deactivate** — `POST /v1/workflows/{id}/{versionId}/deactivate?<scope>` (`204`). A snippet can
+  carry MULTIPLE active versions; deactivate EACH version before deleting.
+- **Delete (archive)** — `POST /v1/workflows/archive` with
+  `{"data": {"workflow_ids": [id]}, "filter": {<scope>}}` (`200`). The filter scope must MATCH the
+  object's scope: for an account-scoped snippet the filter must be `accountIds`-only — adding
+  `siteIds` returns `404 "Object not found"`. A snippet still referenced by a workflow cannot be
+  archived (`400 "Active workflows cannot be archived"` / reference guard); archive or unbind the
+  referencing workflow first.
diff --git a/plugins/s1-secops-skills/skills/mgmt-console-api/README.md b/plugins/s1-secops-skills/skills/mgmt-console-api/README.md
index fa1ef48..7f83ece 100644
--- a/plugins/s1-secops-skills/skills/mgmt-console-api/README.md
+++ b/plugins/s1-secops-skills/skills/mgmt-console-api/README.md
@@ -12,7 +12,7 @@ cp -r sentinelone-mgmt-console-api ~/.claude/skills/
 
 In Cowork/Claude Code, the path is:
 
-```
+```text
 /sessions/<session>/mnt/.claude/skills/sentinelone-mgmt-console-api/
 ```
 
diff --git a/plugins/s1-secops-skills/skills/mgmt-console-api/SKILL.md b/plugins/s1-secops-skills/skills/mgmt-console-api/SKILL.md
index 1dc45c0..3b77fc0 100644
--- a/plugins/s1-secops-skills/skills/mgmt-console-api/SKILL.md
+++ b/plugins/s1-secops-skills/skills/mgmt-console-api/SKILL.md
@@ -9,7 +9,7 @@ description: Use whenever the user wants to query, update, create, or act on a S
 Wraps the SentinelOne Management Console API (Swagger 2.0, spec version 2.1, 781 operations) with a pre-built Python client, a compact endpoint index, and per-tag reference files.
 
 > **Sandbox proxy blocked?** If calls to `*.sentinelone.net` fail with a connection or proxy error inside the Claude sandbox, use the `s1-secops-mcp` server instead. It runs locally on your machine via `node` and bypasses the sandbox proxy entirely. Setup: add it to `claude_desktop_config.json` (see `s1-secops-mcp/README.md`). The MCP server exposes all the tools in this skill — `s1_api_get`, `s1_api_post`, `purple_ai_alert_summary`, `uam_list_alerts`, `uam_get_alert`, `uam_add_note`, `uam_set_status` — with schemas validated against the live API. For natural-language Purple AI queries and AI investigations, use the Purple MCP (`mcp__purple-mcp__purple_ai`) directly — those operations require a browser-session teamToken that API tokens never obtain.
-
+>
 > **Load this skill BEFORE any console/UAM *write*, not just reads.** Add-note, set-analyst-verdict, set-status, assign, and IOC-create all run through the UAM `alertTriggerActions` mutation with a specific action-id + `OrFilterSelectionInput` shape (see `references/UNIFIED_ALERTS.md`): action ids are `S1/alert/addNote` / `analystVerdictUpdate` / `statusUpdate`, and the alert is targeted by `filter:{or:[{and:[{fieldId:"id",stringEqual:{value:<id>}}]}]}` — the alert id is the FILTER, never the action `id`. Hand-rolling this GraphQL from live schema introspection is the fast path to a wrong action-id/filter and a misleading empty result. Also: `alertTriggerActions` returns a success-shaped `ActionsTriggered` even when nothing changed — always re-query (`uam_get_alert`) to confirm the write landed.
 
 ## Setup — configure credentials first
@@ -54,6 +54,7 @@ When the user asks for something involving the S1 API, follow this pattern:
 The S1 API uses **GET for every read operation** — listing, counting, and exporting. POST is only for actions and mutations. Violating this produces HTTP 404, not a permissions error, because the path simply does not exist.
 
 **Read (always GET):**
+
 | Intent | Correct endpoint |
 |---|---|
 | List agents | `GET /web/api/v2.1/agents` |
@@ -65,6 +66,7 @@ The S1 API uses **GET for every read operation** — listing, counting, and expo
 | Get system info | `GET /web/api/v2.1/system/info` |
 
 **Write / action (POST/PUT/DELETE):**
+
 - Agent actions (isolate, reconnect, uninstall, scan): `POST /web/api/v2.1/agents/actions/<action>`
 - Threat actions (mitigate, verdict, fetch-file): `POST /web/api/v2.1/threats/<action>`
 - Mutations (notes, exclusions, IOCs, custom rules): POST/PUT/DELETE on the relevant resource path
@@ -161,6 +163,7 @@ See the **PowerQuery Scheduled Detections** subsection below for the full schedu
 ```
 
 Events rule gotchas confirmed against live API:
+
 - `"activeResponse"` in the body returns HTTP 400 "Unknown field" — omit it.
 - `queryLang` defaults to `"1.0"` for events rules; do not set it explicitly (unlike scheduled rules which require `"2.0"`).
 - `treatAsThreat="UNDEFINED"` is accepted on input but stored as `null` in the response.
@@ -199,7 +202,7 @@ The body field for filter criteria is `filterFields`, not `filters`:
 
 **If the POST fails with a feature-not-enabled / not-licensed / unauthorized response on a tenant where the schema is otherwise correct, stop and tell the user to enable the Scheduled Detections feature on the tenant before retrying.** Do not silently downgrade the rule body to S1QL or re-attempt with `queryType: "events"`. The console path is typically *Settings → Account → Detection / SDL Add-Ons → Scheduled Detections* but varies by platform version, so phrase the ask in terms of capability ("please enable Scheduled Detections on this account") rather than the exact click path.
 
-**CREATE — POST /web/api/v2.1/cloud-detection/rules**
+#### CREATE: POST /web/api/v2.1/cloud-detection/rules
 
 All five `data` fields are required. `queryLang: "2.0"` is mandatory; omitting it returns HTTP 400 "query lang must be 2.0". `filter` accepts `accountIds` or `siteIds` (account-level rules cover all sites under that account):
 
@@ -232,7 +235,7 @@ All five `data` fields are required. `queryLang: "2.0"` is mandatory; omitting i
 
 **GET requires `isLegacy=false`** — without this query parameter, the list endpoint returns 0 results for scheduled rules even though they exist and are visible in the console UI. Always include it. **When listing all rules regardless of type (e.g. searching by name), always pass `isLegacy=false` — without it you will only see events-type rules and silently miss all scheduled rules:**
 
-```
+```text
 GET /web/api/v2.1/cloud-detection/rules?isLegacy=false&limit=100
 GET /web/api/v2.1/cloud-detection/rules?siteIds=<id>&queryType=scheduled&isLegacy=false
 GET /web/api/v2.1/cloud-detection/rules?ids=<ruleId>&siteIds=<id>&isLegacy=false
@@ -260,7 +263,7 @@ Note: `name__contains` filter silently returns 0 for scheduled rules when `isLeg
 
 **ENABLE/DISABLE** — dedicated PUT endpoints. The filter takes `ids` plus an optional scope (`siteIds` or `accountIds`); `ids` alone works because rule IDs are globally unique. Do NOT include `isLegacy` in the body — it returns `400 filter: isLegacy: Unknown field` (`isLegacy` is a GET-listing param only). Tenant-validated 2026-06-16: `{"filter": {"ids": [...]}}` returned `{"affected": N}`.
 
-```
+```text
 PUT /web/api/v2.1/cloud-detection/rules/enable   body: {"filter": {"ids": ["<ruleId>"], "siteIds": ["<siteId>"]}}
 PUT /web/api/v2.1/cloud-detection/rules/disable  body: {"filter": {"ids": ["<ruleId>"], "siteIds": ["<siteId>"]}}
 ```
@@ -295,7 +298,7 @@ If you call this immediately after creating a note you will get "Alert Note with
 
 When starting on an unfamiliar tenant, run the non-destructive smoke test once:
 
-```
+```text
 python scripts/smoke_test_queries.py --workers 12
 ```
 
@@ -459,6 +462,7 @@ query purpleLaunchQuery($request: PurpleLaunchQueryRequest!) {
 ```
 
 Variables (`$request`):
+
 ```jsonc
 {
   "request": {
@@ -492,6 +496,7 @@ Variables (`$request`):
 ```
 
 `PurpleUserDetailsRequest` schema (confirmed via live validation error — does NOT have `siteIds` or `groupIds`):
+
 ```jsonc
 {
   "accountId": "<19-digit ID>",  // ID! required
@@ -505,7 +510,8 @@ Variables (`$request`):
 ```
 
 Full end-to-end flow for one user question (observed in browser session):
-```
+
+```text
 1. purpleLaunchQuery  (NATURAL_LANGUAGE, /web/api/v2.1/graphql)
    → result.powerQuery.query  (the generated PQ string)
 
@@ -534,9 +540,11 @@ Full end-to-end flow for one user question (observed in browser session):
 ```
 
 Starter-prompt flow (e.g. "Find install logs" on the homepage):
-```
+
+```text
 createNotebook → purpleLaunchQuery (NATURAL_LANGUAGE) → addPurpleInputOutputMessage
 ```
+
 Note: starter prompts that return a documentation-style answer skip the `launchQuery`/`pingQuery` stage entirely.
 
 **API-token users: use the Purple MCP.** The `purple_ai_query` MCP tool has been removed — `purpleLaunchQuery NATURAL_LANGUAGE` is confirmed non-functional for service-account API tokens (requires browser-session teamToken; returns AsimovError from LaunchQueryManager). Use `mcp__purple-mcp__purple_ai` for NL queries and `mcp__purple-mcp__powerquery` to execute the returned PQ.
@@ -573,7 +581,7 @@ Verdict enum: `UNKNOWN`, `TRUE_POSITIVE`, `FALSE_POSITIVE`.
 
 > **`purple_query()` and `scripts/call_purple.py` are non-functional for API tokens.** Both call `purpleLaunchQuery NATURAL_LANGUAGE`, which requires a browser-session teamToken that service accounts never have (confirmed SERVICE_ERROR 2026-05-03). Use the Purple MCP instead:
 >
-> ```
+> ```text
 > mcp__purple-mcp__purple_ai   # natural-language query → PQ → result
 > mcp__purple-mcp__powerquery  # run a PQ string directly
 > ```
@@ -681,7 +689,7 @@ For ranges past 2-3 days with `event.type=*`-scale aggregates, slice the window
 
 `timebucket(...)` works in PQ when used as a NAMED grouping output inside `group ... by`:
 
-```
+```text
 | group n = count() by day = timebucket('1d'), action     ← works
 ```
 
@@ -741,6 +749,7 @@ If you ever have to read a raw LRQ response (e.g. debugging), know:
 ## Unified Alert Management (UAM) — PRIMARY alert API
 
 > **Alert API precedence — important:**
+>
 > 1. **PRIMARY — GraphQL UAM** at `POST /web/api/v2.1/unifiedalerts/graphql`. This is the modern, multi-source alerts inbox (EDR, XDR, Identity, STAR, Cloud, NGFW, and ingested third-party telemetry). IDs are UUIDs (e.g. `019db24c-8b6d-7451-8697-b1b2e1a270f1`). Use this for any alert listing, filtering, triage, note, status, verdict, assignment, group-by, facet, or CSV-export task.
 > 2. **SECONDARY — REST** at `GET /web/api/v2.1/cloud-detection/alerts`. Older surface, scoped to cloud-detection events (STAR rule hits, EDR overflow). IDs are int64 (e.g. `2055164731151448891`). Use only when you specifically need the denormalized REST payload (`agentDetectionInfo`, `sourceProcess`, `targetProcess`, `ruleInfo`) or when UAM is unavailable. These are **parallel surfaces, not redundant** — the same alert will have different IDs in each.
 > 3. **No `createAlert`.** S1 does not expose a mutation for creating alerts directly. Alerts are server-side byproducts of detection engines — create a STAR/Custom Detection rule (`POST /web/api/v2.1/cloud-detection/rules`), upload an IOC that matches live telemetry (`POST /web/api/v2.1/threat-intelligence/iocs`), or generate synthetic endpoint activity. `addAlertNote` is the closest reversible content-creation path against an existing alert.
@@ -780,7 +789,7 @@ uam.set_alert_status(
 
 CLI equivalents:
 
-```
+```text
 python scripts/call_unified_alerts.py list --filter detectionProduct=EDR --first 20
 python scripts/call_unified_alerts.py facets status severity detectionProduct
 python scripts/call_unified_alerts.py notes <alert-id>
@@ -971,6 +980,7 @@ sources = list_data_sources(client, hours=24, limit=200)
 CLI: `python scripts/inspect_source.py --list` prints a ranked table of every source that ingested in the last 24h. If a name the user asked for isn't in the list, fuzzy-match and surface candidates rather than running a query that will return 0.
 
 Rules of thumb:
+
 - There can be multiple rows with the same `dataSource.name` under different `dataSource.category` values (e.g. `SentinelOne / security`, `SentinelOne / None`, `SentinelOne / telemetry`). Treat category as metadata, not part of the name.
 - A source with non-zero `ct` in 24h is live. Anything else is either decommissioned, in a different time window, or scoped out of the current token.
 
@@ -992,6 +1002,7 @@ prim_key, action_key = pick_keys(schema)
 CLI: `python scripts/inspect_source.py --source "<name>" --window 24h`.
 
 Key points:
+
 - Uses the LRQ `LOG` queryType (not PowerQuery). PQ has no wildcard column projection; `| columns *` errors and `| limit N` only returns `timestamp + message`. `LOG` returns every flat attribute the parser emits under `matches[].values`, which is how the Event Search UI populates its "Event properties" panel.
 - Sync SDL `/sdl/api/query` is ~30% faster than async LRQ on your-tenant. The dispatcher prefers it and falls back to LRQ LOG on HTTP 404/401/403. Force a backend with `backend="sdl"` or `backend="lrq"` if benchmarking.
 - Escalating window (1h -> 4h -> 24h -> requested) keeps busy sources ~3s. Only sparse sources (audit, low-volume demos) pay the full widening cost. Override with `escalate=False` for a single-rung run at `hours=`.
@@ -1110,7 +1121,7 @@ Order: `user`, then `src.hostname`, then `src.ip.address`, then none. The collec
 
 ### Running the whole thing
 
-```
+```text
 # From the skill root, with $CLAUDE_CONFIG_DIR/sentinelone/credentials.json configured.
 python scripts/build_source_report.py --source "<vendor>" --window <7d|24h|...>
 python scripts/render_charts.py reports/<slug>_<window>/data.json
@@ -1134,16 +1145,17 @@ The collector creates `reports/<slug>_<window>/` on first run. The `reports/` di
 
 Consult the per-tag reference files for exact parameter names — the above are orientation, not copy-paste ready.
 
-
 ## Hyperautomation (HA) — workflow management
 
 API root (confirmed via live network capture 2026-05-03):
-```
+
+```text
 /web/api/v2.1/hyper-automate/api/v1
 ```
+
 Auth: same `Authorization: ApiToken <token>` header as all other S1 REST calls.
 
-### Endpoints
+### Hyperautomation Endpoints
 
 | Operation | Method | Path |
 |---|---|---|
@@ -1163,6 +1175,7 @@ Export/import were not captured in the v1 network trace. They are confirmed work
 ### List response shape (key fields)
 
 Each item in `data[]`:
+
 ```jsonc
 {
   "id": "<workflowUUID>",                     // top-level workflow ID
diff --git a/plugins/s1-secops-skills/skills/mgmt-console-api/tests/README.md b/plugins/s1-secops-skills/skills/mgmt-console-api/tests/README.md
index b55f635..73aa958 100644
--- a/plugins/s1-secops-skills/skills/mgmt-console-api/tests/README.md
+++ b/plugins/s1-secops-skills/skills/mgmt-console-api/tests/README.md
@@ -78,7 +78,7 @@ explicit scope selection via a single-account-pinned token.
 a hand-curated allow-list of read-only POSTs, calls them, and records the
 HTTP status + response shape.
 
-```
+```text
 python scripts/smoke_test_queries.py                                # default: skip streaming endpoints
 python scripts/smoke_test_queries.py --include-slow                 # also call exports / downloads
 python scripts/smoke_test_queries.py --tag Threats                  # just one tag
@@ -102,7 +102,7 @@ because some XDR export endpoints stream large payloads.
 
 Proves the full IOC workflow end-to-end, reversibly:
 
-```
+```text
 CREATE  POST   /web/api/v2.1/threat-intelligence/iocs
 LIST    GET    /web/api/v2.1/threat-intelligence/iocs?name__contains=<run_tag>
 DELETE  DELETE /web/api/v2.1/threat-intelligence/iocs   (body filter: {uuids: [...]})
@@ -125,7 +125,7 @@ Demonstrates the alert-API story end-to-end: **GraphQL UAM is PRIMARY**,
 REST `/cloud-detection/alerts` is **SECONDARY**, parallel surfaces with
 different ID formats.
 
-```
+```text
 1. POST /web/api/v2.1/unifiedalerts/graphql  (list alerts, first=5)
 2. POST /web/api/v2.1/unifiedalerts/graphql  (alert(id) detail)
 3. POST /web/api/v2.1/unifiedalerts/graphql  (addAlertNote mutation)
@@ -160,7 +160,7 @@ aborts cleanly with a clear message — expected behaviour, not a bug.
 CREATE → LIST → UPDATE → DELETE → VERIFY on
 `/web/api/v2.1/cloud-detection/rules`.
 
-```
+```text
 CREATE  POST   /web/api/v2.1/cloud-detection/rules
        body.filter: {accountIds: [<id>]}
        body.data:   {name, severity, expirationMode, queryType, status=Disabled, s1ql}
@@ -188,7 +188,7 @@ the first visible account instead.
 Proves the UAM bulk-ops mutation pattern against an existing alert,
 with full restoration:
 
-```
+```text
 1. Pick most-recent alert → record {status, analystVerdict}
 2. set_alert_status  (rotates NEW→IN_PROGRESS or vice versa)  → wait_for_field
 3. restore status to original                                  → wait_for_field
@@ -215,7 +215,7 @@ to target a specific alert.
 CREATE → LIST → UPDATE → DELETE → VERIFY against
 `/web/api/v2.1/report-tasks`.
 
-```
+```text
 CREATE POST  /web/api/v2.1/report-tasks
        body: {data: {name, scheduleType=manually, insightTypes, fromDate, toDate},
               filter: {siteIds}}
@@ -250,7 +250,7 @@ during the test window.
 Exercises the SOC workflow "take an indicator observed on an alert and
 promote it to a tracked TI IOC":
 
-```
+```text
 1. Pick most-recent alert
 2. Read alert.rawIndicators, extract a file-hash observable (MD5/SHA256)
 3. CREATE an IOC for that hash, tagged to the alert:
@@ -277,7 +277,7 @@ verify the indicator is stitched, then close the alert
 (status=RESOLVED + analystVerdict=TRUE_POSITIVE_BENIGN) so it leaves the
 SOC queue.
 
-```
+```text
 1. POST https://ingest.us1.sentinelone.net/v1/indicators   (gzip + Bearer + S1-Scope)
 2. POST https://ingest.us1.sentinelone.net/v1/alerts        (finding_info.related_events[].uid)
 3. Poll UAM GraphQL list_alerts for name~=<run_tag> (up to 90s)
@@ -289,7 +289,7 @@ This is a **different API family** from everything else in the skill. All
 other tests hit `<tenant>.sentinelone.net/web/api/v2.1/...`. The UAM
 Alert Interface (formerly "Ingestion Gateway") lives on a separate host
 family (e.g. `ingest.us1.sentinelone.net`). Find your region endpoint at
-https://community.sentinelone.com/s/article/000004961. The interface uses its own wire contract:
+<https://community.sentinelone.com/s/article/000004961>. The interface uses its own wire contract:
 
 - Auth header is `Bearer <JWT>`, NOT `ApiToken <JWT>`. The mgmt console
   REST scheme is rejected with HTTP 401 `"Unsupported auth type: ApiToken"`.
@@ -328,7 +328,7 @@ test does not: **batching**, **multiple observables per indicator**, and
 **multiple indicators linked to one alert** across all three supported
 OCSF classes.
 
-```
+```text
 1. Build 3 indicators in one batch:
    - file    (OCSF class 1001) with Hostname, File Name, SHA-256, MD5, User Name, IP Address
    - process (OCSF class 1007) with Hostname, Process Name, Resource UID (pid), User Name, IP Address
@@ -396,7 +396,7 @@ delta is the payload shape.
 
 Proves the full lifecycle for `queryType=scheduled` rules (PowerQuery-based detections) on the demo site (`siteId=<site-id>`). No separate test script exists yet — the lifecycle was confirmed via an inline Python session. See the schema gotchas below before writing a script.
 
-```
+```text
 CREATE  POST  /web/api/v2.1/cloud-detection/rules
         data: {name, queryType="scheduled", queryLang="2.0", severity, expirationMode,
                status="Disabled", scheduledParams: {query, runIntervalMinutes, lookbackWindowMinutes, threshold}}
@@ -486,7 +486,7 @@ VERIFY  GET   /web/api/v2.1/cloud-detection/rules?ids=...&siteIds=...&isLegacy=f
 
 ## 12. Unified Exclusion lifecycle (2026-05-03)
 
-```
+```text
 CREATE  POST  /web/api/v2.1/unified-exclusions
         data: {exclusionName, threatType="EDR", osType="linux",
                type="path", value=<path>, pathExclusionType="file",
@@ -500,6 +500,7 @@ VERIFY  GET   (expect 0 hits)
 ```
 
 **Gotchas confirmed vs. live API:**
+
 - `modeType` and `type` are required — swagger marks them optional but API rejects without them.
 - `engines` is required when `modeType=suppression`.
 - `engines` and `interactionLevel` are mutually exclusive — passing both returns HTTP 400.
@@ -510,7 +511,7 @@ VERIFY  GET   (expect 0 hits)
 
 ## 13. Hyperautomation workflow import lifecycle (2026-05-03)
 
-```
+```text
 IMPORT  POST  /web/api/v2.1/hyper-automate/api/public/workflow-import-export/import
         body: {data: {name, description, actions: [...]}, filter: {accountIds: [...]}}
         response: top-level "id" and "version_id" (NOT "workflowId"/"versionId")
@@ -522,6 +523,7 @@ DELETE  DELETE /web/api/v2.1/hyper-automate/api/v1/workflows/{id}?accountIds=<ac
 ```
 
 **Gotchas confirmed vs. live API:**
+
 - Public import response key is `id` not `workflowId`; `version_id` not `versionId`.
 - `/api/public/workflows` and `/api/v1/workflows` return the same nested format: `{id, workflow: {...}, actions: []}`. The `workflow.id` == top-level `id`.
 - Tenant had 1050+ workflows. `nextCursor` returns literal string `"null"` (truthy in Python) — loop by skip/limit, not cursor. Sort by `updated_at desc` and scan first 20 to find a newly imported workflow without paginating 1050 rows.
@@ -529,7 +531,7 @@ DELETE  DELETE /web/api/v2.1/hyper-automate/api/v1/workflows/{id}?accountIds=<ac
 
 ## 14. Detection rule ENABLE/DISABLE lifecycle (2026-05-03)
 
-```
+```text
 CREATE   POST  /web/api/v2.1/cloud-detection/rules  (see Section 11 for scheduled schema)
 ENABLE   PUT   /web/api/v2.1/cloud-detection/rules/enable
          body: {filter: {ids: [<ruleId>], siteIds: [<siteId>]}}
@@ -540,9 +542,10 @@ DELETE   DELETE /web/api/v2.1/cloud-detection/rules
 ```
 
 **Gotchas confirmed vs. live API:**
+
 - After ENABLE, `status` transitions through `"activating"` before settling on `"active"`. Both are valid post-enable states — accept both in assertions.
 - Tested with both `queryType=scheduled` (requires `isLegacy=false` on GET) and `queryType=events`. Both use the same enable/disable endpoints.
-- Tested on demo (site <site-id>). Scheduled rule used `runIntervalMinutes=1440` and `threshold.value=9999` so it cannot fire within the test lifetime even when briefly enabled.
+- Tested on demo (site `<site-id>`). Scheduled rule used `runIntervalMinutes=1440` and `threshold.value=9999` so it cannot fire within the test lifetime even when briefly enabled.
 
 ---
 
@@ -552,7 +555,7 @@ STAR rules ("streaming threat assessment rules") are product marketing terminolo
 real-time event detection rules. The API has no `/star-rules` path — they are
 `cloud-detection/rules` with `queryType=events`. The `/star-rules` path returns 404.
 
-```
+```text
 CREATE  POST   /web/api/v2.1/cloud-detection/rules
         body: {data: {name, description, queryType="events", s1ql, severity,
                       expirationMode, status="Draft", treatAsThreat, networkQuarantine},
@@ -568,6 +571,7 @@ VERIFY  GET    ids=<id> → data=[]
 ```
 
 **Gotchas confirmed vs. live API:**
+
 - No `/star-rules` path — use `cloud-detection/rules` with `queryType=events`.
 - `"activeResponse"` in the CREATE body returns HTTP 400 "Unknown field" — omit it.
 - `queryLang` defaults to `"1.0"` for events rules; do not set it explicitly.
@@ -582,7 +586,7 @@ VERIFY  GET    ids=<id> → data=[]
 
 ## Running the full test suite
 
-```
+```text
 # 1. Read-only sweep — ~60s default, several minutes with --include-slow.
 python scripts/smoke_test_queries.py --workers 16 --timeout 10
 
diff --git a/plugins/s1-secops-skills/skills/powerquery/SKILL.md b/plugins/s1-secops-skills/skills/powerquery/SKILL.md
index 590667c..0640823 100644
--- a/plugins/s1-secops-skills/skills/powerquery/SKILL.md
+++ b/plugins/s1-secops-skills/skills/powerquery/SKILL.md
@@ -24,7 +24,7 @@ When the user asks you to write or investigate with a PowerQuery:
 
 ## The grammar in one page
 
-```
+```text
 initial-filter-expression
 | command
 | command
@@ -34,6 +34,7 @@ initial-filter-expression
 **Initial filter** (everything before the first `|`) is the only place where `* contains "x"` and `* matches "regex"` multi-field search works. It can be empty — start the query with `|` and it is treated as "all events" (e.g., `| group ct=count() by event.type`).
 
 **Commands** (each starts with `|`):
+
 - `filter expr` — keep matching rows (initial filter implicit)
 - `columns f1, "Renamed f2"=f2, …` — select, rename, compute output columns (creates a *new* record set — previous fields not accessible after)
 - `let f = expr, …` — add computed fields without discarding existing ones
@@ -99,7 +100,7 @@ These are where queries go wrong. Internalize them before writing.
    - **All-column text search:** `* contains 'evil.com'` or `* matches 'regex'` in the **initial filter** (before the first `|`) searches ALL indexed fields — use when you need to find text anywhere in the event. Dramatically faster than `message contains`. Only works before the first `|`; not valid in `| filter …` after a pipe, and not valid in Alerts.
    - **Empty filter (all events):** start the query with `|`, e.g. `| group ct=count() by event.type`.
 2. **Double-escape regex almost everywhere.** `src.process.cmdline matches "\\d+"`, `tgt.file.path matches '^C:\\\\Windows\\\\Temp\\\\[a-z]{8}\\.tmp$'`. The only place you don't double-escape is the `$"…"` shorthand (searches `message`).
-3. **Regex lazy quantifiers (`?`) are not supported.** The SDL regex engine does not support lazy (non-greedy) quantifiers: `.*?`, `.+?`, `[^x]*?` etc. all return HTTP 500 "Dangling meta character '?'". Use a negated character class instead: `[^"]*` in place of `.*?"`, `[^ ]*` in place of `.*? `, etc.
+3. **Regex lazy quantifiers (`?`) are not supported.** The SDL regex engine does not support lazy (non-greedy) quantifiers: `.*?`, `.+?`, `[^x]*?` etc. all return HTTP 500 "Dangling meta character '?'". Use a negated character class instead: `[^"]*` in place of `.*?"`, `[^ ]*` in place of `.*?`, etc.
 4. **After `columns` or `group`, previous fields are gone.** These commands create an entirely new record set. If you'll need a field later, carry it through: `group ct=count(), host=any(endpoint.name) by src.process.storyline.id` — don't expect `endpoint.name` to still be addressable after that `group` unless you aggregate it.
 5. **Subqueries can't go after `group`, `sort`, or `limit`.** And the subquery must itself produce the column named in the `in (...)` expression (via `columns` or `group`). `user in (action='login' | group 1 by user)` is valid; `user in (action='login')` is not.
 6. **`compare` and `transpose` must be the LAST command.** Put `sort` before `compare` if you want to order the non-shifted side.
@@ -114,7 +115,7 @@ These are where queries go wrong. Internalize them before writing.
 15. **Null-filter at the wrong stage: `filter x = null` before `x` is computed returns 500.** Use `filter !(x =*)` for is-null until after a `let`/`join`/`lookup` has produced `x`.
 16. **Coalesce-style fallback uses bare-field truthy test, NOT `(field = *) ? a : b`.** PQ has no `coalesce()` / `ifnull()` / `nvl()`. To pick the first non-null of several fields inside a `let`, chain bare-field ternaries — they evaluate the field's truthiness directly:
 
-    ```
+    ```text
     | let user_id = actor.user.email_addr
                   ? actor.user.email_addr
                   : (actor.user.name ? actor.user.name : src.process.user)
@@ -124,7 +125,7 @@ These are where queries go wrong. Internalize them before writing.
 17. **`if(...)` is not a function in aggregates.** `sum(if(cond, 1, 0))` returns 500. Use `count(<predicate>)` instead — `count(severity_id == 5)` evaluates the predicate per row and sums the truthy ones. Same for any "count where X" semantic.
 18. **Always filter `field=*` before projecting or inspecting any field.** `| limit N | columns field` returns the first N events regardless of whether the field is populated — most rows will be null. Add `field=*` to the initial filter to scope to events that actually carry the field:
 
-    ```
+    ```text
     // Wrong — returns nulls; message may not be present on most events
     dataSource.name='FortiGate' | limit 3 | columns message
 
@@ -160,7 +161,7 @@ The primary execution path is the Long Running Query API. It is async (launch +
 
 **Three calls, in order:**
 
-```
+```text
 POST   https://<console>.sentinelone.net/sdl/v2/api/queries          -> launch, returns {id, ...}
 GET    https://<console>.sentinelone.net/sdl/v2/api/queries/{id}?lastStepSeen=N   -> poll every 1-2s
 DELETE https://<console>.sentinelone.net/sdl/v2/api/queries/{id}     -> cancel when done
@@ -273,7 +274,7 @@ For all three rule types (API shapes, the correlation `correlationParams` block,
 
 Hunt: PowerShell that made an outbound connection to a non-RFC1918 IP in the last 24 hours, with command line.
 
-```
+```text
 src.process.name contains 'powershell' dst.ip.address = *
 | let is_private = net_rfc1918(dst.ip.address)
 | filter is_private = false
@@ -287,7 +288,6 @@ src.process.name contains 'powershell' dst.ip.address = *
 
 Notice: filter early (`dst.ip.address = *` prunes events without a destination IP), `net_rfc1918` is the right way to split internal vs external (don't hand-roll CIDRs), `array_agg_distinct` caps the array so the row stays small, `any(src.process.cmdline)` grabs a representative cmdline since we're collapsing per storyline.
 
-
 ## PowerQuery execution via s1-secops-mcp
 
 PowerQuery execution uses the `s1-secops-mcp` MCP tools, which bypass the Cowork sandbox
diff --git a/plugins/s1-secops-skills/skills/sdl-api/README.md b/plugins/s1-secops-skills/skills/sdl-api/README.md
index 3998c90..b5c252b 100644
--- a/plugins/s1-secops-skills/skills/sdl-api/README.md
+++ b/plugins/s1-secops-skills/skills/sdl-api/README.md
@@ -12,7 +12,7 @@ cp -r sentinelone-sdl-api ~/.claude/skills/
 
 In Cowork/Claude Code, the path is:
 
-```
+```text
 /sessions/<session>/mnt/.claude/skills/sentinelone-sdl-api/
 ```
 
diff --git a/plugins/s1-secops-skills/skills/sdl-api/SKILL.md b/plugins/s1-secops-skills/skills/sdl-api/SKILL.md
index 8806ede..e64b851 100644
--- a/plugins/s1-secops-skills/skills/sdl-api/SKILL.md
+++ b/plugins/s1-secops-skills/skills/sdl-api/SKILL.md
@@ -265,7 +265,6 @@ There is no undo. Configuration files are versioned but accidental deletes still
 
 For complex hunts and detection authoring use the `sentinelone-powerquery` skill for the query body, then call `c.power_query()` from this skill to execute it. For Mgmt Console resources (agents, threats, sites) use `sentinelone-mgmt-console-api`.
 
-
 ## Using s1-secops-mcp tools for direct SDL operations
 
 If a direct bash call to sdl_client.py fails with a proxy error, use the s1-secops-mcp MCP
diff --git a/plugins/s1-secops-skills/skills/sdl-dashboard/README.md b/plugins/s1-secops-skills/skills/sdl-dashboard/README.md
index 319b84f..76bdbbf 100644
--- a/plugins/s1-secops-skills/skills/sdl-dashboard/README.md
+++ b/plugins/s1-secops-skills/skills/sdl-dashboard/README.md
@@ -12,7 +12,7 @@ cp -r sentinelone-sdl-dashboard ~/.claude/skills/
 
 In Cowork/Claude Code, the path is:
 
-```
+```text
 /sessions/<session>/mnt/.claude/skills/sentinelone-sdl-dashboard/
 ```
 
diff --git a/plugins/s1-secops-skills/skills/sdl-dashboard/SKILL.md b/plugins/s1-secops-skills/skills/sdl-dashboard/SKILL.md
index e8a089e..056251e 100644
--- a/plugins/s1-secops-skills/skills/sdl-dashboard/SKILL.md
+++ b/plugins/s1-secops-skills/skills/sdl-dashboard/SKILL.md
@@ -31,7 +31,7 @@ This workflow is mandatory for every new or modified dashboard. Steps 0, 1, and
 
    **`validate_dashboard.py` MUST be run as a background process** — at ~10s per panel, a 30-panel dashboard takes 5 minutes; a 60-panel dashboard takes 10-30 minutes. Both exceed the MCP timeout. Start it with `python3 scripts/validate_dashboard.py ... > /tmp/validate_out.txt 2>&1 &`, confirm the PID, then poll `len(json.load(open(evidence_json)))` vs the expected panel count in short separate calls. The script persists results after every panel (idempotent), so a cancelled poll never loses work. When a `stacked_bar` or `line` panel using `| transpose` returns 0 rows in validation, cross-check whether the corresponding number panel for the same source shows data — if it does, the empty result is a V1-API artefact, not a broken query. Document it in the Appendix as confirmed false-empty and do not remove the panel.
 
-8. **Screenshot review with the user (MANDATORY).** API validation proves each panel's query returns rows; it does NOT prove the panel RENDERS. Render-only failures happen in the browser, not the API, so `validate_dashboard.py` cannot see them: a panel showing "Couldn't load content", a markdown tile showing "Untitled", a number reading "34 principals" under a title that already says principals, an empty chart, or a broken legend. After EVERY deploy, ALWAYS ask the user to open the dashboard and send screenshots of each tab, then read them, diagnose each visual defect, fix the JSON, and re-deploy, without waiting to be asked. Prompt explicitly, e.g.: "The dashboard is deployed at /dashboards/<name>. Please open it and send screenshots of each tab so I can catch any render-only issues and fix them automatically." Treat this as part of deployment, not optional polish. Fixes for the common render-only defects are in the **Quick triage** table.
+8. **Screenshot review with the user (MANDATORY).** API validation proves each panel's query returns rows; it does NOT prove the panel RENDERS. Render-only failures happen in the browser, not the API, so `validate_dashboard.py` cannot see them: a panel showing "Couldn't load content", a markdown tile showing "Untitled", a number reading "34 principals" under a title that already says principals, an empty chart, or a broken legend. After EVERY deploy, ALWAYS ask the user to open the dashboard and send screenshots of each tab, then read them, diagnose each visual defect, fix the JSON, and re-deploy, without waiting to be asked. Prompt explicitly, e.g.: "The dashboard is deployed at `/dashboards/<name>`. Please open it and send screenshots of each tab so I can catch any render-only issues and fix them automatically." Treat this as part of deployment, not optional polish. Fixes for the common render-only defects are in the **Quick triage** table.
 
 ## Pre-authoring discovery
 
@@ -39,7 +39,7 @@ Different tenants connect different data sources, and even the same tenant drift
 
 ### 1. Enumerate connected data sources every session
 
-```
+```text
 | group UniqueDataSourceNames = array_agg_distinct(dataSource.name)
 | limit 1000
 ```
@@ -86,7 +86,7 @@ If a field is only present in `raw_data`, it can still be filtered via a full-te
 
 A single `event.type` value frequently bundles multiple distinct event kinds (delivery-time vs click-time, scheduled vs on-demand, inbound vs outbound, policy-event vs detection-event). The discriminator field, often named `creationMethod`, `messageType`, `triggerType`, `disposition`, etc., may or may not be promoted to the top level. Run an exploration query before authoring count panels:
 
-```
+```text
 dataSource.name='<source>' event.type='<type>'
 | group hits=count() by <candidate-discriminator>
 | sort -hits
@@ -99,7 +99,7 @@ If the same `event.type` row repeats with different discriminator values, that s
 
 Before including any field as a grouping column in a table panel, confirm it is non-null for that specific `event.type`. A column that is null for all rows produces an empty column in the rendered table with no error. The check is one query:
 
-```
+```text
 dataSource.name='<source>' event.type='<type>' <field>=*
 | group count=count()
 | limit 1
@@ -155,19 +155,24 @@ The patterns below produce HTTP 500s or silent renderer failures on current SDL
 Network device logs (FortiGate, Palo Alto, etc.) emit KV pairs where values are wrapped in double quotes: `app="HTTPS.BROWSER" appcat="Web.Client"`. The `| parse` format string is itself double-quoted, so you cannot embed a `"` to match the wrappers. The workaround is two passes:
 
 **Pass 1** — capture the whole non-whitespace token including its surrounding quotes:
-```
+
+```text
 | parse "app=$raw_app{regex=\\S+}$" from message
 ```
+
 This extracts `"HTTPS.BROWSER"` (with quotes) into `raw_app`.
 
 **Pass 2** — extract the clean value by matching the alphanumeric content, which skips the leading `"`:
-```
+
+```text
 | parse "$app_name{regex=[A-Z0-9./_-]+}$" from raw_app
 ```
+
 This produces `HTTPS.BROWSER` (no quotes) in `app_name`.
 
 Full example for an app-ctrl panel:
-```
+
+```text
 dataSource.name='FortiGate' event.type='app-ctrl'
 | parse "app=$raw_app{regex=\\S+}$" from message
 | parse "appcat=$raw_cat{regex=\\S+}$" from message
@@ -210,7 +215,7 @@ Rules:
 
 When a field needed for the panel is buried inside `raw_data` rather than parsed to a structured column, the only filter is a full-text predicate against `raw_data`. Example:
 
-```
+```text
 dataSource.name='<source>' event.type='<type>' '<json-snippet>'
 ```
 
@@ -260,6 +265,7 @@ When two semantically distinct event populations exist within the same `event.ty
 A dashboard is a JSON object (SDL also accepts unquoted keys — JavaScript-literal format). Three top-level shapes:
 
 ### Single-tab dashboard
+
 ```json
 {
   "duration": "4h",
@@ -269,6 +275,7 @@ A dashboard is a JSON object (SDL also accepts unquoted keys — JavaScript-lite
 ```
 
 ### Multi-tab dashboard
+
 ```json
 {
   "configType": "TABBED",
@@ -299,6 +306,7 @@ A dashboard is a JSON object (SDL also accepts unquoted keys — JavaScript-lite
 Every panel is an object inside `graphs`. The `graphStyle` property picks the panel type.
 
 ### Layout
+
 Every panel **must** have explicit `x`, `y`, `w`, `h` in its `layout` object. Dashboards with many panels (observed at 18+) where `x`/`y` are omitted can hang the browser renderer indefinitely — the auto-layout pass appears to loop on collision detection when panels stack at the implicit (0,0) origin. The symptom is the browser tab becoming unresponsive before any query fires.
 
 ```json
@@ -344,6 +352,7 @@ Best for: event rates over time, multi-metric comparison, trend lines.
 ```
 
 For a **PowerQuery-driven** line chart (needed for complex grouping):
+
 ```json
 {
   "title": "Login attempts over time",
@@ -372,6 +381,7 @@ Best for: category breakdowns over time, per-group counts.
 ```
 
 For a **grouped-data X-axis** (not time):
+
 ```json
 {
   "graphStyle": "stacked_bar",
@@ -436,10 +446,11 @@ Query must reduce to a single number (use `group count()`, `estimate_distinct()`
 ```
 
 > **No "millions" (or thousands) number format.** SDL number panels scale only via `format: "auto"` (which may render K/M/B); there is no explicit millions option. To force a specific unit, divide in the query and label the title: `... | group ev = count() | let Events_M = ev / 1000000 | columns Events_M | limit 1` with title `"Total Events (M)"`. Always carry the unit (GiB, events, min, count, ratio) in the title or `suffix` — a number panel renders only a bare value.
-
+>
 > **Options — stick to the minimal set.** Production reference dashboards only set `{format, precision, suffix}`. Fields like `backgroundColor` and `color` are documented in some places but are not consistently honoured by the renderer — at best silently ignored, at worst the panel renders blank or hangs. Do not add them until tested against the specific tenant.
 
 With trend indicator (S-25.1.5+):
+
 ```json
 {
   "graphStyle": "number",
@@ -502,6 +513,7 @@ A 2D matrix where color intensity is the aggregated value of each cell. As of S-
 | `"linkConfig"` | `{ "template": "<url>" }` | Make cells click-through to a URL, e.g. a pre-filtered Unified Alerts view. |
 
 **Categorical heatmap example** (alerts severity x product, data labels + click-through, live-validated):
+
 ```json
 {
   "title": "Alerts by severity and product",
@@ -520,6 +532,7 @@ A 2D matrix where color intensity is the aggregated value of each cell. As of S-
 ```
 
 **Time heatmap example** (classic, x-axis = time, requires `timebucket()` and the anchor column named `timestamp`):
+
 ```json
 {
   "title": "Identity Logon Activity by User [heatmap]",
@@ -539,6 +552,7 @@ A 2D matrix where color intensity is the aggregated value of each cell. As of S-
 **Pre-filter to top-N categories before transpose:** After `transpose`, any (category, anchor) cell with no events becomes null. To keep the heatmap readable and avoid sparse null columns, use `| filter <field> in (...)` to pin the transposed set to the most active values. Find candidates first: `| group count=count() by <field> | sort -count | limit 15 | columns <field>`.
 
 **When to use heatmap:**
+
 - Categorical x-axis: alerts by severity x product or asset category, detections by OS x technique, any (category x category) count matrix.
 - Time x-axis: login activity per user over time (insider threat, off-hours spikes), hourly event volume across sources or endpoints, day-of-week x hour activity patterns.
 
@@ -571,7 +585,7 @@ Accepts GitHub-flavored Markdown. Good for section headers, links, or explanatio
 > `"content": "..."` is created successfully and renders as a **blank tile with
 > no error** — the API accepts it, the UI just has nothing to display. Always
 > use `"markdown": "..."`.
-
+>
 > **Title duplication:** the SDL UI renders the `"title"` field as a header above the panel body. Do NOT repeat the same heading inside the `"markdown"` body. A common mistake is setting `"title": "## Policy Enforcement"` (with the `##` markdown prefix) and then starting the markdown body with `## Policy Enforcement\nDescription...` — this produces the heading twice. Keep the `title` field as plain text and put only the descriptive prose (no repeated heading) inside `"markdown"`. Also: a markdown panel with NO `title` key renders an "Untitled" header in S-26.1 (observed live), so always set a short plain-text `title`.
 
 ```json
@@ -705,6 +719,7 @@ Pre-quoting rule: if the field requires string matching, embed single quotes in
 ```
 
 For user-friendly dropdown labels:
+
 ```json
 { "name": "region",
   "values": [
@@ -715,6 +730,7 @@ For user-friendly dropdown labels:
 ```
 
 Hide a parameter from the UI (declared but not displayed):
+
 ```json
 { "name": "base_search", "options": { "display": "hidden" }, "defaultValue": "dataSource.name='MySource'" }
 ```
@@ -763,7 +779,8 @@ string can be case-mixed (`Critical` and `CRITICAL` both appear) — see
 `sentinelone-powerquery/references/pitfalls.md` for handling.
 
 ### EDR / XDR telemetry (endpoint events from `dataSource.name='SentinelOne'`)
-```
+
+```text
 dataSource.category = 'security'
 event.category in ('process', 'file', 'ip', 'dns', 'indicators', 'logins', 'url', 'registry')
 ```
@@ -772,7 +789,8 @@ event.category in ('process', 'file', 'ip', 'dns', 'indicators', 'logins', 'url'
 `indicator.name`, `agent.uuid`, `endpoint.name`, `src.process.{user,cmdline,image.path}`.
 
 ### Third-party sources
-```
+
+```text
 dataSource.vendor = 'Microsoft'        // O365, Azure AD
 dataSource.name = 'FortiGate'          // field namespaces differ per event.type — validate each type separately before authoring panels
                                        // traffic:   src_endpoint.ip, dst_endpoint.ip, app_name (populated), unmapped.action, traffic.bytes_out/in
@@ -790,27 +808,32 @@ field namespaces vary by parser version and tenant.
 ### Common PowerQuery patterns for panels
 
 **Top-N table** (always add a bar column with `showBarsColumn: "true"`):
-```
+
+```text
 event.category='indicators' | group count=count() by indicator.name | sort -count | limit 20
 ```
 
 **Timeline line chart** (use `timebucket` + `transpose`):
-```
+
+```text
 event.type='process' | group count=count() by timestamp=timebucket('1h'), endpoint.os | transpose endpoint.os on timestamp
 ```
 
 **Single number** (estimate_distinct for cardinality):
-```
+
+```text
 | group estimate_distinct(agent.uuid)
 ```
 
 **Geo enrichment**:
-```
+
+```text
 | group count=count() by country=geo_ip_country(src.ip.address) | sort -count
 ```
 
 **URL deep-link in table**:
-```
+
+```text
 | let Threat_URL = format("https://your-console.sentinelone.net/incidents/threats/%s/overview", threat_id)
 | columns Computer=data.computer_name, Threat_URL, Path=data.file_path
 ```
@@ -924,21 +947,26 @@ Dashboard panels run their queries in the SDL console's built-in rendering engin
 ### 1. Use `net_rfc1918()` — never hand-roll CIDR regex
 
 **Slow (avoid):**
-```
+
+```text
 | let rfc1918 = not (dst.ip.address matches '((127\\..*)|(192\\.168\\..*)|(10\\..*)|(172\\.1[6-9]\\..*)|(172\\.2[0-9]\\..*)|(172\\.3[0-1]\\..*)).*')
 | filter rfc1918 = true
 ```
+
 **Fast:**
-```
+
+```text
 dst.ip.address = *
 | let is_external = not net_rfc1918(dst.ip.address)
 | filter is_external = true
 ```
+
 The built-in function is evaluated natively; the regex is evaluated as a string per event.
 
 ### 2. Always add `| limit 1` to number panels
 
 Number panels reduce to a single row. Without `| limit 1`, the engine continues scanning after finding the answer. Always terminate:
+
 ```json
 "query": "dataSource.name='ActivityFeed' activity_type in (\"133\",\"134\") | group count() | limit 1"
 ```
@@ -946,6 +974,7 @@ Number panels reduce to a single row. Without `| limit 1`, the engine continues
 ### 3. Add explicit `| limit N` to every table panel
 
 Unbounded tables force a full scan. Always cap results:
+
 - Detail tables (time-sorted raw events): `| limit 200`
 - Aggregated top-N tables: `| limit 20` or `| limit 25`
 - Donut/pie panels: `| sort -count | limit 10`
@@ -954,7 +983,7 @@ Unbounded tables force a full scan. Always cap results:
 
 `field=*` is the canonical SDL presence predicate: it matches any event where the field is present and non-null. Accuracy note (live-verified 2026-07-29 via the LRQ API): `field != null` returned results identical to `field=*`; the earlier claim that it hard-errors or compares against the literal string "null" was NOT reproducible on LRQ. The console/dashboard renderer engine remains unverified for `!= null`, so `field=*` stays the REQUIRED form in all dashboard JSON, rule bodies, and examples:
 
-```
+```text
 // Required: canonical presence check
 dataSource.name='alert' severity_id=*
 | group count=count() by severity_id
@@ -969,7 +998,7 @@ This applies in the initial filter predicate (before the first `|`) and in `| fi
 
 After a `| group count=count() by ...`, SDL may produce rows with `count=0` for sparse buckets (especially after `transpose` or when grouping over a large key space). These zero rows render as empty cells in heatmaps and false entries in tables. Filter them out:
 
-```
+```text
 | group EventCount=count() by user_name=user.name, timestamp=timebucket('1h')
 | filter EventCount > 0
 ```
@@ -980,7 +1009,7 @@ Apply the same pattern to any aggregated numeric field you're visualising: `| fi
 
 `| columns` removes every field not listed. Any `| sort` placed after `| columns` that references a field not in the projected set is operating on a non-existent field and silently fails or hangs the panel (bullet panels are especially prone to this):
 
-```
+```text
 // Wrong — severity_id is gone after | columns, sort fails silently
 | group value=count(), target=..., label=... by severity_id
 | columns value, target, label
@@ -997,7 +1026,8 @@ This affects any pipeline that projects away the sort key: bullet panels, donut
 ### 7. Use `event.category = *` not `event.category != ''`
 
 `!= ''` requires evaluating the field value as a string comparison. `= *` is a cheaper is-not-null predicate:
-```
+
+```text
 dataSource.category = 'security' event.category = *
 | group count=count() by timestamp=timebucket("1 day"), event.category
 ```
@@ -1022,7 +1052,8 @@ For a 24h dashboard, `'10m'` (144 points) can work for low-cardinality single-se
 ### 6. Push filters early — before the first pipe
 
 The initial filter (before the first `|`) is evaluated as an index predicate. Conditions placed there are far cheaper than `| filter` commands applied after a full scan:
-```
+
+```text
 // Good — index-level filter
 event.category = 'ip' event.network.direction = 'OUTGOING' dataSource.category = 'security'
 | group count=count() by dst.ip.address | sort -count | limit 20
@@ -1047,7 +1078,7 @@ SDL/Scalyr column types are locked at first ingest. A field that *should* be num
 
 **Failsafe pattern for every dashboard panel that does numeric work:**
 
-```
+```text
 dataSource.name='alert' severity_id=*
 | let sev = number(severity_id)
 | filter sev >= 4
@@ -1055,7 +1086,7 @@ dataSource.name='alert' severity_id=*
 | sort sev
 ```
 
-```
+```text
 dataSource.name='FortiGate' unmapped.action='close'
 | let bytes_out_n = number(traffic.bytes_out)
 | let bytes_in_n  = number(traffic.bytes_in)
@@ -1161,11 +1192,11 @@ This is the same V1-query schema-discovery pattern from the `sentinelone-sdl-api
 
 1. **Log out and log back in.** The SDL UI caches panel render state in the session. After a `put_file`, the browser can serve a stale render from the prior version even though the underlying config changed. A fresh login clears session state completely. Try this before any config investigation when the query is confirmed to return data.
 2. **Hard refresh** (`Ctrl+Shift+R` / `Cmd+Shift+R`). Eliminates cached state from a previous broken version. Resolves ~10% of "still hung" reports.
-2. **Check dev-tools network tab.** If panel queries are NOT being fired, the renderer is stuck before any HTTP call. Cause is structural (layout/options/JSON parse), not query performance. If queries ARE firing, record the slowest and move to step 3.
-3. **Run the slow panel's query in isolation via the V1 API.** If it returns fast, the issue is renderer-side (column names, `transpose`, panel options). If it is slow, optimise the query.
-4. **Reduce panel count by 50%.** If the dashboard now loads, the issue was concurrency or memory in the renderer. Add panels back 25% at a time until a regression isolates the offender.
-5. **Diff against a working reference dashboard in the same tenant.** `list_files /dashboards/`, `get_file` on a working dashboard, compare top-level keys, panel `layout` shape, `options` keys, and `graphStyle`-specific fields. Working dashboards in the same tenant are more reliable ground truth than any external documentation, because rendering rules drift between SDL releases.
-6. **Roll back.** Always keep a backup of the prior dashboard JSON before `put_file`-ing a new version. Restore via `put_file(expected_version=current)` to unblock analysts while iterating offline.
+3. **Check dev-tools network tab.** If panel queries are NOT being fired, the renderer is stuck before any HTTP call. Cause is structural (layout/options/JSON parse), not query performance. If queries ARE firing, record the slowest and move to step 3.
+4. **Run the slow panel's query in isolation via the V1 API.** If it returns fast, the issue is renderer-side (column names, `transpose`, panel options). If it is slow, optimise the query.
+5. **Reduce panel count by 50%.** If the dashboard now loads, the issue was concurrency or memory in the renderer. Add panels back 25% at a time until a regression isolates the offender.
+6. **Diff against a working reference dashboard in the same tenant.** `list_files /dashboards/`, `get_file` on a working dashboard, compare top-level keys, panel `layout` shape, `options` keys, and `graphStyle`-specific fields. Working dashboards in the same tenant are more reliable ground truth than any external documentation, because rendering rules drift between SDL releases.
+7. **Roll back.** Always keep a backup of the prior dashboard JSON before `put_file`-ing a new version. Restore via `put_file(expected_version=current)` to unblock analysts while iterating offline.
 
 ---
 
@@ -1173,7 +1204,7 @@ This is the same V1-query schema-discovery pattern from the `sentinelone-sdl-api
 
 Run this before every `put_file`. Items marked **[scripted]** are checked automatically by `scripts/panel_safety_check.py`.
 
-```
+```text
 PRE-AUTHORING
 [ ] Live data-source enumeration confirms every dataSource.name used by the dashboard exists
 [ ] V1-query schema discovery run for every source; field list saved for the session
@@ -1244,7 +1275,6 @@ POST-DEPLOY (MANDATORY)
 - **Use `estimate_distinct()`** for cardinality counts — exact distinct is expensive on large datasets.
 - **Add a markdown panel** to each tab explaining what it covers — this helps both users and future editors understand the dashboard at a glance.
 
-
 ## Sandbox proxy blocked? Use Desktop Commander
 
 Dashboard deployment uses `sdl_client.py` from the `sentinelone-sdl-api` skill, which
diff --git a/plugins/s1-secops-skills/skills/sdl-log-parser/SKILL.md b/plugins/s1-secops-skills/skills/sdl-log-parser/SKILL.md
index c035aa7..b58f335 100644
--- a/plugins/s1-secops-skills/skills/sdl-log-parser/SKILL.md
+++ b/plugins/s1-secops-skills/skills/sdl-log-parser/SKILL.md
@@ -53,19 +53,19 @@ These are the DSL traps that cost the most iteration cycles when authoring parse
 
 Two related queryability rules (not DSL traps, but they matter for any consumer of the parser):
 
-6. **The raw `message` field is preserved on every event regardless of parser activity.** SDL never lets a parser overwrite `message`; the raw event body always survives. So `parse "field=$x$" from message` queries continue to work alongside the typed columns the parser produces. This is the backward-compat escape hatch during a parser rollout.
-7. **When two ingest paths produce OCSF for the same source, the schema can drift.** A common case: upstream collector (Observo etc.) flattens `type=traffic, subtype=forward` to just `event.type='forward'` while the downstream parser keeps both fields populated. Consumers (dashboards, STAR rules, hunts) should write subtype filters as `(event.subtype='forward' OR event.type='forward')` until the rollout fully converges.
-8. **Trailing `.*` at the END of a format string suffers the leading-`.*`-strip too.** A field marker like `$process.cmd_line{regex=.*}$` placed at the end of a format string captures the EMPTY STRING. The SDL stripping rule applies whether `.*` starts the regex or IS the entire regex. Use `[\\s\\S]+` (one-or-more) or `[\\s\\S]*` (zero-or-more) for "everything that remains on the line" semantics — those forms don't begin with `.` and survive intact.
-9. **Regex alternation matches in DECLARATION ORDER, not longest-leftmost.** `regex=CRON|CROND` is a bug — `CRON` matches the prefix of `CROND` and leaves `D` dangling. Put longer alternatives first: `regex=CROND|CRON|crond|cron`. Applies to named patterns, inline `{regex=...}`, and any other alternation. When alternatives share a prefix, sort by length descending.
-10. **gron expands arrays into `[N]`-indexed attributes; index with `[N]`, NOT `.N.`** Do not believe "gron drops arrays." `$unmapped.{parse=gron}$` emits one queryable attribute per array leaf: `unmapped.signInEventTypes[0]`, `unmapped.additionalDetails[0].key`, `unmapped.targetResources[0].modifiedProperties[0].newValue`. The trap that makes arrays look dropped is querying with dot-index (`unmapped.targetResources.0.id` → null); the real key is bracket-indexed (`unmapped.targetResources[0].id`). gron/dottedJson = each element its own attribute (use for "extract every field"); `strict*` = array kept as one JSON value for `array_from_json()`. Scalar/object flattening is identical across all three. Caveat: a raw PowerQuery `columns`/`filter` clause can't type the `[`, so validate `[N]` fields with `powerquery_schema_discover`, not a `columns` projection. To lift a whole array subtree to OCSF, `rename_tree { from: "unmapped.targetResources[0].modifiedProperties", to: "entity.data" }`. Tenant-validated 2026-06-22 (Microsoft Entra ID). See `references/parse-directives.md`.
-11. **`copy` first-of-N treats an empty string `""` as "exists" and lets it win.** `copy {from: ["userId","servicePrincipalId"]}` where `userId` is `""` copies the empty string, not the fallback — silently breaking identity-coalesce (e.g. service-principal / managed-identity sign-ins whose `userPrincipalName`/`userId` are empty but `servicePrincipalName`/`servicePrincipalId` hold the identity). Fix by dropping empty strings upstream (the collector/Lua serializer should omit `""` values), or `drop` the empty source before the `copy`. Tenant-validated 2026-06-22.
-12. **On a LIVE source, a "still broken" event is usually pre-propagation, not a parser bug.** Parser activation is ~3-5 min and a continuously-ingesting source keeps producing events through the OLD version during that window; SDL never re-parses historical events. Bump `metadata.version` every deploy and confirm via `| group count() by metadata.version` (or `powerquery_schema_discover`) which version parsed a given event before chasing a "bug." Related: if the parser sets event time from a log field, events are stamped at the log's own time, so widen validation query windows (`24h`/`7d`) or filter by a nonce field instead of time, or you get zero rows and a false negative.
+1. **The raw `message` field is preserved on every event regardless of parser activity.** SDL never lets a parser overwrite `message`; the raw event body always survives. So `parse "field=$x$" from message` queries continue to work alongside the typed columns the parser produces. This is the backward-compat escape hatch during a parser rollout.
+2. **When two ingest paths produce OCSF for the same source, the schema can drift.** A common case: upstream collector (Observo etc.) flattens `type=traffic, subtype=forward` to just `event.type='forward'` while the downstream parser keeps both fields populated. Consumers (dashboards, STAR rules, hunts) should write subtype filters as `(event.subtype='forward' OR event.type='forward')` until the rollout fully converges.
+3. **Trailing `.*` at the END of a format string suffers the leading-`.*`-strip too.** A field marker like `$process.cmd_line{regex=.*}$` placed at the end of a format string captures the EMPTY STRING. The SDL stripping rule applies whether `.*` starts the regex or IS the entire regex. Use `[\\s\\S]+` (one-or-more) or `[\\s\\S]*` (zero-or-more) for "everything that remains on the line" semantics — those forms don't begin with `.` and survive intact.
+4. **Regex alternation matches in DECLARATION ORDER, not longest-leftmost.** `regex=CRON|CROND` is a bug — `CRON` matches the prefix of `CROND` and leaves `D` dangling. Put longer alternatives first: `regex=CROND|CRON|crond|cron`. Applies to named patterns, inline `{regex=...}`, and any other alternation. When alternatives share a prefix, sort by length descending.
+5. **gron expands arrays into `[N]`-indexed attributes; index with `[N]`, NOT `.N.`** Do not believe "gron drops arrays." `$unmapped.{parse=gron}$` emits one queryable attribute per array leaf: `unmapped.signInEventTypes[0]`, `unmapped.additionalDetails[0].key`, `unmapped.targetResources[0].modifiedProperties[0].newValue`. The trap that makes arrays look dropped is querying with dot-index (`unmapped.targetResources.0.id` → null); the real key is bracket-indexed (`unmapped.targetResources[0].id`). gron/dottedJson = each element its own attribute (use for "extract every field"); `strict*` = array kept as one JSON value for `array_from_json()`. Scalar/object flattening is identical across all three. Caveat: a raw PowerQuery `columns`/`filter` clause can't type the `[`, so validate `[N]` fields with `powerquery_schema_discover`, not a `columns` projection. To lift a whole array subtree to OCSF, `rename_tree { from: "unmapped.targetResources[0].modifiedProperties", to: "entity.data" }`. Tenant-validated 2026-06-22 (Microsoft Entra ID). See `references/parse-directives.md`.
+6. **`copy` first-of-N treats an empty string `""` as "exists" and lets it win.** `copy {from: ["userId","servicePrincipalId"]}` where `userId` is `""` copies the empty string, not the fallback — silently breaking identity-coalesce (e.g. service-principal / managed-identity sign-ins whose `userPrincipalName`/`userId` are empty but `servicePrincipalName`/`servicePrincipalId` hold the identity). Fix by dropping empty strings upstream (the collector/Lua serializer should omit `""` values), or `drop` the empty source before the `copy`. Tenant-validated 2026-06-22.
+7. **On a LIVE source, a "still broken" event is usually pre-propagation, not a parser bug.** Parser activation is ~3-5 min and a continuously-ingesting source keeps producing events through the OLD version during that window; SDL never re-parses historical events. Bump `metadata.version` every deploy and confirm via `| group count() by metadata.version` (or `powerquery_schema_discover`) which version parsed a given event before chasing a "bug." Related: if the parser sets event time from a log field, events are stamped at the log's own time, so widen validation query windows (`24h`/`7d`) or filter by a nonce field instead of time, or you get zero rows and a false negative.
 
 ## When to use this skill
 
 Use this skill when the user wants to turn raw log text into structured SDL events. Common triggers:
 
-- "Write a parser for this <vendor> log."
+- "Write a parser for this `<vendor>` log."
 - "Why isn't `<field>` showing up after ingest?"
 - A pasted log line — CEF, syslog, JSON-per-line, key=value, multi-line, vendor-specific.
 - Edits to an existing parser ("add a rewrite that masks the password", "tag every event with `dataset=fortinet`").
@@ -202,7 +202,7 @@ A parser file is augmented JSON (unquoted keys allowed, `//` and `/* */` comment
 
 ## Field-matcher syntax inside a format string
 
-```
+```bash
 $fieldName=patternName{parse=...}{regex=...}{attrWhitelist=...}{attrBlacklist=...}{timezone=...}$
 ```
 
@@ -213,7 +213,7 @@ Rules that bite people often:
 - Two adjacent `$a$$b$` with no delimiter between them require a pattern or regex on `$a$` so it knows when to stop.
 - `message` is reserved — it's the raw event text. You cannot capture into `message` from a format. You *can* `discardAttributes: ["message"]` to drop it.
 - A literal `$` in the log requires `\$$` (escape the dollar, then close the field).
-- Any space in the format matches `\s+`. To match a single literal space use `\\ ` (backslash-space).
+- Any space in the format matches `\s+`. To match a single literal space use `\\` (backslash-space).
 
 For the full directive list see `references/syntax.md` and `references/parse-directives.md`.
 
@@ -230,7 +230,7 @@ When you've identified the shape of the source log, jump straight to the canonic
 | CEF over syslog | `community/generic_access_logs-latest/` (or `examples/01-cef-over-syslog.json`) | Pipe-delimited header + KV extension |
 | LEEF over syslog | `community/leef_template_logs-latest/` | Multi-format header + KV body |
 | Pure key=value freeform | `sentinelone/marketplace-fortinetfortigate-latest/` | `repeat: true` catch-all, attrBlacklist, observables array |
-| Key=value with record-type fan-out to many OCSF classes | `examples/12-linux-auditd-ocsf.json` | ` type=`-anchored record-type capture (avoids the `nametype=` collision), KV catch-all, v1 first-match-wins mappings fanning one source to Process 1007 / File 1001 / Auth 3002 / Finding 2004 / Network 4001, EXECVE arg-vector → `process.cmd_line` via `computeFields` `replace()` |
+| Key=value with record-type fan-out to many OCSF classes | `examples/12-linux-auditd-ocsf.json` | `type=`-anchored record-type capture (avoids the `nametype=` collision), KV catch-all, v1 first-match-wins mappings fanning one source to Process 1007 / File 1001 / Auth 3002 / Finding 2004 / Network 4001, EXECVE arg-vector → `process.cmd_line` via `computeFields` `replace()` |
 | Positional CSV (100+ columns) | `sentinelone/marketplace-paloaltonetworksfirewall-latest/` | `commaSeparatedvalues`, `skipNumericConversion`, `attr[N]` indexed access in v1 mappings |
 | Positional space-delimited | `sentinelone/marketplace-awsvpcflowlogs-latest/` | `intermittentTimestamps`, fixed columns |
 | Pipe-delimited (non-CEF) | `sentinelone/marketplace-zscalerinternetaccess-latest/` | `pipeSeparatedValues` parse directive |
@@ -279,8 +279,8 @@ Apply in order — first match wins:
 - **The parser only sees the `message` field.** Ingest-time attributes (`app_id`, `cluster`, `region`, custom enrichments from collectors / HEC ingest) are NOT visible to format strings, format-level `discard:` filters, or `rewrites` regex inputs. They ARE visible to `mappings` predicates and `mappings` op `from:` paths since mappings run after parsing. Encode any sentinel you need to gate a format on into the message body or anchor on a string the message itself contains.
 - **v1 `mappings` is FIRST-MATCH-WINS.** Mapping entries are tried in declaration order; only the first entry whose `predicate` matches an event runs. A `predicate: "true"` catch-all therefore MUST go LAST in the list — placed first, it shadows every per-app/per-class entry below it (renames don't apply, class constants stay generic). Pattern: most specific predicates first, generic catch-all last. If two predicates would both fire on the same event and you want both effects, fold their transformations into a single entry. Tenant-validated April 2026.
 - **Fragment-format anchors must live INSIDE the prefix's regex, not as separate format-string text.** The format `$_pre{regex=[\s\S]*}$/actuator/health$_suf{regex=[\s\S]*}$` (greedy `[\s\S]*` followed by literal text in the format string between the field markers) does NOT match — the engine commits each field's regex independently and won't backtrack across literal-text gaps. Working form: `$_pre{regex=[\s\S]*\/actuator\/health}$$_suf{regex=[\s\S]*}$` (literal anchor inside the prefix's regex). Same shape as Phase-10 IOC formats (`[\s\S]*X-Forwarded-For=[\[]?` baked into the prefix).
-- **Greedy `[\s\S]*ANCHOR` lands on the LAST occurrence of `ANCHOR`.** That is the right behaviour when the captured token follows the rightmost anchor on the line (Dropwizard `[\s\S]*\[dw-[0-9]+ - ` is unique to the request-line bracket). It fails when the anchor is too generic: `[\s\S]*\[` followed by a `UT-[0-9]+` capture fails on any line whose last `[` is something else (e.g. `[#033[36m...]` ANSI brackets). Two fixes: (a) make the anchor multi-character and discriminating (`[\s\S]*\[UT-`), accepting that the literal is consumed by the anchor and your capture holds only the trailing portion (`$user_task_id_num{regex=[0-9]+}$`); or (b) use a lazy quantifier (`[\s\S]*?`) plus a discriminating literal when the FIRST occurrence is the right one.
-- **Greedy `[\\s\\S]*<anchor>` collides with COMPOUND field names that contain the anchor as a substring.** Anchoring a record-type capture on bare `type=` (`$_pre{regex=[\\s\\S]*type=}$$rectype{regex=[A-Z0-9_]+}$`) silently mis-fires on auditd PATH records because `nametype=NORMAL` (and `objtype=`) contain `type=` — the greedy match lands on the LAST `type=` (the one inside `nametype=`), captures `NORMAL`, and the rest of the format then fails. Fix: widen the anchor with the delimiter that precedes the REAL token, e.g. ` type=` with a leading space (`$_pre{regex=[\\s\\S]* type=}$`), since the real record-type follows a space (`audispd: type=PATH`) whereas `nametype=`/`objtype=` are preceded by a letter. General rule: when your anchor is a short substring that also appears inside longer field names, disambiguate it with a neighbouring delimiter. Tenant-validated 2026-06-01 on a Linux auditd parser: bare `type=` parsed SYSCALL/EXECVE/PROCTITLE but dropped every PATH record; ` type=` fixed all record types.
+- **Greedy `[\s\S]*ANCHOR` lands on the LAST occurrence of `ANCHOR`.** That is the right behaviour when the captured token follows the rightmost anchor on the line (Dropwizard `[\s\S]*\[dw-[0-9]+ -` is unique to the request-line bracket). It fails when the anchor is too generic: `[\s\S]*\[` followed by a `UT-[0-9]+` capture fails on any line whose last `[` is something else (e.g. `[#033[36m...]` ANSI brackets). Two fixes: (a) make the anchor multi-character and discriminating (`[\s\S]*\[UT-`), accepting that the literal is consumed by the anchor and your capture holds only the trailing portion (`$user_task_id_num{regex=[0-9]+}$`); or (b) use a lazy quantifier (`[\s\S]*?`) plus a discriminating literal when the FIRST occurrence is the right one.
+- **Greedy `[\\s\\S]*<anchor>` collides with COMPOUND field names that contain the anchor as a substring.** Anchoring a record-type capture on bare `type=` (`$_pre{regex=[\\s\\S]*type=}$$rectype{regex=[A-Z0-9_]+}$`) silently mis-fires on auditd PATH records because `nametype=NORMAL` (and `objtype=`) contain `type=` — the greedy match lands on the LAST `type=` (the one inside `nametype=`), captures `NORMAL`, and the rest of the format then fails. Fix: widen the anchor with the delimiter that precedes the REAL token, e.g. `type=` with a leading space (`$_pre{regex=[\\s\\S]* type=}$`), since the real record-type follows a space (`audispd: type=PATH`) whereas `nametype=`/`objtype=` are preceded by a letter. General rule: when your anchor is a short substring that also appears inside longer field names, disambiguate it with a neighbouring delimiter. Tenant-validated 2026-06-01 on a Linux auditd parser: bare `type=` parsed SYSCALL/EXECVE/PROCTITLE but dropped every PATH record; `type=` fixed all record types.
 - **Per-event parse limit is just under 50,000 chars.** Long events get truncated *before* parsing.
 - **Line groupers max 100,000 chars per joined event.** Above that, the grouper still emits but truncated.
 - **`intermittentTimestamps: true`** is required for logs (like MySQL general query log) that emit a timestamp only on the second they roll over. Without it, every line missing a timestamp gets the ingest time.
@@ -385,6 +385,7 @@ This pattern preserves first-match-wins semantics at the mapping-entry level (wh
 **Format-id-as-sentinel predicate**: `format: { id: "mySqlErrorLog", ... }` auto-sets a boolean-string field `mySqlErrorLog='true'` on events that matched that format. Use `predicate: "mySqlErrorLog='true'"` (v0) or `"mySqlErrorLog == 'true'"` (v1) to fan mapping entries out to sub-shapes. Quote the `'true'` — it's a string, not a bare boolean.
 
 **`mappings.version: 1` uses FIRST-MATCH-WINS, not all-match.** The first mapping block whose predicate matches consumes the event — no subsequent blocks run. This is the single most important structural constraint when using v1. Consequences:
+
 - A `predicate: "true"` unconditional block placed FIRST will fire on every event and prevent all per-app conditional blocks from ever executing. Always place the catch-all at the END.
 - `drop` / `drop_tree` transformations cannot be factored into a standalone unconditional block at the start and shared across per-app blocks. They must be duplicated into each per-app block. Verbose but correct.
 - **`rename` ops have the SAME problem as `drop`.** If you have a catch-all rename block at the end (typed-OCSF migration: srcip → src_endpoint.ip, devname → device.name, etc.) AND per-subtype `constant` blocks earlier (for activity_id fan-out), the catch-all rename NEVER fires for events that matched a per-subtype block — only the catch-all events get renamed. The per-subtype events keep raw vendor field names. To make the parser produce typed OCSF on ALL events, you MUST duplicate the rename list into every per-subtype block alongside its constants. Tenant-validated 2026-05-26 on FortiGate v1.1.0: with renames only in catch-all, event.subtype='forward' events had activity_id=6 from the constant block but src_endpoint.ip=null because the rename never ran; with renames duplicated into the per-subtype block, all fields populated. Pattern: each per-subtype block = its own constants + the full rename list. Verbose but correct.
@@ -489,14 +490,13 @@ Annotated, runnable parser definitions. Copy and adapt rather than starting from
 - `examples/06-alias.json` — One-line alias parser (`{ aliasTo: "json" }`) for the case where a built-in already does the job.
 - `examples/07-juniper-srx-rtflow-ocsf.json` — Juniper SRX RT_FLOW_SESSION_CREATE (structured-data syslog, RFC 5424-ish). Demonstrates: the **vendor-native capture + `mappings.rename` to OCSF** idiom end-to-end (source-address → `src_endpoint.ip`, nat-source-address → `connection_info.src_translated.ip`, etc.), repeating key/value catch-all on the structured-data body, `computeFields` for protocol-id → `connection_info.protocol_name` and encrypted YES/NO → `tls.is_encrypted`, Network Activity 4001 class tagging.
 - `examples/08-gron-capture-template.json` — The PARSER_TEMPLATE shape lifted from `ai-siem`: capture the entire event with `$unmapped.{parse=gron}$`, then do every rename/copy/cast/constant in a single v1 `mappings` block. Ideal scaffold for JSON-shaped sources when you want all OCSF work in one place.
-- `examples/12-linux-auditd-ocsf.json` — Linux auditd over syslog (`<pri> ts audispd: type=<REC> msg=audit(<epoch>:<id>): k=v ...`). Demonstrates: a ` type=`-anchored record-type + audit-event-id capture (with the leading space that avoids the `nametype=` collision), the KV catch-all, v1 first-match-wins `mappings` fanning the record type out to OCSF classes (SYSCALL/EXECVE/PROCTITLE → Process 1007, PATH/CWD → File 1001, USER_*/CRED_* → Authentication 3002, ANOM_*/AVC/SECCOMP → Detection Finding 2004, SOCKADDR → Network 4001), per-op `predicate` status/severity derivation, and cleaning the EXECVE arg vector into a readable `process.cmd_line` via a `computeFields` PowerQuery `replace()` (the `replace` mapper op is a no-op and there is no hex decode for `proctitle`).
+- `examples/12-linux-auditd-ocsf.json` — Linux auditd over syslog (`<pri> ts audispd: type=<REC> msg=audit(<epoch>:<id>): k=v ...`). Demonstrates: a `type=`-anchored record-type + audit-event-id capture (with the leading space that avoids the `nametype=` collision), the KV catch-all, v1 first-match-wins `mappings` fanning the record type out to OCSF classes (SYSCALL/EXECVE/PROCTITLE → Process 1007, PATH/CWD → File 1001, USER_*/CRED_* → Authentication 3002, ANOM_*/AVC/SECCOMP → Detection Finding 2004, SOCKADDR → Network 4001), per-op `predicate` status/severity derivation, and cleaning the EXECVE arg vector into a readable `process.cmd_line` via a `computeFields` PowerQuery `replace()` (the `replace` mapper op is a no-op and there is no hex decode for `proctitle`).
 - `examples/README.md` — When to pick which template.
 
 ## Summary of the contract you're holding
 
 When a user pastes a log and asks you to parse it, you owe them: (1) a parser file written against the SDL augmented-JSON DSL, (2) proof it actually extracts the right fields when ingested through the live SDL pipeline (not just the editor preview), (3) a clean handoff (final path, fields, sample query). The bundled references and examples exist so you don't have to hold the entire DSL in your head — load them as needed and reach for the templates first.
 
-
 ## Parser deployment via s1-secops-mcp
 
 Parser deployment and validation use the `s1-secops-mcp` MCP tools, which bypass the
@@ -505,7 +505,6 @@ and `hec_ingest` directly instead of falling back to the `sentinelone-sdl-api`
 skill scripts. The MCP tools run locally on your machine and make direct HTTPS calls
 to `*.sentinelone.net` without proxy interference.
 
-
 ## Per-app sentinel pattern (multi-tenant / multi-service parsers)
 
 Use this pattern when a single parser handles events from many distinct services or applications, each needing its own OCSF class assignment.
@@ -533,7 +532,7 @@ Use this pattern when a single parser handles events from many distinct services
 
 Run this periodically to catch new services that have accumulated in the catch-all:
 
-```
+```text
 dataSource.name = 'MySource' app_name = *
 | group count=count(), has_class=count(class_uid) by app_name
 | filter has_class == 0
diff --git a/plugins/s1-secops-skills/skills/sdl-solutions/README.md b/plugins/s1-secops-skills/skills/sdl-solutions/README.md
index 8a311de..5ee560b 100644
--- a/plugins/s1-secops-skills/skills/sdl-solutions/README.md
+++ b/plugins/s1-secops-skills/skills/sdl-solutions/README.md
@@ -14,14 +14,14 @@ primitive skill directly.
 
 | Solution | What it does | Guide | Playbook (Claude-facing) |
 |---|---|---|---|
-| Data source onboarding | Take a raw stream already reaching the tenant and operationalise it end to end: OCSF normalisation, device/user enrichment, dashboard, MITRE-mapped detections, and a SOC threat-response playbook | [guide](../docs/solutions/data-source-onboarding.md) | [`references/data-source-onboarding.md`](references/data-source-onboarding.md) |
-| Asset enrichment | Enrich raw logs with device, user, vulnerability, misconfiguration, alert, or cloud context from the Asset Inventory, at ingest or at query time | [guide](../docs/solutions/asset-enrichment.md) | [`references/asset-enrichment.md`](references/asset-enrichment.md) |
-| UEBA behavioural anomaly detection | Baseline ANY security or non-security signal per (action, principal) and detect z-score deviations: SPIKE, DROP, SILENT, NEW-BEHAVIOR. Run interactively to investigate, or deploy a baseline lookup, a scheduled PowerQuery rule, a nightly refresh, and a dashboard | [guide](../docs/solutions/ueba-anomaly-detection.md) | [`references/ueba-anomaly-detection.md`](references/ueba-anomaly-detection.md) |
-| Ingest health monitoring (per device) | Per-device ingest health (per firewall, endpoint, server) on a 7-day hour-of-day seasonal baseline rebuilt daily: volume spike/drop, ingest lag, ingest loss, and parser drift, with a dashboard and email notifications | [guide](../docs/solutions/ingest-health-monitoring.md) | [`references/ingest-health-monitoring.md`](references/ingest-health-monitoring.md) |
-| Custom detection exclusions | Suppress known-good noise in a STAR Custom Detection rule over a third-party or EDR source, for all three rule types: single-event and correlation rules carry the exclusion as an inline `AND NOT (...)` negative list; scheduled rules key against a CSV exclusion list (assets by IP/CIDR/host, or custom domains/users/values) via a lookup anti-join, with an exclusion-effectiveness dashboard | [guide](../docs/solutions/custom-detection-exclusions.md) | [`references/custom-detection-exclusions.md`](references/custom-detection-exclusions.md) |
-| Risk-Based Alerting (RBA) | Publish noisy-but-interesting observations as low-noise risk events into a `risk` index, accumulate risk per user/host object amplified by asset risk factors, and fire one high-fidelity alert on a 24h cumulative-score or 7d multi-MITRE-tactic threshold. Deploys contributors, a risk-factor table, a scheduled collector flow, four incident rules, and a dashboard | [guide](../docs/solutions/risk-based-alerting.md) | [`references/risk-based-alerting.md`](references/risk-based-alerting.md) |
-| Detection as Code (DaC) | Scaffold a Git + CI pipeline where detection engineers author rules as TOML, a pull request triggers validation and four-eyes review, and a merge syncs the changed rules to the Custom Detection Rule API. Covers single-event, correlation, and scheduled rule types, ships a zero-dependency TOML-to-API sync engine with idempotent create-or-update, and CI for GitHub Actions, GitLab CI, and Azure Pipelines | [guide](../docs/solutions/detection-as-code.md) | [`references/detection-as-code.md`](references/detection-as-code.md) |
-| Alert noise reduction | Find the (source, signature) pairs flooding the alert queue, separate ingested and already-actioned noise (block/drop/sinkhole/reset) from real S1 detections, recommend an ingestion-severity filter, auto-resolve already-mitigated alerts with a note, optionally preserve signal-worthy categories as one correlation rule, and ship a noise-vs-signal dashboard. Product/source/signature/action values are discovered live; nothing is hardcoded | [guide](../docs/solutions/alert-noise-reduction.md) | [`references/alert-noise-reduction.md`](references/alert-noise-reduction.md) |
+| Data source onboarding | Take a raw stream already reaching the tenant and operationalise it end to end: OCSF normalisation, device/user enrichment, dashboard, MITRE-mapped detections, and a SOC threat-response playbook | [guide](../../docs/solutions/data-source-onboarding.md) | [`references/data-source-onboarding.md`](references/data-source-onboarding.md) |
+| Asset enrichment | Enrich raw logs with device, user, vulnerability, misconfiguration, alert, or cloud context from the Asset Inventory, at ingest or at query time | [guide](../../docs/solutions/asset-enrichment.md) | [`references/asset-enrichment.md`](references/asset-enrichment.md) |
+| UEBA behavioural anomaly detection | Baseline ANY security or non-security signal per (action, principal) and detect z-score deviations: SPIKE, DROP, SILENT, NEW-BEHAVIOR. Run interactively to investigate, or deploy a baseline lookup, a scheduled PowerQuery rule, a nightly refresh, and a dashboard | [guide](../../docs/solutions/ueba-anomaly-detection.md) | [`references/ueba-anomaly-detection.md`](references/ueba-anomaly-detection.md) |
+| Ingest health monitoring (per device) | Per-device ingest health (per firewall, endpoint, server) on a 7-day hour-of-day seasonal baseline rebuilt daily: volume spike/drop, ingest lag, ingest loss, and parser drift, with a dashboard and email notifications | [guide](../../docs/solutions/ingest-health-monitoring.md) | [`references/ingest-health-monitoring.md`](references/ingest-health-monitoring.md) |
+| Custom detection exclusions | Suppress known-good noise in a STAR Custom Detection rule over a third-party or EDR source, for all three rule types: single-event and correlation rules carry the exclusion as an inline `AND NOT (...)` negative list; scheduled rules key against a CSV exclusion list (assets by IP/CIDR/host, or custom domains/users/values) via a lookup anti-join, with an exclusion-effectiveness dashboard | [guide](../../docs/solutions/custom-detection-exclusions.md) | [`references/custom-detection-exclusions.md`](references/custom-detection-exclusions.md) |
+| Risk-Based Alerting (RBA) | Publish noisy-but-interesting observations as low-noise risk events into a `risk` index, accumulate risk per user/host object amplified by asset risk factors, and fire one high-fidelity alert on a 24h cumulative-score or 7d multi-MITRE-tactic threshold. Deploys contributors, a risk-factor table, a scheduled collector flow, four incident rules, and a dashboard | [guide](../../docs/solutions/risk-based-alerting.md) | [`references/risk-based-alerting.md`](references/risk-based-alerting.md) |
+| Detection as Code (DaC) | Scaffold a Git + CI pipeline where detection engineers author rules as TOML, a pull request triggers validation and four-eyes review, and a merge syncs the changed rules to the Custom Detection Rule API. Covers single-event, correlation, and scheduled rule types, ships a zero-dependency TOML-to-API sync engine with idempotent create-or-update, and CI for GitHub Actions, GitLab CI, and Azure Pipelines | [guide](../../docs/solutions/detection-as-code.md) | [`references/detection-as-code.md`](references/detection-as-code.md) |
+| Alert noise reduction | Find the (source, signature) pairs flooding the alert queue, separate ingested and already-actioned noise (block/drop/sinkhole/reset) from real S1 detections, recommend an ingestion-severity filter, auto-resolve already-mitigated alerts with a note, optionally preserve signal-worthy categories as one correlation rule, and ship a noise-vs-signal dashboard. Product/source/signature/action values are discovered live; nothing is hardcoded | [guide](../../docs/solutions/alert-noise-reduction.md) | [`references/alert-noise-reduction.md`](references/alert-noise-reduction.md) |
 
 ## Outcomes
 
diff --git a/plugins/s1-secops-skills/skills/sdl-solutions/assets/detection-as-code-starter/README.md b/plugins/s1-secops-skills/skills/sdl-solutions/assets/detection-as-code-starter/README.md
index 0bc7bfd..c15653c 100644
--- a/plugins/s1-secops-skills/skills/sdl-solutions/assets/detection-as-code-starter/README.md
+++ b/plugins/s1-secops-skills/skills/sdl-solutions/assets/detection-as-code-starter/README.md
@@ -15,7 +15,7 @@ also accepted if you prefer them or are migrating an existing library.
 
 ## Repository layout
 
-```
+```text
 detection-as-code/
 ├── detections/
 │   ├── endpoint/      # one .toml per rule, grouped by target system
diff --git a/plugins/s1-secops-skills/skills/sdl-solutions/references/ueba-anomaly-detection.md b/plugins/s1-secops-skills/skills/sdl-solutions/references/ueba-anomaly-detection.md
index c8073ea..6beb653 100644
--- a/plugins/s1-secops-skills/skills/sdl-solutions/references/ueba-anomaly-detection.md
+++ b/plugins/s1-secops-skills/skills/sdl-solutions/references/ueba-anomaly-detection.md
@@ -1,7 +1,7 @@
 # UEBA behavioural anomaly detection
 
 The **s1-ueba-deployer is the source of truth** for this solution. The full documentation lives at
-[`docs/solutions/ueba-anomaly-detection.md`](../../docs/solutions/ueba-anomaly-detection.md), mirrored
+[`docs/solutions/ueba-anomaly-detection.md`](../../../docs/solutions/ueba-anomaly-detection.md), mirrored
 from the deployer.
 
 Read that document for: the security use-case selector (intent to data sources to detections to
diff --git a/plugins/s1-secops-skills/skills/soc-investigator/SKILL.md b/plugins/s1-secops-skills/skills/soc-investigator/SKILL.md
index da19231..5863c7c 100644
--- a/plugins/s1-secops-skills/skills/soc-investigator/SKILL.md
+++ b/plugins/s1-secops-skills/skills/soc-investigator/SKILL.md
@@ -221,6 +221,7 @@ After the user confirms, begin Phase 1 immediately.
 ### Phase 1: Alert Ingest & Entity Extraction (5 min)
 
 #### 1.1 Fetch alerts
+
 ```text
 Use: sentinelone-mgmt-console-api
 Query: GET /threats (filtered by user input)
@@ -228,6 +229,7 @@ Output: alerts.jsonl
 ```
 
 #### 1.2 Single-pass entity extraction
+
 ```json
 {
   "alerts_processed": 42,
@@ -241,6 +243,7 @@ Output: alerts.jsonl
 ```
 
 #### 1.3 Draft timeline (alert order, not forensic)
+
 ```text
 - 2025-06-16 10:00 | HIGH   | DESKTOP-ABC123 | john.doe   | Suspicious Process Execution (powershell)
 - 2025-06-16 10:05 | MEDIUM | DESKTOP-ABC123 | john.doe   | Registry Modification (persistence)
@@ -248,6 +251,7 @@ Output: alerts.jsonl
 ```
 
 #### 1.4 Draft MITRE (simple inference from alert type)
+
 ```json
 {
   "tactics": ["Execution", "Persistence"],
@@ -259,12 +263,14 @@ Output: alerts.jsonl
 ```
 
 **Output files**:
+
 - `entities.json` - extracted entities
 - `timeline_draft.csv` - simple chronological alert list
 - `mitre_draft.json` - inferred tactics/techniques
 - `summary.md` - 1-page overview for quick review
 
 **Approval gate** (if enabled):
+
 ```text
 ✓ SHORT investigation complete.
   - 42 alerts processed
@@ -284,6 +290,7 @@ Includes SHORT, plus:
 ### Phase 2: IOC Enrichment (5 min)
 
 #### 2.1 Batch IOC lookups
+
 ```text
 Use: Purple MCP (VirusTotal) + sentinelone-mgmt-console-api (S1 IOC API)
 
@@ -295,6 +302,7 @@ For each IOC in entities.json:
 ```
 
 #### 2.2 Sample if >20 IOCs
+
 ```text
 If IOC count > 20:
   Sort by alert_count (descending)
@@ -307,6 +315,7 @@ If IOC count > 20:
 ### Phase 3: Endpoint Process Context (5 min)
 
 #### 3.1 One PowerQuery per unique endpoint
+
 ```text
 Use: sentinelone-powerquery skill
 
@@ -339,6 +348,7 @@ Query B: Network behavior for same user
 **4.2 Refine MITRE with IOC context** - add evidence chains and confidence scores
 
 **Output files**:
+
 - `threat_intel.json` - IOC lookups
 - `powerquery_results.jsonl` - process/network queries
 - `timeline_enriched.json` - merged context
@@ -346,6 +356,7 @@ Query B: Network behavior for same user
 - `timeline.csv` - timeline for import to Excel/Splunk
 
 **Approval gate + Third-Party Option** (if enabled):
+
 ```text
 ✓ MEDIUM investigation complete.
   - 8 IOCs looked up (3 malicious, 2 suspicious, 3 clean)
@@ -371,6 +382,7 @@ Includes MEDIUM, plus:
 ### Phase 5: Deep Forensic Queries (25 min, PARALLEL)
 
 #### 5.1 For each endpoint in alerts, run 4 deep PowerQueries
+
 ```text
 Per endpoint:
 
@@ -407,6 +419,7 @@ Query D: Full network behavior
 ### Phase 6: Threat Intelligence Deep-Dive (10 min, PARALLEL)
 
 #### 6.1 SDL threat intelligence correlation
+
 ```text
 Use: sentinelone-powerquery skill
 
@@ -421,6 +434,7 @@ For each IOC in entities.json:
 **Goal**: Find other endpoints/users that encountered same IOCs (lateral spread, supply chain).
 
 #### 6.2 Expand IOC lookups (all IOCs, not sampled)
+
 VirusTotal: Full report for all hashes, domains, IPs + S1 IOC API: All IOCs
 
 **Store results**: `threat_intel_complete.json`
@@ -432,11 +446,13 @@ VirusTotal: Full report for all hashes, domains, IPs + S1 IOC API: All IOCs
 **7.2 Refine MITRE with full forensic evidence** - add confidence scores and evidence chains
 
 **Output files**:
+
 - `full_report.md` - comprehensive investigation report
 - `timeline_forensic.csv` - full timeline for SIEM/Excel import
 - All JSON outputs from earlier phases
 
 **Approval gate + Third-Party Option** (if enabled):
+
 ```text
 ✓ LONG investigation complete.
   - 42 alerts processed
@@ -464,6 +480,7 @@ Choose: [1 | 2 | 3]
 ### Phase 1: Discover Available Data Sources (2 min)
 
 #### 1.1 Query all available data sources
+
 ```text
 Use: sentinelone-powerquery skill
 
@@ -474,6 +491,7 @@ dataSource.name = *
 ```
 
 #### 1.2 Ask user which sources to investigate
+
 ```text
 Available data sources detected:
   ✓ Microsoft 365 (1.2M events)
@@ -489,6 +507,7 @@ Which sources are relevant to this incident?
 ### Phase 2: Schema Exploration (3 min per source)
 
 For each selected source:
+
 - Query A: list all activities (`| group ct=count() by activity_name | sort -ct | limit 30`)
 - Query B: sample 10 events to see available fields
 
@@ -503,6 +522,7 @@ For each user, IP, and domain in `entities.json`, run targeted queries against t
 ### Phase 4: Anomaly Detection (5 min per source)
 
 For each user + activity combination, run timeseries analysis:
+
 ```text
 | let hour = timebucket('1h')
 | group ct=count() by hour
@@ -524,6 +544,7 @@ Surface significant findings, let the user choose which to deep-dive with target
 Synthesize all findings into `third_party_report.md`.
 
 **Output files**:
+
 - `third_party_correlation.json` - full correlation matrix
 - `anomalies.json` - timeseries spikes
 - `deep_dive_*.json` - user-selected deep-dives
@@ -541,6 +562,7 @@ Synthesize all findings into `third_party_report.md`.
 | Third-Party (opt-in) | 15 min | ~10k | Source discovery + entity correlation + anomaly detection |
 
 **Key optimizations**:
+
 - Batch operations (all IOCs at once, all endpoints in parallel)
 - Structured outputs (JSON, no prose)
 - IOC sampling in MEDIUM (top 20 by frequency)