bassimeledath/dispatch: a Claude Code skill that turns your session into a task dispatcher

The context window problem dispatch is aimed at

A single Claude Code session doing several jobs in sequence accumulates context until it degrades. The README describes the failure directly: you ask Claude to review code, refactor a module, write tests, and update docs, and by the third task it is losing track, and by the fifth you are starting a new session. Dispatch attacks that by inverting the roles. The main session stops being the worker and becomes a mediator. It writes a checklist and hands the checklist off, while the reading, reasoning and test-writing happen in separate worker contexts that each get a full window. The intended user is someone already working inside Claude Code on multi-part work: a pre-launch sweep, a set of audits across different subsystems, or anything where the tasks do not depend on each other's intermediate output. If your work is one long dependent thread, there is nothing here to fan out.

How a dispatch actually flows from prompt to worker

The mechanism is a checklist plus a background process. You run /dispatch followed by a task description. Dispatch reads the prompt and creates a plan, which the README calls the only context your main session needs. A background worker picks up that plan in a fresh, full context window and checks off items as it goes. The main session is free the moment the worker is dispatched, so you can dispatch another task, ask a question, or write code while workers run in parallel. The README's five-task example shows the fan-out shape: five plans, five workers, three models, three worktrees, with the main session idle after writing the checklists. Model selection is per task. You name a model in the prompt, and if it is not in your config, dispatch auto-discovers and adds it. If you name several models in one prompt, dispatch uses the last one mentioned. If you name none, it confirms your default before proceeding. That last rule matters more than it looks: it means an unqualified dispatch is interactive, not fire-and-forget.

Workers that ask questions instead of guessing

The most distinctive claim in the README is the question channel. When a worker gets stuck, the documentation states it does not silently fail or hallucinate; it asks a clarifying question, the dispatcher surfaces it to you, and after you answer, the worker continues without losing context. The README gives a concrete exchange: a worker reports that requirements.txt does not exist and asks what feature to implement, the user replies with a /health endpoint specification, and the answer is sent and the worker continues. This is the part that distinguishes dispatch from simply opening several terminals. With claude --background or fire-and-forget runners, the README argues, you are the orchestrator: you track what is running, check progress, notice failures, and context-switch between outputs. Dispatch moves that tracking into the dispatcher and reduces your job to describing what you want and answering questions when asked. Whether the question channel holds up under a long-running worker is not something the supplied material demonstrates, and I would treat it as the first thing to probe.

Install and the config file you will end up editing

Installation is two commands from the README. For a user-level install that applies to all projects, run npx skills add bassimeledath/dispatch -g. For a project-level install shared with a team, drop the -g flag and run npx skills add bassimeledath/dispatch. On first run, the skill auto-detects your CLIs (claude, agent, codex), discovers available models, and generates ~/.dispatch/config.yaml, so no manual config is strictly required. The README also recommends running /dispatch with no arguments at the start of a session to pre-load the config into the dispatcher's context, which it says makes later dispatches faster and avoids confirmation prompts. The configuration file has three sections, and the README shows the backends section, where each provider maps to a CLI command. The claude backend is given as env -u CLAUDE_CODE_ENTRYPOINT -u CLAUDECODE claude -p --dangerously-skip-permissions, and the cursor backend as agent -p --force --workspace. Read those commands before you rely on them. The claude entry unsets two environment variables and passes --dangerously-skip-permissions, which is a deliberate choice the README presents without comment.

Where dispatch is the wrong tool

Dispatch is a skill that runs inside Claude Code, and the README states this as a hard requirement: the host session plans tasks and spawns workers. Other CLIs such as Cursor and Codex work as workers only, meaning background agents that execute subtasks, not as the thing you type /dispatch into. If your team standardised on a different terminal agent, dispatch does not replace it as an orchestrator. There is a second constraint in the configuration. The backends section runs provider CLIs on your machine with flags such as --dangerously-skip-permissions and --force, which means the safety posture of a dispatched worker is whatever those flags allow. A worker with a fresh context window and skipped permission prompts is a good fit for a worktree where you can inspect the diff, and a poor fit for a task whose failure mode is an unreviewed write to a shared branch. The README's own example leans on worktrees for exactly the risky tasks, which is a sensible default you should copy rather than treat as decoration.

How dispatch compares with running claude --background yourself

The closest alternative is the one the README names: claude --background, multiple terminals, or a fire-and-forget agent runner. The difference is who holds the plan. With those tools you write the prompt, launch it, and then you are the one remembering which terminal is doing what, noticing when one has stalled, and carrying the question back and forth. Dispatch inserts a mediator that owns the checklist, tracks workers, surfaces questions, reports completions, handles errors, and offers recovery, in the README's phrasing. The trade is that you give up direct control of the worker loop and depend on the dispatcher's bookkeeping being correct. A second difference is model mixing. With raw background CLIs, switching providers per task is manual; dispatch treats model selection as part of the prompt, with auto-discovery when a name is not yet in config. Neither approach changes the underlying context limits of a single worker, so a task too large for one window is still too large.

Maintenance cost, licence and what the repository does not tell you

The supplied material does not include a licence file or licence identifier, so I cannot state the terms under which dispatch is distributed. That is worth resolving before you adopt it, because the install path writes a config file into your home directory and the backends it defines invoke other CLIs with elevated flags; if you plan to vendor the skill into a team repository, the licence is the first thing to check, and I am not in a position to give legal advice on which terms fit your situation. On maintenance, the config file is the surface you own. Providers change their CLI flags, and the backends section is where that breakage lands, so a provider upgrade is a config edit rather than a code change, which is a reasonable design. The repository metadata shows a last push of 2026-04-06 and no retrieved releases, so there is no versioned release history to pin against; you are tracking the main branch. The README also does not document what happens when a worker dies mid-task, how long worker state persists, or where that state is stored, so recovery behaviour is something to establish by observation before you depend on it.

Editorial conclusion

Adopt dispatch if Claude Code is already your host session and your bottleneck is context exhaustion from doing several unrelated tasks in one conversation. Do not adopt it if you need an orchestrator that runs without Claude Code, since the README states other CLIs such as Cursor and Codex work as workers only. Before committing, verify that first-run auto-detection actually finds your CLIs and writes ~/.dispatch/config.yaml, and check the backends section to confirm the exact command dispatch will run for each provider, including any permission-skipping flags.

Official sources

1. bassimeledath/dispatch on GitHub
2. Issues
3. README