Overview
This example shows how to scaffold a Pluxx plugin from Sumble’s remote MCP, generate workflow-oriented skills and commands, and validate the resulting project across the core four targets:- Claude Code
- Cursor
- Codex
- OpenCode
Prerequisites
- a Sumble API key exposed as
SUMBLE_API_KEY - Node 18+
- Pluxx installed or available via
npx @orchid-labs/pluxx
Scaffold Command
Validation Commands
Generated Source Project
The maintained source project committed in the repository looks like this:Workflow Grouping
The import grouped Sumble’s raw MCP tools into these workflows:account-researchcontact-discoveryhiring-signalstechnographicstable-operationsgeneral-researchlog-out
Key Generated Files
pluxx.config.ts
Generated INSTRUCTIONS.md Structure
Generated Skill Frontmatter
Observed Build Outputs
These outputs were generated during a realpluxx build run. They are intentionally not committed in the repository, but they were produced successfully:
Validation Result
Observed result from the real run:doctor:0 error(s), 1 warning(s), 2 info message(s)lint:0 error(s), 1 warning(s)build: generated all four core bundlestest: passed on Claude Code, Cursor, Codex, and OpenCode
Current Caveats
Install trust for generated hooks
doctor reports that local hook commands require explicit trust at install time:
- Pluxx generated local shell hooks under
scripts/ - users should explicitly opt in before those commands run
Codex hooks are bundled but may still be feature-gated
build also reports the current Codex hook activation caveat when the source scaffold declares Codex hooks without the host feature flag:
- Claude Code, Cursor, and Codex all receive packaged hook output from this scaffold
- Codex plugin-bundled hooks require
[features].plugin_hooks = true;[features].hooks = trueis the general non-plugin hook flag - the Codex plugin still built and tested successfully
- the caveat is about runtime activation, not hook packaging parity