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

[dead]

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?

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.

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

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.

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