In part 1 (Why I Chose Todoist), I said the clincher was that Todoist leaves an API/MCP opening. This part is the story of plugging skills into that opening to automate my task management. But I didn’t build it in the order I now use it (capture → sort → plan → execute). I built the sorting part first.
First, turn tasks into data
To attach skills, I needed to read and write tasks as code. So I connected Todoist to Claude Code (a CLI agent) over MCP.
It wasn’t smooth. I first registered the OAuth-style server (ai.todoist.net/mcp), but it stayed stuck on “Needs authentication.” I tried claude mcp auth todoist and got unknown command 'auth'. That command didn’t exist. The fix was simple: re-register with the personal token passed directly in the header.
claude mcp remove todoist 2>/dev/null || true
claude mcp add todoist -t http https://mcp.todoist.com/mcp \
-H "Authorization: Bearer <personal_API_token>"It showed Connected, I restarted the session, and the tools were there. Now the real part begins.
The most urgent thing was sorting (so, triage first)
My inbox was a pile of half-thrown ideas. I usually dump them on the commute train as they pop up, so by the time I get home an unsorted heap is waiting. Capturing was already handled by Todoist (part 1); what I actually missed was the next step: clearing the pile in one pass. So the first thing I built was a sorting skill (/triage).
“Sorting” sounds trivial, but the key was keeping the criteria in one place. I put a single mapping table — “this folder (project) maps to this Todoist section” — as the single source of truth, and had it flesh out vague items and assign dates. Watching the heap split cleanly by project, the inbox finally felt like an inbox.
Sorting led to planning, planning led to execution
Sorted tasks weren’t just a list anymore; they were data I could work with. So the next pieces followed naturally.
A skill to bundle the sorted tasks into a dependency-aware execution plan (/plan-todo), and execution that runs that plan unattended (/goal). A cycle formed: sort → plan → execute. Up to here it was all one direction — “just get the pile moving somehow.”
The last piece was capture
Running the cycle, I noticed a gap. The entrance. Dropping a thought into the inbox from my phone had been there since part 1, but those still had to go through triage later. What was missing was a way to take something that came up while working at my desk and put it straight into the cycle on the spot.
The trigger was concrete. I was about to write this very ‘Todoist blog post,’ and right there at my desk I wanted to drop it in without going through the triage step, so I could run the plan (build) right away. So I built the capture skill (/todo). On the way in, it sorts by the folder I’m working in and fills in the details, so it can go straight into a plan without triage.
So /todo is the cycle’s starting point, yet it was the last thing I built. I started because sorting was urgent, and only drilled the entrance once running the cycle made me need it. (Being a blog, there were side branches like bundling and publishing a series, but that’s not the main thread.)
The order I use it is the reverse of the order I built it
When I use it now, it flows in one line: capture → sort → plan → execute. But the build order was sort → plan → execute → capture. I started with the most urgent piece, sorting, and filled the empty slots one by one as I ran the cycle.
I actually ran it on a project, and it was a relief. The pile of “when am I going to get to all this” in my head collapsed into a single plan document, and that made a difference.
When I get home, this is what I run
There are two ways in. When an idea pops up on the move or while my mind wanders, I just dump it into the inbox from the Todoist app on my phone (I’ve done this since part 1; it has nothing to do with /todo). /todo is for when I’m sitting at my desk working. Whatever comes up in that project folder, I drop it in with context attached, and it skips triage and goes straight onto a plan.
The processing happens in one batch when I get home.
/triage: sort the inbox heap I dumped from my phone over the day, in one pass.- Go into the project folder and
/plan-todo: that project’s tasks get bundled into aplan-todo.md. /goal plan-todo.md: run that plan unattended.
What I threw in from my phone sits in the inbox; what I added with /todo while working is already sorted into its project. Getting home means one loop of sort, plan, execute. I set it running and just look at the results.
Why I build skills first and sand them down as I go
Underneath this order is how I work. I don’t try to finish a feature in one shot; I register it as a skill first and sand it down as I use it. Three reasons.
- It bundles repetition. Wrap something you do often into a skill and you stop re-explaining it every time. Build it once, then call it with one word.
- It pins behavior. It locks in a way of doing things so the next run does the same, which cuts the drift and the dropped steps.
- You only see the gaps by using it. No matter how perfectly you design in your head, you don’t know what grates until you actually run it. So instead of drawing the finished form, I get it running and shave off what bugs me on the spot.
Building triage first and drilling capture last were both results of this. Build the most urgent piece, run it, and when a gap shows up, fill it then.
Wrapping up
If I’d tried to design the whole thing up front, I probably wouldn’t have finished. I’ve fizzled out that way plenty of times before. This time I built the most urgent piece — sorting — and ran it, and once the cycle started turning, what to build next revealed itself.
It’s not perfect, of course. The plan /plan-todo produces isn’t always clean, and some days I look at the results and go back in. And running things unattended burns a fair amount of tokens — it definitely costs more than doing it by hand. But the relief of dropping the stuff rattling around in my head into a single plan and just letting it run was, for me at least, worth that price.
Automation doesn’t have to start from a grand design. Build the one thing you miss most as a skill and run it, and the next piece shows itself.