feat(plugins): corespeed-cli, a skills-only plugin for Codex on the cs CLI

[corespeed-agent-ensemble]

What

A second plugin, plugins/corespeed-cli/, with one skill and no MCP server. Installed in Codex, it has the agent install @corespeed/cs, sign in once in the browser, and then find and call CoreSpeed tools from the shell:

cs mcp search <words…>     # best matches first, one line each
cs mcp get <tool>          # description, input schema, a call to start from
cs mcp call <tool> '{…}'   # the result on stdout; exit code says what the tool did

Registered in .agents/plugins/marketplace.json as corespeed-cli@corespeed (installation AVAILABLE, authentication ON_USE: nothing to sign in to on install). The MCP plugin corespeed is unchanged apart from the skill below.

Why

• A client that loads no tool list has no tool-list limit. Codex caps a single MCP server at 2,048 tools and drops the whole server above it; an organization with many connectors crosses that on /mcp. The CLI discovers tools on demand instead.
• A skills-only plugin is the shape the OpenAI Plugins Directory accepts without the MCP tool-surface review (each operation as a separate tool, annotations, Scan Tools). This is the package for that submission.

The cs-cli skill catches up with cs 0.5.0

Source is plugins/corespeed/skills/cs-cli/SKILL.md; corespeed-cli carries a byte-identical copy.

• New section Calling tools from a shell: search → get → call, and don't guess a tool's name or arguments.
• cs mcp search and cs mcp get added to the command table; cs mcp call and cs mcp list rows corrected to 0.5.0 behaviour.
• Memory: search at task start, remember after significant work, with the two commands.
• Approvals: exit code 6, and the cs mcp call manage__approval_wait … command printed on stderr to run right away.
• In Codex: the sandbox has no network by default (workspace-write and read-only), so cs is blocked until approved or [sandbox_workspace_write] network_access = true; the agent must not change that setting itself.
• The intro no longer assumes the MCP plugin is installed.
• Result printing stated precisely (reviewer P2, fixed in 9955fce): structuredContent as JSON, otherwise text blocks as text; --raw is the path for JSON parsing.

Because the bundled skill changed, both corespeed manifests go 0.2.0 → 0.2.1 (Codex caches a plugin by version).

CI

check.yml validates the new manifest and adds one step: the CLI plugin has no .mcp.json, its manifest has no mcpServers, and its cs-cli skill is identical to the source copy.

Verified

• Codex 0.151.0: codex plugin marketplace add <this tree> then codex plugin add corespeed-cli@corespeed → listed as installed, enabled 0.1.0; codex mcp list still shows no servers; the cache holds the manifest, the skill and both assets.
• HOL plugin scanner (uvx plugin-scanner scan .): 86/100, no high findings (CI gate is ≥ 80, no high).
• The jq/cmp guards pass locally.

Not in this PR

The Directory submission itself (publisher verification, listing text and artwork, reviewer account, test cases) is portal work. The setup skill in corespeed-haas (skills/corespeed/SKILL.md) still tells Codex users to add the full /mcp; switching its Codex section to the CLI is a separate change.

🤖 Generated with Claude Code

[corespeed-hopper]

Approved with one nonblocking P2 follow-up. No P1 findings.

Reviewed merge base 37b37f8 through head 0822dad. Round 1/5, cycle 1. Session: ed1945d8-2696-4267-a850-653d4848222f.

Checked the manifests, marketplace paths, bundled skills, version changes, assets, and workflow guards. Inspected published @corespeed/cs 0.5.0 against the new command instructions. Targeted offline fixtures verified plain-text output, --raw JSON, structured output, and exit 6 with the approval-wait command. git diff --check passed. Authenticated provider calls were not exercised.

CI passed on this exact head: manifests and scan. The PR description records the CLI-only design and separate Directory submission work.

The inline P2 should be fixed but may follow up; it does not block approval.

[corespeed-hopper]

[P2] Do not promise JSON for default call output

The new text says fallback content is pretty-printed JSON. In published cs 0.5.0, a text-only result prints plain text and exits 0. A local fixture with text "All systems healthy" reproduced that output. Agents following this contract can fail when parsing successful calls with JSON.parse or jq.

State that JSON text is formatted, other text is printed as written, and media produces summaries. Recommend --raw when a parser needs the full JSON result. The canonical CLI documentation already describes this distinction. Apply the clarification to both skill copies. This should be fixed but may follow up; it does not block approval.

[corespeed-hopper]

Approved. The prior P2 output-format finding is resolved in both skill copies. No surviving findings or new blockers.

Cycle 2, round 1/5. Reviewed the delta from previously approved 0822dad to 9955fce. Merge base remains 37b37f8.

The only change corrects the stdout contract and directs JSON parsers to --raw. This matches the published cs 0.5.0 code and the prior targeted fixtures. Both skill copies are byte-identical at the new SHA; git diff --check passed. No code changed, so the earlier fixtures were not rerun.

CI passed on this exact head: manifests and scan.

Reviewer session: ed1945d8-2696-4267-a850-653d4848222f.