New here? Get the free field guide →

← Blog

From Approved Tasks to Shipped Code: A Look Inside Implement-Tasks

SpecDevShip · · 2 min readimplementationworkflow
Contents

Approval is the gate; implement-tasks is what actually walks through it. It's the skill that turns a checked-off plan into real commits, and its behavior is more deliberate than "start writing code" implies.

It works the checklist in order

Whether the source is a light-tier implementation_plan.md's [NEW]/[MODIFY] checklist or a full-tier tasks.md, implement-tasks works items in order, tracking progress as it goes. This isn't just bookkeeping — working in order means dependencies between tasks get respected implicitly, and it means you always know exactly how far through the plan you actually are, not just "mostly done."

One commit per completed, verified item

Commits happen once per completed, verified checklist item — not one giant commit at the end, and not a commit per file edit either. Each message makes clear which task it completes, referencing the task number. This granularity matters more than it seems: a git history that maps cleanly to a spec's own checklist is one of the most useful debugging tools you'll have six months from now, when you need to know exactly which change introduced a regression.

Verification gates completion, not vibes

An item isn't done because code got written for it — it's done when the relevant verification passes: the focused regression script for light tier, or the appropriate slice of the coverage-targeted suite for full tier. Something reported complete with known failures isn't complete; it's flagged explicitly and the question of how to proceed goes back to you.

Autonomy on the small stuff, a stop on anything real

implement-tasks commits autonomously under this convention as tasks complete — it doesn't stop to ask permission for each individual commit, which would make the whole thing slower than doing it yourself. It does stop before anything genuinely higher-stakes: force-pushes, rewriting shared history, merging or deleting branches. The line is drawn exactly where irreversibility starts, not before.

The result, at the end of a session, isn't just working code — it's a git log you could hand to a new teammate and have them reconstruct exactly what happened and why, task by task, without asking you anything.

Get the free field guide. A short, practical eBook walking through the whole workflow — the tier decision framework, the investigate-before-you-fix discipline, and how the approval gates hold up day to day.

Grab your copy →