What makes a good job?
A job label describes what you’d see if the approach is working. The description says where to verify it. Implementation detail goes in the notes field.
The good labels are observable results. The bad labels are implementation steps. Those belong in the notes field, where builder agents read them.
Three fields, three audiences
- Label = what you can observe (strategist checks this)
- Description = where to verify it, UI, devtools, API response
- Notes = how to build it, implementation detail for coding agents
Maturity
The quality bar for this job, set at planning time:
Maturity is not completion status. Use
status: "done" for that.
Status
A job has three states:
A closed ticket is a claim, not proof. When your delivery tracker signals that the linked work is complete, the job moves to
delivered. The team says it’s built. Moving to done means someone has verified the proof condition is actually met in the deployed product. That last step stays with you.
Granularity
- Each job should be verifiable in under a minute. If you can’t confirm it quickly, it’s too big, split it.
- Don’t create jobs until the approach is actively being worked. The approach captures the bet. Jobs are the checkpoints when you’re ready to execute.
- The approach is sometimes the job. For simple approaches, don’t decompose at all. Only create jobs when there’s genuine complexity worth tracking separately.
Execution discipline
When working through jobs. Whether you or an AI agent:- Do the work for this checkpoint
- Verify it passes (check what the description says to check)
- Mark it done
- Move to the next job