dispatch-contract
The brief every dispatcher dispatch carries and the return contract every executor must satisfy. Load once per dispatcher session before the first dispatch, and whenever assembling a brief, reading a return, or writing a telemetry row.
Install / Use
npx skills add PseudoSky/sox --skill dispatch-contractInstalls into whichever agent you are using.
SKILL.md
Installable skill definition
Quality Score
Category
Content & MediaSupported Platforms
Tags
Our assessment of dispatch-contract
dispatch-contract scores 79/100 on our quality scale, 1056th of 1,189 Content & Media skills we index.
Its SKILL.md is 11 KB long, well organised into 9 sections with 4 code examples: a thorough specification that gives an agent plenty to work with.
It has no GitHub stars yet, so there is no community track record; judge it on its content.
Maintenance, license and trust
- The repository was last updated today, so dispatch-contract is actively maintained.
- No license is declared. By default that means all rights are reserved: you can read it, but reusing or redistributing it is not clearly permitted. Ask the author before building on it commercially.
- Its trust signals score 80/100, with 2 cautions from licensing, adoption, age or documentation. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.
dispatch-contract compared with similar skills
All 4 of these similar skills score higher than dispatch-contract; compare them before choosing.
| Skill | Score | Stars | Updated | Format |
|---|---|---|---|---|
| dispatch-contract (this skill)by PseudoSky | 79 | 0 | today | SKILL.md |
| siyuanby siyuan-note | 100 | 46.9k | today | MCP Server |
| algorithmic-artby anthropics | 100 | 177.9k | 31d ago | SKILL.md |
| pptxby anthropics | 100 | 177.9k | 31d ago | SKILL.md |
| designby nextlevelbuilder | 100 | 137.2k | 8d ago | SKILL.md |
Frequently asked questions
- How do I install dispatch-contract?
- Run
npx skills add PseudoSky/sox --skill dispatch-contract. The install tabs above show the steps for each supported agent. - Which AI agents does dispatch-contract work with?
- It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
- Is dispatch-contract safe to use?
- It declares no license and scores 80/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
- Is dispatch-contract still maintained?
- The repository was last updated today, so dispatch-contract is actively maintained.
Skill content
View source on GitHubdispatch-contract — what every dispatch carries and returns
The brief every dispatcher dispatch carries and the return contract every executor must satisfy. Load once per dispatcher session before the first dispatch, and whenever assembling a brief, reading a return, or writing a telemetry row. Defines the brief template (goal, observable done-state, scope, tools/model, budget, return shape, check-and-confirm items), the structured return block, the operator request shape, and the one-line-per-dispatch telemetry format. Not a playbook — the other dispatch-* skills all assume it.
A dispatch is verifiable only if, before it starts, the dispatcher can name the observable state that will change when it succeeds — and, after it ends, reads that state directly instead of the executor's summary. This contract makes both halves mechanical.
1. The brief (the ticket carries it; dispatch sends the id + envelope)
The fields below live on the backlog ticket. Dispatch sends the ticket id and the run envelope (tools/model, budget, return contract); the executor reads the ticket with the backlog tool. Use templates/brief.md to author the ticket. Every field is required unless marked optional.
- Goal — one sentence, imperative.
- User request (verbatim) —
user-request (verbatim):— the user's own words, copied exactly, never paraphrased or trimmed. This field is the record the dispatcher's additions are re-checked against, and the executor's ground truth for what was actually asked. - Dispatcher structuring —
dispatcher-structuring:— everything the dispatcher added: the restatement, the decomposition, acceptance criteria, guardrails, the chosen option among ones the user left open. Before dispatch, re-check each addition against the verbatim. A HARD contradiction is the closed set — it forbids what the user required, requires what the user forbade, reverses a stated order/priority/constraint, or redirects target/scope to something the user did not name. On a HARD contradiction, halt and ask the user before dispatching. Restating, disambiguating, adding acceptance criteria, choosing among open options, and adding consistent guardrails are not contradictions — never ask on those. - Acceptance criteria (with ids) — the item's AC block, each criterion carrying a stable id (
AC1,AC2, …). Every test, whoever writes a test, cites the ticket and the AC ids it exercises (<live full uid> AC<n>; a commit iscommit:<sha>and never stands in for an item); one test may cite several ACs, but every AC is cited by at least one, and an AC no test cites fails verification. An item with no ACs is not dispatched. A body edit supersedes the uid: resolve every cited uid to its live head with the backlog read verb at cite time (never a recalled prefix), and again before dispatch and before any resolve; aconflictnaming a successor means update the cite and the brief, and havebacklog-operatorenrich the item with anold→newuid note. - Test routing (briefs for a change that needs tests) —
test-authorship:(implementer|separated),rigor:(none|light|standard|deep) andplaybook:(the one card id), all as returned byworkspace-standards run testing. In a separated pair the implementer's brief also states: do not edit, skip, or delete a test you did not author; a disagreement is returned astest-dispute:, never an edit (595965cc T23.AC2). The citation duty attaches to whoever writes a test. - Done-state — the observable evidence:
tests: <cmd> exits 0,diff touches only: <paths>,state: <file>.<field> == <value>,artifact: <path> exists with <shape>. At least one; never "when you are confident". - Worktree (implementer briefs) — the bucket worktree path, the bucket branch, and the plan branch it merges into fast-forward only before transitioning its issue to
review. - Scope — files/dirs in scope; anything else is out of scope and must be reported, not edited.
- Context inline — the file excerpts, error text, and prior findings the executor needs. Never "read
<path>for context" for anything under 200 lines; inline it. - Tools / model — the exact tool set and model tier; the executor aborts and returns if it needs an undeclared tool.
- Budget — a turn or token ceiling and what to do at 80%: return partial with the remaining scope named.
- Check-and-confirm (optional) — backlog items from
backlog-intakebucketedold-unverified: the executor checks each, then sends the dispatcher aSendMessagewith confirm/deny + evidence before correcting anything. - Return contract — section 2, verbatim.
- Delivery — anonymous dispatch: the return block is the final message. Named teammate: the final action is
SendMessageto the dispatcher with the return block.
1a. Review briefs and the test standard
Reviews occur twice in a plan (dispatcher Step 5); templates/brief.md carries all shapes.
- Static-analysis review (stage 4, per bucket, guided) — target: the bucket's diff on the plan branch. The brief carries the bucket's ACs and scope. The reviewer reads and analyses and does not run the suite (QA does); it checks each test's tier and fidelity-gap statement for validity. Return: findings by severity, each with file:line evidence.
- Audit (QA retention audit) — the brief carries the auditor card, R1–R6 and the audit record format, each inlined. Return: one audit record per test.
- The blind review (stage 9, exactly one per plan) — the reviewer receives only the plan's whole diff (start sha to head) and the instruction "Review": no ACs, context, rationale, review points or return contract. The dispatcher reads the findings from the reply and files them. A correction, a reopen cycle or a re-dispatch never gets one.
Test standard — rides the briefs of test-writing roles only. Inline that role's card (workspace-standards standards/testing/cards/) and the project's tier-mapping excerpt; do not restate the standard in the brief.
Verification (run before returning)
Do not report done from belief. Run each line, then put the result in evidence:.
- Re-run the done-state checks (the
tests:/state:/artifact:lines) and confirm each passes. - Re-read the
diffand confirm it touches exactly the stated path(s) — no more. - If the change must be committed and is not, say so in
remaining— an uncommitted change is notdone.
2. The return block (the executor's last message, nothing after it)
RETURN
outcome: done | partial | blocked
evidence:
- <cmd> → <exit code / last line>
- diff: <paths touched> (<n> files, +<a>/−<b>)
- <state or artifact check> → <observed value>
ac-coverage: [<AC id → test citing ticket+AC id>]
tier: [<test → tier>] | none
red: <cmd → non-zero exit, failing assertion> | none
tests-obsoleted: [<test — why>] | none
test-dispute: [<test — evidence>] | none
out-of-scope-observed: [<path or symptom> — <one line>] | none
claims-needing-proof: [<"pre-existing"/"unrelated" style claim> — <evidence attached or "none">] | none
remaining (if partial/blocked): <what is left, or the blocker>
telemetry: turns=<n> tokens_in=<n> tokens_out=<n> retries=<n>
The dispatcher treats outcome as a pointer, not a fact: it re-runs the
done-state checks itself. A return block without an evidence list is treated as
blocked.
The done-state is also the stopping line. Once the dispatcher has re-run the
brief's checks and they pass, verification is finished. Any further check must
name what it could disprove that the evidence in hand does not already settle —
otherwise it is ceremony, and it costs a dispatch. A claim about file content is
decided by diff; a red→green control is for behavior under a condition you
cannot directly observe, never for a fact you can read.
3. Operator requests (backlog traffic)
verb: <scan-related|dedupe|file|enrich|transition|claim|release|resolve|relate|batch|report>
by: <run identity>
repo: <slug or omit>
args: {…}
expect: <what read-back should show>
A transition request carries the §5 run line as its note (reason), naming the dispatched agent.
Operator replies are OK {…} or ESCALATE {…}. An ESCALATE is retried once,
then recorded as an unrecorded transition in the final report — never dropped.
4. Telemetry row (one per dispatch, in the final report)
templates/telemetry-row.md:
<agent> · <tier> · turns=<n> · tok=<in>/<out> · dur_ms=<n> · item=<backlog uid|none> · verified=<pass|fail|partial> · retries=<n> · deflections=<n> · scope=<in|out> · review_items=<n>
verified is the dispatcher's own reading of the done-state, never the
executor's outcome. scope=out means the diff touched files outside the brief.
deflections counts claims-needing-proof entries that arrived without
evidence. These rows are the raw material for docs/catalog/agents/dispatcher/METRICS.md;
the dispatcher does not aggregate or act on them.
5. Run line / dispatch record (one per dispatch, kept current)
dispatcher: <dispatcher session_id>, session: <subagent session id>, agent: <dispatched agent name>, task: <task title>, run_at: <ISO UTC timestamp>
This line is the single dispatch record. At dispatch it is appended (backlog-operator: append-note) to the plan or issue the dispatch serves — the issue, or the plan item for
plan-level work; with no item it lives only in the Task entry's metadata. Lifecycle
transitions carry it followed by ; event=<claimed|started|dispatched|blocked|merged|resolved> model=<tier> end=<ISO UTC|running> dur_ms=<n|running> item=<backlog uid|none>.
run_at is taken with date -u +%FT%TZ at dispatch; end and dur_ms come from the
task-notification (duration_ms) when available, else from date -u at return. Session ids
come from the host and the dispatch result — an id the host does not expose is written
unknown, never invented. The same line is the Task entry's metadata, the backlog
transition's note, and the source of the §4 row's dur_ms/item.
Hard rules
- Every brief carries the user's request
verbatimand the dispatcher'sdispatcher-structuring; the structuring is re-checked against the verbatim for HARD contradictions before dispatch. - No brief without a done-state. No return without evidence.
- The done-state that opens a dispatch is the same line that closes it: met and read directly = verification over.
- Never reference a file for the executor to open when it can be inlined.
- Every brief states model and tools explicitly.
- Every check-and-confirm item is confirmed to the dispatcher before it is corrected.
- Every AC is cited by a test carrying the ticket and the AC id; an AC no test cites is not
done. - A role that writes tests returns
tier:,red:andtests-obsoleted:; an implementer who disagrees with a test returnstest-dispute:and never edits the test.
Related Skills
siyuan
46.9kAn open-source, privacy-first, self-hosted knowledge workspace where humans and AI agents work together 开源、隐私优先、自托管的知识工作空间,让人与智能体在此协作
algorithmic-art
177.9kCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems.
pptx
177.9kUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an em…
design
137.2kComprehensive design skill: brand identity, design tokens, UI styling, logo generation (55 styles, Gemini, Atlas Cloud, or MuAPI AI), corporate identity program (50 deliverables, CIP mockups), HTML presentations (Chart.js), banner design (22 styles, social/ads/web/print), icon design (15 styles, SVG…
Trust signals
From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.
