In the last post, I talked about building the /triage skill — it sorted tasks dumped into my Todoist inbox into categories, and even added a step (Step 4) that asked a clarifying question for anything too vague to route. I thought that was the whole job.
It wasn’t.
I wanted to push everything toward full automation
Once it worked, I got greedy. Not just sorting — I wanted a sorted task to be immediately executable by the CLI. So I kept bolting things on.
By June 27, triage was deciding which model to run each task on (model:sonnet / opus) and whether to parallelize it as a workflow (workflow:yes). Whatever triage decided got written straight into each project’s docs/todo.md, and /dispatch would read that file and run it unattended. The flow looked like this:
triage → confirm auto + decide model/workflow
→ write tags into docs/todo.md
→ dispatch reads it and actually executesThe goal was clear: drop one task into the inbox, and it goes from classification to execution with zero human hands on it. I was shoving the entire judgment call of “what kind of task is this” into the automation pipe.
Push too hard and you get nonsense out
The problem was that “sorted” didn’t mean “the same kind of task.”
Take something like “add permission.” One noun phrase. What permission, where, why — you can’t tell from three words. If triage just stamps that auto and hands it off, /dispatch will build something from that vague description. Usually not what I wanted.
This eventually became a hard rule baked into the dispatch skill — a quality gate before execution:
Running with insufficient requirements produces garbage output. Vague descriptions like “add feature,” “improve UI,” “clean this up” — do not execute.
I’d built a system meant to push automation forward, and right in the middle of the unattended execution pipeline, I had to install a brake that says “don’t run this.” I first treated this as a logic problem. Make triage’s clarification step smarter, get it to fill in the gaps on its own. Tune Step 4 harder.
”Can you also build me a discuss skill”
The turn happened that same afternoon. What I actually said was:
can you also build a discuss skill, something that pulls todo discuss tasks one at a time and works through them
Instead of making the clarification logic smarter, I decided to tag anything that needed clarifying with a label: discuss. Ideas that hadn’t matured yet, direction that wasn’t set, anything that needed back-and-forth. Whatever triage couldn’t confidently stamp auto, all of it went here.
And /discuss pulls tasks with that label one at a time. It doesn’t ask everything at once — it opens a single task, asks about the most uncertain part first, and only once an answer sets the direction does it get promoted to auto or manual. On the dispatch side, discuss means “pending decision → hold.” Nothing gets into the automatic execution queue until a human decides.
I hadn’t automated the logic. I’d built a place for automation to stop.
This spot was never meant to be automated
It only became clear once I’d actually run discuss for a while. The problem I’d been holding onto was framed wrong from the start.
I was solving “how do I automate sorting better.” But this spot was never a candidate for automation in the first place. Figuring out what a single task actually means — confirming what “add permission” is actually asking for — that’s context that exists only in my head. No amount of logic-tuning manufactures information that isn’t there. What was needed here wasn’t a smarter classifier. It was one line asking a person.
discuss turned out to be more than a label. “When unsure, discuss” is really a declaration: this judgment belongs to a human. A boundary explicitly drawn inside an automation system, marking out a seat for the person.
Sorting wasn’t exempt either
I’d solved the “what should this task do” ambiguity with discuss. But separately, the same problem showed up in “where should this go.” Triage was deciding which project and section a task belonged to and moving it there automatically — and it screwed up more than I expected. It would confuse Second Brain (running the wiki system itself) with myWiki (building a separate app), or route a task to the content pipeline just because the word “blog” was in the name, even when the actual work was a system improvement. The boundaries between projects were often too subtle to nail down from a task name alone.
So now triage doesn’t auto-confirm section moves either. It proposes the classification first — ”→ Content > [series]. Sound right?” — and only moves the task once I confirm. It wasn’t just whether to run that needed a human check. Where it goes needed one too.
Safe automation is knowing what to leave behind
For a while, automation meant to me “how much more of the human hand can I remove.” That’s the force behind every feature I bolted onto triage. But what actually made the system usable was the opposite decision — deciding what not to automate.
Pushing harder doesn’t produce safety. Forcing ambiguous things through auto piles up nonsense results, and undoing that costs far more than a single question to a human would have in the first place. Safe automation didn’t come from pushing force. It came from knowing what to leave to people.
Triage keeps changing. But now, every time I bolt something on, I ask the same question: is this really a spot for automation, or is it a spot that belongs in discuss?