dispatch-tickets

Files (1)

• SKILL.md

SKILL.md (first lines)

# Dispatch Tickets

Supervise a Mission of multiple selected Tickets on the user's behalf. Each
[orchestrate](../orchestrate/SKILL.md) owner handles one Ticket's technical
work; you maintain the authorized queue, track progress and elapsed time,
support its responsible agent, and verify delivery. Read tracker and repository
evidence for those decisions. Implementation and review stay with the Ticket
owner under `orchestrate`'s review policy, not with the dispatcher.

For an untracked request or only one selected Ticket, follow
[orchestrate](../orchestrate/SKILL.md) in the current conversation instead of
launching a dispatcher or another owner. The maintainer's absence does not
change that route. Once a multi-Ticket Mission is underway, keep supervising it
through its agreed boundary even when only one Ticket remains.

Use the environment's existing subagents or
[tmux-worker](../../productivity/tmux-worker/SKILL.md). This is an agent
workflow described in Markdown, with ordinary notes when useful; it needs no
coordination code or runtime service.

Before reading any relative link, run
`python3 -c 'from pathlib import Path; import sys; print((Path(sys.argv[1]).resolve().parent / sys.argv[2]).resolve())' '<loaded-file-path>' '<relative-link>'`
with this file's actual path and the link, then read the printed path. Resolve
pointers before passing them to a fresh agent. Read
[model-routing](../../productivity/model-routing/SKILL.md) before
model-selectable launches; apply explicit routes and the active harness's
authorization and inheritance rules.

## 1. Establish the Mission

Resolve from the request and accepted sources:

- The finite set of selected Tickets, repository/tracker identities, scope, and
  completion boundary. A list, prose plan, or existing phased JSON plan can
  supply them. Several files or subtasks inside one request do not by themselves
  make a multi-Ticket Mission.
- The execution plan recorded in the Tickets or their incorporated sources:
  planned concurrency, required order, blocking/conflict relations, shared
  resources, and delivery targets. Distinguish priority from a required sequence
  or phase barrier.
- The authorized stopping point and maintainer availability: `Assisted` for
  ordinary Questions, or `Unattended` for continuing within established
  decisions while the maintainer is away. Reuse those choices from the request.
  Absence alone does not require an audit or another approval.
- Existing owners, conversations, candidates, completed deliveries, and the
  permitted recovery scope. Check ongoing work before starting another owner.

Read the configured tracker operations and repository instructions. If required
configuration is missing, follow [setup-omskills](../setup-omskills/SKILL.md)
within its setup authorization. Read selected Tickets and their relations to
determine eligibility. Follow external references as dependency evidence without
adding them to the selected work. The Ticket owner rechecks its complete
contract and applicable execution gates before implementation.

Follow the recorded execution plan and Ticket relations.
[to-tickets](../to-tickets/SKILL.md) owns the concurrency decisions and delivery
boundaries; dispatch checks live prerequisites and capacity before carrying them
out. Resolve a mismatch with the accepted plan before affected starts rather
than silently changing its required topology.

Keep a concise Mission record: selected Tickets, order/relations, owner and
conversation reference, candidate location, start time, last observed progress,
next check or action, blockers, and delivery evidence. Use the current
conversation or an ignored local Markdown note as appropriate. Durable
requirements and delivery history belong in the configured tracker; private
operational notes remain private.

This step is complete when the selected queue, availability, constraints, and
current ownership are known, or a specific missing decision prevents safe
dispatch.

## 2. Start or resume eligible owners

Check live dependency delivery, conflicts, existing ownership, and capacity
before each start. A closed issue or a ready label alone does not establish
delivery or authorization. Apply readiness or Prompt Audit gates when required
by the accepted task or repository, not merely because the maintainer is away.

For a new Ticket, start one fresh responsible conversation with the resolved
`orchestrate` path. Supply:

- Ticket identity, repository/workspace, accepted scope and governing-source
  pointers;
- availability, relevant user decisions and routing instructions;
- dependency results and changes already integrated that affect this Ticket;
- delivery boundary, required checks, shared-resource ownership, and any
  existing candidate;
- the chosen result channel and evidence expected at delivery or a blocker.

The owner investigates, implements, tests, completes the applicable review,
adjudicates, corrects, and delivers. Purely editorial documentation may be
self-reviewed; code, behavior, and governing-authority changes require the
independent pass specified by `orchestrate`. Give the owner the capabilities
for its work and any required reviewer within actual harness limits. A role
name is not a capability grant.

For a paused Ticket, prefer the same conversation and candidate. Send the
resolved blocker, accepted decisions, and relevant intervening deliveries.
Revalidate affected contracts and gates before resuming implementation. Keep one
active owner for each candidate.

Use the transport's supported concurrent launch path for planned parallel work.
Managed direct calls return through their pending calls; after asynchronous
submissions, retain each owner/session identity and release the turn for
completion events. Unknown acceptance calls for evidence recovery, not a
duplicate start. For visible workers, agree on a result artifact or supported
event through `tmux-worker`, preserving the user's editor and worker
conversations.

This step is complete when each chosen Ticket has one known owner and result
path, or its launch/resumption has a concrete unresolved outcome recorded.

## 3. Maintain continuity

On a result, user message, or authorized reminder, inspect the evidence needed
for the next decision:

- **Progress and elapsed time:** compare time spent with the task, last observed
  progress, and any agreed checkpoint. When progress is unclear or a checkpoint

From luizomf/omskills, MIT.

More from luizomf/omskills