Simple Task Loop

A disciplined workflow for implementing multi-phase coding tasks. tasks.md tracks progress in real time. The compiler is your guide: run check often and let its errors show what still needs updating.

Arguments: $ARGUMENTS — the plan (a .plans/<task>/ path or slug). Always run the whole plan.

Picked by pick-tier when the tier is L, with no sensitive path and 3 phases or fewer (or no phase count).

Read task-loop-rules.md in this skill's folder first. It holds the project commands, constraints, concepts, task-list discipline, and finishing steps all three task loops share. This file adds only what is specific to this loop.

Constraints (on top of the shared ones)

• Sync before the next phase. Run sync at the end of every committed phase.

The Loop

Repeat until every task is complete. Work per phase, top to bottom.

1. Check status. Read tasks.md. Every task [x] → go to When you are done. Otherwise start at the next task.
2. Gather what the current phase needs: the spec sections it implements and the code it touches.

3. Implement, one task at a time:

   a. Restate the current task in one sentence.

   b. Do the work. Run check after each logical group of changes — a single task, a phase, or several phases, depending on the work. Use its output to steer: rename something and the errors list every call site still to update. You only see that guidance by actually running it.

   c. Tick it in tasks.md.

   d. Pick the next task under the current phase header and repeat from (a). When the phase has no - [ ] left, go to 3.5.

   Broken builds: if check fails, fix and re-run. Large refactors can leave the build red until a later task lands; that is expected. Once the code should build, it must.

3.5. Audit. Re-read tasks.md. Any task in this phase not [x] means you drifted: return to step 3 with it. The list must be clean before you test or commit.

4. Verify. Run the full test suite and fix failures before proceeding. If a phase must end with a broken build (a refactor spanning phases), first try reordering tasks so every phase ends green; accept a red phase boundary only when no order allows it.
5. Commit and sync. On a green build: commit with a Conventional Commit message, <type>(<scope>): <summary>, one per phase, with the phase named in the summary or body, then sync (resolve conflicts, re-test, commit the merge). On a red build: skip both and commit at the next phase that builds.
6. Go to step 1.

When you are done

Follow Finishing in the rules file.