A kanban board is usually framed as task tracking. In my case, it gradually became something else: an asynchronous communication layer between me and Claude. Ideas trigger plan generation, column position signals intent, and giscus comments keep code review feedback attached to the work instead of buried in old pull requests.
I have been iterating on how I work with Claude Code for weeks. Session notes helped capture "we tried X, learned Y" moments. Preference files made my defaults explicit. A CLAUDE.md reduced cold starts by telling Claude how to orient at the beginning of a session. All of that improved the conversation, but the friction was never the conversation. The friction was the artifacts. Where do plans live? How do they stay linked to tasks? How do I know what is actually in progress without rebuilding context every time?
Before this, I had a ROADMAP.md that went stale, a PLANNING_DOCS_INDEX.md that duplicated it, and plan files scattered across docs/plans/ with no consistent link to the work they were meant to drive. Every few sessions I would consolidate, reorganize, and try a new structure. Nothing stuck because maintaining it felt like separate work.
The solution ended up being something I had already built: the kanban board. Unlike a text file, it behaves like a state machine that updates as a side effect of doing work. It persists naturally because I am already moving cards to reflect reality, and that makes it a better source of truth than anything I have to remember to curate.
The workflow starts with ideas, not plans. When I have a half-formed thought like "add comments to kanban cards" or "improve Sentry integration," I create a card in the Ideas column with a title and maybe a sentence. No checklist, no spec, and no commitment. That separation matters because Ideas is a place to capture direction without pretending I have already decided.
When I am ready to plan, Claude generates a plan doc in docs/plans/. Once the plan exists, I move the card to To Do and attach a planFile field pointing to the doc. That single link solved an entire class of organizational churn. The card and the plan stay paired, which means I do not need a second index file, a stale roadmap, or a mental map of where the "real" plan ended up living.
Over time, the column positions became signals, not just organization. The board has five columns, and each column carries an instruction. Ideas means "explore this sometime." To Do means "planned, ready to start." In Progress means "work on this now." In Review means "verify this is done." Change Log means "completed." The important part is that I can change those signals asynchronously. If I decide late at night that Sentry should be next, I move the card to In Progress. When the next session starts, Claude reads the board state and can pick up the right work without me spending ten minutes reconstructing context.
Card position handled intent, but I still wanted a place for community input. The repository has collaborators, but the board itself is public. People browsing the roadmap might have thoughts on a feature direction, edge cases I had not considered, or context from their own projects that would help shape the work.
So I added giscus discussion threads to kanban cards. Each card now has a comment section backed by GitHub Discussions, which opens the conversation beyond repository collaborators. Anyone can weigh in on an idea before it becomes code, suggest refinements while work is in progress, or flag concerns that would otherwise require opening an issue. The feedback stays attached to the card rather than scattered across PRs or buried in closed issues, and that makes it easier to incorporate when the work actually starts.
What I ended up with is a full cycle that feels surprisingly stable. An idea gets captured as a card, and community feedback can shape it before any code is written. A plan gets generated and linked. Work starts when the card moves to In Progress, and Claude can read the plan and create a branch. A PR opens and the card moves to In Review with a PR label. After merge, the card moves to Change Log, and the checklist gets marked complete. The card comments feature itself went through that same loop, which is part of why I started trusting the pattern.
A few properties make this work in practice. Structured state beats prose because the board updates with work instead of requiring a separate writing habit. Visual prioritization is implicit because position in a column communicates urgency without extra ceremony. The associations are durable because the planFile links to the spec, the PR label links to implementation, and the giscus thread links to community discussion. Most importantly, the whole system is GitHub-native: the board is JSON in the repo, and the discussions live in GitHub, which makes everything searchable, version-controlled, and hard to lose.
The meta point is that most AI tooling assumes synchronous conversation. You talk, it responds, you clarify, it acts. That model works for quick tasks, but it starts to break down when projects span many sessions and the cost of reloading context becomes the real bottleneck. The kanban board flips that. Instead of re-explaining context each time, I update state asynchronously. Claude reads the state and acts. The board becomes the interface layer between my async thinking and Claude's session-bound memory.
I did not design this up front. The board started as a portfolio demo, then became my roadmap, and then I noticed Claude could read it. The comments came later when I wanted review feedback to persist. Each addition was incremental, and the workflow emerged from use rather than from planning.
If you are collaborating with AI tools across sessions, it might be worth looking for artifacts that persist naturally. Conversation history compresses. Text files require discipline. Structured state survives because maintaining it is part of the work, not separate from it. My kanban board started as a project. At this point, it feels more like infrastructure.
The kanban board is live at dylanbochman.com/projects/kanban. If you want the technical deep dive on persistence, read The Serverless Kanban.