Execute a plan with checkpoints

LingCode is fast enough to power through a multi-step plan in one continuous run. That feels like a win until you read the diff at the end.

Three things happen when there are no mid-run checkpoints:

• Architectural drift compounds. Step 2 picks a slightly-wrong pattern. Step 3 builds on it. By step 8, every file is shaped around the wrong pattern, and fixing it means redoing eight steps, not one. The right time to catch the step-2 mistake is right after step 2.
• Review fatigue kicks in. Reviewing one file is easy. Reviewing forty files of agent-written code in one sitting is grueling, and you'll skim. Skimmed reviews approve bugs.
• You lose the cheap rollback. If something's wrong at step 3 of 12, reverting one step is trivial. If something's wrong "somewhere in this 40-file diff," you're either accepting the whole thing or starting over.

Checkpoints are the cure: after each plan step (or each pair of related steps), LingCode stops, summarizes what it changed, and waits for you to confirm before continuing. The cost is small interruptions. The payoff is catching drift while reverting is still one undo.

• A plan file in the repo. If you don't have one, see Write an implementation plan with LingCode first. The plan is what checkpoints check against.
• A clean working tree. Commit (or stash) any unrelated work. You want the checkpoint diffs to show only what LingCode did for the current step.
• Tests that run. Even if coverage is thin, you need a "tests pass" baseline so step-by-step verification has signal. If the suite is broken before you start, fix it before you start.

Tell LingCode to execute the plan one step at a time and stop after each. The default behavior is to power through; you have to opt out of that explicitly:

Execute IMPLEMENTATION_PLAN.md one step at a time.

After each step:
1. Summarize what you changed (files touched, behavior before
   vs. after) in 3-5 lines.
2. Run the verification specified for that step in the plan.
   Paste the actual output, not "looks good."
3. Stop and wait for me to confirm before starting the next
   step. Do not roll into the next step.

If a step fails verification, stop and diagnose — don't move on
hoping a later step will fix it. If the plan is wrong, propose
a plan amendment rather than silently deviating.

Start with step 1.

The three rules — summarize, verify, stop — are the whole skill. Everything else in this tutorial is how to keep LingCode on them when it drifts.

When LingCode hands back its checkpoint summary, read the summary first. Compare it to what the plan said this step would do.

• Matches the plan? Skim the diff to confirm, then approve.
• Did more than the plan? Push back. "Step 2 was supposed to add the database column. You also added the API endpoint — that's step 3. Revert the endpoint and let me approve it as its own step." Out-of-scope work hidden inside a checkpoint is the most common drift pattern.
• Did less than the plan? Ask what's missing. Sometimes LingCode hit an unexpected dependency and quietly punted; you want that surfaced, not skipped.
• Did something different? Pause for a real review. Either the plan needs to change (amend it explicitly) or the change needs to revert.

Each plan step should have specified how to verify it — see the plan-writing tutorial for why. At the checkpoint, run (or have LingCode run) that exact command and look at the actual output.

"Looks right" is not verification. "xcodebuild test -scheme MyApp exited 0 with 47 tests passing, 0 failures" is. Demand the latter.

If the verification fails, you've caught the problem at the exact step it appeared. Diagnose now, before step N+1 builds on top of it.

When a checkpoint passes — summary matches, verification green — commit the step on its own:

git add -A
git commit -m "Step 2: Add user_quota table and migration"

Per-checkpoint commits do three things:

• Make rollback trivial. If step 5 turns out to have been wrong, git revert on one commit, not a forty-file unpick.
• Give reviewers a story. The PR shows up as eight commits matching the eight plan steps, in order. Far easier to follow than one mega-diff.
• Anchor LingCode's context. When you say "go back to how step 4 left things," there's a real commit to reset to.

About half the time, executing a plan teaches you something that means the plan should change. That's fine — but the amendment is its own step.

When LingCode (or you) notices the plan needs to change:

Don't deviate silently. Update IMPLEMENTATION_PLAN.md to
reflect the new approach for steps 5-8, explain in 2 lines
why we're changing course, and commit just the plan edit:

git commit -m "Amend plan: switch step 5 from REST to GraphQL
because the existing schema is already exposed there"

Then wait for me to confirm before continuing execution.

The plan is your contract. When the contract changes, it changes in writing and gets signed off — not in passing inside a code commit.

If a checkpoint reveals the last step was wrong — wrong approach, broken verification, scope creep — recover deliberately:

1. Revert the commit. git revert HEAD, or git reset --hard HEAD~1 if it wasn't pushed and you want a clean history.
2. Update the plan, if the step itself was wrong. The original plan led you here; if you don't amend it, you'll get back to the same spot.
3. Re-run the step. Now from a known-good state, with corrected instructions.

This is exactly the workflow checkpoints exist to enable. Without them, "revert one step" isn't an option — the wrong code is mixed in with seven other steps of right code.

When the last plan step passes its checkpoint, the work is done — but verify one more thing:

• Run the full plan's verification end-to-end. Each step verified itself; now confirm they compose. "Each test passes individually" doesn't always mean "the whole suite passes together."
• Re-read the plan's non-goals. Make sure nothing scope-crept across the run. Mid-run scope creep is more obvious at checkpoints, but it's worth a final pass.
• Check the git log. Eight steps, eight commits, in order. If the log is messier than that, squash before opening the PR.

Open the PR with the plan file referenced in the body. Reviewers get the same checkpoint structure you did, just on read-only.

Package the execution workflow as a skill so LingCode applies it automatically whenever it's running a plan:

---
name: executing-plans
description: Use when you have a written implementation plan to execute in a separate session with review checkpoints. Triggers: 'execute the plan', 'work through the plan', 'implement IMPLEMENTATION_PLAN.md', 'do steps 1-5', 'start the plan'. Actions: stepwise execution, summarize each step, verify with real output, per-step commit, deliberate plan amendment, bad-step recovery. Stops mid-plan if a step changes architecture. Output: clean diffs per step + verification evidence.
---

Execute the referenced plan file (IMPLEMENTATION_PLAN.md by
default) one step at a time.

For each step:
1. Read the step from the plan file. Confirm understanding of
   what changes, why ordered here, and how to verify.
2. Make the changes.
3. Summarize: 3-5 lines covering files touched and behavior
   before vs. after.
4. Run the verification command specified by the plan. Paste
   the actual output.
5. Commit the step on its own with message "Step N:
   ".
6. Stop. Wait for user confirmation before starting the next
   step.

Never roll into a later step without confirmation. If a
verification fails, stop and diagnose — do not push past red.
If the plan turns out to be wrong, amend the plan file with a
brief reason, commit the amendment by itself, and wait for
sign-off before continuing.

At the end, run the full plan's verification end-to-end and
confirm nothing in the non-goals list crept in.

Save as ~/.lingcode/skills/executing-plans/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →