agentsclimarketplace
Sign in

Dispatch

Skill arendon1/agent-skills/process/dispatch

Dispatch fresh subagents for independent tasks, with two-stage review (spec compliance, then code quality). Use when a plan has independent tasks that can run in parallel, or when a task is large enough to benefit from an isolated subagent. Use when the user says "parallel", "dispatch", "subagent", or when the plan has independent tasks, or when a task is large enough to benefit from isolation.From its SKILL.md

Install
npx -y skills add arendon1/agent-skills --skill dispatch

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

dispatch — parallel subagents with two-stage review

Dispatch fresh subagents for independent tasks. Each subagent gets isolated context (you construct exactly what it needs — it never inherits your session's history), implements its task, and commits. Then a two-stage review: spec compliance, then code quality. A broad final review at the end.

WHEN (self-trigger)

  • The build loop detects a parallelizable set in PLAN.md §N.
  • The user says "parallel", "dispatch", "subagent", "run these concurrently".
  • A task is large enough to benefit from an isolated subagent (high context cost if done in the main thread).

Skip when tasks are tightly coupled — single-thread build is better then.

WHY SUBAGENTS

You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed. They never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.

Core principle: fresh subagent per task + task review (spec + quality) + broad final review = high quality, fast iteration.

CONTINUOUS EXECUTION

Do not pause to check in with the user between tasks. Execute all dispatched tasks without stopping. The only reasons to stop: BLOCKED status you cannot resolve, ambiguity that genuinely prevents progress, or all tasks complete. "Should I continue?" prompts and progress summaries waste the user's time — they asked you to execute, so execute.

THE PROCESS

Per task

  1. Construct the implementer prompt. Give the subagent exactly: the task (§T.n row from PLAN.md), the cited invariants (§V) and interfaces (§I) it serves, the test it must pass (from the task's test column), the relevant code paths, and the commit convention. Do NOT give it your session history.
  2. Dispatch the implementer subagent. It implements (via tdd), tests, commits (conventional commit T<n>: ...), and self-reviews against the task spec.
  3. Write a diff file of what the subagent did.
  4. Dispatch the task-reviewer subagent with the diff + the task spec. Two-stage review:
    • Spec compliance — did the subagent do what §T.n + §V + §I require?
    • Code quality — does the code verify behavior through public interfaces, respect invariants, avoid shallow abstractions?
  5. If the reviewer reports Critical/Important findings: dispatch a fix subagent with the findings. Repeat until the reviewer approves.
  6. Mark the task [x] in PLAN.md and record progress in the ledger.

Broad final review

After all tasks complete, dispatch a broad whole-branch reviewer that checks the cumulative diff against the full plan (not task-by-task). This catches integration issues single-task reviews miss. Hand the final review's findings to the review loop if any are BLOCK.

IMPLEMENTER PROMPT — what to include

Construct the subagent's context precisely. Include:

  • The exact §T.n row (task, cites, test, blocked-by).
  • The full text of every cited §V invariant and §I interface.
  • The relevant CONTEXT.md terms (canonical names it must use).
  • The relevant code paths (file:line) it will touch.
  • The verification command (the oracle) it must run.
  • The commit convention: T<n>: <goal line> (<§V cites>).
  • Instruction to use tdd (failing test first), then verify before claiming done.

Do NOT include: your session history, other tasks' context, or your own hypotheses about how to implement. The subagent implements fresh from the spec.

TASK-REVIEWER PROMPT — the two stages

  1. Spec compliance: Does the diff satisfy every cited §V? Does it preserve every cited §I shape? Does the named test exist and pass? Cite evidence (file:line) for each claim.
  2. Code quality: Do the tests verify behavior (good) or implementation (bad)? Are there shallow abstractions? Hidden coupling? Missing error handling for the edge cases §V names? Cite evidence.

Findings classified: Critical (blocks merge) / Important (should fix) / Minor (note). Critical/Important -> fix subagent. Minor -> note in the ledger.

BOUNDARIES

  • MUST construct each subagent's context precisely (no session-history inheritance).
  • MUST run the two-stage review (spec compliance + code quality) per task.
  • MUST run the broad final review at the end.
  • MUST NOT pause for user check-ins between tasks (continuous execution).
  • MUST stop only on BLOCKED, ambiguity, or all-complete.
  • MUST hand BLOCK findings to the review loop.
  • MUST use caveman for the ledger and CONTEXT.md canonical terms in prompts.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most plan spec skills give in ~1.1k tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • Prefer AFK slices over HITLin 22 of 1099, across 7 files
  • Write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • construct each subagent context precisely
  • exclude session history from subagent context
  • run the two-stage review per task
  • run the broad final review at the end
  • hand BLOCK findings to the review loop
  • use canonical terms in prompts

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,758. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.