SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdispatch-loop

dispatch-loop

Agents & models

View repository

Updated 10-15 19:58

About this skill

/dispatch-loop — delegation advance loop

Source: an interaction pattern proven effective in the 2026-07-10 simpleinfo-f2e session (28 steps, ~5M subagent tokens, completing Phase 0–5 in full). Core:The main model does not take the field; it only commands, adjudicates, and spot-checks。

Role division

  • Main model: reads plan state-machine output, writes dispatch prompts, spot-checks reports, makes visual/design decisions, HITL, scarce-quota MCP calls (single call, dispatch after writing to file)
  • Sonnet agent: general implementation, research, mechanical file edits, document organization
  • Opus agent: complex implementation, deep review, difficult debugging
  • Agent tool Explicitly carry the model parameter, do not let agents inherit the main model — inheritance means every agent consumes main-model quota

Loop steps (each plan step)

  1. plan_runner.py start <plan> <step> --task-id=<id>(TaskCreate/TaskUpdate sync, best-effort)
    • That script is under the /plan-run skill's repo checkout ;npx skills the snapshot only syncs SKILL.md, and does not carry down scripts/
  2. Dispatch: use the "dispatch prompt skeleton" below; the prompt must include goal/motivation/scope/acceptance criteria/report format; for large materials such as design mockups give thefile pathinstead of pasting content
  3. Dispatch steps in the same working tree sequentially(modifying the same files together and sharing a lockfile will conflict); only run in parallel when truly independent and not modifying files
  4. Spot-check reports(do not trust self-reports): files exist ls, key content grep、git log comparison, testsrun personallyonce; only after the spot-check passes complete, send back or add verification for doubts
  5. Decide whether to complete: if the spot-check passes, move on to step 6; if it does not pass plan_runner.py fail <plan> <step> --reason=..., send back for dispatch or add verification
  6. KB gate before recycling: after the agent reports are all collected, complete two things in order before recycling; the order is fixed and cannot be reversed: (a) Lessonswritten into the KB — session file (_pending/), mature lessons go into wiki/learned/； (b) Summarywritten into state with plan_runner.py complete <plan> <step> --summary="..." --evidence=<路徑> ... — this single command completes both recording and marking complete; for how to write it, see "Summary writing guidelines" below

Summary writing guidelines

--summary All four items must be written in order; even with no content, write "none"; they must not be omitted:

  1. What was done (the result, not a running log)
  2. Where it deviated from the plan text and why (e.g. "the Action says vitest, but in practice the repo's existing jest was kept")
  3. Accepted side effects or known limitations
  4. To-dos deferred to other steps (mark the target step ID)

Maximum 500 characters; after normalization, anything over will be rejected (rc=1, not truncated), so shorten it yourself and send again; put verbatim evidence in --evidence=<路徑>(repeatable, not comma-split), do not stuff it into the summary body. The summarywill notappear in subsequent delta output or Stop hook reason, so there is no need to deliberately write it so short that information is lost just to save tokens — especially items 2 and 4; losing them means it was written for nothing. Received locked If there is an error, rerun the same command; do not change the approach or skip it.

/plan-run Under init always include --require-summary, summary required:next/the ok: line printed by the hook carries the placeholder string --summary="<1.做了什麼 2.偏離plan 3.副作用 4.延後待辦>", which is only a format reminder and must not be copied and submitted as-is—it must be replaced with the four actual items for this step, otherwise it will be rejected (rc=1).

Example:

plan_runner.py complete plans/active/foo.md S3.2 \
  --summary="1. 改寫 dispatch-loop 第 6 步與新增摘要撰寫指引；2. 無偏離；3. 無已知限制；4. README 其餘 plan-run 段落留給後續 step" \
  --evidence=dispatch-loop/SKILL.md --evidence=README.md

Dispatch prompt skeleton

Fill in all six slots for each dispatch; if one is missing, do not send it yet:

