# Agentic Platform Compatibility

RCS should be portable across agentic AI platforms, but **portability does not mean pretending every platform has the same runtime model as Codex**.

The correct goal is:

- one canonical authoring surface
- one compatibility contract
- multiple platform-specific delivery lanes

That contract is now materialized in:

- [`src/platform-targets/manifest.json`](../../src/platform-targets/manifest.json)
- [`src/platform-targets/schema.ts`](../../src/platform-targets/schema.ts)
- [`src/platform-targets/reader.ts`](../../src/platform-targets/reader.ts)

## What stays canonical

These are the source-of-truth surfaces inside this repo:

- `skills/` — canonical workflow skills
- `prompts/` — canonical prompt guidance for setup-owned native-agent generation
- `src/agents/definitions.ts` — canonical native-agent role registry
- `src/catalog/manifest.json` — canonical installability and alias/merged policy
- `templates/AGENTS.md` — canonical orchestration brain template
- `src/config/rcs-first-party-mcp.ts` and related config generators — canonical first-party MCP metadata

Everything else should be an **emitted delivery surface** or an **adapter surface**.

## Delivery lanes

### 1. Codex native setup lane

This is the deepest-supported lane today.

It includes:

- generated native agents under `.codex/agents/`
- installed prompts under `.codex/prompts/`
- installed skills under the selected setup scope
- setup-owned runtime hooks
- `.rcs/` runtime state

This lane is driven by `rcs setup`.

### 2. Codex plugin + marketplace lane

This is the installable bundle lane today.

It includes:

- plugin bundle under `plugins/roblox-ai-os-creator-skills/`
- marketplace metadata in `.agents/plugins/marketplace.json`
- plugin-scoped skill discovery
- plugin-scoped MCP/app companion metadata

Important boundary:

- the plugin bundle is **not** the full runtime setup
- setup-owned prompts, native-agent TOMLs, and runtime hooks remain outside the plugin manifest

### 3. Adapter lane for external platforms

This is how non-Codex platforms should be integrated.

Examples:

- OpenClaw
- Hermes
- future Claude-oriented or marketplace-oriented bridges

The rule is:

- do not fork canonical skill/prompt/runtime truth into platform-specific ad hoc copies
- add a platform adapter or delivery contract that maps canonical RCS surfaces into the target platform’s format

## What “compatible with any agentic AI platform” should mean

It should mean:

- RCS authors once from canonical source surfaces
- RCS can emit or adapt those surfaces for a target platform
- each target gets the format it actually supports

It should **not** mean:

- every platform receives the exact same file layout
- every platform gets Codex-only runtime semantics
- plugin, marketplace, hooks, prompts, and native agents all collapse into one fake universal package

## Platform model

Use this mental model:

- **Canonical source layer**: skills, prompts, registry, catalog, templates
- **Delivery layer**: Codex native setup, Codex plugin bundle, marketplace package
- **Adapter layer**: target-specific bridge for platforms with different runtime rules

## Claude-style example

For a Claude-like platform, the right question is not:

- “Can we copy the Codex plugin/runtime shape into `.claude/`?”

The right question is:

- “Which canonical RCS surfaces should be delivered natively, and which must stay adapter-owned because the target platform does not share Codex runtime semantics?”

That usually means:

- skills may be portable
- selected guidance may be portable
- marketplace/package metadata may be portable
- setup-owned native agents and runtime hooks are **not** automatically portable one-to-one

## Claude-like hosts (Claude Code, Anthropic API clients, and similar)

The manifest lane **`claude-like`** is **planned**: it records the contract and naming boundary for Anthropic-first or Claude-branded hosts. It does **not** promise a finished exporter in any given release until release notes say so.

**Portable without pretending Codex parity**

- Root **`skills/`** workflow markdown (Roblox creator triggers, forge loops, psychology-aware briefs) can be read or mirrored into a host-specific skill or rules directory **as long as** you keep this repository—or a generated export—as the **canonical** text you diff against.
- **`templates/AGENTS.md`** and Roblox-first reference docs under **`docs/reference/`** are portable **policy and vocabulary** surfaces for any agent that can load markdown instructions.

**Not portable one-for-one**

- **Generated Codex native agent TOMLs**, **setup-owned `hooks.json` behavior**, and **`rcs` CLI lifecycle** are owned by the **`codex-native`** lane. Claude Code and similar hosts use different configuration shapes, hook models, and session lifecycles—do not assume you can copy `.codex/` paths verbatim and get equivalent enforcement.
- **RCS-managed MCP defaults** are generated from TypeScript SSOT (`src/config/rcs-first-party-mcp.ts`). Other IDEs may consume MCP via their own config files; treat those files as **host delivery artifacts**, not a second place to edit server lists long-term.

**Practical posture for Anthropic-first teams**

- Treat RCS as the **authoritative Roblox creator policy + skill library** in git, and Codex as **one** supported execution backend—not the only runtime that may ever consume those files.
- When you add automation, add a **small adapter or emitter** (or documented sync step) rather than forking `SKILL.md` bodies into a divergent “Claude-only” tree.

## Marketplace example

For a marketplace-oriented platform, the package should be treated as a delivery artifact:

- emitted from canonical repo sources
- versioned from canonical package/release metadata
- validated against a platform-specific boundary contract

Not as a second source of truth.

## Current repo posture

Today RCS is strongest in:

- Codex native setup
- Codex plugin/marketplace packaging
- adapter-style compatibility lanes such as OpenClaw/Hermes

It is **not yet** a finished universal emitter for every external agent platform.

The **`cursor`** and **`mcp-capable-ide`** manifest lanes are **active at the reference-doc layer** (integration guides and MCP JSON presets). They do **not** yet ship a dedicated Cursor extension or a codegen emitter; deeper automation should still follow adapter/emitter patterns instead of forking `skills/`.

The **`claude-like`** lane remains **planned** until an equivalent reference or emitter ships.

That is intentional. The repo should grow by adding **clean adapters/delivery contracts**, not by duplicating the product into platform-specific silos.

## Concrete target lanes

The current platform target manifest defines these concrete lanes:

- `codex-native`
- `codex-plugin`
- `claude-like`
- `cursor` (active reference delivery: [`cursor-rcs-integration.md`](./cursor-rcs-integration.md))
- `marketplace-bundle`
- `mcp-capable-ide` (active reference delivery: [`mcp-capable-ide-presets.md`](./mcp-capable-ide-presets.md))
- `adapter-openclaw`
- `adapter-hermes`