Compound engineering, one level up

---

I use Every's compound-engineering plugin all day every day inside of Conductor. It is the best writeup I've found of how to actually work with coding agents. Its premise is that each unit of engineering work should make the next one easier. So it walks you through brainstorm, plan, work, review, and compound. /ce-compound writes the lesson into docs/solutions/ so the next time around starts from what you learned. It has around 23k GitHub stars.

The limitation I kept hitting is scale.

Each of those skills works on a single feature. /ce-plan breaks a feature into units. /ce-work runs agents across worktrees to build it. /lfg takes a feature all the way from a plan to an open PR with passing CI, no hands on the wheel. None of them go up a level, though. Nothing takes a project that's twenty features deep and lays out the pieces, the dependencies, and the order to build them. And nothing remembers where that project stands once you close the tab.

The memory part is what got me. Compound engineering remembers lessons well. That's what docs/solutions/ is for. It doesn't remember state. Which tickets are done, which are blocked, what has to land before what. All of that lives in the chat session, and the chat session goes away when you close it. You come back Monday and the project's shape is gone, so you rebuild it from git log and whatever you can recall.

I would often create an "orchestrator" session to break down an epic into tickets in Linear or GitHub, help me figure out what model I would need for each ticket, and then bring those tickets into new sessions to compound engineer. Then, back to the orchestrator to update the status or have it pull from git and the ticket tracker, and on to the next. And it felt more manual than all of this is supposed to feel.

I tried to land this in CE itself first, opening a PR that added the decomposition step as a beta skill. A maintainer closed it, and the reasoning was fair: a breakdown sitting above the plan wasn't a direction they wanted, and it cut against upcoming work to fold things into single docs instead of splitting them. That's a real disagreement, not an oversight. They're betting on fewer, richer docs; for a whole project, I wanted the opposite.

So I built a plugin for the level above: compound-engineering-orchestrator. It depends on Every's plugin and calls the CE skills directly instead of rebuilding them, and it works by copying one of the ideas that already make CE good.

The one idea

Write the durable thing to a file so the session can be throwaway. Here the durable thing is a task graph: a set of committed markdown files describing the project as feature-sized nodes with dependencies. Status isn't stored. It's computed from git on read, so a node is done when its PR merges. Nothing goes stale, and any session on any machine rebuilds the same picture from the files. I've run a project this way for weeks, across many sessions and two machines, and the graph has held the state the whole time.

Four skills work over it, all invoked by hand. /orch-decompose builds the graph. /orch-ripen plans many nodes at once. /orch-next picks the next move. /orch-fanout builds a batch in parallel.

Turning a project into a graph

I pointed /orch-decompose at a scoping doc for a cross-team migration (moving some newsletters between vendors) and it gave back a graph. Each feature-sized piece became a node tagged with its stage (needs discussion, needs a plan, or ready to build), a suggested model tier, and its dependencies, plus a critical path and a self-audit for cycles and orphans. It didn't pretend the fuzzy parts were solid. Only the ready nodes got a real plan, the rest stayed briefs.

What surprised me was the non-engineering work. It pulled a billing sign-off and a data-privacy review out as their own nodes. Those aren't coding tasks, and they're exactly what slips a schedule because nobody tickets them.

The full 11-node graph

Node	Title	Stage	Model	Depends on
n1	User Profile weekly export: add per-contact roster columns	plan	generation	nothing (root; external repo)
n2	Create HubSpot newsletter properties + private app	work (no-PR)	ceiling	nothing (root)
n3	Roster ingest + coordinate join at kickoff	work	generation	n1, n11
n4	HubSpotService (Imports API client) + secrets wiring	work	ceiling	n2
n5	HubSpot delivery task + finalize wiring behind flag	work	generation	n3, n4, n11
n6	Decide contact-creation / marketing-billing policy	brainstorm	ceiling	nothing (root)
n7	PII-in-S3 access + retention review	work (no-PR)	ceiling	nothing (root)
n8	Parallel run + cutover, retire Cordial path	work (no-PR)	ceiling	n5, n6, n7, n9, n10
n9	HubSpot email templates (merge-field render)	work (no-PR)	ceiling	n2
n10	Parity testing: HubSpot vs Cordial output	work	generation	n5
n11	Delivery performance & sharding design	plan	ceiling	nothing (root)

• Roots (ready now): n1, n2, n6, n7, n11

• Critical path: n1 → n3 → n5 → n10 → n8

Running it

/lfg needs a plan to run. /orch-ripen writes them in bulk, planning every node whose upstream decisions are settled, so fan-out has a wide frontier of ready work.

/orch-fanout builds the ready nodes at once. It groups them so no two touch the same file, then stops and shows me the wave (which nodes, which model tier, which worktrees) before spawning anything. Each node runs in its own worktree through the full pipeline: plan, implement, review and apply fixes, commit, push, PR, watch CI. It lands on a green PR it doesn't merge. A wave usually gives me three to five at once. They don't have to share a model; I put mechanical work on a cheaper tier and architectural work on the strongest, and I'm starting to run nodes on non-Claude models just to see how it works and to save on costs.

The review step earns its keep. More than once it caught a real bug and fixed it before the PR reached me. Each wave checkpoints recovery state, and a circuit breaker halts everything if it starts failing across the board.

Then I take over: run CI, review, merge. The orchestrator tells me up front whether order matters and what it is, from the file overlaps, migrations, and dependencies. It's not automatic. On one wave the workers re-planned against just-merged code and quietly landed on the same files, independent when grouped and not by the time the PRs existed. It caught that and gave me the order.

What it won't do

It draws a hard line between "could start" and "safe to run unattended." It won't fan out a node with no PR, like an ops task or a data load. It won't drive a decision or a brainstorm, because those are conversations. And I've watched it stop /lfg halfway to say a plan was too large and too data-dependent to verify in one pass, then ship the slice it could test and leave the rest.

That caution paid off on an ops task against production it refused to drive. I ran it by hand and hit a subtle infrastructure bug, the kind only a live run exposes and a clean diff would hide while reporting success. When its first theory was wrong, it said so and stopped guessing instead of shipping another patch.

Who it's for

I built the orchestrator with the loop it scales, running decompose on its own roadmap and building each rung with the last, and it captures its own rough edges into docs/solutions/ as it goes. It's early: a solo work project, low version number, leaning on Every's plugin, Claude Code, git, and worktrees. But it's driven a multi-week project to dozens of merged PRs across model tiers and even vendors.

If your single-feature agent work already feels good but a whole project puts you back to tracking dependencies in your head and rebuilding state every session, that's the gap it fills. CE got me a feature at a time; this got me the project.

The plugin is on GitHub (MIT). It needs Every's compound-engineering plugin alongside it.