I built it because I was tired of keeping the orchestration logic in my head - spawning a separate session for a blind review, switching back to the implementing session to evaluate results, deciding what to build next. I had plugins for the individual pieces but the sequencing was still on me. I wanted a harness that handled the full loop, and one that was generally useful across projects, not hardcoded to a specific codebase.

You give it a specification - a prompt, a plan file, a PRD - and eforge assesses complexity against your codebase, selects a workflow (simple changes get a fast path, complex ones decompose into a dependency graph of sub-plans), builds in isolated git worktrees, reviews, and validates - all without supervision.

The way I actually use it: I plan a feature interactively in Claude Code, then run `/eforge:build`. The plugin picks up the plan, enqueues it, and a daemon takes over. eforge pulls plans off the queue, understands dependencies between them, executes in parallel where possible, and merges in topological order. Queued work is re-assessed before execution so changes from earlier builds are accounted for, not blindly applied to a codebase that has moved on. I check the results when builds finish - a web monitor dashboard tracks progress, cost, and token usage in real time. eforge builds itself this way.

Each build phase gets its own agent - planner, builder, reviewer, evaluator, fixer. The reviewer runs in a fresh context with no knowledge of how the code was written. Anthropic's engineering team independently arrived at the same pattern (https://www.anthropic.com/engineering/harness-design-long-ru...) - their finding: solo agents approve their own work; adversarial evaluation dramatically improves quality. An evaluator then applies per-hunk verdicts, accepting strict improvements while rejecting anything that alters intent.