Compound Engineering

How it works

The workflow

After install you run /ce-setup once per project. It checks your tools, creates .compound-engineering/config.yaml, and offers additions to AGENTS.md. The README describes the loop as six steps, with "80% ... in planning and review, 20% ... in execution":

1. Brainstorm (ce-brainstorm, what to build). One question per turn, a set of possible approaches, and a readiness check that the requirements are complete, consistent, focused, and usable. It writes a requirements document to docs/plans/.
2. Plan (ce-plan, how to build it). Adds the approach to the same document, using research subagents in parallel. Plans that are kept go through ce-doc-review, which always checks coherence and feasibility and adds up to five more reviewers depending on the plan. The skill never implements.
3. Work (ce-work). Creates a feature branch, then implements the plan's units inline or with parallel subagents. Tests come first by default, commits are small, and each unit records its verification evidence.
4. Simplify (ce-simplify-code). Three reviewers in parallel look at code quality, reuse, and efficiency. ce-work triggers it when 30 or more lines of code have changed.
5. Review (ce-code-review). Sizes itself as lite, focused, or full. A full review always runs a correctness reviewer, adds a project-standards reviewer if the repository has standards files, and picks others from a pool of 16 personas, such as security, performance, data migration, and API contracts. By default the adversarial pass goes to a different vendor's model if its CLI is available. By default reviews only report findings, and they never push.
6. Compound (ce-compound). Writes one lesson from the work to docs/solutions/<category>/, with structured frontmatter (module, date, problem type) and fixed sections: problem, symptoms, what didn't work, solution, why it works, prevention. The bar: would a future engineer repeat the mistake if this document did not exist?

Shipping is ce-commit-push-pr, which opens the pull request with gh, then ce-babysit-pr, which follows CI and review comments. lfg runs the whole sequence without stopping and ends at an open, babysat pull request. It merges only if you allowed it for that run.

Other skills cover strategy (ce-strategy), ideation (ce-ideate), debugging (ce-debug), explaining code (ce-explain), optimizing against a metric (ce-optimize), prototypes, browser and Xcode testing, handoffs, and resolving PR feedback.

Components

• 36 skills, all prefixed ce- except lfg and wtf. The README groups them as the core loop (6), around the loop (4), on demand (8), git (5), autonomous (1), testing and design (4), collaboration (3), and utilities (5).
• No commands and no subagent definition files. Skills are invoked as /ce-plan and so on. Subagents are general-purpose agents given one of 67 prompt files stored inside the skills; 52 distinct roles, from correctness and security-sentinel to learnings-researcher and git-history-analyzer.
• No hooks and no bundled MCP servers. Context7 and XcodeBuildMCP are optional for two skills.
• 59 scripts inside skills, mostly Python, that handle mechanical steps such as working out the review scope and validating lesson frontmatter.

How it steers the agent

There are no hooks, so steering is written into the skills:

• Skills must read their reference files at set points: "Bundled references must be read, never approximated."
• Gates with names: a readiness check before planning, a "Mandatory Completion Contract" for plans, a causal-chain gate in debugging, and a review gate before shipping: "Code review must actually happen before shipping ... Never substitute a mental self-review."
• Receipts: steps return structured results, such as review findings as JSON and a status: complete receipt, and lfg advances only on a valid completion status.
• Git rules: "A bare git commit ... is forbidden", and never git add -A.
• Scripts do the mechanical work so the model does not reproduce it in prose.

Files it writes

• Plans and requirements: docs/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.md, read by the planning, work, review, and autonomous skills.
• Lessons: docs/solutions/<category>/<file>.md. A learnings-researcher subagent searches them during planning, and a learnings persona uses them during review; 15 of the 36 skills refer to this store.
• Vocabulary and direction: CONCEPTS.md (updated by ce-compound) and STRATEGY.md.
• Config: .compound-engineering/config.yaml, plus config.local.yaml for personal settings.
• Scratch files under .context/compound-engineering/ and /tmp.

docs_root in the config moves the docs/ directory. To gather its inputs, ce-compound also reads local session transcripts from Claude Code, Codex, Cursor, Pi, and oh-my-pi.

Install

On Claude Code:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Then run /ce-setup in the project. Claude Code is the source format and the only host validated in CI. Ten other hosts load native manifests from the repository, for example /add-plugin compound-engineering in Cursor, codex plugin marketplace add EveryInc/compound-engineering-plugin in Codex, and pi install git:github.com/EveryInc/compound-engineering-plugin in Pi (which also needs pi-subagents). Copilot, Factory Droid, and Qwen Code convert the Claude format themselves. Gemini CLI is replaced by Antigravity.

Needs git, bash, and Python 3. The PR skills need gh and only work with GitHub. Bun is needed only to develop the plugin.

When to choose it

• You want plans and lessons kept as files in the repository, so the next run starts from what the last one learned.
• You want planning and review to get more effort than implementation, with many reviewer roles.
• Your team uses more than one host: it installs natively on 11 and is converted by 3 more.

When not to

• You need pull-request automation on something other than GitHub.
• You want a small instruction surface you can audit. The skills folder holds about 34,000 lines of Markdown.
• You do not want code sent to a second model provider. Cross-model review is on by default when another vendor's CLI is available; turn it off with cross_model_review_mode: off.
• You want to add your own skills or reviewers inside the harness. The only documented extension point is Compound Packs, which are experimental.
• You want hard gates. Everything is instruction text; there are no hooks.

It has no telemetry: "No telemetry, ever." (STRATEGY.md)

Sources

• EveryInc/compound-engineering-plugin at 8a6e0a2: README.md, AGENTS.md, CONCEPTS.md, STRATEGY.md, PRIVACY.md, skills/*/SKILL.md and their references, plugin manifests, .github/workflows/
• Compound engineering: how Every codes with agents (linked from the README, not read)
• DeepWiki was not used: it was unreachable from the research environment.