Add foundry-redirect skill so the Foundry-app redirect works without hooks (#31)

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.
 - **Skill scripts run on assistants other than Claude Code.** The scripts now resolve their own location with `os.path.realpath` instead of `os.path.abspath`, so an assistant that launches a script through a `~/.agents/skills/<skill>` symlink (Codex, Copilot CLI, Cursor, Antigravity) correctly finds the shared `common/scripts` modules and the managed-venv wrapper — the cold-start dependency bootstrap fires as it does for Claude Code, instead of failing with a missing-`falconpy` error. Each `SKILL.md` now shows a portable invocation — `cd` into the skill's folder, then run `../../scripts/python.sh <script>` on one line — that works whether or not `${CLAUDE_PLUGIN_ROOT}` is set, since that variable is defined only by Claude Code and no equivalent exists on the other assistants.
 - **Agent Plugins manifests for non-Claude assistants** — A root `plugin.json` conforming to the [Agent Plugins](https://agent-plugins.org) 1.0.0 spec and a Codex-flavored `.codex-plugin/plugin.json`, so Codex, Copilot CLI, Cursor, and Antigravity CLI can discover the plugin alongside the existing Claude manifest. CI validates both and keeps their versions in lockstep with `.claude-plugin/plugin.json`.
 - **Install instructions for five AI coding assistants** — Claude Code, Codex, Copilot CLI, Cursor, and Antigravity CLI each get documented install commands (`--plugin-dir` for Claude Code, Copilot CLI, and Cursor; a `~/.agents/skills/` symlink for Codex and Antigravity CLI). Claude Code is verified end to end; the others load the skills and are documented, with broader end-to-end verification tracked separately.

README.md

@@ -192,7 +192,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 |
 |-------|---------|
@@ -201,6 +201,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 |