Claude task management: give Claude Code a real task board instead of one long chat
How to manage tasks with Claude Code: one task per piece of work, each with an owner, a due date, a status and a deliverable. Set it up by hand with markdown task files, see where that stops working, and how a calendar of tasks filed by a manager agent fixes it.
Claude task management works when every piece of work is its own task, with an owner, a due date, a status and a deliverable, stored outside the chat. You can build this by hand with markdown task files that Claude Code reads and updates, or have a manager agent file tasks onto a calendar and assign them for you.
Why does one long Claude chat fail as a task manager?
A single chat feels like a to-do list until you have more than one thing going. Then it fails in predictable ways:
- Context fills up. Long sessions get compacted, and the details of task three fade while Claude works on task seven.
- Work interleaves. A bug report, a refactor and a landing page edit share one thread, and every answer has to dig through the other two.
- Status lives in your head. The chat has no column that says "blocked on me" or "done, waiting for review". You rebuild it by scrolling.
- Results scatter. The finished file is somewhere around message 140. The preview link is in message 212.
- Nothing moves while you are away. A chat only advances when you type.
The fix is the one teams already use for people: keep the list of work separate from the conversation about it. Each piece of work becomes a task with its own record, and the chat becomes the place where you create tasks, discuss them, and make decisions.
What should a task for Claude contain?
A task for an agent needs more than a title, because the agent starts with no memory of why the task exists. These fields cover it:
| Field | What it holds |
|---|---|
| Title | One line that starts with a verb |
| Owner | The agent or session working on it |
| Status | todo, doing, blocked, review, done |
| Due | A date, or a condition like "after the auth change merges" |
| Context | Links to files, specs and earlier decisions |
| Done when | Checks that prove it is finished |
| Deliverable | The path or link where the result goes |
| Log | Short notes the agent appends as it works |
"Done when" matters most. "Improve the onboarding email" never finishes. "Draft three subject lines and one body under 120 words, saved to drafts/onboarding.md" finishes, and you can check it in ten seconds.
Keep each task small enough for one session to finish. If an agent needs two days, it is a project, so split it into tasks.
How do I set up a markdown task board for Claude Code?
You can run a decent board with nothing but files in your repo:
- Create a
tasks/folder with one markdown file per task, named like2026-10-07-fix-signup-redirect.md, and put the fields above in each file's frontmatter. - Add
tasks/board.md, a list of every task grouped by status. Claude regenerates it from the task files whenever a status changes. - Put the rules in your CLAUDE.md so every session follows them:
## Tasks
- At the start of a session, read tasks/board.md.
- Work on one task at a time. Set it to doing and write your session name as owner.
- Never edit a task someone else owns.
- Before marking a task done, run its "Done when" checks and write the deliverable path.
- If you need a decision from me, set the task to blocked and write the question in its log.
- Commit the folder. Git history becomes the record of who changed what, and when.
To work the board, start a session and say "take the next todo task". To check progress, open board.md.
What does Claude Code's built-in task list do?
Claude Code has its own task checklist, which you toggle with Ctrl+T. When the task tools are enabled for your model, Claude fills it as it works, marking items pending, in progress or complete, so you can see the steps of the job in front of it. By default the list belongs to one session. Set CLAUDE_CODE_TASK_LIST_ID to a name and sessions share one list, stored under ~/.claude/tasks/. In the experimental agent teams mode, a lead and its teammates share a list where teammates claim tasks and tasks can depend on each other.
Treat it as the agent's working checklist, and keep your board as the record of the work. The checklist answers "what step is Claude on?" Your board answers the questions a checklist was never built for:
- What is due this week, across every project?
- Which tasks are waiting on me?
- Where is the finished file from Tuesday?
- Which agent owns the billing work?
Use both. Let Claude break a board task into checklist steps, then write the outcome back to the board.
Where does do-it-yourself task management with Claude hit its limits?
The markdown board works well for one person running two or three sessions. It strains as soon as the work spreads out:
- Due dates are just text. Nothing fires on Friday because a file says "due Friday". You still have to start the session.
- Recurring work needs a second system. A weekly report means cron, a headless
claude -pcall and a stored token, all living outside the board. - Status drifts. Agents forget to update the file, or two sessions rewrite
board.mdat once and one change wins. - You are the dispatcher. Every task waits for you to open a terminal and say "take the next one".
- There is no week view. A folder of files tells you what exists. It cannot show what happens on Thursday, or how much is landing at once.
- Deliverables live wherever the agent left them. The path in the task is only as good as the agent's last update.
The method is sound. What it lacks is something that runs the board while you are doing other things.
How do I keep task status honest when agents update it?
Agents report optimistically, so a board they maintain needs a few rules to stay truthful:
- Done requires evidence. Before setting done, the agent writes the command it ran and the result, or links the deliverable.
- Add a review state. Agents move work to review. Only you, or a separate reviewer agent, move it to done.
- Blocked means a question. A blocked task must state the exact decision needed, so you can answer it in one line.
- Stale means check. Look at any task that sits in doing for more than a day. Usually the session ended and the status never caught up.
- One writer per field. Agents write status and the log. You write priority and due dates.
These rules matter more than the tool you pick. A board that says done when nothing shipped is worse than having no board, because it teaches you to stop checking.
How does Kavela turn tasks into calendar items?
In Kavela the task board and the calendar are the same surface. You tell Kav, the one agent that runs your workspace, what you need. Kav files it as a task, assigns it to the worker agent that should own it, and the task lands on the calendar in month, week or day view.
A task can run as soon as possible, be scheduled for later, or carry a due date, and multi-day work shows as one band across the days it spans. Recurring work becomes a routine (every Monday at 8:00 in your time zone, optionally only between a start and end date), and work triggered by a webhook or a new file becomes an event. More on that in how to put Claude on a schedule.
Each worker runs in its own cloud computer and can run Claude Code on your own Claude plan. Finished tasks carry their deliverables (files, preview links, reports), and a Delivered list collects everything the workspace produced. Decisions wait in one Approvals inbox, and from Telegram you can check /tasks and /approvals.
Kavela is in early access and works with your own Claude subscription, with a 14-day free trial. Start your free trial