Correct the hook-portability claim, and name assistants in the changelog

The README said other assistants "do not run these Claude Code hooks." That is
wrong for Codex. Per OpenAI's plugin packaging docs, Codex discovers
`hooks/hooks.json` on its own and sets `CLAUDE_PLUGIN_ROOT` for compatibility,
so every hook path in our manifest resolves there and the hooks execute. They
are written against Claude Code's hook contract and emit
`hookSpecificOutput.additionalContext`, which has not been validated on Codex,
so the README now says that plainly rather than implying they are inert.

Copilot CLI, Cursor, and Antigravity CLI genuinely do not run them, so the
guidance that follows still applies to those three.

Changelog entries now name the assistant where the attribution is real:

- The `connection issue` diagnosis was observed on Codex, whose workspace-scoped
  sandbox denies the token-cache write. Stated as "any assistant with a
  workspace-scoped sandbox can hit this; Codex is where it was observed", since
  the mechanism is not unique to it.
- The OpenAPI adapter gap belongs to Copilot CLI, Cursor and Antigravity CLI:
  Claude Code's skill router invokes the adapter automatically, and those three
  have to run it by hand. Codex is deliberately left off that list because its
  hook support means the router may in fact fire there.
- The `--no-prompt` entry now says explicitly that it is CLI behavior rather than
  assistant-specific, so nobody reads the surrounding entries and assumes it is.
- The fusion-redirect rationale cites the measured case (1 of 10 trials against
  the Agent SDK, which does not load hooks for a local plugin) instead of
  claiming assistants generally never reached it.

Author: mraible

CHANGELOG.md

@@ -9,15 +9,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/), and this
 ### Added
 
 - **Install instructions for five AI coding assistants** — Claude Code, Codex, Copilot CLI, Cursor, and Antigravity CLI each get a verified marketplace command, plus an expandable table of local-clone commands for testing a branch. Four of the five load a local clone with a single flag (`--plugin-dir` for Claude Code, Copilot CLI, and Cursor; `agy plugin install` for Antigravity CLI); Codex has no such flag and discovers skills from `~/.agents/skills/` instead.
