Summary
Executor already solves "configure an integration once, let every MCP agent share it" for tools. I'd love the same for agent skills (Claude Code SKILL.md packs, Codex/Grok equivalents): install a skill into Executor once, and have each connected agent pick it up — instead of hand-copying skill folders into every agent's config.
Think of it as a central skill catalog + per-agent install/sync layer, i.e. a package manager for skills across heterogeneous agents.
Why this is a distinct mechanism (and not just "expose skills over MCP")
The key structural point: skills are not consumed over MCP the way tools are. A Claude Code skill is a SKILL.md file discovered by the harness on the filesystem (~/.claude/skills/, .claude/skills/), scanned at session start and loaded on prompt match. MCP delivers tools/access; skills are instructions/method — a different layer. So skills can't simply ride Executor's existing MCP tool-distribution pipe and show up natively in an agent's skill list.
That means this is a genuinely new capability, not a small extension of the current catalog.
Proposed architecture (the viable path)
Central store + per-agent install adapters + sync, rather than MCP transport:
- Catalog —
executor skill add <name> registers a skill (source: local dir, git repo, or URL) in a central Executor-managed store, with policy/governance like existing integrations.
- Per-agent adapters — translate/emit the skill into each target agent's native format + location:
- Claude Code →
~/.claude/skills/<name>/SKILL.md (+ bundled scripts/resources)
- Codex → its
AGENTS.md / prompt-file convention
- Grok / others → their own config
- Sync — symlink or a small sync step so the central store stays the source of truth and updates propagate to all agents.
This preserves the native skill UX (auto-discovery, bundled files) and requires no protocol changes.
The real hard part
Format fragmentation. There's no shared cross-agent skill standard — SKILL.md vs AGENTS.md vs Grok's own format. So the substantive work is the translation/adapter layer, not distribution. Executor is well positioned for this precisely because it already owns the "one config, many agents" surface.
Naming note
Executor already uses "skill" internally (the skills MCP tool that serves long-form how-to guides for its own tools). To avoid collision, this feature might be better named skill packs / skill sync or similar.
Open questions
Summary
Executor already solves "configure an integration once, let every MCP agent share it" for tools. I'd love the same for agent skills (Claude Code
SKILL.mdpacks, Codex/Grok equivalents): install a skill into Executor once, and have each connected agent pick it up — instead of hand-copying skill folders into every agent's config.Think of it as a central skill catalog + per-agent install/sync layer, i.e. a package manager for skills across heterogeneous agents.
Why this is a distinct mechanism (and not just "expose skills over MCP")
The key structural point: skills are not consumed over MCP the way tools are. A Claude Code skill is a
SKILL.mdfile discovered by the harness on the filesystem (~/.claude/skills/,.claude/skills/), scanned at session start and loaded on prompt match. MCP delivers tools/access; skills are instructions/method — a different layer. So skills can't simply ride Executor's existing MCP tool-distribution pipe and show up natively in an agent's skill list.That means this is a genuinely new capability, not a small extension of the current catalog.
Proposed architecture (the viable path)
Central store + per-agent install adapters + sync, rather than MCP transport:
executor skill add <name>registers a skill (source: local dir, git repo, or URL) in a central Executor-managed store, with policy/governance like existing integrations.~/.claude/skills/<name>/SKILL.md(+ bundled scripts/resources)AGENTS.md/ prompt-file conventionThis preserves the native skill UX (auto-discovery, bundled files) and requires no protocol changes.
The real hard part
Format fragmentation. There's no shared cross-agent skill standard —
SKILL.mdvsAGENTS.mdvs Grok's own format. So the substantive work is the translation/adapter layer, not distribution. Executor is well positioned for this precisely because it already owns the "one config, many agents" surface.Naming note
Executor already uses "skill" internally (the
skillsMCP tool that serves long-form how-to guides for its own tools). To avoid collision, this feature might be better named skill packs / skill sync or similar.Open questions