About
Hello HN,Ever since agents have become increasingly common in development, I've been scratching my head as to how to control their randomness. Recently, I decided to emulate an issue-tracking and project-management tool for agent-driven workflows.Kanban is a Rust-based coordination layer designed to provide a feature-rich terminal interface and enforce rigorous workflows. It aims to be versatile and extendable, made to be tailored to any preferred flow. It comes with full git integration and guardrails such that only what truly benefits a project can go through.The workflow boils down to 4 steps:1. The model reads the skill to contextualize the requirements2. It authenticates and receives a strict, schema-validated JSON payload outlining exact files, context, and acceptance criteria3. Implementation is performed within an automatically isolated Git worktree and branch. The tool tracks progress (e.g., verifying all files were edited) before the task is submitted for review4. A reviewer (preferably a human) evaluates the submission and manually transitions the task to "Done," which triggers the final merge and cleans up the task-specific environment.The tool significantly decreases the agent development time, while increasing the human planning phase.There is more to it than I can cover here, so I'd be happy to answer any questions about the architecture, the workflow, or the insights I gained while using it. For more information, I recommend skimming the README, which acts as an index to all documentation files.Repo: https://codeberg.org/hydrafog/kanban
Comments (5)
Agent-first" is doing a lot of heavy lifting there. Curious how agents actually interact with the board, direct file manipulation, or some IPC layer mediating access? Because the moment multiple agents mutate the same task state, you've essentially reinvented distributed systems problems in your home directory.
Local-first is a smart call, but "agent-first" feels premature given how quickly the agent landscape is shifting. What happens when the task schema needs to change because some new model handles instructions differently? 🔧
Local-first with agent support is a practical combination. Managing agent unpredictability through structured task flows makes sense, though the learning curve might be steep for anyone not already comfortable in the terminal.
Local-first + agent-first is an interesting combo. Most agent integrations I've seen just slap an API on top of an existing SaaS product and call it done, which always feels clunky. Curious how you're handling the agent interface, is it just reading/writing to markdown or JSON files directly, or is there some kind of protocol layer for agents to claim tasks and report back? The "controlling randomness" angle makes a lot of sense; giving agents a structured board to pull from beats letting them freestyle over your entire codebase. Would be nice to see how the board state is persisted under the hood.
Wrangling agent randomness straight from the terminal is exactly what we need, congrats on shipping.
Related Products
Free Currency Converter API
Limestone Digital
AI-Powered Software Development, Engineering Team Augmentation,
ChangeSpec
MobileGym: A Verifiable and Highly Parallel Simulation Platform for Mobile GUI A
IronFile - Completely Customizable
Turnkey Industrial SaaS Platform (80k+ LOC) • 12 Enterprise Connectors
Technologies.lat
Quality Assurance for software that is here for the long run
ComingUp