GTD for Developers: A Practical Guide (2026)

GTD for developers is David Allen's method with four adaptations: GitHub issues stop being your personal task manager, projects live in markdown, coding agents take the delegate slot in the workflow, and the weekly review counts shipped work instead of started work. The five steps stay exactly as written in 2001. Only the plumbing changes.

This guide is about the parts that break specifically when your workday is a terminal, an editor, and a pull request queue.

What does GTD look like inside a dev workflow?

GTD inside a dev workflow looks like the standard five steps with capture tuned for mid-function thoughts. You are deep in a file, you notice a follow-up ("this migration needs a production dry run"), and the thought has about four seconds of shelf life before the code crowds it out. The whole game is capturing that thought in under ten seconds without leaving the editor context.

That is why developers adopt and abandon task managers faster than any other audience. Every tool that asks you to switch windows, pick a project from a dropdown, and type a clean sentence fails the mid-function test. Capture has to be nearly free, which in practice means voice, a global hotkey, or a command-line alias, all landing in one inbox.

GitHub issues or a personal inbox: which one runs your day?

A personal inbox runs your day; GitHub issues run the team's sprint. The distinction matters because the two systems have different owners and different physics. An issue is a shared commitment with a public audience, labels, and a review process. Your open loops include plenty of things that are none of that: a library to evaluate, a doc to read, a personal errand, a nagging question about whether the retry logic is actually idempotent.

Forcing personal loops into a repo pollutes the tracker and quietly turns your task list into whatever the team's queue happens to be. The working split:

• GitHub Issues: scoped, shared, code-adjacent commitments the team needs to see.
• Personal inbox: everything you noticed, owe, or wonder, processed on your own cadence, linking out to issues when one exists.

Why do markdown files make good GTD projects?

Markdown files make good GTD projects because they are the only project format a developer will still be able to read in ten years. A project is a heading, a desired outcome, and a list of next actions. Markdown holds all three, versions cleanly in git, diffs readably in a pull request, and greps when you cannot remember where you parked something.

A minimal project file:

# Project: billing webhooks v2

Outcome: retries verified against production-like scheduler.

## Next actions
- [ ] Add scheduler integration test
- [ ] Dry-run migration on staging
- [ ] Write rollout notes for on-call

## Waiting for
- [ ] Priya: sign-off on retry budget (asked Tue)

The full setup, including how to keep next actions from going stale, is in our guide on markdown task management.

Can coding agents be your GTD delegates?

Yes, and treating them as delegates is the framing that keeps agent work honest. In GTD terms, delegating means handing off a next action and tracking it on your waiting-for list until it comes back. A coding agent run is exactly that: you hand off a scoped task, the agent works, and the result comes back for your review. The handoff belongs on waiting-for, with a date.

The failure mode is the transcript. Agent runs produce leftovers, failed tests, skipped migrations, follow-up refactors, and those leftovers evaporate when the session ends unless they leave the transcript. The durable pattern is a capture step at the end of every run, filed into your personal inbox. Our walkthrough on the Claude Code task inbox covers the capture prompt and the API call. If you want to script it, the task management API reference documents the capture endpoint your agents can post to directly.

How does the weekly review change for shipped-vs-started work?

The dev weekly review's core question changes from "what is on my list" to "what did I actually ship". Developers are structurally good at starting: new branches, new spikes, new half-finished refactors. The review exists to force the honest count. Walk every active project and ask whether anything shipped this week. A project that started three things and shipped none is not progressing; it is expanding.

Thirty minutes, Friday afternoon:

1. Sweep the inbox to zero, including every agent handoff that came back this week.
2. Walk active projects: shipped, started, or stalled? Stalled ones get a smaller next action or a demotion to someday maybe.
3. Check waiting-for: agent runs and human delegates both. Nudge what is due.
4. Write down the one thing that ships next week. One, not five.

How do I set up GTD as a developer in one afternoon?

Set it up in four moves. First, pick one personal inbox that captures in seconds: quik.md's voice capture works without leaving keyboard context, and everything it holds exports as markdown. Second, write the boundary rule down: team commitments go to the tracker, everything else goes to the inbox. Third, move your three most active projects into markdown files with an outcome line and a next-action list. Fourth, put a 30-minute Friday review on the calendar with the shipped-vs-started question at the top.

The pillar on AI task managers compares how different tools handle the capture and routing half of this setup. Whichever tool you pick, the method is the same: capture cheap, clarify on a schedule, review weekly, ship.

FAQ

What is GTD for developers?

GTD for developers is David Allen's five-step method (capture, clarify, organize, reflect, engage) applied to a coding workflow. The adaptations are small but specific: GitHub issues hold team commitments while a personal inbox holds everything else, projects live in markdown, coding agents are treated as delegates on a waiting-for list, and the weekly review measures shipped work rather than started work.

Should I use GitHub Issues as my whole GTD system?

No. GitHub Issues is an excellent shared tracker for scoped team work and a poor personal task manager. It has no place for non-code commitments, no someday maybe, and no review rhythm. Run your personal GTD system next to the tracker and link out to issues when a task needs one, instead of forcing every open loop into a repo.

How do coding agents fit into GTD?

As delegates. When you hand a scoped task to a coding agent, you have delegated work, so it belongs on your waiting-for list with a review date. When the run finishes, the leftovers (failed tests, risky migrations, follow-up refactors) need to leave the transcript and land in your inbox as actionable items.

What is the best GTD app for developers?

The best GTD app for developers is one that is plain-text friendly, scriptable, and fast to capture into. quik.md fits because voice capture works without leaving the keyboard context, every project exports as markdown, and the capture API lets agents and scripts file follow-ups directly. Obsidian with the Tasks plugin is the local-only alternative.

How do I capture tasks without breaking flow while coding?

Keep capture under ten seconds and out of the editor's way. Voice capture is the lowest-friction option: speak the follow-up without leaving the current file, and let the AI file it. The discipline is capture now, clarify later. Every item you clarify mid-function is a context switch you pay for twice.

Related reads

• Claude Code task inbox: durable agent handoffs
• Markdown task management
• Task management API reference
• AI task managers: the pillar guide

References

• Getting Things Done, David Allen, 2001, revised 2015.
• GitHub Issues documentation, GitHub Docs.
• Obsidian Tasks plugin, open source on GitHub.