Summary
I'd love to see an official version of the Compound Knowledge plugin that works with OpenAI Codex CLI. Today the plugin is built specifically for Claude Code — installation goes through the Claude Code plugin marketplace (/plugin marketplace add ...), the workflows are exposed as Claude Code skills/agents, and the customization layer reads CLAUDE.md. None of that carries over to Codex, so Codex users can't adopt the compounding-knowledge loop.
Problem / motivation
The core value of this plugin — the /kw:brainstorm → plan → confidence → review → work → compound loop, with learnings saved to docs/knowledge/ and surfaced automatically next time — is agent-agnostic in principle. But the current implementation is tied to Claude Code:
- Install path: requires the Claude Code plugin marketplace; there's no equivalent entry point for Codex.
- Commands/agents: the 6 skills, 2 review agents, and 3 research agents are defined as Claude Code components.
- Customization: the strategic-alignment and data-accuracy reviewers read
CLAUDE.md for business context, data hierarchy, and style guides.
As a Codex user, I can't take advantage of any of this, even though my projects already use the same plans/ + docs/knowledge/ markdown convention the plugin relies on.
Proposed solution
Provide a Codex-supported distribution of the plugin. A few possible directions (open to whatever fits your architecture best):
- Map the
/kw:* workflows onto Codex's command/prompt mechanism so the same loop is callable in a Codex session.
- Read project context from a config-agnostic source (e.g. also support
AGENTS.md / a generic config file) in addition to CLAUDE.md, so the reviewers work regardless of which agent is running.
- Document a Codex install/setup path equivalent to the current Claude Code marketplace flow.
Since the knowledge files are already plain, git-tracked, greppable markdown, the underlying knowledge layer should port cleanly — the work is mostly in the agent-integration layer.
Alternatives considered
- Manually copying the prompts into Codex by hand — works in a pinch but loses the parallel research/review agents, the auto-surfacing of past learnings, and the install/update experience.
Additional context
- Plugin currently documents Claude Code as the only supported host.
- Happy to help test a Codex build or provide feedback on the integration. Thanks for building this — the compounding-knowledge concept is great and I'd like to use it in my Codex workflow.
- The plugin is cited/recommended to use within this Every guide to Codex here: https://every.to/guides/codex-for-knowledge-work > Level 5: Compound your Codex system.
Summary
I'd love to see an official version of the Compound Knowledge plugin that works with OpenAI Codex CLI. Today the plugin is built specifically for Claude Code — installation goes through the Claude Code plugin marketplace (
/plugin marketplace add ...), the workflows are exposed as Claude Code skills/agents, and the customization layer readsCLAUDE.md. None of that carries over to Codex, so Codex users can't adopt the compounding-knowledge loop.Problem / motivation
The core value of this plugin — the
/kw:brainstorm → plan → confidence → review → work → compoundloop, with learnings saved todocs/knowledge/and surfaced automatically next time — is agent-agnostic in principle. But the current implementation is tied to Claude Code:CLAUDE.mdfor business context, data hierarchy, and style guides.As a Codex user, I can't take advantage of any of this, even though my projects already use the same
plans/+docs/knowledge/markdown convention the plugin relies on.Proposed solution
Provide a Codex-supported distribution of the plugin. A few possible directions (open to whatever fits your architecture best):
/kw:*workflows onto Codex's command/prompt mechanism so the same loop is callable in a Codex session.AGENTS.md/ a generic config file) in addition toCLAUDE.md, so the reviewers work regardless of which agent is running.Since the knowledge files are already plain, git-tracked, greppable markdown, the underlying knowledge layer should port cleanly — the work is mostly in the agent-integration layer.
Alternatives considered
Additional context