compound-engineering

Compound Engineering

AI skills that make each unit of engineering work easier than the last.

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-brainstorm and /ce-plan
• Review to catch issues and calibrate judgment with /ce-code-review and /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.

Learn more

• Compound engineering: how Every codes with agents
• The story behind compounding engineering

Workflow

The core loop is six steps: brainstorm the requirements, plan the implementation, work through the plan, simplify what you wrote, review the result, then compound the learning -- and repeat with better context.

Skill	Purpose
/ce-brainstorm	Interactive Q&A to think through a feature or problem and write a right-sized requirements doc
/ce-plan	Turn the requirements into a detailed implementation plan with guardrails
/ce-work	Execute the plan with worktrees and task tracking
/ce-simplify-code	Refine the freshly written code for clarity and reuse before review
/ce-code-review	Multi-agent review against the plan before merging
/ce-compound	Capture the learning into docs/solutions/ so the next loop starts smarter

Each cycle compounds: /ce-compound writes learnings that the next /ce-brainstorm and /ce-plan read as grounding -- brainstorms sharpen plans, plans inform future plans, reviews catch more issues, patterns get documented. That return arrow is the whole point.

Additional skills

These sit around the loop or get reached for on demand -- not every cycle needs them.

Skill	When to reach for it
/ce-ideate	Before the loop, when you don't yet know what to build -- generates and critically ranks grounded ideas, then routes the strongest one into /ce-brainstorm
/ce-strategy	Upstream anchor -- creates and maintains STRATEGY.md, read as grounding by ideate, brainstorm, and plan so strategy choices flow into every feature
/ce-product-pulse	Outer loop -- a time-windowed report on what users actually experienced (usage, performance, errors), saved to docs/pulse-reports/; its follow-ups feed back into ideation and brainstorming
/ce-debug	Instead of brainstorm -> plan -> work when the input is a bug rather than a feature -- reproduce, trace the causal chain to root cause, then fix

For the full catalog and how each skill chains together, see docs/skills. The complete inventory is below.

Quick Example

Finding a direction -- when you don't have a specific idea yet, ideate first, then carry the strongest survivor into the loop:

/ce-ideate new drawing tools
/ce-ideate surprise me
/ce-ideate github issues   # ground ideas in your open issues instead of a prompt

/ce-ideate does the homework first (codebase, past learnings, prior art on the web, optionally your issue tracker), then hands you a ranked set of grounded candidates to take into /ce-brainstorm.

Standard feature loop -- turn a rough idea into shipped, reviewed code:

/ce-brainstorm make background job retries safer
/ce-plan
/ce-work
/ce-simplify-code
/ce-code-review
/ce-compound

Simplifying code -- use it after fresh implementation work, or point it at code that keeps slowing changes down:

/ce-simplify-code
/ce-simplify-code simplify the code in my most-churned file

The first pass tightens recent branch changes before review. The targeted pass is useful when one file keeps absorbing unrelated fixes, follow-ups, or merge conflicts.

Debugging a bug -- when you start from broken behavior instead of a feature: