Add foundry-redirect skill so the Foundry-app redirect works without hooks

The workflows orchestrator declines Falcon Foundry app requests (UI, functions,
collections, manifest.yml, custom third-party API integrations), but that instruction
lives in a skill whose description matches Fusion-workflow language — so a 'build a
Foundry app' prompt never loads the orchestrator and never reads the redirect. On
Claude Code the fusion-foundry-bridge hook covers the gap; hooks do not fire in Codex,
Copilot CLI, Cursor, or the Agent SDK, so for those the redirect is structurally
unreachable.

This adds skills/foundry-redirect/SKILL.md whose description matches Foundry-app
language directly, so the redirect is reachable on every assistant. It declines the
request and points to the crowdstrike-falcon-foundry plugin, and yields to that
plugin's own development-workflow skill (stronger match) when it is installed. Mirrors
the fusion-redirect skill foundry-skills added for the reverse direction.

README skills table and CHANGELOG updated. Frontmatter/version-consistency/size-budget/
markdownlint all pass.

Author: mraible

CHANGELOG.md

@@ -8,6 +8,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/), and this
 
 ### Added
 
+- **`foundry-redirect` skill** — declines Falcon Foundry app requests (a UI page, serverless function, collection, `manifest.yml`, or custom third-party API integration) and points to the sibling `crowdstrike-falcon-foundry` plugin. The `workflows` orchestrator already declines these, but its description matches Fusion-workflow language, so a "build a Foundry app" prompt never loads it; a Claude Code hook covered that gap, but hooks do not fire in Codex, Copilot CLI, Cursor, or the Agent SDK. This skill's description matches Foundry-app language directly, so the redirect is reachable on every assistant. It yields to the Foundry plugin's own skill when that plugin is installed.
 - US-3 cloud region to credential setup: a `[us-3]` profile example (`https://api.us-3.crowdstrike.com`) in the setup skill's multi-cloud block and in the README region notes, alongside a `[us-gov-1]` example that was also missing. The auth module already accepts any `base_url`, so this documents the host rather than changing behavior.
 - Throttling reference in the execution skill: explains that a workflow stuck "in progress" may be throttled (Fusion paces an action past a volume limit, auto-retrying up to 6 hours) rather than failed, how to recognize it on the execution detail view, and when sustained throttling signals a workflow-design issue.
 - Deduplicate and Rate Limit action reference plus a worked tutorial example. Covers all six Deduplicate activities and all four Rate Limit activities: the `definition`/`cid` scope values (which the console labels "Workflow" and "CID"), the atomic claim, metadata handoff, and the save-time validation the builder runs. The example deduplicates third-party NG-SIEM detections into a single case. Action IDs were confirmed against a live tenant; the example passes validation at all tiers.

README.md

@@ -156,7 +156,7 @@ The `workflows` orchestrator is the entry point: you say what you want, and it r
 
 ## Skills
 
-One plugin provides five skills: an orchestrator plus four focused sub-skills.
+One plugin provides six skills: an orchestrator, four focused sub-skills, and a Foundry-app redirect.
 
 | Skill | Purpose |
 |-------|---------|
@@ -165,6 +165,7 @@ One plugin provides five skills: an orchestrator plus four focused sub-skills.
 | `deployment` | Duplicate check, import to CID, release, version management |
 | `execution` | Trigger workflows with payloads, monitor status, tail logs, debug failures |
 | `lookup-files` | Manage Falcon Next-Gen SIEM lookup files (CSV/JSON/TXT) for CQL `match()` queries |
+| `foundry-redirect` | Declines Falcon Foundry app requests (UI, functions, collections, `manifest.yml`) and points to the `crowdstrike-falcon-foundry` plugin |
 
 ### Architecture
 

skills/foundry-redirect/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: foundry-redirect
+description: >
+  TRIGGER when the user asks to "build a Foundry app", "create a Foundry app",
+  mentions manifest.yml, or needs a UI page/extension, serverless function,
+  collection, or a custom API integration from a third-party API (Okta, ServiceNow,
+  Jira, etc.) built. DO NOT TRIGGER for a standalone Fusion workflow that only wires
+  together existing actions. This skill declines Foundry-app requests and points to
+  the crowdstrike-falcon-foundry plugin, so the redirect works even without Claude
+  Code hooks; it yields to the real Foundry plugin when that plugin is also installed.
+version: 1.0.1
+updated: 2026-08-17
+tags: [fusion, foundry, redirect, routing]
+author: CrowdStrike
+license: MIT
+compatibility: Claude Code >=1.0
+metadata:
+  category: routing
+---
+
+# Falcon Foundry Redirect
+
+If this skill triggered, the request is a **Falcon Foundry app**, not a standalone
+Falcon Fusion workflow. It belongs to the sibling Falcon Foundry plugin — the
+`fusion-skills` plugin builds Fusion workflows only.
+
+Why this skill exists: the `workflows` orchestrator declines Foundry-app requests too,
+but its description matches *Fusion workflow* language, so a "build a Foundry app"
+prompt never loads it. On Claude Code a hook covers that gap; on Codex, Copilot CLI,
+Cursor, and the Agent SDK there are no hooks, so this skill — whose description matches
+Foundry-app language directly — is what makes the redirect reachable.
+
+## What to do
+
+Do NOT author workflow YAML. Do NOT scaffold an app yourself. Respond with all three:
+
+1. State plainly that this request needs a Falcon Foundry app, not a standalone Fusion workflow.
+2. Name the plugin: **`crowdstrike-falcon-foundry`**.
+3. How to install it: `/plugin install crowdstrike-falcon-foundry`, or clone https://github.com/CrowdStrike/foundry-skills.
+
+## When both plugins are installed
+
+If `crowdstrike-falcon-foundry` is present, its own `development-workflow` skill matches
+Foundry-app requests directly and handles them — a stronger match than this one, so the
+agent picks it and this redirect never fires. That is correct: this skill is the safety
+net for when the Foundry plugin is absent, not a competitor with it when present.
+
+## Foundry app vs. standalone workflow
+
+| Signal in the request | Route |
+|---|---|
+| "Foundry app", `manifest.yml`, a UI page/extension, serverless function, collection, or custom third-party API integration | **Here** — redirect to foundry-skills |
+| A trigger plus existing Fusion actions only (no UI, function, collection, or custom integration) | **`workflows`** — handle it as a standalone workflow |
+| "a workflow inside a Foundry app" | **Here** — the app owns the workflow; Foundry scaffolds it |
+| Fetch/summarize a population of alerts/detections the workflow doesn't already hold | **`workflows`** — a standalone CrowdStrike HTTP Request handles this without an app |