I have been at war with task management for as long as I can remember. Not for lack of trying. Over the years I have worked through most of the usual suspects: sticky notes that migrated silently off my desk, paper notebooks that accumulated in a drawer without ever speaking to each other, and plain text todo lists that gave me a fleeting sense of control before collapsing under their own weight. None of them lasted. Not because I am disorganised by nature, but because I eventually understood that these systems were not built for the way my brain actually works.
The most sustained attempt came with Things, the task management app available on Mac and iPhone. I committed to it seriously for several years, using it as the backbone of a Getting Things Done implementation. GTD, developed by the consultant David Allen and popularised in his 2001 book of the same name, is a methodology built on the idea that your mind is for having ideas, not holding them: everything gets captured, categorised, and reviewed on a regular schedule, leaving your head free to think rather than remember. The theory is elegant. In practice, the system grew. And grew. Several hundred tasks accumulated across projects, areas, and someday lists, and one day I opened Things, looked at what was in front of me, and felt not clarity but dread. I closed the app. I did not open it again with any real intention for a long time.
What those years taught me, eventually, is something deceptively simple: if something is not visible, it does not exist. Not as a metaphor. As a genuine description of how I process information. A project buried three levels deep in a sidebar might as well not be there. A task without a date, floating in a list of sixty others, will not get done. It will just contribute to the ambient guilt of an unprocessed inbox.
Finding Obsidian, and running into the same wall
A few months ago I discovered Obsidian, a note-taking application that stores everything as plain Markdown files on your own machine. No proprietary format, no cloud lock-in, no subscription required to export your own data. I synchronise my vault across my Mac mini, my work Mac, my iPhone, and my iPad via a private GitHub repository, which suits my preferences for data ownership perfectly well.
What made Obsidian feel different from anything I had tried before was the Dataview plugin, which treats your notes as a queryable database. I could write a note for each project, tag it with a status, and have a dynamic view that showed me only active work, automatically, without maintaining a separate list by hand. For the first time, a tool felt like it was matching my mode of thinking rather than imposing its own.
The satisfaction did not last unchallenged. Obsidian has a rich ecosystem of task management plugins, and I tried several of them. The problem was familiar: they gave me somewhere to put tasks, but not a system that would surface the right tasks at the right moment. Within a few weeks, I had accumulated a backlog that felt exactly like Things had felt at its worst. More tasks than I could hold in view, no obvious way to decide where to start, and the same low-grade anxiety that had sent me away from GTD in the first place.
At that point I made a decision that I should perhaps have made years earlier: rather than finding another system to adapt to, I would build something adapted to me.
Designing before building
I want to be precise about what that build actually involved, because the word "building" suggests that most of the time was spent writing code. It was not. Roughly two thirds of the total time invested in this project went into design: thinking through the constraints, pressure-testing assumptions, and eliminating bad ideas before they made it into the codebase.
The tool I used for that process was Claude, the AI assistant from Anthropic. But I did not use it to generate code. I used it to interrogate my own thinking, following an approach developed by Matt Pocock, a TypeScript educator, called the grill-me skill. The premise is straightforward: you describe what you want to build, and the AI proceeds to interview you relentlessly, question by question, exploring every branch of the decision tree until you have reached a genuine shared understanding of the problem. For each question, it offers its own recommended answer, which you can accept, reject, or modify. Pocock describes these sessions as lasting around 45 minutes, and producing a conversation dense with context, real constraints, and answers to questions you had not thought to ask yet. The comparison he draws is to rubber ducking: the old developer practice of explaining your code out loud to an inanimate object until the problem reveals itself.
What this produced, in my case, was clarity about constraints I had not fully articulated. The single most important one was this: the system could not require discipline to maintain. Any system that depends on a daily review ritual, on opening a specific app every morning, or on a sustained act of will to keep current will eventually fail. It did not matter how well-designed the tool was if its correct operation depended on me being at my best. I am not always at my best. The system needed to work on the other days too.
From that starting point, the design requirements followed naturally. I needed to be able to decide what to work on in under thirty seconds when a window of time opened unexpectedly. Short sessions, thirty to sixty minutes, needed to be viable and regular rather than rare and marathon-length. Important long-term projects needed to stay visible without requiring me to actively go looking for them. And unstructured time needed to feel like genuine rest rather than unprocessed guilt.
The architecture
With those constraints established, the architectural decisions were less a matter of preference and more a matter of elimination.
Obsidian was already in use as a daily notes system, which meant it was the natural foundation: no additional friction for capture, synchronisation already solved, and the Dataview plugin available for dynamic views. The Homepage plugin, which opens a designated note automatically when Obsidian launches, gave me the centrepiece of the system: a single note, 🏠 Accueil.md, that functions as a cockpit. It shows only what matters right now. Tasks for today, tasks for the near future, active projects, and a rotating spotlight on whichever non-IT project would otherwise become invisible behind daily urgencies.
For the automation layer, I needed something with more data-processing capability than shell scripts, which lack the ergonomics for structured Markdown parsing, and less overhead than building an Obsidian plugin, which would have required working within the plugin API, restarting the app to test, and distributing via the community store. Node.js was already present in my stack from the newsletter summariser project I built earlier this year: gray-matter for YAML front matter parsing, inquirer for an interactive CLI, simple-git for safety commits. A small, well-understood toolchain.
The system was split into two independent scripts rather than one monolithic tool. The first, flux-a.js, handles the structural content of the home page: project rotation, Dataview query blocks, the available activities table. It runs on a schedule via launchd and requires no user interaction. The second, index.js, runs the daily triage: it reads tasks from daily notes, imports anything captured in iPhone Reminders, and runs the interactive digest. Keeping them separate means either can fail, be updated, or be skipped without affecting the other. This is the kind of architectural decision that costs very little to make correctly at the start and a great deal to retrofit later.
One early design decision that did not survive contact with reality was the idea of a separate task file, À faire.md, that would serve as a central store of tasks independent of the daily notes. It was prototyped and abandoned quickly. Maintaining two sources of truth introduces its own overhead; the daily notes were already where tasks were being captured, and making the system read from them directly meant no duplication and no synchronisation problem to manage.
The daily notes became the source of truth for everything. The system reads from them; it does not own them. And the act of writing a task in the right section of a daily note is the only categorisation required: sections like Voir, Lire, Ecouter ("Watch, Read, Listen to") are routed automatically to wish list files, items in EN COURS ("On-going") are copied directly to the home page without going through the triage step, and everything else enters the interactive digest, where I select up to three tasks for today and up to five for the near future. The rest goes to later, automatically, without requiring a decision for each one.
What this required to get right
The most important thing I can say about this design phase is that no part of it was obvious in advance. The constraints I described above, once written down, look like they should have been self-evident. They were not. The grill-me approach was useful precisely because it forced explicit answers to questions I would otherwise have left vague: What happens when no work window opens for three days? What if the home page shows a project I am deliberately avoiding? What is the difference between "later" and "never"? Each of those questions has a concrete answer baked into the current design, and most of those answers only emerged through the conversation.
There is a version of AI-assisted development that consists of handing a problem to a model and accepting whatever it produces. This was not that. The code came later, and most of it was straightforward once the decisions had been made clearly. The hard work was the thinking, and the tool was useful because it made that thinking rigorous rather than because it replaced it.
The second part of this article covers the implementation: the four build phases, the bugs that cost the most time, what was abandoned along the way, and what comes next.