目標：{做什麼，一句話可判定}
動機：{為什麼要做、這結果拿去幹嘛}
範圍：只動 {檔案/目錄}；不碰 {明確排除項}
既有慣例：先讀 {參考檔案}，比照命名、import、錯誤處理、註解密度
驗收條件：
- {具體可判定條件，例：`pnpm test` 全綠、新增測試覆蓋 {行為清單}}
- build 通過（{指令}）
回報格式：
- 改了哪些檔（路徑:行號範圍）＋每檔一句話
- 驗收條件逐條標 PASS/FAIL，附指令輸出關鍵行（不是「應該會過」）
- 禁止流水帳；全文 ≤30 行

Type fine-tuning:

  • Search and locate：agent Explore、model haiku(if the scope is vague or spans multiple naming conventions, escalate sonnet); require each item to include 檔案:行號, and list the search patterns tried so people can judge whether anything was missed
  • Implementation：agent general-purpose、model sonnet; acceptance criteria must include tests and build commands
  • Refactor/batch file changes: same as above (mechanical application of an already-decided pattern may lower haiku); list the transformation rules verbatim and explicitly state "do not fix other issues along the way; if you see a suspected bug, note it and report back"; when files will be changed in parallel with other agents, add isolation: "worktree"
  • Research and verification：model sonnet; source priority: official docs > source code > issue/changelog > blog, attach a source to every claim, and if it cannot be found, explicitly write "not found" rather than speculating to fill gaps
  • Review and acceptance: the reviewer must bea fresh context that did not participate in the implementation; hard-code at the start "you are the acceptor, default to suspicion, and the output is the places that do not meet the acceptance criteria, not an endorsement"; end with a one-line overall verdict ACCEPT / REJECT

General rules:

  • If a slot is uncertain, it is better to write one more sentence of rationale than to leave it blank
  • When dispatching, also think about "how I will verify its report";do not send dispatches whose verification method is unclear
  • Send multiple mutually independent dispatches in parallel in the same message
  • Dispatch prompt explicitly state "execute it yourself; delegation is prohibited"(see the empirical lessons below for the reason)

Obligations of the main model after dispatch: when a report is received, first verify the format (whether the acceptance criteria have PASS/FAIL item by item, whether claims have sources); if missing, send it back for re-reporting and do not fill in the gaps yourself; for anything involving a commit, personally git diff compare; for failed dispatches, record the trajectory (prompt + output + failure reason) before escalating.

Token discipline (the reason this skill exists)

  • In the plan, mark each step with [expected number of agents × model tier × estimated tokens], with phase subtotals + full-plan total
  • If a single step exceeds budget by 2x → stop and re-estimate; do not add more dispatches to fill gaps
  • Trim review gates according to "risk × irreversibility": low-risk steps need only a single verification; only core logic/irreversible operations should stack multiple reviews
  • Order-of-magnitude reference (measured on 2026-07-10, small landing page project):
    • A single implementation step ≈ 60–130K subagent tokens
    • headed verification step ≈ 100–200K
    • 30-agent formation code review ≈ 1.6M—over-engineered for a small repo, roughly equal to half the sum of all implementation steps
    • When the repo is <5K lines, review with a single reviewer agent or a small formation of ≤4 angles
  • Use SendMessage to follow up with an existing agent (include agentId); do not dispatch again

Empirical lessons (known pitfalls under this pattern)

  • The dispatch prompt explicitly states "execute personally, no further delegation": a general-purpose agent may reassign the task to a background agent it spawns and then end immediately—that background agent becomes an orphan (its completion notification cannot return to the main conversation), and the task silently evaporates.
  • The main model's visual judgment must not use thumbnails: first magnify 3x + pixel sampling before drawing conclusions (the Figma dark canvas will be misread as UI elements); when agent measurements conflict with subjective impressions, use live sampling to adjudicate and do not stubbornly insist.
  • Real regressions exist that jsdom cannot detect (the pointer capture case): UI behavior changes must be supplemented with headed verification; unit green ≠ behavior correct.
  • Subagent reports will look polished but need spot-checking (verification cannot self-verify); screenshots produced by headed verification steps should be kept in the scratchpad for downstream steps to use.
  • Materials are lost after compaction: first retrieve the session transcript jsonl (grep old tool results, restore user-pasted images from base64), then consider reacquiring them.
  • Calls to scarce-quota MCPs (such as Figma Starter) are not delegated to agents—agents may retry and make multiple calls; make a single call in the main conversation, and dispatch work only after the artifact is saved to a file.