Show HN: VS Code Agent Kanban: Task Management for the AI-Assisted Developer

hodanli · 3 days ago

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

gbro3n · 3 days ago

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.

hodanli · 3 days ago

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.

swaminarayan · 3 days ago

“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.

gbro3n · 3 days ago

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.

physicles · 3 days ago

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.

arikrahman · 3 days ago

Manus workflow uses three file approach via deliverables.md, taskplan.md, and notes.md. I use this combined with VSDD with my agents.

swaminarayan · 3 days ago

sure will take a look

scotty79 · 3 days ago

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.

noemit · 3 days ago

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.

Dead Comment

trvz · 3 days ago

Lane position should be managed by putting files into different folders.

Name and dates can also be stored in the filename and file metadata.

gbro3n · 3 days ago

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.

gbro3n · 3 days ago

Intro: https://www.appsoftware.com/blog/introducing-vs-code-agent-k...

Youtube (Quick demo): https://www.youtube.com/watch?v=Y4a3FnFftKw

GitHub: https://github.com/appsoftwareltd/vscode-agent-kanban

maurelius2 · 3 days ago

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?

gbro3n · 3 days ago

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.

BloodAndCode · a day ago

ngl this actually makes a lot of sense. i've been running into the same “context rot” problem with copilot / claude sessions… you spend like an hour discussing architecture with the agent and a few days later the whole reasoning is basically gone. starting from scratch again... the idea of keeping the planning conversation as plain markdown in the repo is kinda neat. boring in a good way. no database, no hidden state, just files you can diff and commit. feels very git-native. also like the plan → todo → implement separation. forcing the agent to write the plan first probably saves a lot of token-wasting thrashing. curious though — how messy do those task md files get after a while? i can imagine long agent conversations turning them into pretty big logs.

empath75 · 3 days ago

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.

sathish316 · 3 days ago

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

gbro3n · 3 days ago

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?