Build Loop
A checked build loop for multi-file changes: assess, plan, execute, review, iterate, learn. Plan-verify, native debug-loop, dependency cooldown, DOE tuning.
Install
claude plugin marketplace add tyroneross/RossLabs-AI-Toolkit
claude plugin install build-loop@rosslabs-ai-toolkitOr direct from the build-loop source repo alone (no companion plugins):
claude plugin marketplace add tyroneross/build-loop
claude plugin install build-loop@build-loopThe Problem
Multi-step builds drift. The model writes code, declares success, and leaves silent failures: placeholder data that looks real, test stubs that never ran, UI pages that do not render, scope creep past the original goal. You forget an edge case. The diff drifts from the plan. The implementer makes a quiet design call you never see.
What I Built
Build Loop turns significant code changes into a checked, repeatable workflow: assess, plan, execute, review, iterate, learn. The plan names design decisions up front. The implementer reports which decisions it made. A lint compares the claim to the diff. Cheap checks catch obvious mistakes before tests run. Every number on the page traces back to a real source. The build stops if what shipped does not match what was promised.
/build-loop:run is the single command for any coding task. The orchestrator classifies intent and routes to the right mode — build, fix, refactor, optimize, research, or test. You do not choose the mode.
How It Works
| # | Phase | Purpose |
|---|---|---|
| 1 | Assess | Read state (project type, architecture, tools, prior runs); define goal + 3-5 scoring criteria with pass/fail conditions |
| 2 | Plan | Task breakdown with dependency order and parallel-safe groups; plan-verify lint + plan-critic before execute |
| 3 | Execute | Build locally or dispatch authorized parallel subagents with MECE file ownership |
| 4 | Review | Critic → Validate → Optimize (opt-in) → Fact-Check → Simplify → Auto-Resolve → Report — seven ordered sub-steps, single exit point; routes to Iterate on failure |
| 5 | Iterate | Repair Review failures and re-validate (up to 5x classic, 25x autonomous) |
| 6 | Learn (optional) | Detect recurring patterns across runs; auto-draft experimental skills/agents with A/B tracking |
The plugin picks the right model for each task: a strong model to plan and review, a faster model to write code, a small model for pattern checks. Plans with five or more synthesis dimensions auto-route to the strong model in one pass — five is the cutoff measured in testing where the fast model lost cross-decision context.
Native Debugging
Debug-loop, debugging-memory, and logging-tracer are built into the plugin as skills — root-cause investigation without a bundled MCP server. /build-loop:debug <symptom> runs causal-tree analysis, fix, verify, critique (up to 5 iterations). The orchestrator also auto-invokes the debug loop on Review-B Validate failures and Iterate attempts 2 and 3, so you usually do not call it manually. The standalone Coding Debugger plugin can be installed for extended cross-project incident memory; build-loop bridges to it when present and keeps going with local fallbacks when not.
Three Modes In One Plugin
- Build — features, refactors, migrations, schema changes, and any multi-file work.
- Optimize — measurable improvements using Design of Experiments instead of one-variable-at-a-time guessing. Test six variables at once and find out which one actually moved the number.
- Research — repo-grounded analysis before deciding whether to change code.
Hard-Won Defaults
Each round of dispatch-pattern testing has surfaced a default now baked into the loop:
- Plan verification before execution — the plan must name the goal, files, criteria, commands, and design decisions before build work starts.
plan-verifyruns a deterministic lint (delete-with-callers, numeric-drift, route-change-evidence, package-state, missing-evidence);plan-criticruns a soft critique. - Critic plus live validation for UI — passing tests do not mean the page renders. UI work needs a critic pass and browser or IBR-style evidence.
- Explicit ownership for workers — parallel workers get bounded MECE file ownership; the orchestrator integrates the final diff.
- Discoverability as a criterion — a shipped feature needs a path into the UI, not just a component on disk.
- Paid API guardrails — cost-bearing APIs require rate limits, failure handling, and explicit validation before release.
Dependency Cooldown
Build-loop refuses to install third-party JS packages (or version bumps) until the resolved version has been published for at least 7 days. Mitigates smash-and-grab npm compromises — a malicious version published then yanked within hours never reaches your lifecycle scripts. Three layers: native config injection (npm min-release-age, pnpm minimumReleaseAge, yarn npmMinimalAgeGate), a PreToolUse backstop hook for ungated projects, and a constitution rule with an advisory commit-auditor flag on <7d-old deps in lockfile diffs. User-authored scopes are exempt via a configurable allowlist.
Multi-Session Coordination
When more than one coding agent works the same repo, build-loop coordinates through Agent Rally Point — repo-local presence, write-boundary checks, durable handoffs. Auto-invoked at three trigger points (Phase 1 Assess preamble, Phase 3 chunk-close, Phase 4 Review-A); solo runs incur only a ~100-token status poll, peer runs auto-bootstrap a coord file and write presence. Lead leases prevent two orchestrators from claiming the same merge.
Host-Neutral
Claude Code gets slash commands, agents, hooks, and plugin bridges. Codex gets skills, AGENTS.md, and explicit subagent prompts only when the user authorizes parallel delegation. Other coding tools can still follow the same phase structure through a plain AGENTS.md contract. The bridges matter: build-loop can consult API Registry before integration work, architecture mapping (NavGator) before risky edits, debugger memory before repeating an old failure, and visual validation (IBR) when UI behavior matters. When a bridge is missing, the loop keeps going with local fallback checks.
Deployment Policy
Build-loop uses a repo-local policy before running push/deploy commands. Default: preview and TestFlight flows auto-run; production deploys, releases, publishes, and protected-branch pushes require explicit confirmation. Repos can override each target with auto, confirm, or block.