How to Write a Task Your Future Self Won't Curse

You open a task you wrote eighteen days ago. It says "fix the thing." You stare at it. Which thing? Fix it how? Was this the dropdown bug or the webhook one? You spend twenty minutes reconstructing context that took you ten seconds to lose — and the actual fix takes five.

That re-investigation tax is invisible until you add it up. Every cryptic task is a small debt you collect from your future self, with interest. And for solo devs and freelancers there's a special twist: there is no one to ask. You are both the author and the confused archaeologist. The good news is that the fix costs almost nothing. A task is just a message to your future, context-free self — and a few extra minutes writing it well buys back hours of re-investigation later.

---

The anatomy of a bad task

Bad tasks share a single root cause: they were written by someone with full context for someone they assumed would also have full context. That assumption is always wrong. Future-you is effectively a stranger who happens to share your handwriting.

Here's the gallery of usual suspects:

• "fix the thing" — no object, no outcome, no scope.
• "update API" — which endpoint? Update it to do what? Why now?
• "refactor" — refactor what, toward what, and how will you know you're done?
• "talk to Sarah" — about what? What decision are you trying to reach?
• "bug" — a noun with no verb. What's broken, where, and what should happen instead?

Each of these made perfect sense at the moment of capture. The mistake is treating the title as a memory aid for present-you instead of a brief for future-you. Present-you doesn't need the task written down at all — you already know. The task only exists to serve the person who has forgotten everything.

