Skip to content
AgentDock

Using AgentDock

Task queue

GitHub issues as the queue, ready labels and blockers.

AgentDock has no task tracker of its own. The orchestrator's queue is the project's open GitHub issues that carry the ready label, and the Queue page shows that queue the way the orchestrator sees it. Open it from Project → Queue.

GitHub stays the editor: you label, edit, close and prioritise issues there. The only write the Queue page offers is filing a new issue.

How an issue gets into the queue

An open issue is in the queue when it carries the project's ready label. The label is, in order:

  1. the project's Ready label override (Settings → General);
  2. orchestrator.readyLabel from the project's .code-analyzer-config.json;
  3. cs:ready.

Add the label on GitHub, use /code-sentinel:issue --ready or /code-sentinel:spec in Claude Code, or click New issue on the Queue page. See Writing specs for how to write an issue the orchestrator can dispatch.

States

Every queued issue gets one state, computed with the same rules as the orchestrator's own triage. The first rule that matches wins.

StateWhenWhat clears it
in_flight (IN FLIGHT)An open pull request says Closes #n (or Fixes, Resolves), a live slot works on the issue, or the issue has cs:in-flightThe pull request merges or closes
blocked_person (BLOCKED, person)The issue has cs:needs-person, or its body has a Gate: lineA person answers and removes the gate
blocked_work (BLOCKED, work)A Depends on #m line points at an issue that is open, or was closed without a merged pull request#m is closed by a merged pull request
no_spec (NO SPEC)The body has no acceptance criteria, a bug has no reproduction, or a size: XL / size: XXL issue has no ## Parallel planEdit the body on GitHub
ready (READY)None of the aboveThe orchestrator dispatches it

Each row also shows the reason, what would clear it, and the priority. The list is ordered like the orchestrator orders it: priority: critical, then high, then medium, then unlabelled, then by lowest issue number.

Body conventions the queue reads

Issue body
Depends on #41
 
## Acceptance criteria
- [ ] Exports a CSV of the filtered rows
- [ ] An empty filter exports every row
 
## Parallel plan
| Slot | Owns | Touches | Depends on | Lead | Model |
|---|---|---|---|---|---|
| i42-api | apps/api/src/export/** | apps/api/src/app.module.ts | none | yes | opus |
  • Acceptance criteria: a ## Acceptance criteria section with at least one - [ ] item. A bug instead needs ## Steps to reproduce or ## Reproduction.
  • Depends on #m: read only at the start of a line, outside code fences, and never as owner/repo#m. A dependency closed by hand, without a merged pull request, still blocks.
  • ## Parallel plan: the slot table that cs-spec writes. AgentDock does not recompute waves; it lists the slot names, lead and model under the issue.

The orchestrator's verdict wins

The orchestrator writes its own verdict for each issue on its round board. When that round is newer than the last change to the issue, the Queue page shows the orchestrator's state and reason, and marks the source. If AgentDock's own computation disagrees, a muted note says what AgentDock computed. This keeps one brain: the orchestrator.

Held for a lead, below the list, comes only from the orchestrator's latest round. It lists slots waiting for a lead slot to merge first, and when they will dispatch.

List and Board views

Switch between List and Board in the toolbar. The board has five fixed columns, one per state. You cannot move cards: state comes from GitHub and the orchestrator, never from the UI.

Click an issue to open its sheet: the body, its blockers with links, its parallel-plan slots, its state in recent rounds, and a link to GitHub. Filter chips narrow the list by state. Refresh (operators) asks the runner to poll GitHub now.

Create an issue

Operators can click New issue. The dialog has Title, Body, Labels and a Queue for the orchestrator switch.

  • The runner files the issue with its own gh (gh issue create --repo <owner/repo>), so it is authored by the GitHub account signed in on that machine.
  • Queue for the orchestrator adds the ready label only when the body is complete enough to dispatch: it has acceptance criteria, and a size: XL issue has a parallel plan. Otherwise the switch is disabled and the dialog says what is missing.
  • Labels are limited to labels that already exist on the repository's issues, plus enhancement and bug. The ready label itself cannot be picked by hand, so the completeness rule cannot be skipped.

Every created issue is audited with its title, labels and whether it was queued.

How fresh the queue is

The runner's issues collector polls GET /repos/<owner>/<repo>/issues?state=open through gh, with an ETag, so an unchanged queue costs no GitHub rate limit.

SituationPoll interval
Default60 seconds
Your settingqueue.pollSeconds in runner.json, from 15 to 3600
GitHub App installed and healthy for the project10 minutes, because push events trigger an immediate poll

With the optional GitHub App, GitHub tells AgentDock when an issue, pull request or check changes and the runner polls at once. If GitHub stops reaching you, the runner falls back to 60 seconds. Nothing breaks either way.

Open pages update live: a change in the queue reaches the browser within a few seconds of the next poll.

Who can do what

ActionMinimum role on the project
See the queue and issue sheetsviewer
Refresh, create an issueoperator

A user who is not a member of the project gets a 404, as if the project did not exist.

Next steps