compound-engineering

Compound Engineering Plugin

Development tools that compound. Every task you complete makes the next one faster -- not through magic, but through structured knowledge capture and reuse.

29 specialized agents. 24 commands. 21 skills. One workflow that actually works.

Quick Start

# 1. Add the marketplace
claude /plugin marketplace add https://github.com/The-Rabak/compound-engineering-plugin

# 2. Install the plugin
claude /plugin install compound-engineering

# 3. Navigate to your project and run setup
/compound-engineering:setup

Setup auto-detects your stack (Laravel, NestJS, Python, Vue, TypeScript, Rust, etc.) and configures the right review agents for your project.

The canonical source now lives in portable/compound-engineering/. This repository also ships generated Copilot assets under .github/, built from that same portable source.

Generated platform outputs under .github/, plugins/compound-engineering/, and .claude-plugin/marketplace.json are intentionally committed in this repository. Local workflow artifacts such as .copilot-instructions.md, compound-engineering.local.md, .worktrees/, and docs/execution-sessions/ are local-only and should stay ignored.

Regenerate platform outputs

bun run build:platforms

That rebuilds:

• plugins/compound-engineering/ for Claude Code
• .github/ for Copilot

To verify generated files are committed and in sync (same check run in CI):

bun run verify:generated

Sync OpenViking globals

bun run sync:ov
# or override the helper path when testing
OV_CORE_PATH=/path/to/ov-core.sh bun run src/index.ts sync-ov portable/compound-engineering

This refreshes the global OV agent registry, the global OV skill registry, and mirrored skill support files from the portable source so future sessions in any project can reuse them.

Reference OV bootstrap assets and instructions live under src/ov_setup/. They are sanitized examples copied from a local OV setup so contributors can bootstrap the same workflow without committing machine-specific state.

How It Works

The plugin is built around a plan → build → review → learn cycle. Each phase is a standalone command, and learnings from every cycle persist and feed into the next one. The learnings-researcher agent surfaces past solutions during planning and review, so you don't solve the same problem twice.

  ┌──────────┐      ┌───────────────┐
  │  PLAN    │─────▶│  DEEPEN PLAN  │
  └────┬─────┘      └───────┬───────┘
       │                    │
       ▼                    ▼
  ┌──────────────────────────────────────────┐
  │              WORK                        │
  │                                          │
  │  Orchestrator decomposes plan into tasks │
  │                                          │
  │    ┌────────────┐  ┌────────────┐        │
  │    │ subagent 1 │  │ subagent 2 │  ...   │──▶ commits
  │    └────────────┘  └────────────┘        │
  │           │              │               │
  │           ▼              ▼               │
  │    ┌─────────────────────────────┐       │
  │    │  learnings brief (shared)   │       │    ◀── Ralph Loop
  │    └─────────────────────────────┘       │    variation:
  │           │                              │    iterate until
  │           ▼                              │    all tasks pass
  │    regression guard ──▶ next task        │
  └──────────────────────────────────────────┘
       │
       ▼
  ┌──────────────────────┐
  │       REVIEW         │
  │  (parallel agents)   │──▶ findings
  └──────┬───────────────┘
         │
         ▼
  ┌──────────────────────┐
  │      COMPOUND        │
  │  (capture learnings) │──▶ docs/solutions/
  └──────────────────────┘

The work phase is where the heavy lifting happens. It implements a variation of the Ralph Loop -- an iterative execution engine that decomposes a plan into scoped chunks, delegates each to a focused subagent, accumulates learnings across tasks, and runs regression guards after every chunk. The orchestrator never writes code itself; it decomposes, delegates, records, and routes. Each subagent gets a scoped prompt with only the context it needs plus a learnings brief filtered by domain relevance.

The Ralph Loop

The Ralph Loop is a self-referential iteration mechanism built on Claude Code's hook system. A stop hook intercepts the session exit, checks whether a completion promise has been met, and if not, feeds the original task back into the conversation with updated iteration state. This creates persistent, goal-directed execution with a guaranteed termination condition.