I had very similar thoughts to this piece at the beginning of the year but I took a bit of a different approach with the tool I built, Kan [0]. Rather than markdown files in directories like OP went with, I went for plain json files stored in a `.kan` directory, with the primary interface being not the files themselves but the CLI and an embedded frontend which could be run with `kan serve`. Agents work really well with the CLI and the frontend provides a nice snappy UI for humans to interact with and manage their tasks in a kanban format, all offline and acting entirely on files in the repo's VCS (somewhat like Typemill).
Overall it's been a great workflow and it works great with agents, it's the main way I manage tasks with agents, I agree the 'tickets in the repo' approach works really well.
Shameless plug but I hit these exact same kinds of walls and I tried out alternatives like agent-deck or herdr, but ultimately didn't enjoy the TUI approach that herdr/Tmux solutions offer, so I built Muster [0] and I'm quite proud of it -- it's turning out really well and is my daily driver at home and at work. It uses libghostty so I get the same sort of Ghostty-feel as Ghostty by itself provides. It supports SSH / remote machines well too and allows agents from different harnesses to message and work together thru 'muster daemons'.
Continuing to work on Kan, an offline Kanban board which operates on plain text files in your repo, so you can just commit the entire board into Git!
I'm finding it really good for agentic work these days as, using the kan CLI, agents do really well with it for tracking work and leveraging the board. I'm using it for all my projects these days.
Big fan of gron[0] and zoxide[1]. Gron for flattening and viewing JSON, and zoxide (z) for fuzzily jumping around on my system or on remote systems with z installed.
Also been using Rad [2] (disclaimer: am author) to replace my suite of Bash scripts and write new ones, quite happy with one atm which sets reminders e.g. 'remind 2h check the CI build' which will give me an OS reminder in two hours, I use it a ton at work.
One is Rad [0], a programming language tailored for writing CLI scripts and tools (mainly an alternative to Bash), taking a declarative approach to things like script arguments. Latest push has been largely on static type analysis, since making that really good is the sort of thing that helps both people and AI agents write good Rad.
Second project is Kan [2], a Kanban board which operates on text files on your machine, and is designed to be Git friendly so you can check it into your repo.
I am continuing to work on Kan [0], a dev-focused kanban board that works via plain text files in your repository. I am finding it really useful for solo projects, giving a really simple way to get per-project Kanban boards that I can sync via Git. Since it's local only, it's really snappy, and given the dev-focus, it can offer some pretty nice workflows with local hooks, customization, etc.
The other project I am continuing to work on is Rad [1], a programming language tailor made for writing CLI scripts. It's not for enterprise software, it specializes specifically in CLI, offering all the essentials built-in, such as a declarative approach to arguments and generated help (as opposed to Bash where you have to roll your own arg parsing and help strings each time).
I've been working on Kan [0] which is a CLI written in Go that can serve a Kanban board ( `kan serve` ). Serving the Kanban board means opening up a localhost page for a Kanban board which acts on files stored locally on your machine, in your repo. Just plaintext JSON & TOML files. The Kanban board is written in TypeScript. You commit Kanban board changes like any other files.
I use it for all my personal projects. Any new project where I will have todo lists, I'll run `kan init` and `kan serve`, and begin tracking tasks. Because it's a CLI, you can interact with the board thru the CLI with commands like `kan add` and `kan edit`, so I've even included a SKILL markdown file in the repo which I use to let Claude read and interact with my boards. You can also navigate all your boards from a single `kan serve`, so it's convenient and snappy cross-project too.
Really appreciated this perspective. Much more tempered and less hype than a lot of other articles I see.
I thought the "dont let agents finishing interrupt you" workflow was an interesting point. I've set up chime hooks to basically do the opposite, and this gives me pause to wonder if I'm underestimating the cost of context switching. I'll give it a go.
This is exactly the frustration that lead me to write Rad [0] (the README leads with an example). I've been working on it for over a year and the goal is basically to offer a programming language specifically for writing CLIs. It aims for declarative args (no Bash ops parsing each time), automatic --help generation, friendly (Python-like) syntax, and it's perfect for dev build scripts. I'll typically have something like this:
#!/usr/bin/env rad
---
Dev automation script.
---
args:
build b bool # Build the project
test t bool # Run tests
lint l bool # Run linter
run r bool # Start dev server
release R bool # Release mode
filter f str? # Test filter pattern
filter requires test
if build:
mode = release ? "--release" : ""
print("Building ({release ? 'release' : 'debug'})...")
$`cargo build {mode}`
if lint:
print("Linting...")
$`cargo clippy -- -D warnings`
if test:
f = filter ? "-- {filter}" : ""
print("Running tests{filter ? ' (filter: {filter})' : ''}...")
$`cargo test {f}`
if run:
bin = release ? "target/release/server" : "target/debug/server"
$`./{bin}`
Usage: ./dev -b (build), ./dev -blt -f "test_auth" (build, lint, test auth), ./dev -r (just run).
Overall it's been a great workflow and it works great with agents, it's the main way I manage tasks with agents, I agree the 'tickets in the repo' approach works really well.
[0] https://github.com/amterp/kan
reply