-- **`fusion-redirect` skill** — A standalone Falcon Fusion workflow (a trigger plus actions that already exist, with nothing to build) belongs to the sibling Falcon Fusion plugin, and this skill says so. The advisory previously lived in `development-workflow`'s body, behind a trigger description that correctly does not match a Fusion-only request, so assistants that rely on skill descriptions rather than hooks never reached it. As its own skill it is reachable on every assistant. When the Falcon Fusion plugin is installed, that plugin's own skill is the stronger match and handles the request directly.
+- **`fusion-redirect` skill** — A standalone Falcon Fusion workflow (a trigger plus actions that already exist, with nothing to build) belongs to the sibling Falcon Fusion plugin, and this skill says so. The advisory previously lived in `development-workflow`'s body, behind a trigger description that correctly does not match a Fusion-only request, so it was only reachable when the skill router hook injected it. Wherever hooks do not fire the advisory was unreachable, measured at 1 of 10 trials against the Agent SDK, which does not load hooks for a local plugin. As its own skill, selected on its own description, it no longer depends on hooks at all. When the Falcon Fusion plugin is installed, that plugin's own skill is the stronger match and handles the request directly.
 - **Agent Plugins manifest** — A root `plugin.json` conforming to the [Agent Plugins](https://agent-plugins.org) 1.0.0 spec, so any conforming client can discover the plugin alongside the existing Claude and Codex manifests. CI validates it and `release.sh` bumps its version with the others.
 - US-3 cloud region to the cloud-region documentation: added `us-3` to the `FOUNDRY_CLOUD_REGION` value lists (headless-operation reference, e2e-testing env var table) and the multi-cloud deployment section. Foundry CLI 2.0.2 added US-3 support; the base URL (`api.us-3.crowdstrike.com`) is in FalconPy as of v1.6.4.
 
 ### Fixed
 
-- **`connection issue` on tenant commands is diagnosed** — In a sandboxed agent the usual cause is a denied write to `~/.config/foundry/token.json`, where the CLI keeps its short-lived access token, not a network fault. The CLI reports only the symptom, so agents were investigating networks and credentials. The debugging skill now explains that the ~30-minute token refresh is expected and that the fix is to request write access to that one directory and retry.
-- **Three commands that reject `--no-prompt`** — `foundry version`, `apps list`, and `apps list-deployments` fail with `unknown flag` when given it. Two of those are in the prerequisite check, so "always add `--no-prompt`" was breaking the first thing an agent runs.
-- **OpenAPI adapter dependencies on assistants that do not run hooks** — The adapter script needs `pyyaml`, and a bare `pip install` fails on Homebrew and system Pythons with `externally-managed-environment` (PEP 668). The API integrations skill documents an explicit virtualenv setup, which assistants without Claude Code's hooks need in order to run the script at all.
+- **`connection issue` on tenant commands is diagnosed (Codex)** — Codex confines writes to the workspace, so the CLI is denied the write to `~/.config/foundry/token.json` where it keeps its short-lived access token. The CLI reports only `connection issue`, the symptom, so agents were investigating networks and credentials instead. The debugging skill now explains that the ~30-minute token refresh is expected and that the fix is to request write access to that one directory and retry. Any assistant with a workspace-scoped sandbox can hit this; Codex is where it was observed.
+- **Three commands that reject `--no-prompt`** — `foundry version`, `apps list`, and `apps list-deployments` fail with `unknown flag` when given it. This is CLI behavior, not assistant-specific: any agent following "always add `--no-prompt`" hits it, and two of those commands are in the prerequisite check, so it was breaking the first thing an agent runs.
+- **OpenAPI adapter dependencies on assistants that do not run Claude Code hooks (Copilot CLI, Cursor, Antigravity CLI)** — On Claude Code the skill router hook invokes `adapt_spec_for_foundry.py` automatically. Assistants without that hook have to run it by hand, and the script needs `pyyaml`, which a bare `pip install` cannot supply on Homebrew or system Pythons (PEP 668 `externally-managed-environment`). The API integrations skill now documents an explicit virtualenv setup so the script is runnable without the hook.
 - **Sub-skill routing survives a single-entry-point install** — `development-workflow` now documents that sub-skills live beside it on disk as `../<name>/SKILL.md`, and how to handle a capability-level request that lands on the orchestrator: read the sub-skill from disk first, then skip straight to the CLI command when `manifest.yml` already exists. Assistants that register only the orchestrator no longer have to infer this. The orchestrator's trigger description is unchanged, so skill selection on a fully-registered install behaves exactly as before.
 - **Sub-skills point back to the orchestrator** — Every capability sub-skill now links to `development-workflow` near the top of the file, so an assistant without routing hooks that selects a sub-skill directly still finds the CLI prerequisite check, scaffolding order, and manifest coordination. Previously only `e2e-testing` mentioned the orchestrator, and only in a footer.
 

README.md

@@ -77,7 +77,7 @@ The Claude Code plugin includes hooks that ensure the right skills get used:
 
 Hooks observe prompts and tool I/O to keyword-match Foundry-specific actions; no data leaves the session.
 
-Other assistants discover and follow the skills but do not run these Claude Code hooks. They must apply the documented `--no-prompt` guardrails and run the OpenAPI adaptation helper explicitly. Skill-specific helpers live beside their `SKILL.md` files so Agent Skills and plugin installations remain self-contained; this packaging is separate from Falcon Foundry CLI connectivity, which is covered by the sandbox diagnostics in the debugging skill.
+Codex discovers `hooks/hooks.json` on its own and sets `CLAUDE_PLUGIN_ROOT` for compatibility, so these hooks can execute there — but they are written and tested against Claude Code's hook contract, so treat their behavior on Codex as unvalidated. Copilot CLI, Cursor, and Antigravity CLI do not run them at all. On any assistant where the hooks do not run, apply the documented `--no-prompt` guardrails and invoke the OpenAPI adaptation helper explicitly. Skill-specific helpers live beside their `SKILL.md` files so Agent Skills and plugin installations remain self-contained; this packaging is separate from Falcon Foundry CLI connectivity, which is covered by the sandbox diagnostics in the debugging skill.
 
 ## Skills