I ended part 2 with this:
“Start with the one thing you find most annoying, make it a skill, and put it to use. The next piece will show itself.”
Here’s what that actually looks like. This is the real conversation log from June 22nd — the day I built /triage, a skill that automatically sorts my Todoist tasks. About 90 minutes, start to finish.
It started with one question
11 AM. The question was simple.
Me: “I want to make a skill for sorting the Todoist inbox — should it be global or project-specific?”
No spec. No prior planning. I just knew what I wanted to build and asked where to put it first.
Claude’s answer came immediately.
“Global is better. Sorting your Todoist inbox isn’t tied to any specific project — you’ll want to run it from any session, any time.”
That made sense. So I described how I wanted it to work.
Me: “I have 3 categories — the inbox should move things into the right category, and each category has sections, so it should figure out which section each task belongs to… The end result should be specific enough that I can actually act on the task from the CLI.”
That was enough to get started.
The first version was done in five minutes
Claude queried the Todoist API first. It fired off find-projects, find-sections, and find-tasks simultaneously — grabbed the project IDs, section IDs, and the full list of content scenarios in one pass. Then it wrote the skill file.
“Structure mapped. Writing the skill now.”
A file appeared at ~/.claude/commands/triage.md. Markdown with hardcoded section IDs, classification logic, and execution steps. “Looks good. Want to run it?”
Immediately tried to run it.
Claude: “⚠️ This is a global command invoked with
/triage— I can’t call it directly as a tool. I’ll manually walk through the logic and show you the results.”
Claude couldn’t call the skill it just made. So it ran the logic manually instead — classified the three tasks sitting in the inbox and moved them using update-tasks.
The first bug showed up during execution
Right after the moves completed.
Claude: “Correcting the skill file — turns out you can’t use
projectIdandsectionIdtogether inupdate-tasks. Only one at a time. UsesectionIdalone and the project follows automatically.”
The first version of the skill had both in the same call. Todoist’s API doesn’t allow it. The file was edited on the spot.
There was no way to know this at design time. You find it by running it.
”Does this sort everything, or just the inbox?”
After the moves, I ran /triage again. The inbox was empty.
“No tasks to move.”
That’s when the question came.
Me: “Does this sort everything inside each category, or just stuff from the inbox?”
It didn’t. The first version only handled the inbox → 3 categories direction. Tasks already inside a project but sitting in the wrong section were untouched.
Claude: “Correct — right now it only handles inbox → the 3 categories.”
Me: “Let’s expand it to cover everything.”
Five minutes later, the skill was rewritten. What started as inbox-only now scanned all four projects — inbox, work, side projects, and content. Tasks already in the right place were skipped. Misplaced ones got moved.
It’s not that I forgot to include the full-project sweep when I started. I just built what was urgent first. The inbox was the bottleneck, so that’s where I started.
The longer you use it, the more gaps you notice
Third run of /triage. Nothing to move. And then:
Me: “One thing I’d love is if it also helped clarify vague tasks — should that be a separate skill, or part of this one? I think all-in-one makes more sense.”
Claude: “All-in-one is right. It’s already reading every task during classification — splitting it into two skills would just mean reading the same data twice.”
Step 4 was added to the skill. It now scans all tasks for anything that’s just a noun or too vague to act on, groups them into a list, and asks me once. My answers go into the task’s description field.
That day I clarified 10 tasks. “Add permissions” → “Waiting on security review before adding repo access.” “Deploy skill per project” → “Create a /deploy Claude Code command for each project repo. Standardize the deployment flow.”
After that I added a new section to Todoist — one that didn’t exist yet — and reflected the ID in the skill. Then I asked for date inference, and Step 5 went in: tasks in “this week” section get this Friday, follow-up tasks get a week out, automatically.
Ninety minutes from start to there.
There’s no finished version of a skill
The first version went in at 11:09 AM. Inbox to 3 categories only. Ninety minutes later it handled full re-sorting across 4 projects, plus vague task clarification, plus date inference.
One bug. Two scope expansions. Two feature additions.
None of it was planned upfront. The pattern was: build something, run it, notice what’s missing, add it. The skill file is where the results land, not where the design begins.
In part 2 I said “you only see what’s missing after you run it.” This is what that looks like in practice. Next time something bothers me about /triage, I’ll fix it then.