The Problem
I think in tangents. When I’m talking through a problem with Claude, I don’t produce clean task lists. I produce rambling monologues where actionable items are buried between half-formed ideas, context-setting, and digressions. Somewhere in “we should probably fix the auth flow, also I’ve been meaning to look into Postgres migrations, and oh yeah the CSS on the login page is broken” are three real tasks. But by the time the conversation is over, I’ve moved on and none of them get captured.
The friction is not in knowing what to do. It’s in extracting it. Going from a messy conversation to a structured task list requires a mental shift I rarely bother with. So things fall through the cracks.
The Idea
Todoist already has a feature called Ramble that does something similar — you talk or type freely and it extracts tasks for you. It works well as a standalone capture tool. But my rambling doesn’t happen in Todoist. It happens inside Claude Code, in the middle of working sessions where I’m debugging, designing, or brainstorming. By the time I think to open Todoist and ramble into it, the context is gone. I wanted the same idea, but embedded in the tool where my conversations already happen.
Claude Code supports custom skills — markdown files that act as reusable prompts with access to tools. I already use a Todoist MCP connector that lets Claude create tasks, search projects, and manage labels directly from a conversation. The question was whether I could combine the two: let Claude re-read an entire conversation, pull out every actionable thing I mentioned, and push them into Todoist.
The design took shape through a brainstorming session. One question at a time, multiple choice where possible:
- Trigger: Not a structured input. I ramble naturally, then say “turn that into todos” when I’m done.
- Destination: Everything goes into a Todoist project called “Back Burner.” No project selection, no sorting step.
- Extraction: Capture everything, not just the concrete stuff. Use Todoist priorities to signal how actionable each item is — p1 for “do this now” items, p4 for vague “someday” mentions.
- Approval: Always show me the extracted list before creating anything. I review, adjust, then confirm.
- Scope: The entire conversation, not just the last few messages. The whole point is that useful tasks are scattered across a long, messy discussion.
How It Works
The skill is a single markdown file. No code, no dependencies. When invoked, it instructs Claude to do three things:
First, re-read the full conversation and extract every item that could become a task. This includes explicit requests (“we need to fix X”), implicit intentions (“it would be nice to eventually Y”), and even offhand mentions that suggest future work. Nothing gets filtered out at this stage.
Second, present the extracted tasks in a table with a proposed title, description, and priority for each one. Priority follows a simple heuristic: concrete and actionable items get p1 or p2, vague or aspirational items get p3 or p4. I can edit anything in the list — rename tasks, change priorities, remove items that were just noise, or add things Claude missed.
Third, after I approve, it calls the Todoist MCP tools to create all the tasks in the Back Burner project in one batch.
That is the entire workflow. Ramble, say the word, review a table, confirm.
Why This Works
Task capture tools assume you already know what your tasks are. They give you an input box and expect you to type a clean, actionable item. But most of my tasks don’t start as clean items. They start as fragments inside conversations, shower thoughts, or complaints about something being broken.
This skill meets me where I actually am. I don’t have to context-switch from “thinking out loud” to “writing tasks.” I think out loud, and the tasks get extracted after the fact. The approval step keeps me in control without requiring me to do the extraction work myself.
The priority system handles the ambiguity problem. When I ramble, I mention things at wildly different levels of concreteness. “The login page CSS is broken” is a real task. “We should probably think about migrating to Postgres someday” is barely a thought. Both are worth capturing, but they are not the same thing. Priority makes that distinction visible without requiring me to categorize in the moment.
Takeaway
The gap between having ideas and tracking them is usually a capture problem, not an organization problem. If capturing a task requires you to stop what you’re doing, open a different tool, and formulate a clean description, most tasks never get captured. The ones that survive are the ones that were already obvious enough to remember. Everything else — the half-formed ideas, the things you mentioned in passing, the “we should probably” items — evaporates.
Lowering the capture barrier to “just keep talking and say the word when you’re done” means more of those items survive. They might not all be important. That’s what the Back Burner project is for.