Use when you have a written implementation plan file to execute in a session with human review checkpoints between batches. NEVER use when no written plan exists, when the task is exploratory or open-ended, or when no clear stop-and-report structure has been agreed upon.
Batch execution with checkpoints for architect review. Follow the plan exactly. Report between batches. Stop when blocked.
Default batch size is 3 tasks. Adjust based on task complexity:
| Task Type | Batch Size | Reason |
|---|---|---|
| Simple file moves, renames, config edits | 5-8 | Low risk, easy to reverse |
| Standard feature work with tests | 3 | Default -- balanced risk |
| Complex logic, multiple interacting systems | 2 | Errors compound quickly |
| Infrastructure, database migrations, deploys | 1 | Each step must be verified before next |
For each task in the batch:
When the batch is complete:
Based on feedback:
After all tasks are complete and verified:
Stop executing immediately when:
Ask for clarification rather than guessing. A wrong interpretation compounds across every subsequent task.
Drift means execution is diverging from the written plan. Stop and report when:
Drift is not always bad -- but it must be surfaced, not silently absorbed.
Return to Step 1 (full plan re-read) when:
Do not force through blockers. Stop and ask.
Common failures during plan execution:
| Rationalization | Why It Is Wrong |
|---|---|
| "The plan step is obvious, I can infer what it means." | Ambiguity in plans is a signal to stop and ask, not to interpret. Wrong interpretations compound across all subsequent tasks. |
| "I'll skip verification this once since the change is small." | Small changes have broken large systems. The verification step exists precisely for changes that seem safe. |
| "I'll fix this minor plan error myself rather than interrupting the human." | Plan deviations -- even small ones -- must be surfaced. The human needs to know the plan was wrong. |
| "I'll do 6 tasks this batch since they're all simple." | Batch size calibration exists for a reason. Simple tasks can have complex interactions. Stick to the calibrated size. |
| "The test is failing for an unrelated reason, I'll continue anyway." | A failing test is a failing test. Do not rationalize past it. Stop, report, get guidance. |
| "I'll add this small improvement while I'm in the file." | Unauthorized changes break the checkpoint model. Every change must be in the plan or explicitly approved. |
| "The plan is outdated, so I'll use my judgment for this section." | An outdated plan is a reason to stop and get an updated plan, not a license to improvise. |
| "Reporting after every batch is slow. I'll do 2 batches and then report." | The checkpoint model exists to catch errors early. Skipping a checkpoint means errors propagate further before detection. |
| Prohibition | Why |
|---|---|
| NEVER continue past a failing verification | Failures cascade. The next task likely depends on the current one being correct. |
| NEVER silently fix plan errors | The human must know the plan was wrong. Silent fixes hide information needed for future planning. |
| NEVER add code or changes not in the plan | Unauthorized changes undermine the checkpoint model and introduce unreviewed behavior. |
| NEVER interpret ambiguous instructions -- always ask | Wrong interpretations compound across every subsequent task in the batch and beyond. |
| NEVER skip the finishing-a-development-branch sub-skill at completion | That skill handles final verification, option presentation, and safe handoff. Skipping it leaves work in an unverified state. |
| NEVER execute more than one batch without reporting | The checkpoint model requires human review between batches. Skipping a checkpoint defeats the entire purpose of this skill. |