Rendered at 15:31:16 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
riki137 1 days ago [-]
Hey, I've just recently started using https://github.com/cline/kanban which seems to be similar to your tool, but in Web UI.
How does your tool compare? What makes it better? I'm rooting for competition in this area.
hydra-f 6 hours ago [-]
Completely different philosophies. I will share a TL/DR below:
MY KANBAN CLI IS:
A project management system to plan, estimate, track sprints, measure velocity, assign roles, and give agents structured tasks with acceptance criteria.
CLINE KANBAN IS:
An agent execution platform to run multiple AI agents in parallel on isolated worktrees, review diffs in a web UI, and auto-commit/PR their output.
SIMILARITIES:
- Local
- Git integration with worktree support
- Agent integration with parallel execution
- Task and dependency tracking
DIFFERENCES:
- Language: Rust 2021 vs TypeScript/Node.js
- Interface: Terminal CLI (JSON output) vs Browser web app (React SPA)
- Task Creation: Human-focused vs Agent-focused
- Agent Control: Agent runs the tool as a CLI utility vs Platform spawns and manages the agent as a child process
- Core Engine: Sprints, story points, velocity, and role-personas vs MCP server management, web diff viewers, and auto-PR toggles
- Lifecycle: 8-state validation engine vs 4-column drag-and-drop layout
- Concurrency: File locking (fd-lock) for safe multi-agent CLI access vs Git worktree isolation for massive parallelism (hundreds of agents)
- Output Target: JSON by default (agents consume it) vs Web UI by default (humans consume it)
- Self-Management: Recalibration engine (auto-heal data, reorder tasks, rebalance sprints, archive) vs Not present
- People Registry: Humans tracked separately from agents (people.json) vs Not present
- Storage: JSON files in .kanban/ (atomic writes, two-tier locking) vs Runtime state streams + config files (no persistent task database)
- Statistics: Cycle time, lead time, revisions, blocks, effort ratio vs None
- Coordination: Shared with teammates via git vs Independent instance
There are many more differences between the two, which brings me to my first point. All in all, I see my Kanban as being a much more structured, human-centric, and controlled environment, since it's a complete management system rather than just an execution layer.
You can practically plan the whole project using my tool, before any implementation even starts. That means complete project structure (via files_to_modify), acceptance criterias (+ context), commit messages, branch names, version bump (handled automatically by the tool as tasks are completed) and so on. It's a full project trace, which uses the full potential of a human + agent development workflow.
deathstroke1234 1 days ago [-]
Wow! Looks cool. Will try it out. Is it self hosted or the data leaves my machine?
hydra-f 7 hours ago [-]
Hello! Completely local, nothing leaves your machine
geraldsterling 3 days ago [-]
That's pretty cool. With agent task systems, do you plan on having an audit log? With a 'why did this change?' sort of deal. I guess kind of like a history to be able to track which agents did what.
hydra-f 3 days ago [-]
Yes, any agent can authenticate using its model name. The tool automatically tracks the who, when, and what for all actions.
For monitoring, it comes with local analytics and high-level statistics across the entire board. It logs exactly how the agent ran the "kb" command and whether any failures occured (including the lefthook, for which it automatically scans and runs upon task transition).
I've also built in various quality-of-life features, such as the files_to_modify field, which automatically keeps track of the work done by the agent:
IF the agent edits only the specified files, the process proceeds exactly as instructed.
ELSE, if the agent deviates, the tool generates a full trace of what was and wasn't edited, and automatically appends any newly modified files directly to the JSON.
honestmaker 3 days ago [-]
love seeing local first terminal tools. switching to the browser just to drag a ticket breaks the flow completely. gonna pull this and test it out.
hydra-f 3 days ago [-]
Thank you! Looking forward to it!
boundless88 3 days ago [-]
What coding agents are supported right now?
hydra-f 3 days ago [-]
It's model-agnostic, so anything works. As long as the model is good at instruction following, it won't have issues with using the tool (and the AGENTS.md workflow).
devansh0718 3 days ago [-]
weirdly as a developer now in ai era i dont like to work in cli. curious if same thing happening with someone
hydra-f 2 days ago [-]
You're either thinking of a service, an electron app or a platform. Which would be just a big of a gap as GitHub is to Git
Even a local browser interface would bloat the core tool with unnecessary maintenance and complexity. I love a good GUI, but that's just how I see it
How does your tool compare? What makes it better? I'm rooting for competition in this area.
MY KANBAN CLI IS:
A project management system to plan, estimate, track sprints, measure velocity, assign roles, and give agents structured tasks with acceptance criteria.
CLINE KANBAN IS:
An agent execution platform to run multiple AI agents in parallel on isolated worktrees, review diffs in a web UI, and auto-commit/PR their output.
SIMILARITIES:
- Local
- Git integration with worktree support
- Agent integration with parallel execution
- Task and dependency tracking
DIFFERENCES:
- Language: Rust 2021 vs TypeScript/Node.js
- Interface: Terminal CLI (JSON output) vs Browser web app (React SPA)
- Task Creation: Human-focused vs Agent-focused
- Agent Control: Agent runs the tool as a CLI utility vs Platform spawns and manages the agent as a child process
- Core Engine: Sprints, story points, velocity, and role-personas vs MCP server management, web diff viewers, and auto-PR toggles
- Lifecycle: 8-state validation engine vs 4-column drag-and-drop layout
- Concurrency: File locking (fd-lock) for safe multi-agent CLI access vs Git worktree isolation for massive parallelism (hundreds of agents)
- Output Target: JSON by default (agents consume it) vs Web UI by default (humans consume it)
- Self-Management: Recalibration engine (auto-heal data, reorder tasks, rebalance sprints, archive) vs Not present
- People Registry: Humans tracked separately from agents (people.json) vs Not present
- Storage: JSON files in .kanban/ (atomic writes, two-tier locking) vs Runtime state streams + config files (no persistent task database)
- Statistics: Cycle time, lead time, revisions, blocks, effort ratio vs None
- Coordination: Shared with teammates via git vs Independent instance
There are many more differences between the two, which brings me to my first point. All in all, I see my Kanban as being a much more structured, human-centric, and controlled environment, since it's a complete management system rather than just an execution layer.
You can practically plan the whole project using my tool, before any implementation even starts. That means complete project structure (via files_to_modify), acceptance criterias (+ context), commit messages, branch names, version bump (handled automatically by the tool as tasks are completed) and so on. It's a full project trace, which uses the full potential of a human + agent development workflow.
For monitoring, it comes with local analytics and high-level statistics across the entire board. It logs exactly how the agent ran the "kb" command and whether any failures occured (including the lefthook, for which it automatically scans and runs upon task transition).
I've also built in various quality-of-life features, such as the files_to_modify field, which automatically keeps track of the work done by the agent:
IF the agent edits only the specified files, the process proceeds exactly as instructed.
ELSE, if the agent deviates, the tool generates a full trace of what was and wasn't edited, and automatically appends any newly modified files directly to the JSON.
Even a local browser interface would bloat the core tool with unnecessary maintenance and complexity. I love a good GUI, but that's just how I see it