Compound Engineering Claude skills

Running the compound engineering loop step by step

The README describes a loop of brainstorm, plan, build, review, then capture what you learned. On a typical feature in a real repo, the skills fit together like this:

1. Understand the area first (optional). If you are touching code you don't know, ask ce-explain how the relevant behavior works and why it exists. Its reference files include a closing Check yourself section, with questions first and answers after, so you can test your understanding before you change anything.
2. Brainstorm. Run ce-brainstorm on the rough request. It produces a requirements document and is the step where a human approves direction. Its dialogue reference tells the agent to bring ideas, alternatives and challenges instead of only interviewing you, and to leave technical implementation choices for planning.
3. Plan. ce-plan turns the requirements into an implementation plan. When a choice between approaches needs real exploration, ce-plan can route to ce-bakeoff on its own.
4. Build. ce-work implements the plan. It ships a cross-model-work.sh script, so other models can take part in the work.
5. Review. ce-simplify-code and ce-code-review check the result. ce-code-review is one of the heaviest skills in the repo, with 33 reference files and 6 scripts, most of them specialist reviewer prompts.
6. Compound. ce-compound writes the lessons into the repo so the next cycle can read them. ce-compound-refresh is a separate skill with its own scripts and template, built for revisiting that stored knowledge later.

Once you trust the steps after brainstorming, /lfg chains them hands-off.

Invocation syntax differs by host. The README uses /skill-name on slash-command hosts such as Claude Code. In Codex you invoke installed skills with $skill-name, for example $ce-plan and $lfg. In oh-my-pi (omp), prompts can model-route to visible skills, and manual-only or hidden skills use the native /skill:<name> form.

Choosing between ce-bakeoff, ce-pov, ce-ideate and ce-explain

Several skills outside the main loop sound alike. Their SKILL.md files describe how each one differs:

• ce-ideate is for an open field. Use it when you are still looking for opportunities and have no defined goal.
• ce-brainstorm is for product goals that aren't settled yet. It turns a vague request into requirements.
• ce-bakeoff is for a defined goal whose alternatives haven't been developed. It builds at least two independent candidate solutions against the same brief, has them assessed independently, compares them, and synthesizes a winning approach. The output is non-executable: approach briefs, architectural sketches, product mechanisms or directional pseudocode. The skill says plainly not to turn a routine choice into a competition, and it will not reopen a decision you have already settled. ce-plan and ce-debug call it on their own conditions. ce-brainstorm uses it only when you ask.
• ce-pov is for options that are already developed and need judgment. The README says adding "oracle this" brings in independent model opinions.
• ce-explain is for understanding existing behavior before a change.

The bake-off skill also hands off evidence questions it cannot answer by reasoning alone. Runtime claims go to ce-optimize, which runs experiments. Choices that depend on how something feels to use go to ce-prototype. The README notes that ce-explain and ce-pov can feed into another workflow without a separate round of human interaction, so a plan or debug session can pull in an explanation or a recommendation on the way.

How ce-babysit-pr decides how far to go

ce-babysit-pr keeps an open pull request moving toward merge. It works on GitHub only, including GitHub Enterprise. It reacts to three streams as they arrive. Review comments go to ce-resolve-pr-feedback, CI failures go to ce-debug, and the skill also handles branch-currency items, such as a branch that is behind its base. Its description says it is meant for watching a PR over time or updating an old one, not for resolving one comment or fixing a single CI failure. Before it starts, it judges whether an old PR still belongs.

Each run has one posture, and the posture sets how much authority the agent has:

• target works only on the named PR and stops at looks-ready. It never merges.
• stack-ready walks up a stacked set of PRs. Once a layer has no actionable backlog, it moves to the next open, non-draft layer that needs work. It never merges.
• stack-land does everything stack-ready does, and choosing it counts as permission to land. Once the bottom open layer is settled, it runs gh stack merge and gh stack sync.

The skill's rules say merge-readiness is never merge authorization except under stack-land. The argument hint accepts a PR number, URL or blank for the current branch, a watch or checkpoint mode, a duration, and the posture. If you only want an agent to get a PR ready for human review, use target and you keep the merge decision.

Setup and upgrade gotchas

The install commands are on the page already. These details from the README tend to trip people up:

• Upgrading in Claude Code. Refresh the marketplace before you update. The README warns that running /plugin update alone keeps you on the old version.
• Codex app. Compound Engineering is not in Codex's built-in plugin marketplace yet. Open Plugins in the sidebar, click the arrow next to Create, choose Add marketplace, and enter EveryInc/compound-engineering-plugin as the source with main as the git ref and sparse paths left blank. Then install compound-engineering-plugin and restart Codex.
• Codex profiles. For a non-default profile, run every step against the same CODEX_HOME, for example CODEX_HOME="$HOME/.codex/profiles/work" in front of both the marketplace and plugin commands. The marketplace step only makes the plugin available. The plugin install is what activates the skills for that profile.
• No extra agent setup. On Codex, the specialist reviewer and research behavior lives inside the skills as local prompt assets. You don't install custom agents separately.
• Grok Bot. It uses your Cursor account and plugin library. Install through Cursor Agent chat with /add-plugin compound-engineering. Do not run that command in the Grok Bot chat, and do not clone the repo onto the Grok Bot computer.
• Session history. A ce-compound reference describes a session-history probe that looks for Claude sessions under ~/.claude/projects/ (or under CLAUDE_CONFIG_DIR if set) as well as Codex session files. If the bundled scripts are missing, it skips the probe. If you keep agent transcripts private, know that the compound step may read them locally.
• Skill count. The README badge says 36 skills, while the repo holds more skill folders. One of them, ce-skill-work under .agents/skills, applies the repo's own skill-authoring standard to changes under skills/**. It is for contributors editing the plugin, not for everyday feature work.