A checkbox is a claim about the work

A box next to “Restore bicycle” is technically a task list. It is also a very compact way of concealing the next three weekends.

Under those two words sit several different kinds of uncertainty. You may know the tyres need replacing. You may not know whether the wheel is damaged. You may be waiting for a part. A single checkbox cannot tell you which kind of problem is preventing a ride.

Markdown makes checklists easy to write. The harder and more useful part is deciding what completion means.

Make the finish visible

A task should usually describe a result you could recognise. “Look at wheel” records an activity. “Check whether the rear wheel needs repair; record the decision” records what that activity is meant to establish.

You do not need to turn a hobby into a procurement system. A small list might be enough:

- [x] Find the tyre size and record it below
- [ ] Ask the workshop to assess the rear wheel
- [ ] Order tubes after confirming the tyre choice

The completed item says what has been resolved. The next item is something you can do. The final one contains a condition, so it doesn’t pretend to be ready yet.

Very small actions need no elaborate wording. “Email Sam” is sufficient if Sam and the purpose are obvious in the surrounding note. If the same line appears in an overview away from that context, “Ask Sam about collecting the frame” is kinder to your future self.

Leave the reasoning around the list

A checklist is good at distinguishing unfinished from finished. It is poor at explaining a trade-off.

The bicycle note may contain a paragraph about whether to preserve an old component or replace it. Keep that reasoning as prose. Reducing it to six boxes can make the page look actionable while hiding the decision that matters.

This is where tasks inside a document are useful. A checkbox can live beside the explanation, measurements or quotation that gives it meaning. A separate daily to-do list might simply link to that document, avoiding another copy of the entire plan. As with duplicate working files, two independently edited versions create a question about which one is current.

Clarity’s Tasks overview gathers Markdown checkboxes from documents and links back to their sources. Checking an item there changes the original document. The overview is another route into the same work, so the wording still needs to make sense in its source.

Review the awkward boxes

On returning to the list, pay attention to tasks that have survived several visits. They may be larger than they look, waiting on someone else, or no longer worth doing.

“Research saddles” might need a narrower question. “Collect frame” might be waiting for a message. “Repaint mudguards” might be optional work that you have stopped caring about. These are different states; leaving all three as untouched boxes does not explain any of them.

For a small project, a sentence beside the task can be sufficient. For work involving several people, deadlines and dependencies, a dedicated task tool may be a better home. A Markdown document need not impersonate one.

Review the bicycle note before buying the next part. Identify the next action you can take, leave the reason for anything deferred, and delete the optional job if you have decided against it. An honest shorter list is more useful than a complete inventory of your former intentions.