I didn't get better at to-do lists. I made the work recoverable.

I’ve never been good at to-do lists. I can make one and use it enthusiastically for a few days, but then the work moves, the list does not quite move with it, and maintaining the list starts to feel like another job.

That pattern has followed me across notebooks, apps, reminders and more elaborate systems. The problem has never really been remembering that tasks exist; it is keeping a separate representation of the work accurate while the work itself keeps changing.

I do still use lightweight task tools. Apple Reminders sits naturally inside the Apple ecosystem I already use, so it is useful for casual personal things: remember to buy something, make a call, deal with an appointment, do something later today. But I do not treat it as a system I have to maintain every day. It is disposable memory for everyday life, not a representation of my work.

I also still use Microsoft To Do for work, or perhaps more accurately I still have it. It was the closest thing I had to a conventional professional task list, and I still put things in there sometimes, but I barely update it now. That is revealing in itself. As the GitHub and save-point habit became better at preserving the live state of my work, maintaining a second list of work tasks started to feel less necessary.

I also use Finch, and I like it, but Finch works for me because it is not pretending to be the authoritative state of my professional work. It is a motivation layer: I complete things, get a small reward, and get to dress up a bird. That is genuinely useful, just for a different reason.

The stranger development is that I seem to have ended up with a real work-management system anyway. It lives mostly in GitHub, and I do not think of it as a to-do list because what GitHub gives me is not a better checklist. It gives me a place to preserve the state of the work.

Three active jobs, plus the fading list

The distinction became clearer once I stopped asking one productivity system to do everything.

Layer	Tool	What I use it for	What it does not need to do
Remember	Apple Reminders	Lightweight personal tasks, errands, appointments and things I need to remember later	Preserve project history or stay permanently up to date
Track — fading	Microsoft To Do	Conventional work tasks I still occasionally capture there	Represent the live state of work or demand constant maintenance
Motivate	Finch	Habits, exercise, household jobs and small actions where completion itself is the point	Hold professional context or explain why a task exists
Recover	GitHub + save points	Work that evolves across days, weeks or months: decisions, drafts, evidence, dependencies, unresolved questions and current state	Behave like a pristine daily checklist

The active model is less one perfect to-do list and more remind me, motivate me, recover the work. Microsoft To Do is the interesting in-between case: it shows the older task-list layer gradually becoming less important.

That last recoverable-state layer is the one I was missing. I do not just need to remember that something exists. I need to be able to recover the state of it.

The list kept going stale because reality kept changing

A normal to-do list usually tells me what I thought I needed to do at the point when I wrote it. That is fine if the work is stable, but much of my work is not.

A stakeholder replies and changes the next step. A draft gets reviewed and a different problem appears. A customer story exposes a broader evidence gap, new research weakens an argument I was planning to make, or something that looked urgent on Monday is obviously less important by Thursday.

The list can only remain useful if I keep updating it to reflect those changes, which is exactly the maintenance behaviour I have never sustained particularly well. So I ended up solving a slightly different problem: instead of trying to preserve a fixed view of what I need to do, I preserve enough context to recover where the work actually is.

That means recording things such as the decision that was made, why it was made, what changed afterwards, which files matter, what is waiting on somebody else, which question is unresolved and what the next plausible move currently looks like.

I have written before about AI work needing a save point. I initially thought of that mainly as a persistence problem between tools and models: if useful context exists only inside one conversation, you can lose the work when you move somewhere else. In practice, save points have become more important than that. They have become how I resume my own work.

GitHub became useful because it preserves more than tasks

This happened gradually rather than by design. Editorial Intelligence already lived in repositories because I wanted the ideas, frameworks, evidence and website to persist outside any single AI model, and as I used the system more I started recording issues, decisions, next steps, revisions and unresolved questions there too.

I began doing something similar with work I needed to keep straight across different Sage projects. The exact storage arrangements are different, and confidential company material stays where it belongs, but the working habit is the same: leave enough of a trace that I can come back later without depending entirely on memory.

That turns out to be extremely useful when several projects are moving at once. I can leave a customer-story project for a few days and come back asking where I got to, return to an Editorial Intelligence article after another piece of work interrupts it, or look at a live project and distinguish what is actually blocked from what I merely forgot about.

The repository contains more than the action. It contains some of the reason behind the action, and that distinction is what makes the system feel different from a conventional to-do list.

AI can reconstruct a current action view from the state

The important change is that I no longer need to read every saved note manually to recover a project. AI can work across the stored context and help answer questions such as what changed most recently, which decisions are already settled, what I am waiting for, which assumptions have been overtaken, what remains unresolved and what looks like the smallest useful next move now.

