# loop-implement > Carry out an approved loop-plan plan phase by phase, with tests first, checkpoint reviews, and one commit per phase. `loop-implement` executes an approved `loop-plan` plan from its next incomplete phase to the end. For each phase it writes the tests first, implements the change, runs the acceptance commands, commits once, and records the result in the plan. It runs `review-impl` at the checkpoints the plan names. > **Caution:** > > It starts only from an approved plan. Without one it stops and points you to [loop-plan](https://cross-review.tlelabs.com/docs/skills/loop-plan/) and [review-plan](https://cross-review.tlelabs.com/docs/skills/review-plan/). ## When to use it - A `loop-plan` plan exists, its `Plan Review` reads `APPROVE` with a source, and you want the work carried out. - You are resuming a plan that stopped part way. It continues from the first incomplete phase whose dependencies are complete. ## Invoke it **Claude Code** ```text /loop-implement ``` **Codex** ```text $loop-implement ``` Add the plan path when you have more than one plan, for example `/loop-implement .cross-review/plans/move-tags-to-join-table-plan.md`. A plan outside `.cross-review/plans/` is used only when you give its path. ## What it works out by itself - **The plan.** It runs the `plans` command and takes the one plan with `format: "loop-plan"` and an incomplete phase. A plain markdown file in that folder is never run as a plan. - **Whether the plan may run.** `Plan Review` must read `APPROVE` with its source: `review-plan ` or `user `. `pending`, `REVISE`, or an approval without a source stops it. If the plan was edited materially after approval, it asks you. - **The state of the repository.** It reads the repository instructions, `git status`, the diffs and the recent commits. It keeps unrelated changes you made and never resets or reverts them. ## Round by round Each phase follows the same loop: 1. **Re-read the phase.** It checks only the paths and symbols the phase touches. 2. **Docs and tests first.** It updates the owning documentation, writes or strengthens the tests, and runs them to see them fail. The red result goes in one line. 3. **Implement.** It writes the production code through the real integration path, minimal and consistent with the project. 4. **Verify.** It runs each acceptance criterion’s narrow command, then the phase gates. 5. **Inspect the diff.** Only the phase’s files are staged, with no secrets and no leftovers of renamed names. 6. **Commit and record.** One commit with the planned message. The phase’s met criteria are ticked `- [x]`, and a progress line goes in `Progress Log`. The plan is staged only when git does not ignore it (see [Plans](https://cross-review.tlelabs.com/docs/guides/plans/)). 7. **Checkpoint.** When the plan lists this phase as a review checkpoint, it runs `review-impl`, with the model the plan names if any. The review decides how findings are handled. If the reviewer cannot run (not installed, not logged in, quota, repeated errors), it self-reviews the checkpoint against the same criteria, records `self-review (reviewer unavailable: )` in the progress line, and continues. A self-review is never recorded as a review approval. At the next checkpoint it tries the reviewer again on the whole diff since the last real review. ## Gate discipline - A gate that cannot run is a problem to fix (install, build, or start what the plan names), not a step to skip. - A failure that also happens without the change is a baseline failure. It is recorded and the work continues. Only new failures block. - A criterion that is not fully met is reported as `not done` with the reason. - When a migration or other state-changing step fails part way, it follows the plan’s retry or rollback path. Without one, it stops and asks. ## Changing the plan It does not add technology, dependencies, limits or mechanisms the plan does not contain. When it finds a real problem in the plan, it proposes one change as a decision with context, options, a recommendation and what happens if you agree. If you agree, it records a dated `Decision:` line in `Progress Log`, updates the sections the change touches, and does not rerun the plan review. ## Finalization When the last phase is done: 1. It runs every `Global Gates` command once on the final commit. 2. It runs the end-to-end scenario from `Completion Criteria` and compares the output with the expected output. 3. It audits the cumulative diff and history for problems that span phases. 4. It runs the final checkpoint with `review-impl` on the whole diff. 5. It fixes any defects with a regression test first, then reruns the affected gates. 6. It updates `Completion Criteria` in the final commit. ## What it stops for It stops only for a decision you must make, missing credentials or infrastructure, requirements that cannot both be met, or an irreversible action the plan does not authorize. A review stalemate is your decision. It asks one question at a time. ## What you can say in chat Your latest explicit instruction overrides the procedure. You can: | You say | Effect | | ---------------------------------------- | ------------------------------------------------------------------------ | | “Skip the review at phase 3” | The checkpoint is skipped and the progress line records your instruction | | “Accept the review result” | The current result is recorded as approved by you, not by the reviewer | | “Change the order” or “do phase 4 first” | It follows the order you give, if the dependencies allow it | | “Use model X for the checkpoint” | The checkpoint review runs with that model | | “Stop here” | It stops after the current step and reports the state | ## Example Project: orchard-api. The approved plan `add-webhook-retries-plan.md` has three phases and checkpoints after phases 1 and 3. - Phase 1 (retry queue storage) runs. Its tests fail first, then pass. The commit is `feat(webhooks): store delivery attempts`, and the checkpoint review runs with `review-impl`. The reviewer finds one issue, a missing index on the attempts table. It is fixed with a regression test in the same phase. - Phase 2 (backoff schedule) runs without a checkpoint. - Phase 3 (dead-letter handling) runs. The reviewer is not logged in, so the checkpoint is self-reviewed and the progress line says so. The final checkpoint runs again on the whole diff once the reviewer works. The report lists the commits, the gate results with baseline failures, the review outcomes including the self-review, the criteria marked `not done`, and remaining risks. See also [loop-plan](https://cross-review.tlelabs.com/docs/skills/loop-plan/) for writing the plan and [review-impl](https://cross-review.tlelabs.com/docs/skills/review-impl/) for how checkpoints are reviewed.