Open any of your side projects and ask: where is this? If the honest answer is “let me scroll through the to-do list”, your project management is working against you.
This post describes the simplest system we have found that survives AI agents and many parallel projects: phases plus one next step. It is part 3 of The ShotMatic Method.
Why to-do lists fail with AI agents
A to-do list is fine for one project you touch every day. It breaks when:
- Agents generate tasks faster than you close them. Ask an agent to plan and you get 40 items. None of them tells you how close you are to shipping.
- You switch projects. Coming back after five days, a list of 23 open items gives you no orientation.
- Everything looks equally urgent. A flat list has no shape, so blockers hide between trivia.
What you actually need when you come back to a project is two facts: what stage am I in and what do I do now.
Name the phases once, reuse them forever
Most of your projects of the same kind go through the same stages. Write them down once:
| Game | Book | App |
|---|---|---|
| 1 Concept | 1 Outline | 1 Spec |
| 2 Prototype | 2 Draft chapters | 2 Core screens |
| 3 Core loop | 3 Edit pass | 3 Data & sync |
| 4 Content | 4 Cover art | 4 Store listing |
| 5 Polish | 5 Build EPUB | 5 Review |
| 6 Release | 6 Publish | 6 Release |
Now every project’s status is one short string — Phase 5/9 · build EPUB — and you can compare ten
projects at a glance. The template also becomes something you can hand to an agent: “we are in phase 3;
here is what phase 3 means in this repo.”
Each phase needs an exit check
A phase without an exit check never ends. Write one line per phase that can be verified by running something or looking at something:
- Prototype → “the core action works end to end on a real device.”
- Store listing → “five screenshots and the description are uploaded.”
- Edit pass → “every chapter has been read once start to finish after the last change.”
This is also what you ask the agent to prove before you accept “done” — see the review step in the workflow.
One next step, not a backlog
For each active task, keep exactly one written next step. Rules for a good one:
- It starts with a verb: write, fix, upload, decide.
- It can be started without asking a question.
- It is small enough to finish in one session.
Everything else goes into a backlog you look at only when the current phase is done. Ideas that don’t fit this version at all go on the won’t-do list instead.
Make “stuck” visible automatically
Projects rarely fail loudly. They stall — waiting on an API key, a decision, a mood. Two rules catch this:
- An explicit blocker field. If something is waiting on someone, write it:
blocked: waiting for API key. - Silence counts as stuck. If a task hasn’t moved in seven days, treat it as blocked even if nobody said so.
Stuck work should float to the top of whatever you look at first in the morning. Not because it is urgent, but because it is the work most likely to be silently dying.
Active, Done, Backlog — and nothing else
Three states are enough for a solo builder:
- Active — in a phase, with a next step.
- Done — passed its last exit check. Kept, not deleted, so you can see what shipped.
- Backlog — parked on purpose. Not failed, not forgotten; just not now.
More columns (“in review”, “ready”, “blocked”) add ceremony without adding information — the blocker field and the phase already tell you those things.
Where ShotMatic fits
ShotMatic shows exactly this model: one line per task with its name, next step and Phase 8/14, three tabs
for Active, Done and Backlog, and a red dot that floats blocked or silent work to the top. The data comes
from progress.json in each repo, which your agent keeps up to date — so the board reflects the repo, not a
separate tool you have to remember to update.
Next in the series: running 10 projects in parallel.
