I'm a heavy Claude Code user. I would like to do more actual and proper coding in my daily work, but things are as they are. Moving on...

Handling multiple tasks in Claude made me run into a few bottlenecks. One of the more annoying ones was when I had to shutdown / restart my computer. I would be fanning out my sessions, staying idle for quite a bit until the last terminal window could be closed. Not very productive.

The other one was handling post merge tasks on PRs that were waiting for merges. I ended up keeping sessions up just so that when th PR got merged I would know what to do next. It got confusing pretty fast.

We all know and love task managers like JIRA and similar, but we all know how easy those are to setup for your particular workflows, so I decided to build my own task tracker.

Why not Task Warrior?

I have used Task Warrior before and i do like it. Pretty easy to get the hang of it, extensible enough to automate reports and the likes, but unfortunately i did miss some features (extra fields, essentially).

What i built

So, I created task_tracker, which is a task warrior with the features i needed, a task tracker built for agentic workflow integration. You have stories and tasks, a TUI and some claude hooks so it knows how to use them. Code in Codeberg.

Adding a task

Base command is just to add a task. Here's a sample using all the options available (assuming we installed the binary and added it path as tk):

tk task add \
  --status todo \
  --priority low \
  --repo "telekasten-notes" \
  --issue "#61" \
  --pr "task-tracker/#56" \
  --tag "blog" \
  --person "drawings_and_code" \
  --link  "docs/blog-posts-schedule.md" \
  --date "2026-09-14" \
  --slug "blog-posts" \
  --story "blog-posts" \
  --description "" \
  "Publish the task tracker blog post"


# added task #1687

Post merge tasks

The tool does a lot, or more correctly, can be used to do a lot, but one of the features that I use the most is the "check work that needs to be done once this has merged".

I have another tool (commit_automation), that gives me the closed-prs. With the ids outputted there i can just check what's tracked to do next. Let's say i want to post this post to Linkedin. I'd create a task for that with

# some fields ommited for brevity but taken for the previous command
tk task add \
  --depends-on "1687"
  "Publish the task tracker blog post to Linkedin"

This new task will not be immediately visible when we filter for workable tasks, so we don't have it listed while not being able to act on it.

Once the post is actually published I (or Claude Code), can just do tk task list --repo telekasten-notes --workable, or any other filers like slug, issue, prs,... and we'll get

#1687 todo   low    2026-09-14 blog-posts [#273] @drawings_and_code
Publish the task tracker blog post
[[blog-posts-schedule]]

We then close it with tk task edit 1687 --status done, and rerunning the list command now returns

#1691 todo   low    2026-09-14 blog-posts [#273] @drawings_and_code
Publish the task tracker blog post to Linkedin
[[blog-posts-schedule]]

So we know what do next!

Automating all of this

Now, while running this manually is doable (like we do with TaskWarrior), the productivity bonus here is when we actually integrate this with Claude Code.

The repository has a few skills and hooks so Claude knows how to manage the tool by itself. When creating plans, doing any work overall, stopping sessions, etc, Claude prompts me to create the tasks.

As work is done with tasks for everything (most of the time duplicating Github / JIRA issues), we always have local, easily accessible information on what needs to be done in which order. This makes it easy to ask I merged PR 61 for this repo. What are the next steps? or to mention i got the feedback from @person for a task in this repo and we need to follow up on that.

Here's an example I add to tackle recently. For "reasons", I had to stack /chain several PRs which required independent reviews and other work coming in.

Due to the way this was done, PR A needed to run one migration that conflicted with another migration with PR B: it required renaming the migration. I wanted both PRs to go green on the pipelines, but after A would be merged, B would need some changes.

This was a task with the fields pointing to the local docs with what needed to be donw and why.

By the way, I use telekasten (Zettelkasten) for Neovim, so all my plans, docs, notes are stored in a central location.

So when PR A got merged, the follow up was already written and properly chained so the changed would be done correctly before PR B even got requested a review.

This is a simple example, but more complex ones can be achieved.

And the graphical interface

Did I mention there's also a TUI?

Task Tracker TUI