Philosophy
Each unit of engineering work should make subsequent units easier -- not harder.
Traditional development accumulates technical debt. Every feature adds complexity. Every bug fix leaves behind a little more local knowledge that someone has to rediscover later. The codebase gets larger, the context gets harder to hold, and the next change becomes slower.
Compound engineering inverts this. 80% is in planning and review, 20% is in execution:
- Plan thoroughly before writing code with
/ce-brainstormand/ce-plan - Review to catch issues and calibrate judgment with
/ce-code-reviewand/ce-doc-review - Codify knowledge so it is reusable with
/ce-compound - Keep quality high so future changes are easy
The point is not ceremony. The point is leverage. A good brainstorm makes the plan sharper. A good plan makes execution smaller. A good review catches the pattern, not just the bug. A good compound note means the next agent does not have to learn the same lesson from scratch.
Workflow
/ce-strategy is upstream of the loop -- it captures the product's target problem, approach, persona, metrics, and tracks as a short durable anchor at STRATEGY.md. Ideate, brainstorm, and plan read it as grounding when present, so strategy choices flow into feature conception, prioritization, and spec.
The core loop is: brainstorm the requirements, plan the implementation, work through the plan, review the result, compound the learning, then repeat with better context.
Use /ce-ideate before the loop when you want the agent to generate and critique bigger ideas before choosing one to brainstorm. It produces a ranked ideation artifact, not requirements, plans, or code.
| Skill | Purpose |
|---|---|
/ce-strategy |
Create or maintain STRATEGY.md -- the product's target problem, approach, persona, key metrics, and tracks. Read as grounding by ideate, brainstorm, and plan |
/ce-ideate |
Optional big-picture ideation: generate and critically evaluate grounded ideas, then route the strongest one into brainstorming |
/ce-brainstorm |
Interactive Q&A to think through a feature or problem and write a right-sized requirements doc before planning |
/ce-plan |
Turn feature ideas into detailed implementation plans |
/ce-work |
Execute plans with worktrees and task tracking |
/ce-debug |
Systematically reproduce failures, trace root cause, and implement fixes |
/ce-code-review |
Multi-agent code review before merging |
/ce-compound |
Document learnings to make future work easier |
/ce-product-pulse |
Generate a single-page, time-windowed pulse report on usage, performance, errors, and followups. Saves to docs/pulse-reports/ |
Quick Example
A typical cycle starts by turning a rough idea into a requirements doc, then planning from that doc before handing execution to /ce-work:
/ce-brainstorm "make background job retries safer" /ce-plan docs/brainstorms/background-job-retry-safety-requirements.md /ce-work /ce-code-review /ce-compound
For a focused bug investigation:
/ce-debug "the checkout webhook sometimes creates duplicate invoices" /ce-code-review /ce-compound
Getting Started
After installing, run /ce-setup in any project. It checks your environment, installs missing tools, and bootstraps project config.
The compound-engineering plugin currently ships 37 skills and 51 agents. See the full component reference for the complete inventory.
Claude Code
/plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering
Cursor
In Cursor Agent chat, install from the plugin marketplace:
/add-plugin compound-engineering
Or search for "compound engineering" in the plugin marketplace.
Codex
Three steps: register the marketplace, install the agent set, then install the plugin through Codex's TUI.
codex plugin marketplace add EveryInc/compound-engineering-plugin bunx @every-env/compound-plugin install compound-engineering --to codex
Launch codex, run /plugins, find the Compound Engineering marketplace, select the compound-engineering plugin, and choose Install.
GitHub Copilot
For VS Code Copilot Agent Plugins:
Chat: Install Plugin from Source EveryInc/compound-engineering-plugin compound-engineering
For Copilot CLI:
/plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering@compound-engineering-plugin
Factory Droid
droid plugin marketplace add https://github.com/EveryInc/compound-engineering-plugin droid plugin install compound-engineering@compound-engineering-plugin
Qwen Code
qwen extensions install EveryInc/compound-engineering-plugin:compound-engineering
Local Development
bun install bun test bun run release:validate
From your local checkout
For active development -- edits to the plugin source are reflected immediately.
alias cce='claude --plugin-dir ~/Code/compound-engineering-plugin/plugins/compound-engineering'
Run cce instead of claude to test your changes.
Troubleshooting
bunx @every-env/compound-plugin install compound-engineering --to codex
bunx @every-env/compound-plugin cleanup --target codex
bunx @every-env/compound-plugin cleanup --target copilot bunx @every-env/compound-plugin cleanup --target droid bunx @every-env/compound-plugin cleanup --target qwen
Limitations
Codex native plugin install currently handles skills, not custom agents. The documented Bun followup is required until Codex supports agents in its native plugin spec.
OpenCode, Pi, Gemini, and Kiro installs are converter-backed and may change as those target formats evolve.
Release versions are owned by release automation. Routine feature PRs should not hand-bump plugin or marketplace manifest versions.
FAQ
About Contributions
Please don't take this the wrong way, but I do not accept outside contributions for any of my projects. I simply don't have the mental bandwidth to review anything, and it's my name on the thing, so I'm responsible for any problems it causes; thus, the risk-reward is highly asymmetric from my perspective. I'd also have to worry about other "stakeholders," which seems unwise for tools I mostly make for myself for free. Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won't merge them directly. Instead, I'll have Claude or Codex review submissions via gh and independently decide whether and how to address them. Bug reports in particular are welcome. Sorry if this offends, but I want to avoid wasted time and hurt feelings. I understand this isn't in sync with the prevailing open-source ethos that seeks community contributions, but it's the only way I can move at this velocity and keep my sanity.