Skip to content
changeloop

What is Change Loop?

Audience: project users. This guide explains what to review and decide; the agent handles routine system operations.

Change Loop is a software-change harness for AI coding agents. It gives the agent a repeatable way to agree on a change, implement it away from your working tree, prove it with real evidence, and only then bring it into the project.

Investigate? → Change → Build → Prove → Land

The five lifecycle steps, what each produces, who acts, and the return path when requirements shift.

It is not an AI, and it does not write code. It is a deterministic control plane around your coding agent. It does not replace your agent, test framework, CI system, or Git workflow either — it drives the tools your repository already owns.

The workflow is called Change Loop. Its installed package and CLI remain claude-foundation, so current commands and integrations keep working.

Users keep seven intent-level commands: /investigate, /change, /build, /prove, /land, optional /deliver, and /dev. The agent compiles one semantic draft and drives one advance coordinator; it does not ask the user to operate the internal CLI chain. The compiled OpenSpec packet remains the source of truth.

The problem it solves

Section titled “The problem it solves”

An AI coding agent will tell you it finished. That claim is usually the weakest link in the whole workflow: the agent read its own output, decided it looked right, and reported success. Nothing independently checked that the code runs, that the tests it claims to have written exist, or that the thing you asked for is the thing that shipped.

Change Loop refuses to take the agent’s word for it. Every observable behaviour the change promises becomes a claim with a stable ID, and a claim is only satisfied by a receipt produced by actually executing a project-owned tool. A passing command is not automatically proof, and an agent’s summary is never proof.

Who does what

Section titled “Who does what”

The agreement, implementation, and tool-produced evidence have different owners. Reviewer independence is a separate policy choice; see human approval.

Part Responsibility
You Define intent, make consequential decisions, review the result, and explicitly authorize Land
AI coding agent Investigates, writes the agreement, implements code and tests, fixes what evidence reports
Change Loop harness Controls lifecycle state, scope, sandboxes, evidence, proof freshness, budgets, and Land guards
OpenSpec Stores the durable, human-reviewable requirements and change agreement
Project tools Test runners, linters, Playwright, scanners — these produce the executable evidence
Git and CI Version control and automation, through your existing process

What makes it different

Section titled “What makes it different”

One native owner. The coding agent reads a compact change packet and owns implementation. There is no relay race between PM, lead, engineer, QA, and retro personas — that shape preserved quality but let orchestration dominate cost and latency.

Executable evidence. Claims select capabilities. Capabilities are satisfied by provider contracts that run your tools and produce receipts the runtime validates. Change Loop never installs a test framework or downloads a browser to make evidence appear.

Reuse before rerun. Receipts bind to code, agreement, claims, configuration, environment, protocol, and artifacts. Change a bound input and the receipt goes stale; leave it alone and the work is reused instead of repeated.

Transactional finish. Land records proof assurance, applies the explicitly authorized current sandbox, verifies identity, syncs specs, archives, and cleans up. An interrupted or multi-repository Land resumes from its journal rather than leaving you half-applied.

Risk, not size, selects rigor. Size only controls budget and slicing. A one-line change that touches an auth boundary is not treated as trivial.

Where to go next

Section titled “Where to go next”

Read in this order. You do not need the whole site before your first change.

  1. One change, start to finish — a picture and a worked example; where you appear
  2. Install — requirements and the two supported install paths
  3. Quickstart — take one change end to end
  4. The change loop — why the steps are separate and how work moves backward
  5. Your decisions — what only you approve
  6. Files and ownership — what is yours and what the harness manages

Later, as needed: configure foundation.json, work across repositories, add quality gates, or connect evidence tools. Agents and integrators use the lifecycle pages and the CLI reference.