The Skill That Stops Claude From Forgetting Your Tasks

I just built another skill. I’m calling it Just Do It.

I know, the name is a bit confusing. But it does exactly what it says, so I kept it.

The problem: I talk, Claude forgets

I used to do this with my voice — dictating whatever was in my head straight into a voice-to-text tool. You just vomit whatever you want. No order, no structure, half-finished thoughts, corrections mid-sentence. That’s how I think out loud.

The problem is that an LLM doesn’t handle a raw brain-dump well. Hand it a stream of consciousness and it grabs onto the last thing you said, loses the earlier context, and quietly drops half of what you actually asked for. Not because it’s dumb. Because nothing forced it to hold the structure.

What the skill actually does

Just Do It takes that same “say whatever you want” input and does two things with it:

1. It rephrases what you said into something better — clear, valid points.
2. It then forces the LLM to execute whatever you asked, by creating multiple tasks out of it.

That second part is the one that matters. It uses Claude’s own task tool — a relatively new capability that lets the model track a list of tasks instead of just answering in one shot. My experience with it: it works way better. It forgets way less.

Why it works: it’s just a checklist

If you think about it for a second, it’s the exact same logic as any checklist you’ve ever written for yourself. You write it down, and then you’re forced to follow it — that’s the whole reason checklists work.

Forcing an LLM to build its own task list does the same job. The model isn’t suddenly smarter. It just now has something to check itself against, instead of drifting with whatever was said last.

What actually runs this in Claude Code

This isn’t magic. Claude Code has a built-in task tracker — the model spins up a list on its own when it decides a request needs three or more distinct steps. Each task moves from pending to in progress to completed, and Claude checks and updates that list as it goes, instead of trying to hold the whole plan in its head. It’s the same idea as the official task tracking docs describe: the list is Claude’s working memory. It survives context compaction, so even on a long session it stays oriented on what’s left. You can see it live in the terminal too — hit Ctrl+T and the list pops up.

Here’s the catch: Claude only builds that list when it decides the request is complex enough. A messy voice dump doesn’t look like three clean steps to the model — it looks like one blob of text, so Claude often just answers and quietly drops half of what you asked for. My skill doesn’t add new machinery. It just forces the native task tracking in Claude Code to turn on every single time, no judgment call required. Same tracker, same discipline — just no longer optional.

The part that saves me with ten consoles running

There’s a second piece I added. Whenever the skill rephrases your input, it also forces the result to report back, clearly, what it actually did.

That sounds small until you’re running ten, twenty different consoles at once. You lose track fast. Having each one come back and tell you, in plain terms, what it did for you, means you’re not stuck reconstructing it from memory or scrolling back through the conversation.

The skill, copy-paste it

Here’s the whole thing, copy it. Rename it, drop it into Claude Code as a skill, or just paste the block straight into whatever LLM you’re talking to as an instruction.

---
name: just-do-it
description: Turns a raw, unstructured brain-dump into a forced task list, executes it end to end, and reports back exactly what got done.
---

Rules:
1. Match the output language to the input language — reformulation, questions, and task labels all follow whatever language the user wrote or spoke in.
2. Reformulate the input as a flat list of bullets, one level, no sub-bullets. Each bullet is a complete, short sentence. Never merge two requirements into one. Never drop a detail because it was messy, repeated, or garbled — over-capture instead.
3. No ritual confirmation. If the request is clear, skip "should I proceed?" — reformulate, create tasks, start. Only stop for genuine ambiguity.
4. Always work from tasks. Before executing anything, break the reformulated bullets into atomic tasks and track them with a task list. Every bullet maps to one task.
5. Never call something done while a task is still open. A task is complete only when the result is real and verified, not assumed.
6. Close out with one bullet per task, in plain language, same count and order as the original points. Describe what actually changed — behavior, not code. No file paths, no function names, no snippets. End with where to check the result.

Process:
1. Capture the raw input as given.
2. Comprehend it — extract the goal and every distinct point, constraint, or exclusion. Repair obvious dictation/typo glitches from context. When in doubt, keep the detail rather than cut it.
3. Check for real ambiguity. If something is genuinely unclear, ask a concrete question with 2-4 options. Otherwise skip straight to the next step.
4. Reformulate the input as the flat bullet list described in rule 2 — this is "how you should have said it."
5. Create one atomic task per bullet, plus one final QA task.
6. Execute task by task, updating status as you go.
7. Before closing, re-read the original request and every bullet. Confirm each one actually happened and matches intent, confirm every task is marked done, then write the final recap plus a one-line "where to test this."

No dependencies, no setup. Just a structure the model can’t wiggle out of. I copy and paste it wherever I need it.

Turns out the fix for an LLM that forgets isn’t a smarter model. It’s a better checklist.