on
Task Management for Agentic Coding
When working on a project and refining product specifications, there is a never ending list of tasks, chores, and features. For those who’ve worked in a product engineering organization, you live and die by Jira tickets which scope the work for you. These are the workflows I’ve experimented with during my journey with Claude Code to keep tasks organized:
- GitHub Issues
- Backlog.md
- Linear
- Old napkins
Anthropic announced Claude Code’s change from todo to tasks, while I was finishing up this blog post.
Claude Native Tasks
I was polishing this post and when Anthropic implemented the native tasks functionality.
It was clear we needed to evolve Todos to help Claude work on longer projects. This need was also emerging in the community and we took inspiration from projects like Beads by Steve Yegge.
I didn’t see updated documentation at the time on Anthropic’s website, but I tried to trigger the task feature just by prompting Claude to create tasks. Suprisingly, it worked. There are some obvious differences from the legacy todo. Now tasks can be dependent on other tasks like a ticketing system.
This now gives you a dependency graph that looks like this:
Dependency Graph:
#1 Species Selection
├── #2 Site Selection
│ └── #3 Soil Prep ──┐
└── #4 Cold Stratify ──────┴── #5 PLANT ──┬── #6 Watering
└── #7 Pest Monitoring
As mentioned in the announcement, I found the task list in ~/.claude/tasks/2dfc514e-cee3-4306-aba5-c1cc21fbe167. Each task list will have it’s own folder based on Claude’s session_id. Based on Claude Code’s telemetry, the session_id matches task folder.
SELECT
log_attributes::JSON->>'session.id' as session_id,
timestamp::TIME as time,
body as event,
json_extract_string(log_attributes, '$.model') as model,
json_extract_string(log_attributes, '$.tool_name') as tool,
FROM read_parquet('logs/claude-code/**/*.parquet')
WHERE log_attributes::JSON->>'session.id' = '2dfc514e-cee3-4306-aba5-c1cc21fbe167'
ORDER BY timestamp;
┌──────────────────────────────────────┬──────────────┬───────────────────────────┬───────────────────────────┬────────────┐
│ session_id │ time │ event │ model │ tool │
│ varchar │ time │ varchar │ varchar │ varchar │
├──────────────────────────────────────┼──────────────┼───────────────────────────┼───────────────────────────┼────────────┤
│ 2dfc514e-cee3-4306-aba5-c1cc21fbe167 │ 02:50:19.03 │ claude_code.user_prompt │ NULL │ NULL │
│ 2dfc514e-cee3-4306-aba5-c1cc21fbe167 │ 02:50:24.571 │ claude_code.api_request │ claude-haiku-4-5-20251001 │ NULL │
│ 2dfc514e-cee3-4306-aba5-c1cc21fbe167 │ 02:50:45.52 │ claude_code.api_request │ claude-opus-4-5-20251101 │ NULL │
│ 2dfc514e-cee3-4306-aba5-c1cc21fbe167 │ 02:50:45.536 │ claude_code.tool_decision │ NULL │ TaskCreate │
│ 2dfc514e-cee3-4306-aba5-c1cc21fbe167 │ 02:51:23.371 │ claude_code.api_request │ claude-opus-4-5-20251101 │ NULL │
├──────────────────────────────────────┴──────────────┴───────────────────────────┴───────────────────────────┴────────────┤
Each task is numbered JSON file, this is an example of 1.json
{
"id": "1",
"subject": "Select appropriate milkweed species for your region",
"description": "Research and select native milkweed species suited to your USDA hardiness zone and local conditions. Common options include: Asclepias tuberosa (Butterfly Weed) for dry, sunny areas; Asclepias incarnata (Swamp Milkweed) for moist areas; Asclepias syriaca (Common Milkweed) for meadows; Asclepias speciosa (Showy Milkweed) for western regions. Consider bloom time, height, and moisture requirements.",
"activeForm": "Selecting milkweed species",
"status": "pending",
"blocks": [
"2",
"4"
],
"blockedBy": []
}
This is an exciting feature that I’ll have to continue exploring. Before this task feature, this original post goes over my customized Task Workflow. It’s somewhat similar.
Customized Task Workflow
I discovered ticket on GitHub. It’s a git‑based issue tracker that replaces the earlier beads project beads, which stored tasks as JSONL files in a .beads/ directory and used SQLite for caching.
ticket (tk) is a portable bash script that handles the ticket lifecycle. Tickets are tracked in a .tickets/ directory as a markdown file.
---
id: m-0187
status: open
deps: [m-0a98]
links: []
created: 2026-01-13T00:46:49Z
type: task
priority: 2
assignee: Jimmy
parent: m-d67e
---
# Update generation pipeline to pass through model fields
Update src/pipeline/stages/generation.ts to handle and pass through the new model-related return fields from generateStory().
Files: apps/workers/queues/story-generator/src/pipeline/stages/generation.ts (modify)
Pass modelDisplayName and selectionReason from generateStory() result through the pipeline context so they can be captured in analytics.
Using ticket trades fancy features of ticketing and tasking systems, for simplicity. Since the tasks are tracked in markdown files within the .tickets/ directory, it makes it easy for Agentic Tools to read, modify, or even create tickets without needing something like a MCP.
The Setup
Upskilling Claude to Ticket
I expected Claude to know the ticket CLI, but I didn’t want to waste time having it run tk -h and then guess the proper command syntax. I created a simple Claude Skill which provides a CLI reference, and standards and requirements for the contents of tickets. A small snippet of the ticket SKILL.md
---
name: ticket
description: |
Git-native CLI task tracking with `tk` command. Use when creating tasks from RFCs/plans,
managing roadmap features, or tracking work items. Designed for solo developers and AI agents.
Use when: breaking down plans into tasks, prioritizing features, or checking what to work on next.
---
# Ticket - CLI Task Management
Git-backed issue tracker (`tk`) storing tickets as markdown+YAML in `.tickets/`. Designed for AI agents.
## Quick Reference
tk ls # List all tickets
tk ready # What can be worked on now (unblocked)
tk blocked # What's waiting on dependencies
tk show <id> # View ticket details (partial IDs work)
tk create "Title" [opts] # Create ticket
tk start <id> # Mark in_progress
tk close <id> # Mark completed
Project Manager Agent
It wasn’t obvious to me until seeing examples of other Claude Agents but an agent can load a skill. This is relevant because I want to be efficient with my token usage and I want to keep my agent file small. Whether I prompt the project manager agent, or it automatically gets orchestrated, it will load the aforementioned ticket skill and take care of business. A snippet from my project-manager-agent.md:
---
name: project-manager
description: Organizes tasks using `tk` CLI. Use for breaking down RFCs/plans into tickets, prioritizing roadmap features, and tracking what to work on next.
tools: Read, Write, LS, Bash
---
You help Jimmy stay organized using the `tk` CLI. Keep things simple - no ceremonies, just useful task tracking.
**CRITICAL:** Before starting any work, read `~/.claude/skills/ticket/SKILL.md` and its references in `~/.claude/skills/ticket/references/`. This gives you all `tk` CLI commands, workflows, and ticket content guidelines.
## Core Jobs
1. **Break down plans** - Convert RFCs and plans into actionable tickets with dependencies
2. **Prioritize** - Help decide what to work on next based on priority and blockers
3. **Track progress** - Keep ticket status current, close completed work
The combination of having an agent invoking a skill reduces hallucinations and guesswork the LLM will do when performing simple ticket actions.
The Workflow
Planning
- Create RFC for feature/functionality
- Have the Project Manager Agent read the RFC and create tickets for the proposed solution
- Manually review all the tickets to ensure it aligns with RFC’s proposed solution
- Prompt Claude to begin
Execution
When the tickets are created and properly organized, the work is kicked off with a simple prompt
Have project-manager orchestrate implementation of this epic t-a3be
Similarly to the new Claude task, Claude can understand the dependencies look like and work on the tasks in a linear fashion, or orchestrate multiple sub-agents to work on tasks that don’t have a dependency.
Summary
Anthropic’s move to tasks and the work on my task management workflow validate the fact there needs to be a simple way to manage tasks. This workflow would definitely not work when you are part of a development team, but the simplicity has been perfect for working on my own projects. Taking advantage of skills and agents help make good use of tokens while keeping relevant context available while providing a good developer experience.
Try out the project-manager-agent.md and the accompanying ticket skill. You will need to ensure ticket CLI is installed.
Bonus: Zsh helpers (ticket search)
These are two zsh functions I use in .zshrc that help working with tickets. The first one requires fzf, bat, and ripgrep (rg). As commented, it allows fuzzy search for ticket contents by simply using tks otel which pops open a nice interactive fzf filter
# Fuzzy ticket search: rg <query> → fzf filter → bat preview w/ highlighted line
# Usage: tks [query] (e.g. tks config, tks logging, tks deps)
tks() {
local query="${1:-.}"
rg -n "$query" .tickets/ | fzf --preview "bat --color=always --style=numbers --highlight-line \$(echo {} | cut -d: -f2) \$(echo {} | cut -d: -f1)"
}
Bonus: Zsh helpers (ticket list)
A second zsh function is slightly different but just lists all the tickets using the fzf interactive filter. This is done by looping through all of the ticket markdown files and extracting the id and title. This allows browsing through all of the tickets.
# Ticket list: shows ID + title on left, full ticket on right
# Usage: tkl
tkl() {
for f in .tickets/*.md; do
[[ -f "$f" ]] || continue
local id=$(awk '/^id:/ {print $2; exit}' "$f")
local title=$(awk '/^# / {sub(/^# /, ""); print; exit}' "$f")
printf '%s\t%s\t%s\n' "$id" "$title" "$f"
done | fzf --with-nth=1,2 --delimiter=$'\t' --preview 'bat --color=always --style=numbers {3}'
}
