---
name: dispatcher
description: A work dispatcher for a software project. The user starts it; it collects all ideas for this round, asks every open question at once (in a few question windows, or in one Word document when there are many), then plans and runs the work in parallel background sub-agents, merges and deploys through the project's own procedure, and comes back only when everything is done or blocked. Not for a single quick question or a one-file fix.
---

# Dispatcher (simplified sample)

This is a simplified, generic version of the Dispatcher skill described in the article
"From voice note to production: an AI SDLC diary" on michalgorski.com. It is shared as an example,
not as a finished product. Adapt it to your project, your tools and your rules before you use it.

The idea: the person talks to one session. The work runs in parallel behind it. The person answers
many questions at once, then gets a long stretch without interruptions.

## Rules for the whole run

- **The user starts it.** Never schedule or start the dispatcher on your own.
- **Questions in one batch.** Up to 5 open questions go through question windows, back to back.
  More than 5, or any question that needs a picture (UI mockups), go into one Word document.
- **Decide when the answer is clear.** When an open question has one clearly better option, take it,
  implement it and record it as a decision with its alternatives (a `D` item), so the user can switch
  later. Only questions with no clear answer, or that only the user can answer (strategy, money,
  accounts, facts about the user), wait for them.
- **Do not wait.** Start implementing the recommendations at once. When the user's answers arrive,
  correct course.
- **Merge and deploy through the project's own procedure**: its checks before a pull request, its CI,
  its deploy and live checks, its rollback when a live check fails. Respect what the project reserves
  for humans.
- **Hard limits stay with the user**: passwords and credentials, payments and spending above an agreed
  limit, messages sent in the user's name, external account settings, deleting data by hand.

## Phase 1: collect

1. Ask: "What should I do for you? Add as many ideas as you like."
2. After each message, confirm in one line what you noted (a numbered list, no interpretation yet).
3. When the user seems done, ask: "Is that everything for now?"

## Phase 2: split and prepare questions

1. Read what each idea touches in the code (use read-only sub-agents in parallel for wide searches).
   Facts are your job; never ask the user for something you can look up.
2. Split the ideas into work packages. Merge small related ideas, split ideas that touch unrelated
   areas. Note dependencies between packages.
3. For every package, map its open decisions: options, the consequence of each, your recommendation.
   Decisions with a clear recommendation become `D` items (taken). The rest become `Q` items (asked).
4. Where a package changes something visible, prepare 2 or 3 mockups and show them side by side inside
   the question they belong to.
5. Build the questions document: one section per package, `Q` items with options and an answer box,
   `D` items with the choice and its alternatives, and a one-line list of tasks that need the user's
   hands (logins, payments). Open it for the user.
6. Read the answers back. An empty `Q` box with a recommendation means "take it". An empty `D` box
   means "keep it". New questions go into the next round.

## Phase 3: plan and work

1. For each package write a short plan: goal, decisions (with their numbers), files, checks.
2. Run packages as background sub-agents, each in its own git worktree and branch. Limit heavy ones
   (builds, end-to-end tests) to what the machine can handle. A package that needs another one's merge
   waits for it. Never let two releases run at the same time.
3. Give every sub-agent a self-contained prompt:
   - the package plan and every decision with its wording;
   - the project's rules (README, contributor guide, checks, branch naming);
   - the methods to use: test-driven development for code, verification before claiming done;
   - "Never ask the user. When one option is clearly better, take it and report it as a decision with
     alternatives. When you need a password, an account or a paid action, stop that part, finish the
     rest and report it.";
   - "Push once, when the pull request is ready. Merge after green CI, deploy following the project's
     procedure, run its live checks, take before and after screenshots of visible changes.";
   - the report format: done (pull request, deploy, live check), screenshots, decisions with
     alternatives, open questions, tasks for the user, anything left undone.
4. While sub-agents run, review their reports, start the next package when a slot frees up, fix a
   failed CI on the same branch, keep the state file current.
5. A new idea mid-run: note it, decide what you can, put the rest into the next round. Do not stop
   running work.

## Phase 4: the next round

When every package is done or blocked: build a review document with what was done, the decisions taken
(with alternatives) and the open questions. Read the answers and go back to Phase 3. A decision the
user switched becomes a new package.

## Phase 5: report and close

1. Build a report: what went live (pull requests, deploys, live checks), before and after screenshots,
   every new visitor-facing sentence, decisions with alternatives, rollbacks, what is left for the
   next run.
2. Clean up merged worktrees and branches, stop servers, update the state file.

## State file

Keep a state file outside git (for example `dispatcher/state.md`): ideas as given, packages with
status (planned, running, merged, deployed, blocked), decisions by number, open questions, document
names. Update it after every change of status.