That does not make the AI’s answer automatically correct, but it gives me a much better starting point than trying to remember everything or trusting a task I wrote four days ago. The to-do list becomes something closer to a reconstruction: a conventional list tries to preserve the actions, while this system tries to preserve enough of the underlying state that the actions can be regenerated when I need them.

I didn’t get better at maintaining a to-do list. I made the state of the work recoverable.

This is not the same as auto-generating tasks from meeting notes

I saw a LinkedIn post recently about using Granola and Claude Code to turn meeting notes into an automatically updated to-do list. I could immediately see why that would help, because meeting notes contain decisions and commitments that people otherwise have to transfer manually into another system.

But I think the version I have ended up with goes one step further, at least for the way I work. Meeting notes are one source of state; they are not the whole state.

A project can also contain drafts, comments, research, earlier decisions, open issues, changes of direction, dependencies, published outputs and things learned after the meeting happened. If all I do is extract tasks from each new conversation, I still risk losing the relationship between today’s task and the history that makes it sensible.

What I want the AI to recover is not simply “what did I promise to do?” It is “what is true about this work now?” Only then do I want the next-action view.

The system works because it lets me be less linear

This also explains something else about how I work. I am often moving between threads rather than finishing one neat sequence before touching the next.

At Sage there can be customer stories, product content, GEO work, events, web projects and follow-ups all moving on different timelines. Editorial Intelligence is even less linear because a LinkedIn comment can expose a new idea, which changes an article, which changes a framework, which creates a question worth testing in live work.

A rigid task list does not love that behaviour because it wants me to define the sequence in advance. A recoverable-state system is more forgiving: I can leave a thread, preserve where it stands and come back when it becomes the right thing to work on again.

That does not mean priorities disappear. It means prioritisation happens against a fresher picture of reality, so the useful question becomes less “what is next on my list?” and more “given where everything currently stands, what is the best use of attention now?”

That is a subtle difference, but it fits my working style much better.

The simpler tools still have jobs

None of this has made Apple Reminders, Microsoft To Do or my little Finch bird disappear. But they now occupy very different positions in the system.

Apple Reminders catches everyday things I do not want to hold in my head. Finch gives me a reward loop for exercise, household tasks, habits and small pieces of admin where completion itself is the point. Microsoft To Do still exists as a conventional work-task layer, but the fact I barely maintain it anymore is part of the story: I am less dependent on a manually curated list being the source of truth.

Reminders helps me remember things. Finch helps me do things. The repository helps me remember what the work actually is. Those are different jobs, and I think a lot of productivity systems become frustrating because they try to make one tool solve all three.

A reminder system does not need to hold the whole history of a project. A motivation system does not need to either. And a project-memory system does not need to turn every completed action into a dopamine reward. The conventional work list can still be useful, but it no longer has to carry the whole system.

This changed how I think about the Daily OS

I already had a framework in Editorial Intelligence called the Daily OS. Its original version was mostly organisational: capture signals daily, make editorial decisions weekly, review the system monthly.

That was not wrong, but using the system in real work has made me think the deeper purpose is continuity rather than cadence. The important thing is not that something happens every day; it is that useful work does not become expensive to reconstruct when you stop and return to it.

That means preserving decisions, evidence, unresolved questions and current state at the points where context could otherwise disappear. Daily, weekly and monthly reviews can still help, but they are review rhythms around the system rather than the system itself.

The operating principle I now find more useful is:

Recover state before planning action.

That works for one person juggling several projects, but it also scales to a team trying to understand why a decision was made, or an organisation trying to stop customer evidence and research from disappearing into finished assets. The problem is similar at different scales: work loses context, then somebody has to pay the reconstruction cost later.

There are obvious failure modes

A repository can become stale too. Saving state does not magically remove maintenance; it changes what is worth maintaining.

If important changes never get recorded, AI can reconstruct an obsolete version of the project with great confidence. If I save everything, the system can become so noisy that the useful state is harder to find. If I let AI generate priorities without checking them, I can mistake a plausible reconstruction for a correct one.

And GitHub itself is not the point. It suits me because I already use it as a persistence layer for Editorial Intelligence and because AI tools can work with it easily, but another person could implement the same behaviour in a different system.

The test is simpler: when you return to meaningful work, can you recover where it stands without retelling yourself the whole story? If the answer is yes, the system is doing something useful.

The list I need is the one I can rebuild today

I still make lists, use reminders and forget things. None of this has turned me into a model of personal organisation, but I am less dependent on yesterday’s list being perfectly maintained.

The work itself leaves a recoverable state behind. AI helps me interrogate that state, and I decide what deserves attention now. That feels much closer to the way my brain actually works than maintaining a pristine queue of tasks ever did.

So I no longer think the useful list is necessarily the one I wrote yesterday. It is the view of next actions I can reconstruct from the work as it actually stands today.