Dispatch

by Kai Mysliwiec
5
4
3
2
1
Score: 33/100

Description

Dispatch is a board for Obsidian that gives a small agent-native team a working process: skills that run through the wiki and the team chat, and a chip on every card that sends an agent at the work.

Reviews

No reviews yet.

Stats

6
stars
158
downloads
1
forks
24
days
5
days
20
days
1
total PRs
0
open PRs
0
closed PRs
1
merged PRs
51
total issues
45
open issues
6
closed issues
132
commits

Latest Version

21 days ago

Changelog

The settings tab has its input fields back

0.2.3 shipped a settings tab that rendered no input controls on Obsidian 1.13 or later: every setting appeared as a name and a description with nothing to type into. Legible, and completely inert. If you are on 1.13+, upgrade — there is no workaround short of editing data.json by hand.

Fixes https://github.com/kaimys/obsidian-dispatch/issues/5

What happened

Obsidian 1.13 renders a settings tab from getSettingDefinitions() and stops calling display() as soon as that array comes back non-empty. 0.2.3 added getSettingDefinitions() to feed the new settings search with names and descriptions only, on the assumption that display() would carry on rendering — so all 37 rows arrived without their controls. Below 1.13 the API does not exist, display() still ran, and the tab worked, which is why it passed testing against minAppVersion 1.7.2 and shipped broken to everyone above it.

Introduced in https://github.com/kaimys/obsidian-dispatch/releases/tag/0.2.3 — that release note claimed rendering was unchanged on 1.13+. It was not, and this is the correction.

No settings were lost. data.json and the device-local config kept their values and the board kept reading them throughout; only editing from the UI was affected.

The trade-off

Dispatch is invisible to Obsidian's 1.13+ settings search again, which is the feature 0.2.3 was reaching for. Keeping it would mean porting all 37 settings to declarative control/render definitions and raising minAppVersion to 1.13, dropping every user below it. That is a deliberate decision rather than a lint fix, and it is not scheduled.

minAppVersion stays at 1.7.2. Nothing else changes: no migration, no configuration change, no behaviour change outside the settings tab.

Install

Download main.js, manifest.json and styles.css below into <vault>/.obsidian/plugins/dispatch/, or install Dispatch from Obsidian's community plugin directory. Requires Obsidian 1.7.2+. Desktop only.

Full changelog: https://github.com/kaimys/obsidian-dispatch/compare/0.2.3...0.2.4

README file from

Github

Dispatch

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
— Andrej Karpathy, LLM-Wiki

Dispatch is a board for Obsidian that gives a small agent-native team a working process: skills that run through the wiki and the team chat, and a chip on every card that sends an agent at the work.

Dispatch Boards

Your coding agents ship faster than you can decide. You are now the bottleneck — what remains of the development cycle is deciding what to build, agreeing on it as a team, and reviewing what comes back. Dispatch turns an agent-friendly wiki (à la Karpathy's LLM wiki pattern) into the cockpit for that human side: tickets are plain notes, boards are live views over their frontmatter, and every card can dispatch a coding agent — Claude Code, Codex, any CLI — into the right repository.

  • Refinement is the new development. The agent posts a ticket's open questions into your team chat (Slack via MCP), the team answers where it already talks, and the answers flow back into the spec. Every card shows its refinement state as a ? N badge that burns down to green — green means build-ready.
  • Release planning is drag & drop. The Release Plan view groups tickets by target version: live weighted progress per release, velocity-based forecasts that accumulate across versions, linked release notes for everything shipped. Drag a card — the plan is up to date the moment you drop it.
  • Meetings run themselves around you. The agenda is prepared from the board; after the call, a NoteTaker transcript (e.g. Google Gemini) becomes an interpreted report in your vault, decisions are folded into the affected tickets automatically, and the action items show up per person on the Meetings and Todos tabs.
  • Testing works like refinement. Manual test plans cover only what the automated suites don't; a ✓ N badge counts the open checks through review and turns green when a ticket is safe to ship.
  • Agent skills and MCP are the glue. Chips on the board are one-liners (/refine US00042); the workflow logic behind them lives in your code repository — versioned with the code, reviewed like code, shared through git — while MCP connects the agent to your team's Slack, your tracker and your NoteTaker. Each workflow is one file, with a thin stub per agent, so Claude Code and Codex run the same process instead of two copies that drift. Wiki, team and codebase become one loop, and the agents run it with you.

Under the hood, two primitives: boards (kanban views driven by note properties — drag & drop writes frontmatter) and chips (buttons that launch coding agents with the ticket as context). Configure more than one agent and the chip asks which to run, showing you the exact command before it does. Desktop only — chips and automations spawn local processes.

Documentation

Page What's in it
Overview The four boards — Kanban, Release Plan, Meetings, Todos — and how each one behaves
Wiki structure The three layers, an example folder tree to adapt, and where the wiki lives relative to your code
Page types The frontmatter contract: every page, tickets (incl. the freeze rule), ADRs, releases, meetings
Workflow skills The skill catalog to adapt — ticket loop, releases, meetings, recurring maintenance
Installation & configuration Install, settings, chips and tool commands, run lifecycle, automations, security model

New to the idea? Read Overview, then Wiki structure.

Quick start

1. Install. Open Settings → Community plugins → Browse, search for Dispatch, install and enable it — or go straight to the directory listing.

2. Let an agent set it up. An unconfigured board says so and offers a Set up with claude button, which starts Claude Code in your vault folder with the right prompt. It shows you the exact command before running anything.

The skill behind that button lives in this repo's plugin marketplace:

Claude Code:

/plugin marketplace add kaimys/obsidian-dispatch
/plugin install dispatch-setup

Codex:

codex plugin marketplace add kaimys/obsidian-dispatch
codex plugin add dispatch-setup@dispatch

Or, if you would rather have the skill on its own without the plugin, ask Codex to fetch it — its bundled skill-installer takes a repository path:

$skill-installer install kaimys/obsidian-dispatch plugins/dispatch-setup/skills/dispatch-setup

The prompt carries those two lines itself, so the button works before you have installed the skill. The setup interviews you about your wiki, writes both configuration layers, scaffolds ticket templates and workflow commands, and verifies the result.

See Installation & configuration for the tool command, the per-tool prompt prefix, and the Codex hook wiring — including the trust step, which a Codex setup does nothing without.

Prefer to do it by hand? Every setting the skill writes is documented in Installation & configuration.

License

MIT

Conclusion

Does the setup work for you? Did you run into problems? Is this plugin usefull for you? Any feedback is welcome. Please leave a post on Github Discussions.

Happy prompting!

Or in the words of Andrej Karpathy:

"... an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."
— Andrej Karpathy, LLM-Wiki