There's a name for part of what's happening here. The Zeigarnik effect describes how unfinished tasks occupy mental bandwidth — they nag at you until they're resolved. A vague task gets the worst of both worlds: it nags you (it's unfinished) but gives you nothing to act on (it's incomprehensible). It's pure cognitive overhead. A clear task closes the loop in your head even before you start it, because you trust that everything you need is written down.

---

The cost is real, and it compounds

Context-switching is expensive. Gloria Mark's well-known research on workplace interruptions found it takes on the order of 23 minutes to fully refocus after a switch. A badly-written task forces exactly that kind of switch: you stop, dig through your own memory, maybe open the codebase to figure out what you meant, then try to climb back to where you were.

The math is brutally one-sided. Two minutes of writing versus twenty-plus minutes of archaeology, multiplied by every fuzzy task in your backlog. If you keep a backlog of any size — and most solo devs do — the vague tasks quietly become the reason your backlog feels radioactive. You don't avoid it because it's long. You avoid it because every item requires re-investigation before you can even decide whether to do it. We dug into that failure mode in backlog bankruptcy; writing clearer tasks is the upstream fix.

---

How to write a task your future self will understand

That's the whole system. The rest of this post is each piece in detail, with templates you can copy.

---

The title rule: verb + specific object + outcome

Your board is scanned, not read. On a kanban board you're looking at a column of cards and deciding, in a fraction of a second each, which one to pick up. A good title survives that glance. A bad one forces you to open the card just to remember what it is — which defeats the entire purpose of a board.

The rule: verb + specific object + outcome (or scope).

Notice what the good titles do. They start with a verb, so you know the kind of work. They name a specific object, so there's no ambiguity about target. And many of them hint at the outcome or scope, so future-you knows when to stop. You can read any one of them cold and know roughly what you signed up for.

Keep titles to one line. If your title needs a comma-spliced subclause to make sense, that's a signal the task is actually two tasks, or that the detail belongs in the description.

---

What belongs in the description

The title gets future-you to pick the right card. The description gets them to actually finish it without re-deriving everything. Use markdown so it stays scannable — headers, bullets, code fences, links. Four things earn their place.

1. The why

The single most-skipped, most-valuable line. Why does this task exist? "Customers on the annual plan are getting charged twice because the upgrade webhook fires before the subscription record is committed." Now future-you understands the stakes, can sanity-check the approach, and won't accidentally solve a different problem. The why is also what lets you re-prioritize honestly later — a task with no stated reason tends to either rot forever or get done out of guilt.

2. The "done" criteria

Write down how you'll know it's finished. This is your acceptance criteria, and it doesn't need to be formal:

• No duplicate charge when upgrading monthly to annual.
• Existing monthly-to-monthly upgrades still work.
• A regression test covers the double-fire case.

If you can't articulate what "done" looks like, the task isn't ready — and that's useful information. It usually means the work is still a question ("investigate why charges duplicate") rather than an action, and questions and actions deserve different treatment.

3. Links and context

Paste everything you'd otherwise have to hunt for: the stack trace, the file path, the failing endpoint, the relevant PR, the customer email, the design link. Future-you should never have to reconstruct what present-you already had open in a tab. This is the cheapest, highest-leverage part of the whole exercise — it's just copy-paste.

4. The first concrete step

Activation energy kills more tasks than difficulty does. End the description with the first thing to do: "Reproduce with the test payload in fixtures/stripe/annual-upgrade.json, then check the webhook ordering in lib/billing/webhooks.ts." Now there's no staring-at-the-card moment. You sit down and start.

---

Priority and due date are part of the message

A task isn't just what — it's how much it matters and when it bites. Both belong in the message to future-you, because future-you has to triage a board full of cards and decide what to touch first.

Use priority levels to encode importance honestly. The trap is marking everything P1; if everything's urgent, nothing is, and you're back to scanning a wall of identical-looking cards. A workable solo convention: P1 is "this is actively hurting users or revenue right now," P2 is "this matters and has a real deadline," P3 is "should do, no fire," P4 is "nice to have / someday." We went deep on a solo-friendly version of this in the P1–P4 prioritization guide — the point here is that priority is information you're leaving for yourself, not decoration.

A due date carries different information: it's a real-world deadline, not a vibe. Reserve it for things that genuinely bite on a date — a client deliverable, a renewal, a launch. Don't sprinkle due dates on everything to manufacture urgency. A calendar full of fake deadlines trains you to ignore real ones, and that's a habit you really don't want.

---

One level of subtasks, used as a checklist

Some tasks are genuinely multi-step. The temptation is to either cram the steps into a wall-of-text description or to explode the task into a sprawling tree of nested sub-sub-tasks. Both are traps.

The sweet spot is one level of subtasks used as a literal checklist — the concrete steps to get from "not started" to "done," visible right on the card. For our duplicate-charge example:

• Reproduce with the annual-upgrade test payload
• Add idempotency key to the webhook handler
• Guard against the commit-ordering race
• Write the regression test
• Verify monthly-to-monthly upgrades still pass

That's a checklist, not a project. You can see progress at a glance, you always know the next action, and there's no navigating a tree to understand the work. The moment you find yourself wanting subtasks of subtasks, the parent task is too big and should be split into separate tasks instead. There's a whole case for this constraint in subtasks, one level deep — going deeper buys you nothing but navigation overhead.

---

The test: would I know what to do with zero memory?

Here's the single check that catches almost every bad task before it escapes. Before you move on, reread the task and ask:

If I had zero memory of writing this — if a clone of me with no context opened this card — would they know exactly what to do?

If yes, ship it to the board. If no, you've found the gap: the missing object in the title, the unstated why, the absent done-criteria. Fix it in the ten seconds you have right now, while you still have the context that future-you won't.

This test works because it forces you to drop the curse of knowledge. You can't un-know what you currently know, but you can imagine handing the task to someone who doesn't know it. That someone is real. They show up in three weeks wearing your face.

---

Templates you can steal

Most of your tasks fall into three buckets. Keep a mental template for each so the structure is automatic and you're not reinventing it every time.

Bug

Title: Fix [what's broken] on [where] ([expected vs actual])

Why: [who's affected and how]
Done:
  - [correct behavior]
  - [no regression on X]
  - [test covers it]
Repro: [steps or payload]
Context: [stack trace / file path / PR link]
First step: [reproduce with ...]

Feature

Title: Add [capability] to [surface] ([scope/limit])

Why: [user problem this solves]
Done:
  - [user can do X]
  - [edge case Y handled]
Context: [design link / related code / decision thread]
First step: [scaffold ... / spike ...]

Chore

Title: [Verb] [specific object] ([scope])

Why: [what it unblocks or prevents]
Done: [the measurable end state]
Context: [docs / config / dependency link]
First step: [...]

These aren't sacred. The point is that each one forces the title verb, the why, and a done condition — the three things vague tasks always omit.

---

Keep capture fast or you won't do it

Here's the honest objection: if writing a good task takes effort, you'll skip it in the moment and dump "fix the thing" instead. So the structure only survives if capture is fast. This is exactly why keyboard-first, quick-add capture matters — the friction between "I have a thought" and "it's a well-formed task on the board" has to be near zero.

The trick is to split capture from refinement. In the heat of coding, hit your quick-add shortcut, fire off a title, get back to work. In GritShip that's the N key — new task, type, done, never touch the mouse. Then once a day, sweep the inbox of raw captures and spend two minutes each turning them into proper tasks: add the why, the done criteria, the first step. You get the speed of dumping and the clarity of a real brief, just at different moments. If you live on the keyboard, tuning your shortcuts so quick-add is effortless pays for itself fast.

This split is also the core of a sane solo workflow generally — capture without friction, refine on a schedule, and never let either step block the other. It's the same philosophy behind our solo dev PM guide: the tool should disappear, and what's left is just you and a board of tasks you can actually act on.

---

Frequently asked questions

Isn't writing detailed tasks just overhead for a solo dev?

It's the opposite. A team can ask a teammate what a vague task meant; a solo dev has no one to ask. The detail you skip becomes a re-investigation you pay for alone, usually at 10x the cost of just writing it down. Two minutes now versus twenty minutes later is the trade, every time.

What's the minimum a task needs to be 'good enough'?

A title with a verb and a specific object, plus one line of why. That alone clears most of the bad-task hurdle. The done criteria, links, and first step are upgrades — valuable, but the title and why are the non-negotiable core.

How do I write good tasks without slowing down my coding flow?

Split capture from refinement. Use a keyboard-first quick-add to dump a title in two seconds while you're in flow, then do a daily two-minute sweep to flesh each one into a real brief. Never try to write the perfect task mid-flow — just capture, then refine on a schedule.

Should every task have a due date and a priority?

Priority, yes — it's how future-you triages the board. Due dates, no. Reserve due dates for things with a real-world deadline that genuinely bites on a date. Faking urgency by dating everything trains you to ignore your own deadlines, which defeats the purpose.

When should I use subtasks versus splitting into separate tasks?

Use one level of subtasks as a checklist when the steps only make sense together and share a single 'done.' If a subtask is big enough to want its own subtasks, promote it to a standalone task. Never nest more than one level deep — it adds navigation cost and buys nothing.

What's the fastest way to tell if a task is well-written?

Run the memory test: imagine a clone of you with zero context opens the card. Would they know exactly what to do? If yes, it's good. If no, you've found the missing piece — fix it now while you still have the context they won't.

Every task you write is a tiny letter to a stranger who will thank you or curse you, and that stranger is always you. The cost of writing the good version is a couple of minutes you have right now, while the context is still in your head. The cost of the bad version is paid later, alone, at the worst possible time — usually mid-bug, mid-deadline, with no one to ask. Pick the version your future self won't curse. They're the only one who has to live with it.