Disclaimer
Is this plugin open source? Yes
Is this plugin completely free? Yes, with an MIT license
Is this plugin vibe-coded beyond the author’s ability to comprehend how it works? No
Link:community.obsidian.md/plugins/dispatch
Dispatch
Dispatch is an agentic ticket board for Obsidian: a property-driven Kanban, milestone, and meeting workspace with chips that dispatch AI coding agents such as Claude Code and Codex directly from your notes.
Dispatch turns Obsidian notes into dispatchable tickets and live board views based on frontmatter. You can send coding agents to repositories, route open questions into team chat for refinement, and track readiness with refinement and test badges, drag-and-drop release planning, and release forecasts.
What it does
-
Display all your tickets on a Kanban board -
Drag and drop tickets between the columns -
Start refinement, planning, and development directly from your Kanban board -
Plan your releases by drag and drop -
Estimate dates for upcoming releases -
Prepare agenda for meetings and summarize meeting notes -
Update tickets based on decisions made in meetings -
Track tasks from tickets and past meetings
How it evolved
We started a new mobile app project in April 2026, just as Karpathy’s post about the LLM Wiki pattern appeared on Gist. Since we needed a place to collect requirements anyway, we decided to set up the project with Obsidian and Google Drive.
We are a small team: one product owner and CEO, one part-time interaction designer, and me as the developer. We connected our ticket tool, Asana, to the Wiki via MCP so user stories were mirrored there. The sync worked both ways, so the user stories stayed aligned between Asana and the Wiki.
We only had one meeting per week, and initially it was difficult for me to get open questions answered quickly. I therefore connected Slack via MCP as well and let Claude support refinement. Each ticket refinement started as a Slack post, where we discussed the open questions for one or two days until they were resolved. Claude then updated the ticket in the Wiki, wrote a summary in the thread, and I started development.
During development, I let Claude extract Architecture Decision Records (see ADRs explained by Martin Fowler) from the tickets and collect them in the Wiki as well. These ADRs set the rules for future development. I had seen this pattern in other projects before, but in this case Claude asked for it explicitly because reading all past tickets to reconstruct implicit decisions was too laborious.
We had a real aha moment when we connected the Google Meet Notetaker, powered by Gemini, to the Wiki. The notetaker summaries are usually only somewhat useful because Gemini lacks the project context. But when Claude imported the full meeting transcript into the Wiki, it could add ticket IDs to the summary and even update tickets based on decisions made during the meeting.
Conclusion
Dispatch started as a small helper for our own AI-assisted development workflow, but it became the place where tickets, refinement, release planning, and meeting follow-ups come together inside Obsidian. In the end, we even dropped Asana.
Karpathy’s LLM Wiki pattern is a strong way to support the development process, especially when you combine it with a group chat like Slack. Over time, the Wiki grows into the backbone of the whole process.
If you use Obsidian as a project workspace and want to experiment with agent-driven development from your notes, I would be happy if you gave it a try. Feedback, bug reports, and workflow ideas are very welcome, especially from people using different project setups or AI coding agents.