bryanthaboi

List work order ids and statuses via MCP workorder_list for a date and repo (optional issue). Use for one track (--issue) or all issues under a repo (omit issue).

How to use Dockyard in this chat: work orders live under DOCKYARD_ROOT (default ~/.dockyard). Dockyard exposes MCP tools named workorder_* — not MCP resources, so “list resources” will not show Dockyard. Prefer tool calls for workorder_list_pending / workorder_get / workorder_complete; if tools are missing, use the dockyard CLI or enable MCP via dockyard install-agents and restart the host app. Use when the user says to use Dockyard, drain the queue, or complete work orders.

Mark a Dockyard work order complete in index.json via MCP workorder_complete. Use after the work described in that WO is done and verified; requires date, issue slug, and wo-NNN id.

Load one Dockyard work order’s markdown and status via MCP workorder_get. Use when the user asks to read, review, summarize, or execute a specific WO identified by date, issue slug, and wo-NNN id.

Create a new Dockyard work order on disk via MCP tool workorder_insert. Use when the user wants to queue structured agent work, split a feature into trackable units, or log tasks under a dated issue slug. Requires markdown body with sections from ## Objective through ## Notes; see references/work-order-body-template.md.

List incomplete Dockyard work orders via MCP workorder_list_pending. Use when driving a queue, standup summaries, or “what’s left” across all issues; optional filters date and/or issue. Results sort by date, issue, then WO number.

Read the next 1-based work order sequence number for a date/issue via MCP workorder_next_number. Use when drafting titles or planning how many WOs to create before calling workorder_insert (the server still assigns the canonical id on insert).

Run MCP tool workorder_validate_output on a code string before committing or pasting into product repos. Use when Dockyard workflow requires checking generated code for forbidden substrings (best-effort lint). Triggers when the user wants leakage checks, “sanity check this patch,” or policy compliance on emitted source.

Use whenever you are running as one of several parallel sub-agents and may touch shared files, share work with peers, or need to coordinate intent. Wires you into AOL — the per-repo coordination MCP — so you announce online status, claim files before editing, wait on conflicts, and post short coordination messages instead of stomping on each other.