Show HN: VS Code Agent Kanban: Task Management for the AI-Assisted Developer(appsoftware.com)
appsoftware.com
Show HN: VS Code Agent Kanban: Task Management for the AI-Assisted Developer
https://www.appsoftware.com/blog/introducing-vs-code-agent-kanban-task-management-for-the-ai-assisted-developer
59 comments
I am using another VSCode Kanban extension. Very similar workflow to this one. I am very happy with it, it solved many issues I am having with context.
https://github.com/LachyFS/kanban-markdown-vscode-extension
https://github.com/LachyFS/kanban-markdown-vscode-extension
That's a nice UI on that board. It's advertising the ability to allow the agent to help manage tasks, where this approach uses the tasks to drive the agent.
The way I do it is with an agents.md prompt (though the extension provides a skill). Basically, if a Kanban item is created and referenced, ai uses that to log changes, decisions, and proposed commit messages etc. If there isn't a Kanban item, it creates one and does the same.
“Context rot” with AI coding tools is definitely real. After a few sessions the agent forgets earlier decisions, and you end up repeating the same planning conversation again.
Storing the plan and discussion as Markdown in Git is an interesting approach. It basically treats the agent’s reasoning as part of the project history, not just the final code.
Curious if others here are doing something similar to keep context across sessions.
Storing the plan and discussion as Markdown in Git is an interesting approach. It basically treats the agent’s reasoning as part of the project history, not just the final code.
Curious if others here are doing something similar to keep context across sessions.
I'd been using this workflow for a while, but this post I found on HN a couple of weeks ago really solidified it: https://boristane.com/blog/how-i-use-claude-code/
> The workflow I’m going to describe has one core principle: never let Claude write code until you’ve reviewed and approved a written plan. This separation of planning and execution is the single most important thing I do. It prevents wasted effort, keeps me in control of architecture decisions, and produces significantly better results with minimal token usage than jumping straight to code.
> The workflow I’m going to describe has one core principle: never let Claude write code until you’ve reviewed and approved a written plan. This separation of planning and execution is the single most important thing I do. It prevents wasted effort, keeps me in control of architecture decisions, and produces significantly better results with minimal token usage than jumping straight to code.
I’ve been following that post too since I started using Claude (about two weeks now) and it’s great. Sometimes for small changes I shorten research+plan into one step but I always tell it to stop and wait before it writes the code.
One thing I’ve learned: if you notice the agent spinning its wheels, then throw the work away, identify a fix (usually to Claude.md) and start over. Context rot is real.
One thing I’ve learned: if you notice the agent spinning its wheels, then throw the work away, identify a fix (usually to Claude.md) and start over. Context rot is real.
Manus workflow uses three file approach via deliverables.md, taskplan.md, and notes.md. I use this combined with VSDD with my agents.
sure will take a look
I'll never understand why people treat context as anything other than ephemeral.
If you had a coworker that had tendency to hold everything about the project in their head you would push them to write stuff down eventually.
In strong words probably.
If you had a coworker that had tendency to hold everything about the project in their head you would push them to write stuff down eventually.
In strong words probably.
I have a log of commits and the decisions and changes for each commit. I use it as a source of data/context when building out plans.
I agree with the other commenter who said they don't build anything without a plan. I would double down on that and say that you need to overplan, and regularly toss out plans as you do research/discovery.
I agree with the other commenter who said they don't build anything without a plan. I would double down on that and say that you need to overplan, and regularly toss out plans as you do research/discovery.
Lane position should be managed by putting files into different folders.
Name and dates can also be stored in the filename and file metadata.
Name and dates can also be stored in the filename and file metadata.
Working on additional meta data in the file. What makes you prefer to have lanes managed by file move? I considered it but was concerned about the potential loss of data if there are unsaved changes in the file, or the user accidentally moving a file while the agent is writing to it. I will consider that further though.
I can certainly see the appeal of distributing the context with vc. However, I have always imagined this to be integrated into an existing kanban workflow, similar to a Jira or gh issue board. Perhaps agent specific, perhaps not.
Furthermore, an existing kanban (ticket) workflow will expect you to refine the context into something more ... concentrated, or at least something that we are used to seeing as developers working with tickets, at least more so than the chat history that seem to be favored.
Have you put any thought into how this would integrate into such a process?
Furthermore, an existing kanban (ticket) workflow will expect you to refine the context into something more ... concentrated, or at least something that we are used to seeing as developers working with tickets, at least more so than the chat history that seem to be favored.
Have you put any thought into how this would integrate into such a process?
I did - GitHub and Trello (and I expect Jira) have APIs that could be used to hook up an MCP server. I liked the idea of conversing with the agent in the ticket, but I decided against that because I'd have to keep refreshing the issues, and it seemed a bit janky moving in and out of the IDE.
I also considered a full harness that could stream / sync the responses, but as per my comment below, implementing a full harness meant loosing a lot of the IDE integration features that come with the hand off to GitHub Copilot.
> I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).
Having worked with a flow similar to this for a while - the markdown files become quite valuable as a history of planning and decisions for features. I didn't want to loose that. I just needed some help with managing the plan files I was maintaining - which the kanban board tooling does. A few command shortcuts via @kanban help too
Regarding what goes into the files, the agent tends to be quite concise - you don't see the whole train of thought that some of the harnesses surface.
I also considered a full harness that could stream / sync the responses, but as per my comment below, implementing a full harness meant loosing a lot of the IDE integration features that come with the hand off to GitHub Copilot.
> I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).
Having worked with a flow similar to this for a while - the markdown files become quite valuable as a history of planning and decisions for features. I didn't want to loose that. I just needed some help with managing the plan files I was maintaining - which the kanban board tooling does. A few command shortcuts via @kanban help too
Regarding what goes into the files, the agent tends to be quite concise - you don't see the whole train of thought that some of the harnesses surface.
I had claude build me something similar for my own autonomous agent system, because I was irritated at how much friction Jira has. I suspect a lot of people will do this.
OpenKanban is pretty cool if you’re on the other end and want to use Terminal for both Coding and Task/Project management. It’s almost as good as a Terminal version of VibeKanban, but not so feature rich - https://github.com/TechDufus/openkanban
That does look great. I will check that out. What is the storage for the tasks? I didn't love the Git worktree flow when I tried vibe kanban, spawning lots of folders seemed like it could get problematic on large codebases - unless I'm missing something and just need to get used to that?
I think a container of Kanboard https://kanboard.org/ and an MCP integration would achieve something similar - mostly cause when I think of project management tools that is the only one that actually feels insanely snappy, compared to the slowness of Jira, OpenProject and tbh Trello is also slower.
Would actually be cool to have more local tools like that, that something like Claude Code can integrate with. Find a bug in the code of your own implementation? Comment it in the issue, or add a new thing to fix, then at the end of implementation do a small retro and maybe end up with a SHORT sentence to add to CLAUDE.md on what to look out for in the particular project, OR create a new work item to make some additional prebuild scripts or tests.
Would actually be cool to have more local tools like that, that something like Claude Code can integrate with. Find a bug in the code of your own implementation? Comment it in the issue, or add a new thing to fix, then at the end of implementation do a small retro and maybe end up with a SHORT sentence to add to CLAUDE.md on what to look out for in the particular project, OR create a new work item to make some additional prebuild scripts or tests.
This is pretty awesome. I might build something like this into https://github.com/rcarmo/piclaw (I already have checklists and an editor, so...)
The "context rot" framing is spot on. I've seen the same thing discussed a lot in CI/CD tooling circles — agents lose track of what's already been tried and start suggesting the same fixes in loops.
Storing the reasoning as markdown in git is a clever move. It means the context survives not just across sessions but across team members too. Someone can pick up a task and see why certain approaches were rejected, not just the final code.
Curious if you've found that agents actually read the prior context reliably, or if you need to explicitly inject it at the start of each session.
Storing the reasoning as markdown in git is a clever move. It means the context survives not just across sessions but across team members too. Someone can pick up a task and see why certain approaches were rejected, not just the final code.
Curious if you've found that agents actually read the prior context reliably, or if you need to explicitly inject it at the start of each session.
For anyone still watching this thread, I have reworked the UI to move the task board to the editor pane from the side bar, and have worked to improve the agents tracking of the core instruction set and current task reference in a way that allows working on parallel threads.
https://github.com/appsoftwareltd/vscode-agent-kanban
https://github.com/appsoftwareltd/vscode-agent-kanban
Excited to see many version of such tools to pop up, was also planning on building my own actually. Hope people can share the most competitive ones here in the comments.
There's also https://github.com/openai/symphony that's being developed following a similar Kanban pattern based agent manager (though yours is more sophisticated at the moment imo)
Interesting to see the Kanban workflow being adapted to managing agents, makes sense; each item having the same UX as a Github Issue.
Interesting to see the Kanban workflow being adapted to managing agents, makes sense; each item having the same UX as a Github Issue.
Thanks. I also saw Vibe Kanban which looked quite mature with lots of features. But I was really liking working with markdown files in VS Code - with everything that comes with that (version control capability etc). I went down the route of implementing a full harness for a while like Vibe Kanban, but the issue was that it was unlikely (without significant effort) to be as good as Github Copilot chat, and it meant forfeiting all of the IDE integrations etc (like diff visualisation for the agents actions etc).
Having the Kanban board in VS Code where I'm working, backed by markdown, GitOps friendly files works really well. Moving from the markdown file to the chat editor to type 'plan', 'implement' isn't what I really wanted, but it's really not a problem once you get used to the flow.
Having the Kanban board in VS Code where I'm working, backed by markdown, GitOps friendly files works really well. Moving from the markdown file to the chat editor to type 'plan', 'implement' isn't what I really wanted, but it's really not a problem once you get used to the flow.
What I don't get is why not just use GitHub/Jira kanban directly with the CLI. We don't put them in git for multiple reasons. What are the people who only work in the browser going to do with this?
It reminds me of how Zed wants to have built in Slack when it will be impossible to get everyone to use Zed. A feature that can never really materialize because developers get a say in their tools
It reminds me of how Zed wants to have built in Slack when it will be impossible to get everyone to use Zed. A feature that can never really materialize because developers get a say in their tools
For a long time I've been an agile fundamentalist. I welcome agent assisted coding because it reduces team size and increases autonomy, experimentation, and generally makes self organizing teams a more obvious choice.
Highly structured pseudo agile practices like scrum, never mind SAfE, make even less sense now than they did before. Flat collegial teams for the win.
Highly structured pseudo agile practices like scrum, never mind SAfE, make even less sense now than they did before. Flat collegial teams for the win.
I would say that a kanban board is not synonymous with scrum. In this workflow, the tasks are a way of organising task threads and recording the consideration, decisions and actions taken while working with an AI agent.
Kanban boards are fine. But if you load them down with the rules and elaborations they become part of a travesty of agility. Kanban originated as a lightweight shop floor MRP technique. It was meant to be run by the people making stuff.
I mean, this is a task board and not a Kanban board - Kanban implies things like Work In Progress limits, continuous improvement, and measuring flow to get rid of blockers.
But you're right - you can visualize your workflow without using Kanban - I think it's weird how the term gets appropriated here.
But you're right - you can visualize your workflow without using Kanban - I think it's weird how the term gets appropriated here.
The .md task format as persistent source of truth is the key insight. Context rot is a real problem mid-sprint when agents lose track of earlier decisions. Do you diff against previous state if the agent rewrites a task file mid-execution, or does the human review before committing?
Great to see more products in this space! Definitely going to try this out on desktop.
I’m doing a fair amount of work on mobile, and prompting remote agents. I would love someone to build an OSS cross-platform kanban. It’d probably be complex to add triggers of workflows both locally and remotely though.
I’m doing a fair amount of work on mobile, and prompting remote agents. I would love someone to build an OSS cross-platform kanban. It’d probably be complex to add triggers of workflows both locally and remotely though.
Maybe it will go that way eventually. I haven't got into being able to hand off to agents in the cloud yet, I think as good as LLMs are getting, for complex / professional work the agents still need a lot of steering. I just have to be in the editor with the agent!
I really like tracking things. And with recent changes in agentic coding, these harnesses are missed. Though I was exploring Traycer AI for the use case, would you say this GitHub repo provides same stuff for free ?
Yes - and keeps the user in the IDE. There's lots of products with their own harness. I know harnesses are not that complex to build - but VS Copilot has really nice integrations with the editor. Either one of these companies has to build their own editor, the IDE's need to build in their own task management / kanban, or we need an extension (like this one). I'm working on improving the UI task file management and AGENT instruction, but the hooks that VS Code exposes regarding what you can inject into the chat are something I'm having to work around.
Nice, thanks for quick response. Appreciate it
This is interesting. We've seen markdown as the app. This is markdown as the database for your tasks.
Sorry for the slightly unrelated comment, but the amount of AI written slop comments here is so high. Was this caused by mentioning "AI" in the title?
I think OpenClaw is the reason we are getting so much AI slop these days. The comments here with "key insights" are coincidentally < 1 month old. It seems for some reason, OpenClaw/NanoClaw loves Show HN posts.
Does it gather code level context itself ? Or we need to provide ?
Can we stop all these vibe-coded projects landing on the front page? It is annoying. Just feels like reddit.
guerython(1)
hkonte(1)
xxwink(1)
GitOps & team friendly kanban board integration inside VS Code Structured plan / todo / implement via @kanban commands Leverages your existing agent harness rather than trying to bundle a built in one .md task format provides a permanent (editable) source of truth including considerations, decisions and actions, that is resistant to context rot